Vorqualifikationen in Oldenburg

Vom 4. bis zum 6. Februar fanden die Vorqualifikationen in Oldenburg zu den deutschen Meisterschaften in Magdeburg statt. Die Roboter AG unserer Schule hat mit insgesamt 45 Teilnehmern teilgenommen.

Da nach den Regeln gespielt wurde, die auch schon für die WM gegolten haben, mussten wir fast gar nichts am Roboter ändern (was wie gesagt auch die nicht-Aktivität im gesamten letzten Halbjahr begründet 😉 ). Wir haben lediglich an einigen Stellen der Software optimiert und einige Fehler beseitigt (Fehler, die uns besonders bei der WM auch einige Probleme bereitet haben, wie zum Beispiel die Falscherkennung von schwarzen Fliesen und das sporadische überspringen von Fliesen in der Karte).
Als Optimierungen ist besonders die verstärkt objektorientierte Implementierung der Software zu nennen. Viele elementare Fahrfunktionen (eine Fliese geradeaus fahren, 90° drehen) sind bis zu zwei Jahre alt (wir sind angefangen zu programmieren, als wir das erste mal eine Karte erstellen wollten). Diese Fahrfunktionen wurden dann bei bedarf erweitert und optimiert. Zuletzt waren sie sehr komplex und die einzelnen Komponenten haben nicht mehr perfekt miteinander gearbeitet (was das Überspringen von Fliesen verursacht hat), weshalb die Funktionen entkernt und überarbeitet wurden. Die objektorientierte Programmierung hat nun den Vorteil, dass theoretisch mehrere Fahranweisungen gleichzeitig und unabhängig voneinander abgearbeitet werden kann. Besonders wichtig ist dies beim Abwurf des Rescuekits: Der Roboter muss sich bauartbedingt um 90° drehen, nachdem ein Opfer erkannt wurde, um das Rescuekit möglichst nah am Opfer abzuwerfen. Wenn der Roboter nun ein Opfer erkennt, während er sich dreht, müsste eine neue Drehung gestartet werden, danach muss die unterbrochene Drehung vollendet werden.

Der Wettbewerb selbst ist für uns recht unspektakulär gewesen – in Oldenburg haben leider nur drei Rescue B Teams teilgenommen (es gibt ja auch noch fünf weitere Qualifikationsturniere in ganz Deutschland, die meisten anderen Rescue B Teams aus der Region nehmen in Hannover teil). Die meiste Zeit haben wir darauf gewartet, die fünf Wertungsläufe zu absolvieren.
Insgesamt hat der Roboter sehr gut funktioniert, am Mittwoch hat jedoch auf einmal der Rescuekitabwurf und die Opfererkennung auf einmal nicht mehr funktioniert. Nach intensiver Fehlersuche konnte die Ursache dann allerdings lokalisiert werden (es handelte sich um einen eigentlich ziemlich offensichtlichen Softwarefehler).
In den Wertungsläufen konnten wir meistens die (fast) volle Punktzahl erreichen. In zwei Wertungsläufen wurde allerdings jeweils ein Rescuekit nicht abgeworfen, weil sich die Rescuekits verklemmt haben, was daran lag, dass sie eher unförmig waren. Wir haben bereits 3D gedruckte Fassungen für die Gewichte (damit die Rescuekits auch wirklich liegenbleiben), die wir dann später einsetzen werden.
Außerdem gab es Probleme beim Opfern, die unmittelbar am Beginn der Rampe befestigt waren. Problem ist, dass der Roboter die ersten 30cm der Rampe noch als normale Fliese sieht. Wenn sich in dem Abschnitt ein Opfer befindet, dreht sich der Roboter auf der Rampe (wenn er das Rescuekit abwerfen möchte) und rutscht dabei von der Rampe. Er rutscht also eine Fliese in der Karte zurück und ist quasi in einer Endlosschleife gefangen, weil er dann wieder auf die Rampe fährt und erneut zurückrutscht. Die gesamte Implementation der Rampenüberwindung ist so oder so genau sie wie vorher die Fahranweisungen ziemlich alt und müsste neu programmiert werden, wodurch dieses Problem dann hoffentlich behoben werden kann.

