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

Zitat:

---

wie wäre es damit, eine fertige 2D Physik-Engine zu nehmen?

---

Sich so etwas anzuschauen, schadet sicherlich nicht. Wenn der Quellcode kompakt und Open-Source ist könnten wir ein Engine ja verwenden..
Hast Du eventuell einen Link? Eine Link-Sammlung mit nützlichen Beispielen wäre nicht schlecht.

Hier findet sich ein Beispiel für die Kollisionsdetektion über die Objekte:
http://www.cokeandcode.com/info/tut2d.html

Die Frage, ob man die Kollisionsdetektion über ein Kreisprofile oder über Farbpixel macht, ist nicht ganz einfach zu entscheiden.
Man könnte ja auch jedes Objekt rot umranden, damit es von einem andern Objekt detektiert werden kann.
Vorteil: Die Objekte können beliebig Formen und Größe annehmen.

Methode 2: Jedes Objekt hat ein Kreisprofil.
Vorteil: Kollision kann berechnet werden und Kraftwechselwirkungen ( ein Roboter schiebt den anderen weg ) können einfach realisiert werden.

Nachtrag: Habe gerade eine 2D-Java Engine gefunden
http://www.cokeandcode.com/phys2d/
Witzig, man kann das Demo direkt im Browser starten. Allerdings: mir scheinen die Physik Engines sehr auf "Schwerkraft" ausgelegt. In unserer flachen Welt eigentlich nicht vorhanden. Die Frage wäre auch: wie viel Rechenzeit braucht so was?

Zitat:

---

auch Abrutschen an der Wand u.ä. simulieren,

---

Jetzt weiß ich, warum Dir das Abrutschen so wichtig ist: In der Simualtion läuft der Roboter ziemlich oft in Deadlocks ( er bleibt hängen ). Das liegt meines Erachtens unter anderem auch an einem Fehler in der Methode "Kollision". Dort hast Du geschrieben, dass sich der Roboter immer drehen kann, da er ja Rund ist. Das stimmt aber scheinbar nicht ganz, da es bei einer Zeichung der runden Scheibe "Rundungsfehler" geben kann.

Im Anhang mal eine etwas abgewandelte Version der Methode.

Gut dass es Du das Problem mit der Rotation erkannt und behoben hast.

Zitat:

---

Zitat von robo.fr

http://www.cokeandcode.com/phys2d/
Witzig, man kann das Demo direkt im Browser starten. Allerdings: mir scheinen die Physik Engines sehr auf "Schwerkraft" ausgelegt. In unserer flachen Welt eigentlich nicht vorhanden. Die Frage wäre auch: wie viel Rechenzeit braucht so was?

---

Hab gerade etwas mit Phys2D rumgespielt, und es sieht so aus, als hätte es alles was wir brauchen, bis auf die Tatsache, dass da nur Polygone verwendet werden können. Wenn man sich auf Roboter mit einem Kreis- oder Rechteckprofil beschränkt, ist die Sache kein Problem. Da die API sehr einfach ist, kann man auch schnell selbst neue Formen erstellen. Ein großer Vorteil wäre halt, dass man sich über die Physik keine sorgen mehr machen muss, weil alle Parameter wie Reibung, Masse usw nur eingestellt werden müssten und die Engine erledigt den Rest.

Die Gravitation kann abgestellt werden.

Die Engine ist sehr schnell, 60fps bei einem Dutzend von bewegbaren und statischen Objekten und ca 28% CPU-Auslastung sind drin.

Zitat:

---

Zitat von robo.fr

Die Frage, ob man die Kollisionsdetektion über ein Kreisprofile oder über Farbpixel macht, ist nicht ganz einfach zu entscheiden.
Man könnte ja auch jedes Objekt rot umranden, damit es von einem andern Objekt detektiert werden kann.
Vorteil: Die Objekte können beliebig Formen und Größe annehmen.

---

Das Problem ist ja nicht die Kollisionserkennung an sich sondern die Berechnung der entsprechenden Bewegungen, die die Kollision zur Folge hat. Vielleicht stelle ich es mir zu kompliziert vor, aber ich wüsste nicht, wie man sowas nur anhand der Überschneidungen der Pixel berechnen kann.

Es gibt eine 2D-Engine für .net, die aus Bildern automatisch Polygone erstellen kann. Möglicherweise können wir etwas änliches in Java erstellen, sprich der Benutzer liefert eine Zeichnung vom Profil des Roboters und der Umwelt und die Software berechnet ihre Formen für die Physik-Engine.

