Asuro Simulieren

Hier gibt es einen Robotersimulator in Java, der einen Asuro simuliert.

Man kann den Code für den Asuro im Simulator in Java schreiben. Der Code für den Roboter findet sich im File "AsuroProgramm.java".

Das sieht dann Beispielsweise so aus:

Code:

---

/*******************************************************************************************

*

* Beispielprogramm für Asuro Simulator

*

*

* Blinken und im Kreis fahren

*

*

* Bedienhinweis:

* Zum Ausführen des Programms muss das File in "AsuroProgramm.java" umbenannt

* werden. Danach muss das Programm compiliert werden. Das geht in der Kommandozeile

* mit "javac AsuroProgramm.java" oder durch anklicken des Batch-Files "makeprog.bat"

* Gestartet wird der Simulator dann durch anklicken von "start.bat".

*

* robo.fr, May 2010

*

*******************************************************************************************/

       

        private void blinken(int k)

        {

                int n;

                for(n=0;n<k;n++)

                {

                        asuro.MSleep(500);

                        asuro.StatusLED(LedColor.GREEN);

                        asuro.MSleep(500);

                        asuro.StatusLED(LedColor.OFF);

                }

        }



        public void asuroMain()

        {

                blinken(2);       

               

                asuro.SerPrint("Asuro Simulator ready !!");

               

                while(true)

                {

                        // Motoren einstellen: linker Motor etwas schneller

                        asuro.MotorSpeed(100,100);

                        asuro.MotorDir(AsuroMotor.FWD,AsuroMotor.FWD);

                       

                        // so lange fahren, bis Hindernis kommt

                        while(asuro.PollSwitch()==0);

                       

                        asuro.PrintInt(asuro.PollSwitch());

                       

                        asuro.StatusLED(LedColor.RED);

                       

                        // zurückfahen

                        asuro.MotorDir(AsuroMotor.RWD,AsuroMotor.RWD);

                        asuro.MSleep(500);

                        asuro.StatusLED(LedColor.OFF);

                       

                        // drehen

                        asuro.MotorDir(AsuroMotor.FWD,AsuroMotor.RWD);

                        asuro.MSleep(500);

                       

                        // Motoren ausschalten

                        asuro.MotorDir(AsuroMotor.BREAK,AsuroMotor.BREAK);

                        blinken(1);       

                }

        }

---

Hallo robo.fr,

tolles Programm, dass Du da geschrieben hast, insbesondere weil man die Spielarena beliebig gestalten kann!

Hab etwas damit rumgespielt, und den Code um eine Kollisionserkennung erweitert, sodass der Robi nicht durch eine Wand fahren kann, selbst wenn er das will. Dazu wird der Roboter in ein seperates Bitmap gezeichnet und die Pixel mit den Pixeln des hintergrundbildes verglichen. Bei einer Kollision bleibt der Roboter einfach stehen, ansonsten wird seine Position auf den neu berechneten Wert gesetzt.

Damit die Bewegungen nicht mehr so zackig sind, haben beider Rädes der Roboters jetzt jeweils eine eigene tatsächliche Geschwindigkeit. Diese passt sich bei jedem Bewegungsschritt der Soll-Geschwindigkeit aus MotorSpeed() stück für stück an, sodass der Eindruck von Trägheit entsteht. Der Anpassungsfaktor (Robot.accel_fact) kann frei eingestellt werden.

Cool wäre es, wenn man auch die Helligkeitssensoren simulieren könnte, damit auch Linienverfolgung möglich wäre.

MfG Mark

Edit: die Helligkeitssensoren funktionieren jetzt auch, es wird die durchschnittliche Helligkeit der Pixel eines 3x3 Blocks des Hintergrundbildes berechnet. Wände zur Kollisionserkennung müssen Rot sein, ansonsten werden sie nicht als solche erkannt.

Hi Mark,

super, dass Du etwas weiter programmiert hast. Ich dachte schon, es interessiert sich keiner dafür.
Morgen werde ich mir Deine Änderungen mal genauer anschauen.


Bester Gruß,
robo

P.s.: Für die Begrenzungen hatte ich die Farbe rot gewählt ( also quasi die Gegenstände, die aus der Ebene herausragen, für die Tastsensoren ), die Helligeitssensoren könnten theoretisch auf alle anderen Farben reagieren.