Letztendlich konnten wir aber den 1. Platz erreichen und haben uns für die deutschen Meisterschaften qualifiziert, außerdem kamen ein paar weitere Schwächen des Roboters zum Vorschein. Wir sind also auf jeden Fall zufrieden 😀

Optimierungen und neuer LED Treiber

Neben einigen Optimierungen, besonders hinsichtlich des Rescuekitsabwurfes und den Rescuekits, die nun aus Blei bestehen, da die Plexiglasplättchen immer noch zur Seite gehüpft sind, besonders, wenn der Roboter über sie gefahren ist, haben wir uns heute mit der Reparatur bzw. mit dem Ersetzen des LED Treibers beschäftigt. Wir nutzen nun einen Regler auf Basis des PT4115, einem wirklich tollen Schaltregler, der als Konstantstromquelle für LEDs konzipiert ist und einen entsprechend hohen Wirkungsgrad hat:

 

Der wird als nächstes auf Herz und Nieren getestet 😉

Hier noch ein kleines Foto der nun als Rescuekit verwendeten Bleiklötzchen:

Die Fahrten und Korrekturen des Roboters funktionieren wie gesagt gut, da werden wir nur nebenbei weiter optimieren, genau so bei der Erkennung der schwarzen Flächen und der silbernen Checkpoints sowie das Erkennen des Hochhebens des Roboters und zurücksetzen auf den letzten Checkpoint – Entwicklungsschwerpunkt liegt nun beim intelligenten Erkennen der Rampe, d.h. der Roboter soll, wenn er zwischendurch mal irgendwo gegen fährt und umkippt und die Rampe dann einzeichnet nach einem Eingriff dazu in der Lage sein zu erkennen, dass an der Stelle keine Rampe war.

Zwischenstand:

Deutschland ist im Halbfinale und wir sind weiter fleißig am Programmieren und Optimieren 😀

Wir haben in den letzten beiden Wochen wieder relativ wenig geschafft, da Klausuren (vierstündige auch noch…) anstanden, aber jetzt sind wir damit erstmal durch. Und in 10 Tagen geht es auch schon los… Unglaublich!

Insgesamt sind wir aber zufrieden. Der Roboter fährt ziemlich zuverlässig. Wir haben noch ein paar Feineinstellungen vorgenommen, die Länge der Geradeausfahrt etwas angepasst, zum Beispiel. Außerdem haben wir bei der Kollisionsvermeidung noch eine Korrektur der Korrektur hinzugefügt: Wenn der Roboter nach einer Geradeausfahrt viel schräger steht, als zu Beginn (Erkennung über Differenz der Encoder beim Start der Geradeausfahrt und Ende der Geradeausfahrt) richtet er sich neu aus, sodass er wieder gerade steht. Encoder sind nicht so zuverlässig, besonders bei Geröll (Zahnstochern etc.) dürfte das schwierig werden, weshalb das wahrscheinlich noch auf den Orientierungssensor erweitert wird.

Leider ist uns beim Testen unser LED Schaltregler durchgebrannt – der Dritte, und wieder einfach so, ohne Grund.