Zitat:

---

Das Problem ist ja nicht die Kollisionserkennung an sich sondern die Berechnung der entsprechenden Bewegungen, die die Kollision zur Folge hat. Vielleicht stelle ich es mir zu kompliziert vor, aber ich wüsste nicht, wie man sowas nur anhand der Überschneidungen der Pixel berechnen kann.

---

Ein Verfahren kenne ich auch nicht so genau. Ich hätte aber eine Idee: Wenn ein Objekt ein rotes Pixel berührt, soll es sich wie bisher nicht weiterbewegen. Aber es soll sein internen Geschwindigkeitsvariablen nicht gleich auf Null setzen, sondern langsam reduzieren. Ein leichtes Objekt erniedrigt die Variblen schnell, ein schweres Objekt langsam. Das Ergebnis ist vermutlich wie bei einem "inelastischem Stoß"==> das große Objekt behält mehr Geschwindigkeit und damit den größeren Impuls. ( Wenn das funktioniert ist es eine ganz neue Klasse von Simualtionsverfahren )

Zitat:

---

Es gibt eine 2D-Engine für .net, die aus Bildern automatisch Polygone erstellen kann. Möglicherweise können wir etwas ähnliches in Java erstellen, sprich der Benutzer liefert eine Zeichnung vom Profil des Roboters und der Umwelt und die Software berechnet ihre Formen für die Physik-Engine.

---

Dieses Problem würde ich nach hinten schieben. Lieber klein und mit Kreisen anfangen. Die Simulaton wird die wesentlichen Effekte dann schon zeigen.

Zitat:

---

Zitat von robo.fr

Ein Verfahren kenne ich auch nicht so genau. Ich hätte aber eine Idee: Wenn ein Objekt ein rotes Pixel berührt, soll es sich wie bisher nicht weiterbewegen. Aber es soll sein internen Geschwindigkeitsvariablen nicht gleich auf Null setzen, sondern langsam reduzieren. Ein leichtes Objekt erniedrigt die Variblen schnell, ein schweres Objekt langsam. Das Ergebnis ist vermutlich wie bei einem "inelastischem Stoß"==> das große Objekt behält mehr Geschwindigkeit und damit den größeren Impuls. ( Wenn das funktioniert ist es eine ganz neue Klasse von Simualtionsverfahren )

---

Aber wie willst Du nur anhand der Pixelwerte die genaue Richtung berechnen, in die der Becher geschoben wird?

Zitat:

---

Zitat von robo.fr

Zitat:

---

Es gibt eine 2D-Engine für .net, die aus Bildern automatisch Polygone erstellen kann. Möglicherweise können wir etwas ähnliches in Java erstellen, sprich der Benutzer liefert eine Zeichnung vom Profil des Roboters und der Umwelt und die Software berechnet ihre Formen für die Physik-Engine.

---

Dieses Problem würde ich nach hinten schieben. Lieber klein und mit Kreisen anfangen. Die Simulaton wird die wesentlichen Effekte dann schon zeigen.

---

Aber wofür "klein" anfangen, wenn man gleich (fast) alles auf einmal haben kann?

Irgendwie scheinen wir beide nicht die gleichen Ziele zu verfolgen. Mein Ziel ist es, eine möglichst realistische Simulationssoftware zu erstellen, die in der Lage ist, das Testen auf realer Hardware tatsächlich (oder zumindest teilweise) zu ersetzten. Da ich bisher die Erfahrung gemacht habe, dass eben durch das Abrutschen an der Wand, ungenaue Messdaten, Trägheit usw. der Roboter sich real anders verhält, als es theoretisch sein sollte, möchte ich diese Faktoren so weit wie möglich hinenbeziehen. Ein einfaches User-Interface steht für mich persönlich eher an zweiter Stelle. Es soll natürlich nicht heißen, dass man jedes Detail des Simulators kennen muss, um ihn benutzen zu können. Aber wie gesagt, man kann auch einen Editor bereitstellen, wo man sich die Umgebung per Maus zusammenklicken kann, was nicht viel komplizierter wär als die Benutzung von Paint.

Wüde gerne Deine Ansichten dazu hören.

MfG Mark

Zitat:

---

Aber wofür "klein" anfangen, wenn man gleich (fast) alles auf einmal haben kann?

---

