Der Algorithmus (oder das Programm) zur Formerkennung bestimmt maßgeblich den Regelsatz, also auch dessen Größe. Die Frage muß jetzt also korrekt lauten:

Welcher Algorithmus zur Erkennung der Form des Kastens erlaubt den kleinsten Satz an (Fahr-) Regeln?

Zur Formerkennung: Ich bleibe beim einfachen Programm, das aus dem Verbinden der Umkehrpunkte auf die Form schließen soll. Wie wichtig ist die Ausgangssituation (Position des Roboters am Beginn der Tour)? Ist eine möglichst zu den Banden nichtparallele Bahn am günstigsten? Um rechte Bahnwinkel zu vermeiden, soll der Roboter jetzt folgende Regeln einhalten:

1. Fahre so lange geradeaus, bis du nicht gegen eine Wand stößt.
2. Stößt du gegen eine Wand, setze kurz zurück, drehe dich um 30 Grad nach rechts, und befolge wieder Regel 1.

Das ganze soll er solange durchführen, bis er die Umgebungsform ermittelt hat. Wenn dies geschehen ist, soll er der Form von innen in einer Umrundung folgen. Stimmt dabei was nicht, muss er weiter gegen die Wände fahren, eben so lange, bis er einmal ohne Zusammenstoß eine Ehrenrunde gedreht hat.

So, und wie sieht jetzt der Quelltext aus? Geht’s auch ohne Mustererkennung (mit Sicherheit)? Wie viele Annahmen über die Form stecken hier schon von vornherein in der Programmierung? Bei welchen würde die Programmierung versagen.

Das alles muss noch in eine saubere theoretische Form. Folgende Fragen gilt es dabei zu beantworten: Welche Rolle spielt die Ausgangssituation des Roboters? Welche Formen kann der Algorithmus ermitteln, wie gut ist die »Bahnauflösung«?

Was noch?

Nachtrag: Ergodizität, ick hör dir trapsen…

Meinem Asuro habe ich zur Erledigung einer ähnlichen Aufgabe in meinem Büro folgende Regeln in den Atmel geschaufelt:

1. Fahre solange geradeaus, wie du auf keinerlei Hindernisse stößt.
2. Wenn du auf ein Hindernis stößt, setze kurz zurück, mache eine 90 Grad Drehung nach rechts, und folge dann wieder Regel 1.

Die möglichen Bahnen dieses Manövers sehen von oben so ähnlich aus wie die kleinen Windräder, die man als Kind auf dem Rummelplatz zum Lebkuchenherz bekam: ein Viereck mit jeweils verlängerter Kante an jeder Ecke, die vom Zurücksetzen des Roboters herrührt. Das zentrale Problem ist nun, zu verhindern, dass der Roboter zu schnell wieder in die selbe Bahn einschwenkt und damit in eine ständig sich wiederholende Schleife gerät, solange die Batterien halten. Aber wie kann ich jetzt daraus auf die Form des umgebenden Kastens schließen?

Aber dann ist mir ein anderer Gedanke gekommen.

Kehren wir zur ursprünglichen Fragestellung zurück: Ein Roboter fährt eine Bahn ab und protokolliert sie. Wie wahrscheinlich ist es, dass er selbst bei penibelster Programmierung (was das kleinere Problem wäre) und optimaler technischer Präparierung (schon wesentlich schwieriger) jemals wieder auf die selbe Spur gerät? Null. Oder etwas das nur unwesentlich von Null verschieden ist. Und dieses etwas sinkt mit jeder angenommenen Umrundung, d.h. selbst wenn der Roboter später noch mal in die selbe Spur geraten sollte, was wie gesagt entsetzlich unwahrscheinlich ist, würde er es noch entsetzlich unwahrscheinlicher ein weiteres mal tun. Ganz zu Schweigen von den Wahrscheinlichkeiten für eine absolute Bahnstabilität, und je länger man darüber nachdenkt, umso mehr Unwahrscheinlichkeiten fallen einem ein.

Kurzum, diese vollkommene Bahnstabilität tritt in der Realität nicht ein. Die wird eher so aussehen, dass der Roboter mit jedem Einschwenken in eine bereits abgefahrene Bahn um einen bestimmten Betrag von dieser abweicht. Viel wahrscheinlicher ist also eine Bahn, die so aussieht wie eine etwas kantig geratene Rosette, Lissajouschen Figuren nicht unähnlich. Das geht dann so lange, bis der Roboter bei seiner Drift fast parallel und sehr nahe an eine Kante gerät. Dann kommt ein chaotisches Element hinzu, weil man jetzt nicht mehr voraussagen kann, wann die Drucksensoren reagieren, und dieser „Streifschuss“ in eine neue Bahn mündet. Erst wenn der Roboter wieder den Rückwärtsgang einlegt stellt sich wieder das Bild mit den einbeschriebenen Quadraten ein.

Wie muss ich also, bei einem derartig zu erwartenden Protokollverlauf, die Software programmieren, um auf das Quadrat schließen zu können?

Der primitivste Weg ist eigentlich, nach ausreichend langer Fahrzeit immer jeweils die Umkehrpunkte des Roboters mit ihren nächsten Nachbarn zu verbinden. Dann müsste schon von alleine ein Quadrat zum Vorschein kommen.

Nachtrag: Bahnverhalten noch mal überdenken! Simulation programmieren mit „eingebauter“ Drift.

Nachtrag: Das Problem muss von der anderen Seite angegangen werden! Der Rekonstruktionsalgorithmus liefert letztendlich die Form des Kastens! Je mehr möglichst dicht beieinanderliegende Umkehrpunkte existieren, umso besser wird die Form wiedergegeben. Wie sieht also der Satz von Regeln aus, der diese Umkehrpunkte am besten liefert?