Wir kaufen sehr viel aus China und meistens ist die Qualität super, aber das war ein Reinfall :( Wir haben nun welche auf Basis des PT4115 gekauft, die im Laufe der nächsten Woche ankommen sollten. Die hatten wir auch vorher schon mal in Einsatz und sind wesentlich zuverlässiger.

Auch bei der Erkennung der Checkpoints konnten wir Fortschritte erzielen: Da die silbernen Flächen grundsätzlich in alle möglichen Richtungen reflektieren, bekommt der Untergrundsensor mal mehr und mal weniger Licht. Mal richtig viel, mal so wenig, dass eine schwarze Fläche erkannt wird. Das konnte aber ganz leicht optimiert werden, indem einfach während der Geradeausfahrt die Anzahl der Male, in denen der Sensor eine silberne Fläche erkennen würde, misst. So können silberne Fliesen zuverlässig erkannt werden. Quasi ein Durchschnitt, bei dem Null-Reflexion nicht berücksichtigt wird.
Hier mal ein Bild unseres Untergrundsensors:

Den haben wir nun schon etwas länger so, sind bis jetzt aber noch nicht näher darauf eingegangen. Der Sensor besteht aus dem LED Treiber, der sich weiter hinten im Roboter befindet (auf dem Foto nicht sichtbar), einer 1W High Power IR LED inkl. Kühlkörper und rechts daneben ein abgeschirmter, nach unten gerichteter IR Phototransistor, der als Spannungsteiler über den AD-Wandler des Mikrocontrollers des Roboters ausgelesen wird.

Weiterhin haben wir beim Rescuekitabwurf ein bisschen weitergemacht. Insgesamt funktioniert das schon recht gut, aber noch nicht perfekt. Die Kits fallen nicht immer in den 15cm Radius um die Opfer, weil sie, da sie aus Plexiglas und deshalb recht leicht sind, gerne wieder hochspringen, z.B. wenn der Roboter über sie hinweg fährt. Da sind wir gerade mit Sprühgummi am Experimentieren, dazu mehr, wenn es da Erfolge zu verzeichnen gibt. Da muss aber auch an der Software noch etwas optimiert werden: Der Roboter dreht aktuell nur auf der Stelle, eigentlich muss er vor dem Abwurf noch näher an die Opfer heranfahren…

Noch etwas mehr Arbeit investieren müssen wir in die Rampe – das funktioniert noch nicht zuverlässig genug. Dazu aber auch mehr, wenn etwas getan wurde. Zu beachten ist außerdem, um nochmal auf die Checkpoints zurückzukommen, dass diese sich auch auf der Rampe befinden können. Das sollte aber recht einfach zu implementieren sein…

Hindernisse, die mitten auf Fliesen stehen, stellen im Moment sowohl für uns, als auch andere Teams ein mehr oder weniger unüberwindbares Hindernis 😀 dar. Mal sehen, was sich da noch machen lässt, aber nach aktuellem Stand sieht es so aus, als ob das nichts zur WM wird.

Man sieht: Es gibt noch einiges zu tun! 😀 10 Tage haben wir wie gesagt noch und auch beim Setup vor dem Wettbewerb kann sicherlich einiges noch geschafft werden. Wir halten Euch auf dem Laufenden.

Zwischenstand zum Beginn der Fußball WM

Die Fußball WM in Brasilien beginnt heute offiziell und es dauert nur 36 Tage, bis die RoboCup WM beginnt. Hier ein aktueller Zwischenstand:

Wir nun nicht mehr auf die Kamera (CMUcam) angewiesen, die uns zuletzt ja noch einige Probleme bereitet hat. Sie wird aber dennoch auf jeden Fall eingebaut bleiben, wir sind uns sicher, dass wir sie bald noch gebrauchen könnten (selbst, wenn es nur für die Erkennung der Sackgassen ist (läuft ja jetzt über einen einfachen Infrarot Helligkeitssensor (IR Phototransistor und High Power IR LED), der auf den Boden gerichtet ist)). Implementiert haben wir außerdem und können von unserer To-Do Liste streichen:

  • Fehlerhafter Entfernungssensor:
    Wir haben ein paar neue Infrarotentfernungssensoren bestellt und den Sensor ausgetauscht. Nach einer zusätzlichen Neukalibration aller Sensoren (angepasst auf den neuen Roboter) liefern alle Sensoren perfekte Werte mit einer Genauigkeit von bis zu 1mm. Man merkt deutlich, dass der Roboter zielsicherer und exakter durch das Labyrinth fährt.
  • Kollisionserkennung 2.0:
    Auch hier konnten wir Fortschritte verzeichnen: Dank der neu kalibrierten Sensoren kann der relative Winkel (d.h. wir berechnen keinen absoluten Winkel in Grad sondern haben eine Zahl, die proportional zu einem Winkel ist, diesem aber nicht entspricht; Eine Umrechnung sparen wir uns, weil das nicht nötig ist), mit dem der Roboter zur Wand steht, sehr exakt bestimmt werden. Die zusätzliche Kollisionserkennung funktioniert so, wie wir uns das vorgestellt haben.
    Zudem haben wir die Ultraschallsensoren softwareseitig auf eine maximale Distanz von 30cm begrenz, weiter funktionieren diese nicht zuverlässig und weiter müssen wir auch nicht sehen können. Wir müssen ja nur erkennen, ob da außerhalb des Sichtfeldes der IR Sensoren etwas steht. Das funktioniert auch sehr gut.
    Getestet werden muss aber auch hier noch einiges.
  • Erkennung der Checkpoints:
    Wenn der Wert des Untergrundsensors nach der Geradeausfahrt (Positionswechsel) unter einem bestimmten Schwellwert liegt, steht der Roboter auf einem Checkpoint (silberne Fliese). Diese Position wird zwischengespeichert. Wenn der Roboter nun hochgehoben wird (Erkennung über einen nach unten gerichteten Sharp IR Entfernungssensor), wird dies erkannt und der Roboter setzt sich automatisch an den letzten Checkpoint zurück und fährt weiter, kurz nachdem er wieder abgesetzt wird. Wenn noch kein Checkpoint gespeichert wurde, setzt sich der Roboter zurück zur Startfliese.
  • Hindernisse:
    Hier haben wir seeeeeehr viel getestet, konnten aber noch keine brauchbaren Ergebnisse erzielen. Eine Idee war, dass der Roboter, wenn er ein Hindernis direkt vor ihm vermutet, einen Scan macht, indem er sich auf der Stelle dreht. Das sah dann so aus:
    Diese Scans sahen erstaunlich gut aus, gescheitert ist es dann letztlich an der Weiterverarbeitung der Informationen. Wir wollten eine Hough-Transformation implementieren (wenn diese ein Ergebnis liefert, also sicher eine Linie vor dem Roboter identifizieren kann, ist da kein Hindernis, sondern eine Wand, wenn der Algorithmus kein Ergebnis liefert und die Punkte irgendwie verstreut liegen, befindet sich ein Hindernis vor dem Roboter und bei gar keinen Messwerten ist da nichts vor dem Roboter), aber so richtig (zuverlässig) hat das alles nicht funktioniert und zu viel Zeit wollten wir in diese Idee auch nicht stecken, war nur auf jeden Fall sehr interessant anzusehen und dieses Ergebnis zeigt auch, dass es ohne Laserscanner möglich ist, genaue Informationen über die Umgebung zu bekommen, die auch ohne Probleme in eine Karte mit einer Auflösung von z.B. 1cm eingetragen werden könnten, vorausgesetzt, man hat genug Rechenleistung und Arbeitsspeicher. Aber das ist noch Zukunftsmusik 😀

    Mal sehen, ob uns da noch was einfällt…

  • Bei dem Abwurf der Rescuekits haben wir auch noch nicht sooo viele Fortschritte gemacht – einzelne Opfer können schon in die Karte eingezeichnet werden, Kits werden aktuell aber noch immer abgeworfen. Das sollte aber kein so großes Problem werden.

Es ist also noch einiges zu tun. Wir schreiben aktuell einige Klausuren, wahrscheinlich wird es also in den nächsten zwei Wochen nicht so richtig weitergehen, aber danach werden wir nochmal richtig Gas geben :)

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 :)