Wenn es einfach ist, kein Problem. Ich habe ein wenig Angst, dass sich das ganze Projekt bei zu hohen Ansprüchen im Sande verläuft.

Wenn man die 2D-Physik schnell zum laufen bekommt, ist es sicherlich eine professionelle Sache und gut verwendbar.

Wir programmieren doch Objekt orientiert oder? Wenn man die Klassen und deren Schnittstellen sauber definiert, sollte sich der Unterbau der "Umweltsimulation" ja einfach austauschen lassen. Das wäre toll, man könnte, um schnell zu sein, ein ganz einfaches Umweltmodell unterlegen ( z.B. das was wir jetzt schon haben ) und dann einfach das komplexe Modell unterschieben. Ich gebe zu: ich bin jemand, der erst das grobe Ganze konstruiert und danach die Einzelteile verfeinert. Viele meiner Kolegen bevorzugen aber das umgekehrte Vorgehen: alle Einzelteile sauber nach einander aufbauen. Beide Vorgehensweisen haben ihre Vor- und auch Nachteile und ich will gar nicht sagen, dass meine Vorgehensweise besser wäre. Sie hat aber den Vorteil, dass man schnell zu einem irgendwie laufenden Programm kommt, dass man so lange verfeinern kann, bis einem die Lust ausgeht ( was ja bei Hobby-Projekten öfters mal vorkommt. )
Das ist auch der Grund, warum ich Robosim einfach mal so hin programmiert habe, ohne jedes Detail zu perfektionieren.

Wie würde man die Klassen in diesem Projekt aufteilen? Lass uns das doch mal genauer diskutieren. Ich würde gerne Deine Vorstellungen dazu hören.

- Scheduler, der die Programme in den einzelnen Robotermodellen startet
- RoboterObjektklasse ( alle Objekte, die man in der Welt verschieben kann )
- Roboterklassen: Asuro, NiboBee usw. mit ihren eigenen Programmbefehlen
- Umweltklasse ( oder 2d-Physiksimulation )

Diese Liste ist nur ein Brainstrorming, wir können Sie beliebig verändern, verwerfen o.ä.

Wie sollten die Schnittstellen aussehen?

Also die Schnittstellen so wie Du sie vorgeschlagen hast, klingen insoweit ok. Jedoch würde ich alle beweglichen Objekte (außer den Robotern) von den der Roboter trennen und zwei separate Listen machen, da die Roboter ja ggf. mehr Methoden haben werden, die bei jedem Schritt aufgerufen werden müssen. Um dem ganzen etwas mehr Optik zu verleihen, würde ich jedem Objekt ein Bild zuordnen, welches beim Zeichnen des Objekts verwendet wird.

Bin gerade dabei, einen neuen Simulator für Testzwecke und proof of concept zu bauen, funktioniert auch soweit ganz gut, Quellcode wird wahrschienlich heute Abend folgen. Ist aber wie gesagt nur zum Testen und soll nicht die entgültige Basis werden.

MfG Mark

Zitat:

---

Um dem ganzen etwas mehr Optik zu verleihen, würde ich jedem Objekt ein Bild zuordnen, welches beim Zeichnen des Objekts verwendet wird.

---

Finde ich gut. Meiner Meinung nach sollten die Roboter ein fertig gezeichnets Bild an die Umweltklasse liefern ( also z.B. ein Asuro Realbild nehmen, die LEDs darauf zeichnen lassen und das fertige Bitmap an die Umwelt liefern )

Zitat:

---

Bin gerade dabei, einen neuen Simulator für Testzwecke und proof of concept zu bauen, funktioniert auch soweit ganz gut, Quellcode wird wahrschienlich heute Abend folgen.

---

Bin sehr gespannt :-)

Ich will mir demnächst noch mal ein wenig den SourceCode des ct-Simulators anschauen:
http://www.heise.de/ct/projekte/mach...ziped-releases
Da lässt sich vielleicht auch noch die ein oder andere Idee finden.

So, hat zwar etwas länger gedauert als versprochen, aber eine kommentierte Vorab-Version ist jetzt endlich fertig. Hab das Projekt mit Eclipse geschrieben, wahrscheinlich lässt es sich aber auch mit NetBeans bauen. Im Zip-File ist die Phys2D Engine enthalten (src060408).