Hi,

leider kann ich da nicht viel beitragen - nur eine (vieleicht auch dumme) Frage:
Es gibt doch für den ct-bot (den ich mir mal zulegen wollte) einen fertigen und angeblich auch erweiterbaren Simulator. Wäre es nicht sinnvoller und vieleicht sogar einfacher, dafür einen virtuellen Asuro zu programmieren? In irgendeiner ct war mal so eine Möglichkeit erwähnt...

lg,
Martin

Den gibt es. Er arbeitet allerdings mit einer Java3D Library und ist ziemlich aufwendig. Ich finde es besser, selbst einen Simulator zu bauen, dann kann man alles so machen, wie man es wirklich braucht.
Der Simulator in der jetzigen Form ist ziemlich einfach, deshalb kann man ihn viel einfacher Erweitern als den ct-bot Simulaotr.

Hallo Mark,

Deine Erweiterungen finde ich sehr gut. Ich habe die einzelnen Methoden von Dir kommentiert und mit Kommentaren versehen. Deinen Nickname habe ich in die Beschreibungen eingetragen.

Für eine Erweiterung des Simulators wäre es meiner Meinung nach sehr toll, wenn man mehrere Roboter oder Gegenständer simulieren könnte. Dann wäre es möglich simulierte Roboterwettkämpfe zu machen.
Man könnte vielleicht so etwas wie diesen Wettkampf simulieren:
http://www.youtube.com/watch?v=oscbdxMhX_4

Was hältst Du davon?

Hallo robo.fr,

mehrere Roboter gleichzeitig laufen zu lassen wäre natürlich sehr interessant. Um so etwas wie auf dem Video zu simulieren müsste man auch passive bewegbare passive Objekte definieren können, die bei einer Kollision entsprechend verschoben werden.

MfG Mark

PS: Du hast eine PN

Hier noch weitere Vorschläge zum Simulator:

- Jeder Roboter läuft in seinem eigenen Thread, unabhängig vom Simulator. Der Simulator selbst ist eine Art Server, der den Robotern auf Anfrage Sensorwerte liefert. In bestimmten Abständen (20 ms z.B.) liest er die aktuelle Geschwindigkeit aller Roboter aus und ändert entsprechend deren Koordinaten in der Umgebung. Der Roboter selbst müsste Interfaces wie getXPos(), getYPos(), draw(Graphics g) ... bereitstellen, die vom Sumulator aufgerufen werden.

- Wände bestehen nicht aus Pixeln bestimmter Farbe sondern sind eigenständige Objekte (Linien) in der Umgebung, z.B. von ( 10 | 10 ) nach ( 50 | 10 ). Die Umgebung würde also aus einer Liste von Wänden und einem Hintergrundbild für Linienverfolgung bestehen. Dadurch, dass dem Simulator die Anfangs- und Endkoordinaten bekannt sind, kann dieser die Steigung der Wände ausrechnen und somit auch Abrutschen an der Wand u.ä. simulieren, wie das in der echten Welt vorkommt, wenn ein Roboter gegen eine Wand fährt. Die Steigung kann man außerdem benutzen, um IR-Entfernungssensoren zu simulieren. Die Genauigkeit der Messung wird nämlich deutlich schlechter, wenn sich die Wand in einem zu geringen Winkel zum Sensor befindet.

- Es gibt zusätzliche verschiebbare Objekte (vorzugsweise rund, weil dadurch Berechnungen einfacher werden). Die könnten dann z.b. die Becher aus dem Video darstellen, oder auch Holzscheiben für den Robo Collect Wettbewerb usw.

MfG Mark

Zitat:

---

- Jeder Roboter läuft in seinem eigenen Thread, unabhängig vom Simulator. Der Simulator selbst ist eine Art Server, der den Robotern auf Anfrage Sensorwerte liefert. In bestimmten Abständen (20 ms z.B.)

---

Das finde ich gut, so können wir es machen. Die Abtastrate sollte so hoch sein, dass die mechanischen Zeitkonstanten ( Beschleunigung der Motoren ) im Simulationsmodell berechnet werden können. Das Modell sollte die Schnittstellen zur Verfügung stellen und die mechanischen Trägheiten selbst berechnen.

Zitat:

---