Wie es weitergeht: Überarbeitung des Roboters

Insgesamt sind wir über unser Abschneiden bei den deutschen Meisterschaften sehr zufrieden. Wir hätten nicht gedacht, dass unser Roboter, abgesehen von den Fehlerkennungen, die ja durch ein einfaches Verstellen der Wärmesensoren behoben werden konnten, so gut funktionieren würde. Wir haben uns nicht auf Hindernisse eingestellt, die sich bei den Läufen in den Parcours befanden, unser Roboter konnte diese aber dennoch fast immer sauber umfahren. Hindernisse besitzen mindestens 4 Ecken, dürfen aber auch jede andere Form mit mehr als 4 Ecken (bis hin zum Kreis) haben. Eine Mindestgröße gibt es nicht, eine maximale Höhe von 40cm darf aber nicht überschritten werden. Zudem müssen Hindernisse immer 20cm von einer Wand entfernt sein (wenn eine vorhanden ist). Problem ist, dass unser Roboter aktuell genau 20cm breit ist und dass es da eng werden kann (obwohl er bewiesen hat, dass es möglich ist). Eine weitere Schwäche ist, dass die Infrarotentfernungssensoren einen sehr kleinen Öffnungswinkel haben (generell ist das sehr gut, da so gezielt gemessen werden kann, für eine Hinderniserkennung ist das jedoch weniger gut geeignet, da unter Umständen Hindernisse in einem toten Winkel stehen können, die Hindernisse also einfach von den Sensoren „übersehen“ werden und der Roboter kollidiert). Dagegen helfen Ultraschallsensoren, da sie das gesamte Sichtfeld des Roboters abdecken können.