Die Klasse Environment enthält ein World-Objekt aus Phys2D und hat zusätzlich eine Liste mit allen Robotern. Bei jedem Simulationsschritt werden wird von jedem Roboter die Methode doStep() aufgerufen, die den Roboter entsprechend weiter bewegt. Alle sichtbaren Objekte (also auch Roboter) haben das Interface Showable implementiert, das eine Methode zum Zeichnen des Objekts enthält.

Um nicht nur Zweirad-Roboter simulieren zu können, hat jeder Roboter deshalb eine allgemeine doStep()-Methode, die die Geschwindigkeit des Roboters regelt, ohne dass die Umgebung wissen muss, wie. Von Robot abgeleitet ist die Klasse TwoWheelRobot, die die Basis für Roboter mit Differentialantrieb darstellt. Der Asuro ist so ein TwoWheelRobot. Das Programm für den Asuro muss von Asuro abgeleitet werden und ein Runnable implementieren. Dadurch entfällt im Programm das ständige "asuro.IrgendeineFunktion".

Im Moment ist ein sehr einfaches Sumo-Programm implementiert, die nach Objekten sucht und diese über die schwarze Markierung hinausschiebt. Dazu hat der Asuro eine Erweiterung in Form eines Sharp-Distanzsensors mit 80 cm Reichweite bekommen.

Die Simulator-Klasse erstellt eine neue Umwelt und kann beliebig viele Roboter bzw Physik-Objekte hinzufügen.

MfG Mark

Hey, nicht schlecht, sieht tatsächlich ziemlich realistisch aus, fast wie im Beispielfilm.
Dass man die Klassen nicht mehr vor die AsuroBefehle schreiben muss, macht die ganze Sache um einiges praktischer als immer asuro.Befehl schreiben zu müssen.

Zur Kompatibilität: Der Asuro Befehl heist Msleep(), Du hast ihn sleepMS() umbenannt.
Ich frage mich, ob das Programm in der Form auf dem realen Asuro laufen würde ... wäre ein Experiment wert.

Was Eclipse anbelangt, habe ich es zwar installiert, es ist mir allerdings nicht gelungen, Dein Program aus den Sourcen zu kompilieren und laufen zu lassen, allerdings bin ich nicht der Ecipse Spezialist. Das ist auch der Grund, warum ich den ursprünglichen RoboSim mit einem Batch-File kompiliert habe: es funktioniert ohne Installation und macht keine Probleme.

Dein Jar-File läuft auf Anhieb, allerdings dürften Leute ohne Eclipse ein Probelm haben, das Asuro-Programm zu kompilieren. Wenn es einfach genug wäre, könnte man hier im Forum einen virtuellen Roboterwettbewerb ausrufen, das könnte einige Leute interessieren.

Bester Gruß,
robo

OK, sleepMS habe ich jetzt in Msleep umbenannt, danke für den Hinweis.

Könntest Du bitte die Fehlermeldungen posten, die entstehen, wenn Du versuchst, das Projekt zu compilieren? Normaleweise müsste es sich problemlos importieren lassen. In der Version, die ich angehängt habe, fehlt allerdings der Ordner "Editor", da dieser sowieso noch nicht einmal annähernd benutzbar ist. Eventuell muss man den Ordner aus den Projekteinstellungen entfernen.

Eclipse wird von den meisten Java-Programmierern verwendet, deshalb hab ich es genommen. Vielleicht bin ich auch mittlerweile zu verwöhnt von Code Completion, automatischer Einrückung usw, aber ich kann mir nicht vorstellen, für so ein Projekt keine IDE zu benutzen. Außerdem müssten die meisten sowieso erstmal das JDK installieren, und da kann man auch gleich Eclipse mit dazu nehmen.

Ein virtueller Roboterwettbewerb wäre sehr interessant, zudem man da auch ganz neue Sachen ausprobieren könnte, die in der realen Welt garnicht möglich wären.

MfG Mark

Hallo,

finde ich superspannend.

Auch ich habe mir phys2d und Eure Erweiterungen dazu runter geladen. Versuche mich gerade daran. Es sollte doch möglich sein das orginal C-Programm für den Asuro mit der Simulation zu verbinden (über Sockets).

Zitat:

---

Es sollte doch möglich sein das orginal C-Programm für den Asuro mit der Simulation zu verbinden (über Sockets).

---

Nur zu, es wäre schön, wenn es klappt.
Eine andere Möglichkeit könnte das Java JNI Interface zu nutzen. Ist eventuell einfacher zu programmieren.

