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

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?

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

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.

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.

- 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