Bei der WM werden die neuen Regeln zu Einsatz kommen. Eine wesentliche Neuerung ist, dass es zum Einen Checkpoints gibt: Zu diesen Checkpoints muss der Roboter zurückgesetzt werden, wenn ein Lack of Progress auftritt, er also eine schwarze Fliese durchfährt oder er die Karte verliert (den LoP würden wir dann ausrufen). Dafür darf die neue Position des Roboters nach einem LoP dem Roboter nicht mehr mitgeteilt werden, der Roboter muss sich also bei einem LoP wieder zum letzten Checkpoint zurücksetzen. Ob dem Roboter die Information LoP „ja“ oder „nein“ gegeben werden kann, ist noch nicht sicher, da bekommen wir noch eine Antwort vom Technical Committee, also den Entwerfern der offiziellen Regeln.
Weiterhin muss der Roboter bei Opfern nun Rescuekits abwerfen, von denen er maximal 12 Stück dabei haben darf. Dadurch wird man gezwungen, die Opfer in die Karte einzuzeichnen (damit man nicht mehrere Kits bei einem Opfer abwirft, was generell kein Problem ist, unter Umständen bekommen dann aber einige Opfer gar kein Kit). Generell muss natürlich auch ein Abwurfmechanismus entwickelt werden, das ist aber kein großes Problem. Beim Einzeichnen der Opfer in die Karte muss berücksichtigt werden, dass sich auch mehrere Opfer auf einer Fliese befinden könnten…