Habe ich jetzt gemacht (nicht JNI sondern via Sockets). D.h. es geht jetzt auch mit einem C-Programm AsuroSumoClient.exe (VisualStudio).

Dazu habe ich das JAVA Projekt etwas umgestellt (auf Packages verteilt). Auch hauptsächlich deswegen weil ich zwischen dem HardwareRoboter und seiner Software trennen musste (damit letztere auch in C programmiert werden kann).

Simulator.java habe ich nach Simulation1.java umgenannt -> (wie gehabt) zwei lokale Clients.
Simulation2.java -> ein lokaler Client und ein remote Client.
Simulation3.java -> zwei remote Clients.

Startet man Simulation2 oder Simulation3 muss man natürlich noch die remote Clients starten. Am besten vorher. Die warten dann auf den Start der Simulation.
Einen Client gibt es für JAVA -> AsuroSumoClient.java
Und einen zweiten Client gibt es für C -> AsuroSumoClient.exe

Der remote Client wird jeweils in blau angezeigt.

edit: Es heißt AsuroSumoClient und der blaue Asuro war nicht zu sehen.

Hi rossir,

schön, dass Du so weit gekommen bist. Ich habe ja schon gedacht, Du hättest das Projekt schon aufgegeben.
Beim Durchsehen scheint mir, dass Du Dein Copyright in den entsprechenden Routinen nicht eingetragen hast. Das ist meiner Meinung nach bei Open-Source Projekten wichtig, damit man weiß, was von wem kommt. Es reicht ein Nickname aus.

Die Asuro Source könnte man noch aus dem C-Programm als eigenständiges Programmfile herauslösen, so dass der Code wirklich Asuro-kompatible wird ( allle Funktionen bis auf "main" antürlich )

Ich persöhnlich verwende den GCC, deshalb wird's schwierig für mich, den VCC Code zu kompilieren.

Ansonsten: Gratulation zu Deiner Arbeit,

robo

Hallo robo,

Copyright? Wofür? Eigentlich habe ich ja nur den von Euch geschriebenen Code mit cut&past umgestellt und die ASURO Lib Funktionen in schreibweise und Parameterverwendung näher an die Orginal Asuro Lib 2.9.1 gebracht. Dann ein bisschen Socketzucker dazu getan.

Selbst beim C-Code bin ich so vorgegangen. Ich habe den vorhandenen JAVA Code genommen und reingepastet und noch C-mäßige Microanpassungen vorgenommen. Auch hier dann noch ein bisschen Socketzucker in MSWINSocket.cpp. (Und selbst das meist via cut&past aus dem Netz.)

Also nichts Besonderes und vor allem nur dort MSWIN-spezifisch wo es um Sockets geht. Deswegen ist meine Hoffnung, dass man es leicht nach GCC umstellen kann. (Dort kenn' ich mich aber nicht aus.) Wahrscheinlich braucht man nur ein neues/eigenes GCCSocket.cpp.

Ich glaube schon (bin optimistisch), dass man das Ziel erreicht und Simulator C-Code 1:1 in den Asuro übertragen kann. Könnte das nicht ein schönes (Zwischen-)Ziel sein?

Jup, sieht gut aus.

Ich steuere meinen Roboter auf dem Bildschirm mit dem Board, welches ich an der Seriellen Schnittstelle angeschlossen habe.
Der Screenroboter fährt mit den Anweisungen, welche vom Atmegaboard kommen. Das Board wertet die laufenden Daten aus, die vom Screenroboter über die Schnittstelle gesendet werden. Ich programmiere in GFA32 (ist jetzt Freeware).

Nebenbei mein Board :
Ich mache es mit einer Ex-Platine, wo 3 Atmega drauf sind mit 16mhz, 2x Atmega32 und 1x Atmega8, dazu habe ich vorn quer ein Steckbrett gesetzt.
Darauf sind zur zeit 2x PCF8574, 1x 27c256, 2x 8ter Leuchtdiodenbänke, 1x Irdiode ,1x Tsop.
Die Platine selber hat noch 1xFBas-Buchse , 1x Stecker für PC-Tastatur, 1x LCD-Display, 1x Seriell(Max), 1x SD-Karte.

Mit diesem Ding kann man unendliche weiten des Atmegas und den Sensoren entdecken.

Alle Anschlüsse sind Steckbar , also keine Festverdrahtung der Sensoren.

Zitat:

---

Der Screenroboter fährt mit den Anweisungen, welche vom Atmegaboard kommen. Das Board wertet die laufenden Daten aus, die vom Screenroboter über die Schnittstelle gesendet werden. Ich programmiere in GFA32

---

Hallo funkheld,

das ist eine interressante Anwendung: eine echte "hardware in the loop" simulation. Das entspricht dem Vorgehen in der Industrie.
Du verwendest also den Simulator, um Deine reale Prozessorhardware zu testen :-)

