Asuro Simulieren

[robo.fr]

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?

[robo.fr]

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.

[p_mork]

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

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.

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.

[robo.fr]

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 )

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.

[p_mork]

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?

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

[robo.fr]

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?

[p_mork]

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

[robo.fr]

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 )

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.

[p_mork]

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 (src06040.

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

[robo.fr]

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