{28} Active Tickets by Owner (Full Description) (7 matches)

solve_maze() sollte bei allen Messungen ADJUST_DISTANCE berücksichtigen und außerdem ein paar Messwerte der Distanzsensoren abwarten, hierfür bietet sich das neue Verhalten (#115) an.

Derzeit löst ein Notfall-Verhalten den Aufruf aller Notfall-Funktionen aus. Dies kann aber manchmal gar nicht so sinnvoll sein: Bsp: (konstruiert) Der Bot folgt einer Wand. Nun sieht er links und vorne eine Wand => dreht nach rechts. Dann will er wieder vorwärts fahren und trifft dabei auf einen Abgrund. Jetzt springt das Notfallverhalten "avoid border" an und danach werden die registrierten Notfall-Funktionen abgearbeitet. Darunter auch "der hang on handler" vom hängenbleiben Verhalten und er fährt rückwärts. Dabei bleibt er an der Wand hängen. Oder: Unload Pillar bleibt an ner Wand hängen => Notfallfunktion border_in_map_handler trägt einen Abgrund in die Map...

Mein Vorschlag: Jedes Notfall-Verhalten bekommt eine ID (2er-Potenz). Bei "anspringen" des Verhaltens wird diese ID in eine globale Variable gespeichert. Jede Notfall-Funktion erhält eine Reaktions-Maske. Der Aufruf der Notfall-Funktionen erfolgt wie bisher. Wird nun eine Notfall-Funktion aufgerufen kann diese Funktion die globale Variable mit der eigenen Reaktions-Maske vergleichen und so nur auf bestimmte Notfälle reagieren, beziehungsweise auf Notfälle unterschiedlich reagieren. Sind alle abgearbeitet wird die ID auf 0 gesetzt.

void notfallfunktion_XYZ(void) {
   if(global_emergency_id & my_reaction_mask == 0)
       return;
   else {
       if(global_emergency_id == AVOID_BORDER_ID) {
             // ...
       }
       else if(global_emergency_id == HANG_ON_ID) {
             // ...
       }
   }
}

Drei Erweiterungen des Verhaltenssystems könnten eine deutliche Verbesserung bringen:

• Die Möglichkeit, ein Verhalten auch mehrfach zur selben Zeit starten zu können (z.B. kann ein Notfallverhalten dann bot_turn() benutzen, obwohl das zur Zeit eigentlich aktive Verhalten bereits einen bot_turn()-Aufruf ausgeführt hat).
• Jedes Verhalten kann die Frequenz, mit der es aufgerufen wird, selbst bestimmen (--> periodische Task).
• Ein Verhalten kann auf Grund von Abhängigkeiten blockiert werden (z.B. wird ein Verhalten, das auf die Map zugreift, nur dann geschedult, wenn die Map (MMC) nicht im Zugriff / gesperrt ist - derzeit werden in diesem Fall alle Verhalten blockiert).

Eine Lösung für alle o.a. Punkte ist nicht gerade trivial, letztlich läuft das Ganze vermutlich auf Multithreading / ein Mini-OS hinaus.

Insbesondere stellt sich die Frage, inwieweit solch ein Verhaltenssystem (und die Verhalten selbst) zum bisherigen System kompatibel sein kann und muss.

Direkt profitieren würden davon das bot_drive_area()-Verhalten (Map-Überwachung), die Notfallverhalten sowie ein Explore-Verhalten, das ähnlich wie ein Notfallverhalten unbekannte Hindernisse umfährt und anschließend weiter die Umgebung erforscht.

Weitere Information in der  Mailingliste (siehe auch Vorgänger und Nachfolger).

Vereinfachung beim EEPROM für MCU und PC: Wenn man einfach alle EEPROM-Variablen in ein Struct packt und nur das in die EEPROM-Section legt, hat man eine feste Ordnung und kann die Variablen über ihren Namen ansprechen.
Für den einfachen Zugriff kann man noch ein kleines Makro machen, so dass der Anwender gar nichts vom Struct mitbekommt. Außerdem ist es für MCU und PC identisch, beim Start liest man einmal die Datei ein, schreibt die Daten an die Adresse des Structs im RAM und fertig, es muss keine aufwendige Zuordnungstabelle erstellt werden, man braucht keine Linker-Map, Post-Build-Schritte usw.