Zitat:

---

um Deine reale Prozessorhardware zu testen...

---

Mein Radius für Versuche ist dadurch grösser und Kostengünstiger.
Es macht mir mehr spass damit , als mit einem realen Robotor zu spielen.

Das Wichtigste ist ja eigentlich immer der Atmega.

Man lernt dadurch sehr viel, Pc und Atmega zu proggen.

OK, der try and error zyklus ist mit der Simulation kürzer. Aber nicht vergessen: Eine Simulation ist nur eine Annäherung an die Realität. Da wird sicher noch etwas Nacharbeit nötig sein, wenn Du Dein Programm auf dem realen Roboter laufen lässt.

Hi
Ich weiss nicht, ob noch jmd an dem Programm arbeitet: Jedoch wollte ich fragen: Wie startet man das Programm? Bei uns gibt es ein Seminar Informatik und wir benötigen einen Simulator zum Üben für die Programmierung eines Asuros.
Ich danke schon mal im voraus

Hallo WvB,

hat was gedauert. Blickte selber nicht mehr durch weil ich es unterirdisch dokumentiert hatte. Jetzt weiß ich wieder und es ist simpel:
1a)

1. Download: robosim2_134.zip (z.B. in C:\asurotmp)
2. cd C:\asurotmp
3. java -cp robosim2_134.zip robosim.asuro.games.Simulation1

Du siehst zwei grüne ASUROs welche Pucks aus der Arena schieben. Dabei ist "grün" die Farbe von ASUROs die durch einen JAVA Client gesteuert werden. In der Simulation1 werden beide ASUROs von JAVA gesteuert.

1b)
Alternativ und etwas einfacher in der Bedienung:

1. copy robosim2_134.zip robosim2_134.jar
2. java -jar robosim2_134.jar bzw. Doppelklick auf robosim2_134.jar

2)
Oder, lass in der Simulation2 einen ASURO von JAVA steuern (grün) und den anderen ASURO durch einen C Client (blau).

1. Download: asuroclient2.zip
2. Extrahiere daraus: AsuroSumoClient.exe
3. start java -cp robosim2_134.zip robosim.asuro.games.Simulation2
4. AsuroSumoClient.exe

3)
Oder, lass in der Simulation3 beide ASUROs durch den C Client (blau) steuern.

1. start java -cp robosim2_134.zip robosim.asuro.games.Simulation3
2. start AsuroSumoClient.exe
3. AsuroSumoClient.exe

Zusätzlich ist der JAVA Quellcode in robosim2_134.zip.
Der C Quellcode (für vc) ist in asuroclient2.zip.

Zur Kommunikation zwischen dem Simulations Server (hier in JAVA) und den ASURO Clients (JAVA oder C) wird der TCP/IP Port 50501 verwendet.

Bin jetzt wieder etwas drin in der Materie und denke, dass ich weitere Fragen jetzt etwas schneller beantworten kann. ;-)

Erstmal Danke!
Also habs versuchs komm aber net ganz klar.](*,)
Ich hab die befehle in die Konsole eingeben, aber es öffnet sich kein Fenster. Also jetzt mal so: Ich such einfach eine simulation, wo die Mitschüler einfach "versuchen" können den asuro in C zu promgrammieren (vorallem Motorstrg). Deshalb sollte der Aufruf möglichst einfach sein.
Dann mal so gefragt: Ist das möglich mit diesem Programm?

Gerne helfe ich weiter aber wie soll ich ohne Infos weiter helfen? Was hast Du denn eingegeben, in welcher Console (Mac/Linux/WIndows/Cygwin)? Und was gibt es (evtl.) für Fehlermeldungen.

Hast Du den C Quellcode angeschaut?
Denn ich verstehe Deine Bemerkung nicht: Ist er Dir nicht einfach genug oder eben doch und es ist erst mal nur die Simulation die nicht läuft?

Also Methode 1b funktioniert(Hab mich vertippt:( ), aber ich weis nicht wie ich den programcode ändern kann und ein Asuro würde reichen.
Nachtrag: 2) auch aber wie ändere ich das Programm ohne robosim2 jedesmal neu zippen zu müssen und Client lässt sich nicht straten

