CMUCam – Kommunikationsprobleme

Leider bereitet uns die CMUCam, die wir zur Detektierung der Hindernisse benutzen möchten, noch einige Schwierigkeiten. Bis jetzt war geplant, dass die Kamera über I²C ausgelesen wird. Problem dabei ist, dass sie gepollt werden muss, die muss also ständig gefragt werden, ob neue Daten zur Verfügung stehen. Wenn die Daten dann nicht schnell genug abgefragt werden, gehen Daten verloren. Halbwegs gut funktioniert hat das bis jetzt lediglich mit einem weiteren Scheduler Task, der alle 20ms (Kamera verarbeitet Bild mit 50Hz) die Kamera abfragt. Nun kommt der Scheduler aber aufgrund der vielen auszuführenden langsam in Bedrängnis – manchmal werden Tasks nicht komplett ausgeführt (wenn die Kamera zu viel Zeit für sich beansprucht) und bestimmte, teils wichtige Dinge (Encoder auswerten) werden vergessen. Deshalb wollen wir die Kamera nun über die serielle Schnittstelle auslesen. Hier sendet sie einfach alle Daten zum Roboter, sobald etwas detektiert wird. Hier können in einem Stapelspeicher die Daten dann auf die Verarbeitung warten. Anscheinend gibt es da aber noch ein paar Kommunikationsprobleme.

Wir wollen uns nun vorerst voll den Rescuekits und den Checkpoints widmen – die beiden Aufgaben haben gerade höhere Priorität. Danach sehen wir, wie es mit der Kamera weitergeht. :)

CMUcam, Ultraschallsensoren und was sonst noch zu tun ist…

Nachdem ein Monat lang kein neuer Beitrag kam, nehmen wir uns jetzt mal  wirklich, wirklich, wirklich, versprochen vor, öfters etwas zu schreiben 😀 Wir setzen mal als grobes Ziel mindestens einen wöchentlichen Blogeintrag.

In diesem Monat ist nicht sonderlich viel passiert, da wir relativ wenig Zeit für den Roboter hatten. Wir liegen aber sehr gut in unserem Zeitplan, weshalb das kein großes Problem ist.