1. Fahre solange geradeaus, wie du auf kein Hindernis stößt.
2. Wenn du auf ein Hindernis stößt, setze kurz zurück, drehe dich um 90 Grad, fahr kurz geradeaus, stoppe, drehe dich um 90 Grad zurück und befolge wieder Regel 1.

Die langwierigen Erörterungen über die möglichen Bahnen erübrigen sich dann (hoffentlich). Wieviele Regeln sind das jetzt eigentlich? Ist das optimal (glaube ich nicht)? Beweis!

Nachtrag: Hat sich jetzt erledigt… (siehe Eintrag M II)

Worin liegt eigentlich der genaue technische Vorteil derartiger Ansätze? Der wichtigste ist natürlich das Prinzip Biene (oder Ameise oder Wespe oder sonst irgendeines schwarm- und staatenbildenden Insektes). Jedes Insekt für sich ist kaum schlauer als das Stückchen Apfelkuchen, das es vom Krümelhaufen auf meinem Teller zum Nest zu schleppen versucht. Zusammen aber bauen sie riesige Nester, ernähren abertausende Larven und bekämpfen jeden Eindringling bis zur Selbstaufgabe. In wieviele Funktionseinheiten ist z.B. ein Ameisenhaufen aufgeteilt? Arbeiter, Soldaten, ein paar Drohnen und die Königin? Und was, oder besser wieviel kann man mit dieser Aufteilung erreichen? Jedenfalls gilt hier ganz klar: die Menge macht’s.

Und diese Frage, die Frage nach der Anzahl der einzusetzenden Einheiten in Abhängigkeit von der Komplexität der Aufgabe, ist die Frage die ich gerne klären würde. Wieviele Roboter brauche ich, um unbekanntes Gelände zu kartografieren, wieviele um einen Garten anzulegen mit Blattspinat, Tomaten und einem Blumenbeet mit saisonal wechselnder Blütenfolge? Nicht der eine komplizierte Alleskönner für zweieinhalb Millionen ist hier gefragt, sondern die 10, 20 oder 100 Billigsteinheiten für 15, 95 das Stück.

Nachtrag: Jede Funktionseinheit verfügt über einen Satz von Regeln, z.B. die Arbeiter über die Regeln „Futter suchen“, „Futter ins Nest transportieren“ und „einem weiteren Arbeiter Futterplatz mitteilen“. Wie sehen die Koordinierungsregeln aus? Braucht man überhaupt welche (Selbstorganisation)?

Mit meinem Lecksuchgerät ist es irgendwie anders. Mit dem Gerät scheint sich sogar das Problem zu ändern. Das ist natürlich Unsinn, aber bei der Auseinandersetzung mit dem Gerät habe ich ständig neue Einsichten in das Problem, und mit neuen Einsichten kommen neue Ideen, mit neuen Ideen neue Lösungen und mit neuen Lösungen neue Geräte…

Wie oft hätte ich gerne jemanden gefragt. Wie oft frage ich jemanden, und innerhalb kürzester Zeit erreiche ich mehr als in tagelanger Klausurarbeit.

Die Idee ist ebenso einfach wie alt: Überall gibt es Leute, die jeweils einen Teil der Lösung kennen. Man muss sie nur irgendwie zusammenbringen. Das Internet scheint die perfekte Lösung zu sein: Raum und Zeit sind in ihm aufgelöst.

Die nächste Frage ist die Technik. Allgegenwärtig ist das Chatten, mittlerweile sogar mit Video. Nur mit dem Schreiben von Formeln, gemeinschaftlichen Zeichnen, eben der echten „Lehrraumsituation“ hat das nur wenig zu tun.

Beim Suchen in den unendliche Netzweiten stoße ich auf VNC. Alte Technik, daher zuverlässig und meistens kostenlos. Allerdings eher was für den Austausch im kleinen Kreise. Ab 5 Leuten wird’s zum Tanz. Ab 8 muss man schon sehr diszipliniert arbeiten, um sich nicht ständig gegenseitig in die Mausspur zu fahren. Das Netz ist groß, aber eng.

Als nächstes komme ich auf sog. „Collaborative Software“. CITRIX ist hier Marktführer. Alles ganz hübsch, aber nur für Windows. Die enge Ankopplung und gegenseitige lizenztechnische Verwurstelung passt mir irgendwie nicht. Man hat ständig das Gefühl, entweder gerade gegen einen Vertrag zu verstoßen, oder einen abzuschliessen, ohne es zu wollen.

Am Ende bleiben 2 Lösungen. Die eine, Marratech, hat gerade einen Teil ihrer Software an Google verkauft. Die andere, Yugma, braucht nach eigenen Angaben noch ein bisschen Entwicklungszeit, bis sie auch auf einem Linux-Server problemlos läuft. Einen klitzekleinen Haken haben allerdings beide: umsonst geht gar nichts. Im Gegenteil.

Seit einigen Jahren arbeite ich an einem raketenlosen Verfahren für eine permanente Anbindung des Orbits, um den Transport von Gütern und Menschen in sehr große Höhen billig zu bewerkstelligen (alle Aufzüge lassen grüßen). Thematisch würde das in diesen X-Prize Rahmen passen – wenn ich noch jemanden finden würde, der die restlichen paar tausend Kilometer überwindet. Das Verfahren ist nur der erste Schritt bis an den Rand der Atmosphäre. Nicht nur von da an sind neue Ideen gefragt…