c't Projekte - c't-Bot und c't-Sim - Mailinglisten

c't-Bot und c't-Sim


[Voriger (Datum)] [Nächster (Datum)] [Voriger (Thread)] [Nächster (Thread)]
[Nach Datum][Nach Thread]

Re: [ct-bot] Sommerloch?

Absender: Timo Sandmann
Datum: Mo, 29.06.2009 11:57:46
In-reply-to: <000001c9f826$b51d45d0$0200a8c0@mexpnew>
References: <000001c9f826$b51d45d0$0200a8c0@mexpnew>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

wie erfreulich, dass die Stille sofort auffällt ;-)

Zuerst einmal die Punkte, die bei mir bereits angefangen sind:

o Thema 1 - Bot-Lokalisierung: Ich habe drei kleine IR-Baken gebastelt, die sehr einfach aufgebaut sind (1 ATtiny25, 2 Transistoren, 2 Kondensatoren, 6 IR-LEDs) und ständig die Koordinaten ihrer eigenen Position (wie eine Fernbedienung) mir IR-Licht durch die Gegend blinken. Am Bot gibt es einen zusätzlichen Sensor (anstelle der Helligkeitssensoren angeschlossen), der lediglich aus einem Fernbedienungsempfänger (wie IC9) besteht, der an das Ende einer dünnen Plastik-Röhre geklebt ist. Dreht sich der Bot nun auf der Stelle, kann ein Verhalten messen, unter welchem Winkel zwei verschiedene solcher Baken angepeilt werden. Da die Baken ihre Position in Weltkoordinaten übermitteln, kann der Bot, nachdem er drei Baken gesichtet und somit zwei Winkel zwischen den Dreien gemessen hat, daraus seine eigene Position berechnen. Die Hardware dafür ist fertig und sehr einfach zu bauen. Ein einfaches Testverhalten mit der minimal nötigen Mathematik gibt es auch schon, ebenso ein Bakenobjekt für den Sim. In der Simulation funktioniert die Lokalisierung auch schon sehr gut. Leider fehlte mir bisher die Zeit, das Ganze im Zusammenhang auf dem echten Bot auszuprobieren und zu schauen, wie hoch die erzielte Genauigkeit ist. Das kommt aber natürlich noch. Bei diesem Thema gibt es auch noch viele weitere Dinge, z.B. wie man das Messverfahren verfeinern kann (Encodergenauigkeit in Software aufbohren), weitere Messverfahren wie Berechnung der eigenen Ausrichtung (heading) aus dem Scan dreier Baken, Kreuzpeilung (nur zwei Baken sichtbar, aber eigene Ausrichtung bekannt), Update der Position on-the-fly, also wenn im Vorbeifahren eine Bake erkannt wurde, Gewichtung der Messergebnisse, wenn mehr Baken als nötig im Sichtfeld sind uvm. Wenn hier allgemeines Interesse an der Sache besteht, kann ich die Ergebnisse mal auf einer Wiki-Seite zusammentragen, der Hardwareaufwand ist minimal und das Ganze daher auch leicht nachzubauen.

o Thema 2 - Scriptsprache für Bot-Verhalten: Schon vor längerer Zeit kam die Idee auf, eine kleine und sehr einfache Scriptsprache zu bauen, mit der sich der Bot bzw. genauer gesagt fertige Verhalten des Bot-Frameworks steuern lassen. Diese Bot-Programme sind einfache Textdateien, die entweder im EEPROM des ATmegas oder auf der MMC/SD- Karte abgelegt werden. Somit braucht man bei Änderungen nicht immer den Controller neu zu flashen und kann auf einer MMC auch sehr viele solcher Programme ablegen ohne an Speicherplatzgrenzen zu stoßen. Die Sprache besteht dabei (bisher) im Wesentlichen aus Verzweigungen und Schleifen sowie Verhaltensaufrufen. Ein sehr einfaches Beispiel wäre:
for(4)
  bot_drive_distance(0,100,15)
  bot_turn(90)