"jedesmal eu zippen zu müssen"
Es gibt zwei ZIP Dateien, welche meinst Du?

AsuroSumoClient.exe: "Client lässt sich nicht straten" -> side-by-side Konfiguration ungültig
Also da kenne ich mich nicht aus. Bei mir läuft's unter Win7 (und sogar noch unter XP) ohne meckern. Durch Internet Suche (Warum hast DU das nicht schon gemacht?) bin ich auf diese Seite gestoßen http://social.technet.microsoft.com/...itprogeneralde welche auf fehlende C++ Redistributables hinweist.
Bin mir aber nicht bewußt (für so ein einfaches C-Programm) ein besonderes C++ Redistributable gebraucht bzw. installiert zu haben. Folge den Anweisungen dort und schau doch nach welches vermisst wird, sag mir dann hier im Forum bescheid und installiere es.

Welchen C Compiler nutzt Du? Vielleicht reicht ja einfaches neu-compilieren der C-Sources von AsuroSumoClient.

Wie gefällt Dir denn Variante Simulation3? Die müßte doch erst mal reichen für nur einen ASURO!? (Der zweite bleibt dann einfach stehen und tut nichts weil ihn keiner (kein Programm) steuert.)

Zitat:

---

Zitat von rossir

Durch Internet Suche (Warum hast DU das nicht schon gemacht?) bin ich auf diese Seite gestoßen (Der zweite bleibt dann einfach stehen und tut nichts weil ihn keiner (kein Programm) steuert.)

---

Hab ich...
Etwas neues zu instalieren ist nicht möglich, da es auf dem Schulserver laufen muss.
Ich nutze Eclipse(mit Erweiterung) und Dev-c++.
Und zu Simulation3... Das Fenster öffnet sich, aber keine Asuro bewegt sich....liegt es daran, dass der Client nicht läuft?
Und wenn ich es neu kompiliere kommt ,bei Dev, die Meldung:

Zitat:

---

