So, um das Ganze ein bischen zu strukturieren:

Step 1: Vereinbarung einer Datenstruktur, um µ-Maps auf einem µ-Controller zu speichern. Dateiformat ist hier wohl zu hoch gegriffen. Eine einheitliche Struktur würde aber die Wiederverwendung von Code-Snippets vereinfachen. Mein Vorschlag: Rasterdaten mit 4 Bit / Pixel. Damit lassen sich genug Werte codieren, um
- befahrbar
- nicht befahrbar
- hier bin ich
- hier steht eine Bake
- undefiniert
- "gestern war hier noch frei heute steht hier was ist es vielleicht die katze?"
zu codieren.
Für den Zugriff auf die Karte sollte man einen Satz passender Funktionen bauen, damit ist dann auch das Aufsplitten in die oberen/unteren 4 Bit verkapselt. Im ersten Schritt könnte die Karte auch erstmal "fest" codiert werden, d.h. händisch erstellt und geladen. Man kann davon ausgehen, den Bot beim Start auf ein definierte Position zu stellen bzw. ihm seine Position mitzuteilen. Orientierung und Rückkehrgenauigkeit stellen die erste Herausforderung an den Bot und seine Steuerung - Navigation - Odometrie. Eine zweite/dritte "Ebene" würde ich an der Stelle für überflüssig halten (oder gibt es da einen Anwendungsfall für?)

Step 2a: Aufbau der Karte durch den Bot selber. Dabei sollte es darum gehen, die Daten vom Bot selber erfassen zu lassen. Heraus kommt dabei eine Karte, die weniger in "go vs. nogo" eingeteilt ist, als grundsätzliche "wo könnte ich fahren"- Informationen. Praktische Herausforderungen werden sein, passende Filter für die Bewertung der Sensorinformationen zu entwickeln. Wann wird ein Pixel "schwarz", wann wird es "weiß"? Was mache ich mit wiedersprüchlichen informationen unterschiedlicher Sensoren? Was mache ich mit Wiedersprüchlichen Informationen zwischen Karte und Sensor-Input?

Step 2b: Die Orientierung innerhalb der Karte. Geht man in Step 1 und 2a noch davon aus, daß der Bot auf einem definierten Startpunkt steht, ist es natürlich spannender wenn er "spontan" beim Einschalten seine Position erkennen kann. Was man Outdoor mit DGPS halbwegs lösen kann, ist indoor eine andere Aufgabenstellung. Hier finde ich die Überlegungen zu einem "Local Positioning System" sehr gut, "Leuchttürme" die rotieren und dabei die Winkelinformation verschicken. Damit können die aufsummierten Fehler der Wegeerfassung wieder ausgeglichen werden.

Bis hierhin sollte das alles auf dem Mikro-Controller gelöst werden können.

Step 3ff: Kommunikation mit einem Steuer-PC. Dabei spielt es keine Rolle, ob der PC "onboard" sitzt oder per Funk angebunden ist. Also:
- Karten upload
- Karten download
- Statusabfragen
- Steuerbefehle
- rendern einer Pixel-Karte aus der "großen" Vektorkarte

Als Datenformat auf dem PC würde ich entweder ein XML-basiertes Format vorschlagen, oder einen offenen Standard aus der 3-D Welt. Letzteres hätte den Vorteil, daß es Viewer fertig gibt. Ersteres wäre "human readable" und könnte einfach in Datenbanken abgelegt werden.

Soweit erst mal.
Reinald