liest er die aktuelle Geschwindigkeit aller Roboter aus und ändert entsprechend deren Koordinaten in der Umgebung. Der Roboter selbst müsste Interfaces wie getXPos(), getYPos(), draw(Graphics g) ... bereitstellen, die vom Sumulator aufgerufen werden.

---

Hmm, an dieser Stelle würde ich die Interfaces vielleicht anders machen. Das Steuerprogramm des Asuro gibt ja eigentlich Werte wie z.B. PWM, Motordrehrichtung, Tasterinputs, Incoderinputs, Liniensensorinputs an. Deshalb würde ich die Schnittstellen eher so aufbauen. Oder meinst Du das ginge nicht?

Zitat:

---

- Wände bestehen nicht aus Pixeln bestimmter Farbe sondern sind eigenständige Objekte (Linien) in der Umgebung, z.B. von ( 10 | 10 ) nach ( 50 | 10 ). Die Umgebung würde also aus einer Liste von Wänden und einem Hintergrundbild für Linienverfolgung bestehen.

---

Hmm, an dieser Stelle würde man den Vorteil der Freihand-Zeichnung des Hintergrundes verlieren.

Zitat:

---

Dadurch, dass dem Simulator die Anfangs- und Endkoordinaten bekannt sind, kann dieser die Steigung der Wände ausrechnen und somit auch Abrutschen an der Wand u.ä. simulieren, wie das in der echten Welt vorkommt, wenn ein Roboter gegen eine Wand fährt.

---

Meiner Meinung nach könnte man das Abrutschen auch über die punktuelle Kollision berechnen. Wenn der Roboter schräg auf einen Punkt auftrifft, kann man über die schiefe Ebenen-Gleichungen das Wegrutschen berechnen.

Zitat:

---

Die Steigung kann man außerdem benutzen, um IR-Entfernungssensoren zu simulieren. Die Genauigkeit der Messung wird nämlich deutlich schlechter, wenn sich die Wand in einem zu geringen Winkel zum Sensor befindet.

---

Das wäre gut, wenn man die IR-Entfernungssensoren simulieren kann ( meinst Du die nach vorne ausgerichteten SFH5110-36 ? ). Ich könnte mir vorstellen, dass man auch ein gutes Ergebnis bekommt, wem man ca. 8 Sehstrahlen nach vorne ausrichtet und die Entfernung irgendwie aus einer Gewichtung der Auftreffpunkte auf die roten Hindernisse berechnet.

Zitat:

---

- Es gibt zusätzliche verschiebbare Objekte (vorzugsweise rund, weil dadurch Berechnungen einfacher werden). Die könnten dann z.b. die Becher aus dem Video darstellen, oder auch Holzscheiben für den Robo Collect Wettbewerb usw.

---

Wettbewerbe simulieren zu können, ist bestimmt super. Das könnte viele Leute hier interessieren.
Zur Vereinheitlichung wäre mein Vorschlag, eine allgemeine Objektklasse zu schaffen, in der die Becher und die Roboter aufgenommen werden. Ein Becher wäre dann einfach ein antriebsloser Roboter mit einem geringen Gewicht.

Mit der Thread-Programmierung habe ich noch keine große Erfahrung. Vielleicht kennst Du Dich da schon besser aus. Ich habe gerade was über "Runnable" und "Callable" gelesen. Morgen könne ich mal ein kurzes Testprogramm zu den Thread Funktionen versuchen.

So, ich hoffe, meine Kommentare waren nicht zu viele.

Was hältst Du davon?

Bester Gruß,
robo

Hallo robo.fr,

wie wäre es damit, eine fertige 2D Physik-Engine zu nehmen? Das würde eine ganze Menge Arbeit ersparen. Bisher habe ich aber nur Engines für Polygone / Kreise gefunden, d.h. man müsste die Objekte entweder direkt im Quellcode in die Umgebung einfügen oder zusätzlich einen Editor bereitstellen, mit dem man die Spielwelt konstruiert.

Threads sind im Grunde keine wirklich große Sache, man hat eine von Thread abgeleitete Klasse, die die Methode void run() implementiert. Wenn man [object].start() aufruft (start ist eine Methode aus Thread) wird ein neuer Thread erstellt, der run() aufruft. So laufen dann sowohl die run() - Methode als auch der Aufrufer von start() parallel.

MfG Mark