Es kommt also einiges dazu, deshalb werden wir, zumal das Plexiglas schon etwas gelitten hat, ein neues Chassis bauen, das 1cm kleiner ist (der Roboter hat dann eine Größe von genau 19cm x 19cm). Die Infrarotentfernungssensoren sollen so weit wie möglich nach unten, um notfalls auch noch sehr kleine Hindernisse erkennen zu können. Natürlich kommen auch Ultraschallsensoren dazu, wir werden drei Stück von den Devantech SRF10 verwenden. Der Abwurfmechanismus wird mit einem Servo bewerkstelligt.
Unsere Zeilenkamera wird zudem mehr oder weniger von einer richtigen Kamera abgelöst, generell wollen wir aber weniger auf Kameras setzen. Wir werden nun die neue CMUcam5 benutzen, die man im November bei Kickstarter unterstützen konnte. Vorteil ist, dass man der Kamera einfach Objekte, die getrackt werden sollen, beibringen kann. Die Position dieser Objekte wird dann z.B. seriell per UART ausgegeben. Was nicht so toll ist, ist, dass das Ganze nur mit farbigen Objekten funktioniert. Da müssen wir uns also noch was einfallen lassen. Notfalls versuchen wir, einzelne Pixel der Kamera auszulesen. Vorteil dieser Kamera gegenüber unserer Zeilenkamera ist einfach, dass wir uns um nichts mehr kümmern müssten, die Belichtung also unabhängig vom Roboter und auch ohne LED geregelt werden kann etc. Selbst, wenn wir mit der Kamera selbst vorerst nichts anfangen können, wird sie uns zumindest als Ansteuerung für das Servo dienen (man kann sogar zwei Servos an die Kamera anschließen). Für den Notfall (plötzliche Regeländerung? Superteam Wettbewerb?) sind wir dann gewappnet.
Generell sind wir von Kameras nicht mehr so begeistert, nachdem uns unsere Zeilenkamera bei den hellen, beleuchteten Wettbewerbsparcours nicht mehr so gut funktioniert hat, im Gegensatz zu unserem Backupsensor am Untergrund, der auch bei extrem hellem Licht noch die gleichen Werte geliefert hat. Erschwerend dazu kommt, dass die Zeilenkamera aufgrund ihrer Neigung nicht dazu in der Lage ist, silberne Flächen (die Checkpoints) zu erkennen, da das gesamte Licht von der Kamera weg reflektiert wird und diese Flächen somit als Sackgasse erkannt werden würden. Der Sensor muss genau senkrecht nach unten zeigen, damit bei silbernem Untergrund das gesamte Licht und bei schwarzem Untergrund wenig bis gar nichts reflektiert wird.
Wahrscheinlich werden wir dafür unseren aktuellen Backup-Untergrundsensor mit einer High Power IR LED aufrüsten, sodass er auch noch funktioniert, wenn er weiter vom Untergrund entfernt ist (wenn der Roboter Speed Bumps überquert oder die Rampe befährt).

All diese Ideen und Gedanken sind in unseren neuen, überarbeiteten Entwurf für den Roboter eingeflossen. Im Folgenden ein paar Bilder:

Kitdropper

Kitdropper: Ein Servo schiebt ein Stück Plexiglas nach vorne, drückt dabei ein Rescue Kit aus dem Schacht (die Kits werden durch eine kleine Feder zurückgehalten, damit sie nicht so herausfallen) und fährt wieder in die Ausgangsposition zurück.

 

 

 

 

 

 

 

 

 

Untere Ebene des Roboters mit Motoren, Powerunit (Anschlüsse der Motoren und des Akkus), dem Orientierungssensor, einem Ultraschallsensor nach vorne und einem normalen Infrarotentfernungssensor nach hinten und dem Kitdropper

 

 

 

 

 

 

 

 

 

Zweite Ebene

Zweite Ebene mit allen Entfernungssensoren nach unten, zwei Ultraschallsensoren, der Kamera und dem Mainboard

 

 

Komplettansicht

Komplettansicht des neuen Roboters – Das Display ist jetzt aus Platzgründen etwas weiter vorne

 

 

 

 

 

 

 

 

 

Komplettansicht - FOVs

Komplettansicht des Roboters mit eingezeichneten FOV (Field of view) aller Sensoren. Gut erkennbar ist der gut abgedeckte Bereich vor dem Roboter.

Tag 3: Deutsche Meisterschaften „German Open“ in Magdeburg: Zwei Wertungsläufe

Heute sind wir sehr zuversichtlich auf gute Ergebnisse bei den Wertungsläufen in den Wettbewerb gegangen. Wir haben vor dem ersten Wertungslauf heute wieder einige sehr spezielle Situationen getestet, die wahrscheinlich aber nicht so bei den deutschen Meisterschaften in einem Wertungslauf zu bewältigen werden

