Scheduler

Wir haben uns nun dazu entschieden, einen simplen Scheduler zu nutzen. Die ganzen Echtzeitbetriebssysteme (soweit man sie überhaupt so nennen kann) haben alle so viele vermeintliche Sicherheitsmaßnahmen (also z.B. bei jedem noch so kleinen Fehler in eine Endlosschleife fahren), was auf jeden Fall den ganzen Wertungslauf kaputt machen würde. Wir brauchen ja auch nicht diese ganzen Funktionen wie während der Laufzeit Tasks erstellen – wir wissen ja schon vorher, was in welchem zeitlichen Rhythmus aufgerufen werden muss. Genauer haben wir uns nun schon den RIOS-Scheduler, entwickelt von der University of California, angesehen (für detailliertere Informationen siehe hier). Der ist schlank, relativ simpel und scheint zu funktionieren – weiteres wird noch getestet.

Wir würden unser Programm so aufteilen:

  • Labyrinth→ 25ms
    Zeitkritische, aufeinander basierende bzw. aufbauende Aufgaben des Systems, die allerdings nicht auf bestimmte Ereignisse warten (keine Schleifen), sondern nur berechnen:
    Mapping, Navigation, Fahranweisungen, Geschwindigkeitsregelung
  • Auswerten digitaler Sensoren → 10ms
    Wärmesensoren und IMU
  • Auswertung des ADC’ → 1ms
    (Es wird jede Millisekunde ein Kanal ausgewertet und per Median (3 – 5 Messungen) gefiltert, somit sind alle 16 Kanäle in 48ms aktualisiert. Diese Auswertmethode hat den Vorteil, dass sie keine Schleife benötigt, die Rechenzeit verschwendet, in der auf das Ergebnis der AD-Wandlung gewartet wird (es wird ja zwischen Start der Wandlung 1ms gewartet, bis der Task erneut aufgerufen wird, in der Zeit ist die Wandlung auf jeden Fall beendet). Das reicht völlig aus, da die analogen Sharp Entfernungssensoren sowieso nur alle 39ms ihren Ausgang aktualisieren. Wir haben nun ein Array, bei dem jeder Eintrag alle 48ms aktualisiert wird, in dem die Analogwerte mediangefiltert für jeden Kanal gespeichert werden.
  • Sonstiges (zeitkritisch) → 1ms
    Software-Timer und Inkrementalgeber
  • Sonstiges, nicht zeitkritisches (Status LEDs, Display…), in der Hauptschleife

Wir haben die Anzahl der Tasks bewusst möglichst gering gehalten. Man hätte die Aufgaben noch weiter differenzieren können, das hätte aber evtl. eine höhere Fehleranfälligkeit zufolge und macht den Verlauf des Programms schlechter Vorhersehbar.
Die Software ist so recht strukturiert aufgebaut. Wie vielleicht aufgefallen ist, haben wir keinen Task für die Kamera. Das haben wir bewusst so gemacht, denn wir werden der Kamera nun doch sehr wahrscheinlich einen eignen Mikrocontroller spendieren. Es wäre sicherlich möglich, die Kamera in unsere Software einzubringen, aber das ist mit verhältnismäßig viel Aufwand verbunden und würde das System doch recht stark auslasten. Dazu mehr, wenn es so weit ist.

Außerdem haben wir nun endlich unsere Geschwindigkeitsregelung endgültig verbessert. Problem war, dass der Regler zu träge war, es also zu lange gedauert hat, bis die Soll-Geschwindigkeit erreicht wurde, was zu Folge hatte, dass der Roboter je nach Geschwindigkeit mal etwas länger, mal weniger lange gebraucht hat, bis er von 100% vorwärts auf 100% rückwärts geschaltet hat. Nun ist die Regelung sehr präzise und sollte sehr schnelle Fahrmanöver ermöglichen.

Des Weiteren haben wir in unser Setup-Menü einen Menüeintrag „Debug” hinzugefügt, in dem verschiedene Debuggingstufen eingestellt werden kann. Je nach Grad werden so per Bluetooth detaillierte Meldungen über das, was gerade im Roboter geschieht, ausgegeben.

Wir sind somit in unserem schon recht lockerem Zeitplan recht weit nach vorne gekommen, was nicht schlecht ist. So bleibt uns mehr Zeit zum Testen.