endf()
Damit fährt der Bot einmal ein Quadrat (vier Seiten von 15 cm Länge) ab. Wenn man jetzt auch Rückgabewerte von Verhalten auswertet, lassen sich damit komplexere Sachen wie z.B. solve_maze() lösen. Man kommt dann allerdings schnell an einen Punkt, wo man verschiedene solcher Programme speichern und ausführen können möchte, da kommt Thema 3 ins Spiel. Die ursprüngliche Idee war außerdem, ein kleines Programm oder eine Sim-Erweiterung zu schreiben, mit dem / der sich solche Bot- Programme grafisch erstellen lassen. Also dass man aus einer Liste der verfügbaren (in C geschriebenen) Verhalten sehr einfach ein Bot- Programm zusammenklicken kann. Für solch ein Programm fehlt mir allerdings die Zeit, darum hatte ich das Ganze erstmal auf Eis gelegt. Ich denke, dass so eine einfache Bot-Sprache und evtl. ein Programm zur grafischen Erstellung vor allem für Anfänger interessant wäre, weil man ohne C zu können und sich mit dem Bot-Framework befasst haben zu müssen dem Bot viele Dinge beibringen könnte. Ich weiß nicht, wie viel Interesse an dieser Sache allgemein besteht. Den Code, den ich bisher dafür habe, wieder rauszukramen (wie gesagt leider ohne ein grafisches Frontend) und in den aktuellen Bot-Code zu integrieren sollte kein allzu großer Aufwand sein. Wer meint, dass er das gern hätte, kann sich ja einfach mal zu Wort melden. Falls sogar jemand Interesse daran haben sollte, ein GUI-Frontend in Java (oder sonst wie) zu schreiben, ist das natürlich auch sehr willkommen. Ich kann da dann gern auch noch viele weitere Infos zu geben.

o Thema 3 - MMC-Mini-Dateisystem: Da es relativ viel Code erfordert, auf FAT16 / 32 neue Dateien zu erzeugen, welche zu löschen oder ihre Größe zu ändern, kam die Idee auf eine (relativ einfache) Implementierung eines Dateisystems für die MMC zu realisieren. Damit kann der Bot selbst Dateien auf der MMC anlegen, löschen, umbenennen, kopieren usw. Das ist z.B. für die Map interessant, so dass man verschiedene Karten speichern kann (beim Einschalten wird eine vorgegebene Umgebungskarte geladen, die aber im Betrieb nicht verändert wird). Oder aber auch für die unter 2.) genannten Bot- Programme auf MMC. Weiterer Vorteil: Es gibt keine Fragmentierung durch das FAT-Dateisystem auf der MMC mehr, an der das jetzige MiniFAT scheitert. Außerdem sollte das Dateisystem auf dem PC als Laufwerk einzubinden sein, so dass man die Dateien einfach mit einem beliebigen Editor bearbeiten kann oder mit normalen Mitteln des Betriebsystems kopieren, löschen usw. Unter Linux und Mac OS X geht das recht einfach über FUSE. Wie man das unter Windows hinbekommt oder ob es mittlerweile eine FUSE-Portierung für Windows gibt, weiß ich nicht, darum ist das Ganze bisher auch nicht fertig geworden. Vielleicht gibt es ja jemanden, der sich da auskennt und sich der Sache annehmen möchte. Unter Linux, Mac und auf dem Bot funktionierten die wichtigsten Datei- / Verzeichnisoperationen ganz gut soweit ich mich erinnere.


Weitere Ideen für Verhalten und andere Dinge fallen mir noch sehr viele ein, hier mal ein paar:

- - Ein neues solve_maze(): Nicht weil das Vorhandene so miserabel implementiert wäre, sondern weil es einfach schon sehr alt ist und somit nicht von den verbesserten Grund-Verhalten profitiert, die es inzwischen gibt. So nutzt es z.B. nicht immer bot_turn(), um den Bot zu drehen usw.

- - Eine Abgrund- / Locherkennung für solve_maze() (oder dessen Nachfolger): Bisher werden Löcher ja komplett ignoriert. Im Wettbewerb hingegen gab es viele neue Labyrinth-Verhalten, die das berücksichtig haben. Wäre auch mal interessant, was aus all denen eigentlich geworden ist...

- - Labyrinth lösen und dabei Gegenstände einsammeln: Wenn man z.B. Dosen in einem Labyrinth verteilt, könnten zwei Bots von zwei Eingängen aus starten und wer am meisten Dosen gesammelt hat, hat gewonnen. Hierbei wäre es gut, wenn sich der Bot merkt, wo er schon war, um nach dem Abtransport der Dose in seine Basis nicht erst wieder den Weg suchen zu müssen. Gleiches gilt natürlich auch schon für den Rückweg zur Basis. Oder man muss die Dosen nur wegschaffen, also eine möglichst lange Strecke komplett frei räumen -> Dosen in Löcher fallen lassen erspart den kompletten Rückweg zur Basis.

- - Mehrfache Instanzen eines Verhaltens: Es wäre sehr praktisch, wenn ein Verhalten auch mehrfach (von verschiedenen Verhalten) gestartet werden könnte. Insbesondere für Notfallverhalten ist das sehr wichtig, um dort nicht jedes Mal das sprichwörtliche Rad neu erfinden zu müssen.