Beim Testen haben wir einige Bugs gefunden, die im Wesentlichen etwas mit der Rampe zu tun hatten. Diese Bugs konnten wir aber recht schnell beseitigen. Zudem haben wir die Zeilenkamera wieder ins Programm aufgenommen und auch dort einen weiteren Bug beseitigt, der unter bestimmten Situationen auftritt, wenn die Kamera die schwarze Fläche einmal nicht erkennt und der Roboter somit über den Untergrundsensor die Sackgasse erkennen muss.

Beim ersten Wertungslauf heute haben wir alle Opfer bis auf eines erkannt. Das hatte wieder etwas damit zu tun, dass die Opfer bei den Parcours hier etwas zu hoch für uns befestigt waren. Das Problem hatten wir auch schon gestern, wir haben die Sensoren da allerdings einfach etwas nach oben gebogen und bei Tests im Testparcours schien alles zu funktionieren.
Letztlich haben wir die Sensoren dann über Distanzbolzen erhöht und hatten im insgesamt dritten Wertungslauf gar keine Probleme und konnten die volle Punktzahl erzielen.

Somit dürften wir ziemlich sicher auf dem 2. Platz landen (sicher ist aber noch nichts 😉 ). Wie viele Teams sich für die WM qualifizieren, werden wir wahrscheinlich erst nächste Woche erfahren. Es bleibt also spannend!

Tag 1 + 2: Deutsche Meisterschaften „German Open“ in Magdeburg: Setup und erster Wertungslauf

Nachdem wir gestern planmäßig um 13:00 Uhr in Magdeburg angekommen sind, haben wir erst unser Gepäck in die nur 5min vom Bahnhof entfernt liegende Jugendherberge gebracht, da die Messehalle erst um 14:00 Uhr für die Teilnehmer öffnete.

Wir haben dann die ganze Zeit getestet, getestet, getestet, ganz besonders kritische Situationen mit Hindernisse, die dieses Jahr das erste mal bei deutschen Meisterschaften zu Einsatz kamen. Darauf waren wir so nicht vorbereitet, da die Hindernisse aber zumindest hier nur aus Flaschen, die in der Mitte von Foyers stehen, bestehen, stellen sie kein großes Problem für unseren Roboter dar. Selbst, wenn nur 20cm Platz zwischen Hindernis und Wand sind, findet der Roboter irgendwie seinen Weg dadurch und die Karte stimmt trotzdem noch überein.

Zuversichtlich sind wir dann in den zweiten Tag gestartet. Die Wettbewerbsarena wurde extrem stark ausgeleuchtet, da sich erstmals eine Kamera und ein großer Bildschirm über der Arena befand, um den Zuschauern das Verfolgen des Geschehens im Parcours zu erleichtern. Auf dem Wettbewerbsparcours durften wir sogar zwei Stunden vorher noch testen, wobei sich dann herausgestellt hat, dass diese extreme Beleuchtung unsere Sackgassenerkennung über die Zeilenkamera stark beeinträchtigt. Problem 1 war, dass zum Einen relativ starke Kontraste durch die Beleuchtung entstanden (Schatten/Licht), die unter Umständen als Sackgasse erkannt wurden. Zudem war das Licht stellenweise einfach so hell, dass die Kamera schlichtweg überfordert war und überbelichtet, was sich daran bemerkbar macht, dass die Werte extrem springen (die Kamera verlangt eine noch kürzere Belichtungszeit, was aber nicht mehr möglich ist). Die einzige Lösung war, unsere Erkennung der schwarzen Flächen auf den Backup-IR-Sensor umzustellen, der sich unter dem Roboter befindet. Dieser liefert sehr, sehr zuverlässige Werte, wir benutzen ihn normalerweise nur, um zu erkennen, wenn ein Schwellwert für die Zeilenkamera falsch eingestellt wurde. Leider haben wir in den zwei Stunden, die uns bis zu unseren Wertungslauf noch übrig geblieben sind, keine funktionierende Lösung gefunden, um ein Befahren der schwarzen Flächen zu vermeiden, weshalb wir für diesen einen Wertungslauf immer, wenn wir eine Sackgasse erkannt haben, drei Wände in die Karte eingezeichnet, damit der Roboter nicht durch die Sackgasse fährt. Zurückzuführen ist der Fehlschlag der Implementation darauf, dass unsere komplette Software darauf ausgelegt ist, die schwarzen Fliesen gar nicht erst befahren zu müssen. Deshalb mussten wir leider so ein bisschen pfuschen…