C:\....Asuro simulation\version 2\asuroclient2\AsuroClient\AsuroClientLib.cpp In function 'void Init()':
10 19 C:\....Asuro simulation\version 2\asuroclient2\AsuroClient\AsuroClientLib.cpp [Warning] deprecated conversion from string constant to 'char*' [-Wwrite-strings]
C:\....Asuro simulation\version 2\asuroclient2\AsuroClient\AsuroClientLib.cpp In function 'void MotorDir(int, int)':
21 35 C:\....Asuro simulation\version 2\asuroclient2\AsuroClient\AsuroClientLib.cpp [Warning] deprecated conversion from string constant to 'char*' [-Wwrite-strings]
C:\....Asuro simulation\version 2\asuroclient2\AsuroClient\AsuroClientLib.cpp In function 'void MotorSpeed(int, int)':
32 37 C:\....Asuro simulation\version 2\asuroclient2\AsuroClient\AsuroClientLib.cpp [Warning] deprecated conversion from string constant to 'char*' [-Wwrite-strings]
C:\....Asuro simulation\version 2\asuroclient2\AsuroClient\AsuroClientLib.cpp In function 'char PollSwitch()':
43 37 C:\....Asuro simulation\version 2\asuroclient2\AsuroClient\AsuroClientLib.cpp [Warning] deprecated conversion from string constant to 'char*' [-Wwrite-strings]
C:\....Asuro simulation\version 2\asuroclient2\AsuroClient\AsuroClientLib.cpp In function 'float getSharpDist()':
48 41 C:\....Asuro simulation\version 2\asuroclient2\AsuroClient\AsuroClientLib.cpp [Warning] deprecated conversion from string constant to 'char*' [-Wwrite-strings]
C:\....Asuro simulation\version 2\asuroclient2\AsuroClient\AsuroClientLib.cpp In function 'void LineData(unsigned int*)':
60 34 C:\....Asuro simulation\version 2\asuroclient2\AsuroClient\AsuroClientLib.cpp [Warning] deprecated conversion from string constant to 'char*' [-Wwrite-strings]
C:\....Asuro simulation\version 2\asuroclient2\AsuroClient\AsuroClientLib.cpp In function 'void StatusLED(int)':
71 32 C:\....Asuro simulation\version 2\asuroclient2\AsuroClient\AsuroClientLib.cpp [Warning] deprecated conversion from string constant to 'char*' [-Wwrite-strings]
C:\....Asuro simulation\version 2\asuroclient2\AsuroClient\AsuroClientLib.cpp In function 'void BackLED(int, int)':
82 34 C:\....Asuro simulation\version 2\asuroclient2\AsuroClient\AsuroClientLib.cpp [Warning] deprecated conversion from string constant to 'char*' [-Wwrite-strings]
C:\Users\...\AppData\Local\Temp\cc36wH7Q.o AsuroClientLib.cpp:(.text+0x10): undefined reference to `remoteCall(char*, ...)'
C:\Users\...\AppData\Local\Temp\cc36wH7Q.o AsuroClientLib.cpp:(.text+0x3a): undefined reference to `remoteCall(char*, ...)'
C:\Users\...\AppData\Local\Temp\cc36wH7Q.o AsuroClientLib.cpp:(.text+0x64): undefined reference to `remoteCall(char*, ...)'
C:\Users\...\AppData\Local\Temp\cc36wH7Q.o AsuroClientLib.cpp:(.text+0x7f): undefined reference to `remoteCall(char*, ...)'
C:\Users\...\AppData\Local\Temp\cc36wH7Q.o AsuroClientLib.cpp:(.text+0xa1): undefined reference to `remoteCall(char*, ...)'
C:\Users\...\AppData\Local\Temp\cc36wH7Q.o AsuroClientLib.cpp:(.text+0xdf): more undefined references to `remoteCall(char*, ...)' follow
i:\portableapps\dev-cpp\mingw64\x86_64-w64-mingw32\bin\ld.exe C:\Users\...\AppData\Local\Temp\cc36wH7Q.o: bad reloc address 0x0 in section `.pdata'
i:\portableapps\dev-cpp\mingw64\x86_64-w64-mingw32\bin\ld.exe final link failed: Invalid operation
C:\....Asuro simulation\version 2\asuroclient2\AsuroClient\collect2.exe [Error] ld returned 1 exit status

---

Ich hoffe du kannst mit trotzdem helfen und danke nochmal für die bisherigen Versuche.

Es stehen noch Antworten aus:

1) Es gibt zwei ZIP Dateien, welche meinst Du?
2) Welches C++ Redistributable wird denn gebraucht?

Mit dev-c++ bzw. GCC kenne ich mich nicht aus. Mein Code ist für MS VC 2008. Du müsstest ihn dann nach dev-c++ migrieren. Wäre schön wenn ich den dann auch bekäme um ihn zu integrieren.

Neu:
3) Trotzdem, das Listing kommt mir so vor als würdest Du nur AsuroClientLib.cpp kompileren und die anderen Source Dateien nicht. Stimmt das?

Zu Simulation3:
Ja, die ASUROs stehen weil AsuroSumoClient.exe nicht läuft. Die warten nämlich darauf, dass ein Client (irgend ein Client) sie steuert.

Zitat:

---

Zitat von WvB

Nachtrag: 2) auch aber wie ändere ich das Programm ohne robosim2 jedesmal neu zippen zu müssen und Client lässt sich nicht starten

---

Ich will doch einfach nur einen asuro simulieren lasse :(
Ja hab mal mit AsuroClientLib.cpp angefangen, jedoch war das die "fehlerreichte" Datei.
Und meine Verwirrung ist inzwischen groß....

zu 1) Es gibt zwei ZIP Dateien, welche meinst Du?
Ich gehe jetzt mal davon aus, Du meinst die Datei robosim2_134.zip (und nicht asuroclient2.zip) aus dem robosim2 Paket.

2) Welches C++ Redistributable wird denn gebraucht?
Noch offen.

zu 3) "AsuroClientLib.cpp ... "fehlerreichte" Datei"
Nein, das siehst Du falsch. In Deinem Listing sind viele Warnings aber kein einziger Fehler zu AsuroClientLib.cpp. Die Fehlermeldungen kommen vom Linker. Der beschwert sich darüber, dass eine Funktion fehlt. Diese ist aber in einer anderen Datei des C-Sources vorhanden. Du müsstes also ein C Projekt aufsetzten und darin allen Sourcecode aus asuroclient2.zip aufnehmen. Daran, dass Du das einfach (noch) nicht gemacht hast erkenne ich, dass Du diesbezüglich wenig Erfahrung hast. Jetzt kann ich Dir aber gerade auch bzgl. dev-c++ bzw. GCC nicht weiter helfen.