- - Ein deutlich erweitertes Konzept zur Notfallbehandlung: Hier gibt es auch viel zu tun. Im Idealfall wird ein beliebiges Verhalten durch ein Notfallverhalten unterbrochen, das Notfallverhalten korrigiert den Notfall nachhaltig (umfährt z.B. ein im Weg stehendes Objekt oder ein Loch) und anschließend macht das Hauptverhalten mit seiner eigentlichen Aufgabe (beispielsweise Dosen einsammeln) weiter, ohne erneut in dieselbe Notfallsituation zu geraten.

- - Notfallverhalten, die ein Hindernis oder ein Loch voraus wirklich umfahren: Ein sehr einfaches Konzept wäre hier, dass man aus der Bot- Ausrichtung und den Radgeschwindigkeiten beim Eintreffen des Notfalls berechnet, wohin der Bot gerade will. Falls er geradeaus möchte, legt man eine Gerade in diese Richtung und fährt links- oder rechtsherum (bei aktiver Map kann man hier nachschauen, was besser ist) an dem Hindernis oder der Lochkante entlang, bis der Bot die Gerade (das erste Mal) überquert hat. Falls der Bot auf einer Kreisbahn unterwegs war, müsste man die entsprechende Kurve schneiden als Abbruchbedingung.

- - Explore-Verhalten für die Map: Ein Verhalten, das unbekannte Bereiche der Map sucht, dort hinfährt und die Gegend erkundet. Fährt der Bot z.B. auf einer spiralförmigen Bahn, sehen die Distanzsensoren sehr viele Informationen über die Umgebung. Alternativ kann man auch Punkte in der Karte suchen, deren nähere Umgebung unbekannt ist, diese anfahren und den Bot dort um 360 Grad drehen. Anschließend sucht man wieder Punkte in unbekannter Umgebung usw. Auf jeden Fall geht es in erster Linie nicht darum, alles lückenlos abgefahren zu haben (wie bei drive_area()), sondern die Karte so zu erweitern, dass möglichst viele Bereiche bekannt sind. Deutlich vereinfachen lässt sich das Ganze mit dem o.a. Notfallverhalten, das selbstständig Hindernisse umfährt, so dass das Explore-Verhalten einfach "drauf los" fahren muss und man den Code zur Hindernisumfahrung nicht mehrfach braucht.

- - Ich habe letztens gelesen, dass jemand ein Schachprogramm für einen ATmega geschrieben hat. Eine Idee wäre, dass zwei Bots gegeneinander spielen, wobei die Felder halt recht groß sein müssten. Die Figuren stehen dann in der Mitte und die Bots fahren auf den Kanten, um zu einem Feld zu kommen (Pfadplanung für den kürzesten Weg, freie Felder könnte man z.B. auch quer überfahren). Dort sammeln sie die Figur ein (catch_pillar()), fahren zum Zielfeld (Pfadplanung) und laden die Figur dort aus (unload_pillar()). Anschließend muss der neue Spielstand per Bot-2-Bot-Kommunikation an den anderen Bot übertragen werden. Alternativ kann man natürlich auch eine Mensch-Schnittstelle einbauen, vielleicht fährt der Bot dann aber auch die Figuren fauler Spieler ;-) Oder ein echter Bot spielt gegen einen Simulierten.

- - Weitere lustige Aufgaben mit Praxiserfahrung gibt es z.B. auch unter http://www.tu-chemnitz.de/etit/proaut/rk/index.php?id=47 - die meisten waren sehr spannend anzusehen. Macht natürlich mit verschiedenen Teams, die gegeneinander antreten, viel mehr her.

- - Wer mehr an Dingen interessiert ist, die klappern, wenn sie herunterfallen: Eine verbesserte Akku-Überwachung wäre schön, so dass der Bot rechtzeitig mitbekommt, wann ihm die Energie ausgeht.

Einige der Punkte sind auch schon hier aufgeführt: http://www.heise.de/ct/projekte/machmit/ctbot/report/3 - teilweise mit ein paar weiteren Infos.

Grüße,
Timo


Am 28.06.2009 um 21:29 schrieb Frank Menzel:
Hallo,
ist ja in der letzten Zeit recht still um den bot geworden. Liegt?s am
Sommerloch?
Würde mich mal interessieren, was überhaupt gerade so in Vorbereitung
ist, woran gearbeitet wird bzw. was so an Anwendungs-Verhalten noch
wünschenswert wäre

Denn ich leide momentan auch irgendwie an Ideenlosigkeit:-(

Gruß, Frank

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.11 (Darwin)

iEYEARECAAYFAkpIkBkACgkQDH/BX4067fKIfgCgvRysSDQ4+Q+ImPTQo/WDpB6s
EskAnAsREFWG/lpaVT2Qeu2sCxQ2yFP4
=RF/d
-----END PGP SIGNATURE-----