RP6 mit MetaController

[schmiereck]

Hi,

ich habe gerade das "RP6Base_Move_05" des SP6 Example nach C++ portiert und die BehaviourCommands als Klassen rausgezogen.

Nun habe ich folgende Idee für einen "MetaController":

Es gibt Verhaltenweisen die von einer "übergeordneten" Instanz (dem "MetaController") ausgewählt werden und alternativ verwendet werden können.
Idee ist es z. B. zwischen einem "FollowWall" und dem "Avoid" Behaviours umschalten zu können.

Ziel ist es, ein Bewegungsverhalten zu bekommen, das zwar flexibel ist,
aber einer einem festgelegt Weg folgen kann. So in der Art und Weise:
Fahre bis zur Wand. Folge ihr 2 m nach links. Drehe dich nach links. Fahre bis zur Wand. ...

Diese Wege können auch "gelernt" werden, wenn sie einmal zu einem Ziel geführt haben.

Der Robot könnte auch Anhand eine Vergleiches des aktuellen Weges mit schon gespeicherten
Wegen erkennen, auf welchen er sich momentan befindet und in diesen "einrasten".
Er würde also so etwas wie eine allgemeine und recht flexible Karte haben.

Hat jemand schon einmal von etwas ähnlichem gehört und weiss auch schon, woran ich scheitern werde? ;-)

Übrigens, die Sourcen des (Eclipse AVR Plugin) Projektes stehen auf SF zur Verfügung: http://raumschach.cvs.sourceforge.net/viewvc/raumschach/mover2/

Grüße,
Thomas Schmiereck

[shedepe]

Ist der Mega32 des RP6 nicht etwas unterdimensioniert für dein Vorhaben ?

[schmiereck]

Hallo,

sicherlich :-b

Aber es gibt ja für den RP6 noch das Erweiterungsboard - die ist ja, denke ich, genau für solche mehrschichtigen Architekturen gedacht.

Vorerst geht es mir ja erst einmal nur um den prinzipiellen Beweiss das es funktioniert. Hardwaremäßig kann das ja alles je nach Bedarf erweitert werden.

Bisher kann ich aber sagen, das ich sehr erstaunt bin was mit so ein wenig Silizium alles schon möglich ist. Ich hätte auch gedacht, das mir das alles schon viel früher um die Ohren fliegt - ist schon lange her, dass ich beim Programmieren gespannt auf den Bytezähler geschaut habe und nicht auf die MB ;-)

Was ich in Bezug auf C++ noch hinzufügen will:

1. Die "virtual" Funktion für die Behaviours von C++ scheint einige Bytes zu "fressen", hier sollte man überlegen, ob es eine bessere Alternative gibt - aber wenn es dabei bleibt kann ich damit leben, ist ja schon elegant.

2. Das Verhalten der new/ delete Operationen im BehaviourController für die aktiven Behaviours kann ich noch nicht abschätzen. Ich denke aber das die keine große Defragmentation hervorrufen werden, da sich die Speichergöße im Grunde nicht ändern wird.

3. Ansonsten sind die Größen für die C und die C++ Version weitgehend gleich, wenn man sieht, das ich bei der C++ Version viel öfter mit Funktionen statt C&P für die "gleichen" Dinge wie in den Examples für den RP6 arbeite, sinkt sie sogar etwas. Dafür steigt natürlich der Stackbedarf etwas an...

Grüße,
smk

[schmiereck]

Hallo,

der aktuelle Stand des Projektes ist folgender:

Zur Erklärung der Begriffe, States sind die Zustände die der Zustandsautomat eines Verhaltens (Behaviours) einnehmen kann.

Die Aufzeichnung funktioniert, es werden nach jetzigen Stand 2 Bytes pro State-Wechsel benötigt (ein Byte würde reichen, wenn jedes State eine Orientierung (LEFT/ RIGHT) hätte.

Es wird ein Meta-State-System benötigt, um für jeden State abfragen zu können ob und welche Orientierung (LEFT/ RIGHT) er hat und wenn ja, welcher State der mit eine inversen Orientierung ist.

Nicht aus jedem State löst sich seine Orientierung ablesen, manche sind "symetrisch" und die Orientierung des Verhaltens hängt von einem weiteren, internen, Zustand des Behaviours ab.
Die Entscheidung nicht jeden State "orientated" zu machen resultiert aus der Erkenntnis, das damit der State-Automat viel einfacher aufzubauen ist, da nicht für jedes Verhalten eine komplette Links- und Rechts-Abfolge aufgebaut werden muss.
Es wird zwar nun eine zusätzliche Schnittstelle zur Abfrage der internen Orientierung des Verhaltens benötigt, aber da diese einheitlich aufgebaut werden kann, ist dies nicht weiter Aufwändig.

Speicherstand: 0x37C0 von 0x77FF ;-)

Grüße,
smk

[schmiereck]

Das Zusammenspiel zwischen einem BehaviourController und einem MetaController funktioniert ganz gut. Abhängig von dem momentanen Zustand kann der MetaController auf alternative Behaviours umschalten.
Aber ich habe folgendes festgestellt:

MetaController
Momentan ist das Aufzeichnen und die Suche nach Ähnlichkeiten im Verhalten direkt an die Behaviours gekopplelt. Das erkennen, ob er z.B. 5 oder 8 Obstacle-Side States zur Verfolgung eines Wandabschnittes beim "FollowWall" benötigt ist schwierig.

Deshalb:

ReflectionController
Ausgehend von den bisherigen Versuchen glaube ich, dass noch ein "Reflection"-Controller zwischen dem BehaviourController un dem MetaController benötigt wird.
Insbesondere das Verhalten des "FollowWall"-Behaviour ist zu komplex um es direkt in der einen oder anderen Schicht zu behandeln. Beispiel sei hier das erkennen, ob der "FollowWall" gerade einer konkave- oder konvexe-Biegung folgt. Für den Behaviour ist es einfach nur eine Wandverfolgung, für die übergeordnete Ebene ist es interessant, welchen Winkel diese gerade hat.
Weitere auf diese Ebene implementierbare Funktionen sind der Zusammenhang zwischen der aktuellen
Ausrichtung des Robots (Odometrie, Licht, Kompass, Kamera-FixingPoint, ...) und seinen Bewegungen.

Speziell beim "FollowWall" fehlt mir eine Zwischenschicht zwischen dem komplexen Bewegungen und dem "was mache ich momentan".
Auch das zum Teil relativ komplexe "Escape" Verhalten wäre hier besser aufgehoben, das eine "Ich sitze in der Falle" Verhalten implementiert.

Ergebnis ist, dass der Meta-Controller nicht ganz so "feingestaffelte" Verhalten beobachen muss, wie momentane und die Suche nach Wiederholungen einfacher wird.

Gruß.
smk