Im Folgenden einmal eine kleine To-Do Liste mit Dingen, die auf jeden Fall noch bis zur WM erledigt werden müssen:

  1. Fehler bei einem der Entfernungssensoren:
    Einer der Sensoren scheint nicht richtig zu funktionieren (Werte springen). Eventuell hängt das mit Reflektionen zusammen, da müssen wir also die Abschirmung noch optimieren.
  2. Kollisionserkennung 2.0:
    Unsere Kollisionserkennung hat bis jetzt sehr gute Dienste erwiesen, durch die Integration der neuen Ultraschallentfernungssensoren konnte sie noch einmal weiter verbessert werden und kann nun Objekte, die wie im folgenden Bild platziert sind, optimal umfahren:
    Unter Umständen kann der Roboter trotzdem noch an Hindernisse, die ungünstig an der Wand befestigt sind, hängen bleiben. Das soll vermieden werden, indem der Roboter seinen Winkel zur Wand auswertet und, wenn dieser zu groß ist und die Entfernungssensoren auf der entsprechenden Seite kleine Distanzen liefern, kann der Roboter sich neu ausrichten.
  3. Hindernisse:
    Hindernisse müssen einen Mindestabstand von 20cm zur Wand haben, da unser Roboter nun eine Breite von 19cm hat, passt das optimal. Hindernisse wie in Punkt 2 (Kollisionserkennung) werden nicht in der Karte berücksichtigt und können grundsätzlich von den Fahrfunktionen (in der Hierarchie der Software relativ weit unten) umfahren werden.

    Schwierig wird das Ganze bei Hindernissen, die nicht in der Nähe von Wänden und mitten auf einer Fliese platziert sind:

    Der Roboter würde dieses Hindernis, da es zu klein ist, nicht als Wand einzeichnen und somit versuchen, geradeaus zu fahren. Der Roboter passt sich dann an dem Hindernis an und denkt u.U. sogar, dass er auf der Fliese in der Mitte stehen würde. Da er das Hindernis zunächst nicht richtig als Wand einzeichnen kann, wird er einige Male auf der Stelle drehen und wahrscheinlich bald seine Position in der Karte verlieren.
    Mithilfe der CMUcam5, die wir bereits einmal erwähnt haben, wollen wir diese Hindernisse erkennen. Das sieht so aus:
    Oben auf dem Roboter sieht man die nach unten gerichtete Kamera, unten ein paar LEDs. Diese LEDs projizieren helle Punkte auf Hindernisse (hier eine Rolle Klebeband, auch erlaubt). Die Kamera erkennt diese Punkte dann und gibt die Position der erkannten Objekte dann an den Roboter weiter (auf dem Laptop Darstellung mithilfe des mitgelieferten Tools; Man sieht da die weißen Kästen um die grünen Punkte, der Roboter bekommt nur diese Information). Auf Basis der Lage der Punkte zueinander lässt sich die Form und Größe des Hindernis erkennen. So kann erst einmal ein Hindernis generell von einer Wand unterschieden werden, ggf. wird das Hindernis dann auch in die Karte eingezeichnet und die Fliese somit nicht mehr besucht. Der Roboter kann dann zurück auf die letzte Fliese ohne Hindernis fahren. Unterstützt werden kann das zusätzlich durch die Auswertung der gefahrenen Distanzen über die Odometer, das kann aber wirklich nur als Unterstützung dienen, da sie relativ ungenau sind.

  4. Opfererkennung:
    Die Opfererkennung wird nochmal etwas komplizierter. Das größte Problem ist der richtige Abwurf der Rescuekits: Die RescueKits dürfen nicht weiter als 15cm vom Roboter entfernt landen. Unser Kitdropper befindet sich ganz hinten am Roboter, während sich die Wärmesensoren ganz vorne befinden (wichtig, damit auch Opfer, die sich in Ecken befinden, erkannt werden können). Wenn also, sobald die Wärmesensoren ein Opfer erkennen ein Kit abgeworfen werden würde, wäre es zu weit vom Opfer entfernt. Der Roboter muss sich also auf der Stelle drehen. Schwierig wird das, wenn der Roboter sich gerade schon in einer Drehprozedur befindet, da dann Variablen überschrieben werden würden (Drehprozedur von Drehprozedur unterbrechen geht aktuell nicht). Der Roboter muss also zwangsläufig erst alle Fahrprozeduren beenden und ist dann u.U. noch weiter vom Opfer entfernt. Außerdem müsste dann während der Fahrprozeduren die Wand gescant werden und geprüft werden, ob es einen Ausschlag bei der Temperatur gab und dann müsste zu der entsprechenden Stelle zurückgefahren werden. Das hätte den Vorteil, dass der Roboter auch analysieren kann, ob es nun zwei oder sogar mehr Opfer auf einer Fliese gab (dann müssten auch entsprechend viele Rescuekits abgeworfen werden), was dahingehend wichtig ist, weil wir nur pro Wand einzeichnen können, ob es Opfer gab oder nicht. Es gibt also auf jeden Fall einiges zu berücksichtigen. Eventuell machen wir die Wärmesensoren auch einfach ganz nach hinten, sodass das Rescuekit dann immer nur noch wenige cm vom Opfer entfernt ist… Das ist aber nicht optimal.
  5. Rampe:
    Die Rampenerkennung erfolgt bis jetzt „statisch“: Wenn die Rampe einmal irgendwo eingezeichnet wurde, kann sie nicht mehr herausgelöscht werden. Das hat den Nachteil, dass der Roboter die Rampe unter Umständen an einer falschen Stelle einzeichnet (wenn er z.B. ein Hindernis hochfährt, was aber normalerweise in Zukunft nicht mehr passieren darf). Dann kann zum Einen die Rampe nicht mehr eingezeichnet werden, wenn der Roboter an der richtigen Stelle angekommen ist und zum Anderen kommt der Roboter ins Rampenfahrprogramm, wenn der Roboter an dem Hindernis hochgefahren ist. In Zukunft soll der Roboter daher grundsätzlich eine Fliese fahren, auch, wenn er glaubt, dass sich vor ihm eine Rampe befindet (wenn er die zuvor schon einmal eingezeichnet hat), um diese Information zu Unterstützen oder zu Widerlegen. Weiterhin soll das Rampenfahrprogramm optimiert werden; Steile Rampen sind nur schwer zu bewältigen und die Bedingung, wann die Rampe zu Ende ist, müssen nicht immer so zutreffen, wie es aktuell ist (Wand vor dem Roboter wird erkannt).
  6. Erkennung eines Eingriffes:
    Es gibt nun silberne Fliesen, die Checkpoints darstellen, bei einem Lack of Progress (der Roboter durchquert eine schwarze Fliese, es gibt keinen Fortschritt mehr oder wir rufen ihn aus (wenn wir z.B. sehen, dass der Roboter einen Fehler in der Karte hat)) muss der Roboter nicht mehr zur ersten Fliese des aktuellen Raumes zurückgesetzt werden, sondern zum letzten besuchten Checkpoint, dargestellt durch silberne Fliesen. Die Position darf dem Roboter nicht mehr manuell mitgeteilt werden, er muss also die letzte Position selbst mitspeichern. Außerdem muss er erkennen, wenn er hochgehoben wird (es dürfen keine Tasten gedrückt werden), dann setzt er sich zurück zur letzten gesicherten silbernen Fliese und sobald er wieder steht, macht er normal weiter.
  7. SLAM:
    Diesen Punkt haben wir schon einige Male zuvor erwähnt. Im Rahmen meiner Facharbeit, die ich hier evtl. auch noch hochlade, habe ich mich mit den Möglichkeiten der Erkennung eines Fehlers beschäftigt und wie der Roboter diesen Fehler in der Karte beseitigt. Wir gucken aber mal, wie viel Zeit wir zum Schluss noch übrig haben. Wenn es dazu kommt, widmen wir dem Thema aber noch einen eigenen Blogeintrag.

Es gibt also noch einiges zu tun, wir haben aber nun  noch ziemlich genau zwei Monate Zeit bis zur WM und bis dahin sollte das locker geschafft sein :)