Der Wertungslauf brachte uns dann beinahe volle Punktzahl; Leider haben wir nicht sorgfältig genug kalibriert und ein Opfer somit nicht erkannt und ein Opfer falsch erkannt. Aktuell dürften wir somit auf dem zweiten Platz liegen (wahrscheinlich bekommen wir dazu heute Abend beim Social Event noch nähere Informationen). Insgesamt gibt es vier Wertungsläufe, wobei die besten drei gewertet werden.

Nach dem Wertungslauf haben wir uns dann nochmal an den Untergrundsensor gesetzt und konnten ihn recht bald erfolgreich am Roboter zum Laufen bringen. Die starke Beleuchtung wird, soweit wir heute verstanden haben, morgen allerdings ausgeschaltet werden und wir werden wahrscheinlich wieder unsere Zeilenkamera nutzen. Eventuell bleiben wir aber auch erst bei dem unteren Sensor, da er wie erwähnt sehr zuverlässig funktioniert.

Aufgrund der langsamen Internetverbindung können wir momentan leider keine Fotos hochladen, die folgen wie nach Hannover wahrscheinlich Sonntag. :)

Kollisionserkennung und Optimierungen

Wie im letzten Artikel erwähnt, haben wir nun die Kollisionserkennung eingebaut und wir sind wirklich überrascht: Der Roboter funktioniert nun wirklich sehr zuverlässig. Der Testparcours in der Schule hat ein anderes Raster (ca. 28cm) als der Wettbewerbsparcours (genau 30cm, wie in den Regeln vorgegeben), weshalb der Roboter beim Schulparcours immer etwas zu weit fährt und nach dem Wettbewerb dort öfters rausgekommen ist, also seine Position verloren hat. Behoben werden kann das normalerweise nur durch Änderung eines Faktors zum Umrechnen der Encodersteps in cm. Wir wollten die Einstellungen von Hannover aber beibehalten, da bei den deutschen Meisterschaften auch ein Parcours im 30cm Raster genutzt wird. Jedenfalls verliert der Roboter, nachdem wir die Kollisionserkennung implementiert haben, nur sehr, sehr selten die Position (normalerweise muss man sogar nachhelfen). Er erkennt also nun, wenn er bei einer Geradeausfahrt mit einer Wand kollidieren würde (nur einer der drei vorderen Entfernungssensoren erkennt ein Hindernis) und korrigiert dann minimal in die Richtung, in die kein Hindernis ist. Dann wird ganz normal mit der Geradeausfahrt fortgeführt.

Außerdem haben wir die Berechnung des Pfades per Tiefensuche optimiert. Wir haben die Tiefensuche iterativ implementiert, um in Sachen Arbeitsspeicher des Roboters auf der sicheren Seite zu sein (bei der rekursiven Suche wird der Speicher ja dynamisch reserviert, bis evtl. kein Speicher mehr zur Verfügung steht), dazu wird in Zählschleifen der gesamte Speicher der Karte durchgegangen, was unter Umständen relativ viel Zeit (bis zu einer Sekunde) in Anspruch nehmen kann. Das Problem konnten wir beheben, indem nicht mehr im gesamten Speicher der potentielle Pfad berechnet wird, sondern wirklich nur in der Größe der tatsächlichen Karte.

Insgesamt sind wir nun sehr zufrieden mit unserem Roboter und einer erfolgreichen Teilnahme bei den German Open in Magdeburg steht nichts mehr im Wege. :) Natürlich braucht man immer auch etwas Glück, aber mal sehen, wie es so läuft.