RoboCup WM 2015: Wie es weitergeht

Nach unserer Qalifikation für die WM sind die Vorbereitung nun in vollem Gange, sowohl für die Reise, als auch für den Wettbewerb.

Der Roboter hat bei den German Open sehr gut bis perfekt funktioniert. Eigentlich möchten wir deshalb nicht so super viele Änderungen machen. Dennoch möchten wir nicht einfach nichts tun. Uns schwebt schon lange vor, mal ein richtiges SLAM für den RoboCup zu implementieren. Laserscanner sind in den neuen Regeln (in denen sich zum Parcours absolut gar nichts geändert hat, weshalb der Roboter auch nicht geändert werden muss) leider immer noch verboten, weshalb wir nun versuchen, ein eigenes kleines Lidar zu bauen:

Es werden zwölf Sharp Infrarot Entfernungssensoren der neuen Generation (GP2Y0E03) genutzt. Diese lassen sich über I²C auslesen und haben eine Reichweite von 4 bis 50cm. Das Ausgangssignal ist zudem proportional zur Entfernung und muss nicht wie bei den alten Sensoren linearisiert werden.

Zusammen mit den neuen Sensoren soll ein 32bit ARM Controller mit 4,3″ Farb LCD genutzt werden. Alle Änderungen sollen modular sein, sodass notfalls im Wettbewerb schnell zur alten Version des Roboters gewechselt werden kann. Weitere Infos dazu werden wir bald veröffentlichen  :)

Eine Schwachstelle an unserem Roboter ist allerdings der Kitdropper – wir können nur nach hinten abwerfen (und nicht nach links oder rechts). Deshalb müssen wir bei jedem Opfer auf der Stelle drehen. Beim Wettbewerb war das nicht kritisch, weshalb wir den Kitdropper auch so lassen werden. Die Grundhardware des Roboters soll also als praktischen und aus Kostengründen unverändert bleiben.

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.

Überarbeiteter Roboter

Wie im letzten Artikel beschrieben, haben wir einen neuen Roboter geplant – und eher als gedacht ist er fertig geworden. Dies haben wir PlexiLaser.de zu verdanken, die uns freundlicherweise die Plexiglasteile für unseren neuen Roboter gesponsert haben. Danke an dieser Stelle nochmal für den tollen Support und die superschnelle Lieferung!

Der Zusammenbau des neuen Roboters verlief relativ problemlos, dennoch steckten einige Stunden Arbeit darin. 😉 Der alte Roboter musste schließlich komplett zerlegt werden und die neuen Teile in das neue Chassis eingebaut werden. Den Kitdropper haben wir testweise schon zuvor zusammengebaut, hier ein kleines Demonstarationsvideo:

Die Plexiglasteile kleben wir mit einem speziellen Plexiglaskleber zusammen. Dieser härtet (polymerisiert) durch UV-Strahlung (normales Tageslicht reicht) zu „normalem“ Plexiglas, sodass man quasi nachher ein Stück Plexiglas hat, was wirklich nicht so einfach kaputt gehen kann.

Der Kitdropper hat bei den ersten Tests sehr zuverlässig funktioniert. Beim Schieber, also dem Teil, das die Kits festhält und sie auch mithilfe eines Servos hinausschiebt, mussten wir leider schon etwas wegschleifen, da sich Kits sonst unter Umständen verkantet haben (besonders das letzte Kit im „Bunker“), aber das Problem konnte wir beheben.

Beim Zusammenbau gab es sonst nur ein paar kleinere Komplikationen aufgrund unserer relativ vielen Kabel. Wir haben schlicht und ergreifend vergessen, genug Platz mit einzuplanen. Wir könnten, anders als in der Planung vorgesehen, die Distanzen zwischen den Etagen einfach erhöhen, aber dann würde der Kitdropper nicht mehr bündig mit der oberen Etage abschließen, was sehr unschön wäre, weshalb wir einfach versucht haben, die Kabel so effizient zu möglich zu verstauen. Letztlich haben wir das auch hingekriegt. :) Hier mal ein Foto unseres neuen Roboters:

Roboter

Überarbeiteter Roboter – Komplettansicht

 

 

 

 

 

 

 

 

 

Weitere Bilder wie immer in unserer Webgalerie. 😉

Es fällt auf jeden Fall auf, dass der Roboter etwas kompakter ist – wir konnten ihn um 1cm schmaler machen, sodass er nun 19cm x 19cm groß ist. Mit dieser Größe sollte er problemlos den Weg zwischen Hindernissen fahren können.

Um Hindernisse zu erkennen, haben wir ja auch die Ultraschallsensoren eingebaut. Das funktioniert noch nicht so ganz, wie wir uns das vorgestellt haben, aber da werden wir sicherlich auch noch eine Lösung finden. Schwierig wird es nachher zu unterscheiden, ob die Ultraschallsensoren nun ein Hindernis oder eine Wand sehen. Man darf dabei nicht vergessen, dass die Ultraschallsensoren die IR-Entfernungssensoren bei ihren „Entscheidungen“ unterstützen sollen und nicht umgekehrt.

Weiterhin werden wir uns weiter mit einer Optimierung unseres Untergrundsensors beschäftigen. Bis jetzt haben wir eine IR-LED  und einen IR-Phototransistor genutzt, das funktioniert aber nur bis zu Entfernungen von ca. 1cm zum Untergrund. Diese mögliche Distanz wollen wir durch eine High-Power IR LED erhöhen, aber auch dazu mehr, wenn es funktioniert.

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.

Entfernungssensoren und ihre Tücken…

Nachdem es im letzten Monat große Fortschritte gab, ging es diesen Monat leider so gut wie gar nicht voran (deshalb gab es auch keine neuen Beiträge…).

Verursacht wurde diese Verzögerung durch die Entfernungssensoren des Roboters. Wir benutzen die analogen Sharp IR-Entfernungssensoren mit einer Reichweite von 4cm – 30cm. Diese Sensoren arbeiten optisch, nach dem Prinzip der Triangulation (mehr dazu hier). Vorteil dieser Sensoren ist, dass sie zum Einen sehr präzise sind (genau definierter Messpunkt (ca. 5mm Durchmesser, Auflösung ca. 3mm)) und zum Anderen sehr schnell neue Werte liefern (ca. alle 50ms Aktualisierung des analogen Ausgangs eines Sensors).
Wenn man bestimmte Dinge allerdings nicht beachtet (wie wir :/ ), hat man nichts davon; Die Werte rauschen und springen dann ohne Ende, sodass man nicht mehr vernünftig mit ihnen arbeiten kann (was fatal ist, denn ohne Entfernungssensoren geht gar nichts).

Wir mussten also die Ursache für das Rauschen finden: Nachdem wir die Hardware des Roboters als Ursache ausschließen konnten, haben wir näher direkt bei den Sensoren gesucht. Wir haben recht schnell herausgefunden, dass die Sensoren zum Einen bei Sonnenlicht nicht funktionieren (beim Wettbewerb kann uns das egal sein, denn erstens findet dieser in einer Halle statt und zweitens würden alle anderen Teams dann auch Probleme bekommen). Aber auch, wenn die Sonne nicht schien, lieferten die Sensoren unbrauchbare Werte. Die Sensoren müssen sich also irgendwie gegenseitig beeinflussen. In Frage kam da zu Beginn nur das Plexiglaschassis, welches den Strahl des Sensors vielleicht ungünstig reflektiert. Die Probleme traten allerdings auch auf, nachdem die Sensoren weiter nach unten gesetzt wurden und eine Reflexion durch das Plexiglas ausgeschlossen werden konnte.

Wir haben uns dann den Analogausgang der Sensoren genau auf einem Oszilloskop angesehen:

Rauschen
Das Rauschen und die Spikes sind wieder klar zu erkennen. Man sieht aber auch, dass sie periodisch auftreten. Nach einigem Hin- und Her und Tappen im Dunkeln haben wir die Ursache dann gefunden:

Schwingungen

Wie im Bild erläutert, beeinflussen sich die Sensoren gegenseitig (Interferenzen). Um das zu prüfen, haben wir einfach immer nur einen Sensor pro Richtung „sehen“ lassen und die anderen zugedeckt. Das Ergebnis ist das obere Bild.
Das periodische Rauschen tritt auf, weil die LED der Sensoren mit einer bestimmten Frequenz moduliert wird. Der Sensor reagiert dann nur auf Licht, das mit der gleichen Frequenz wieder beim Sensor ankommt. So soll ausgeschlossen werden, dass Umgebungslicht den Sensor stört (das Sonnenlicht hat allerdings ein sehr breites Spektrum, weshalb das dann nicht so gut funktioniert).
Man muss sich dann einmal das „aufgenommene“ Bild aus Sicht der Sensoren sehen. Ein Sensor sieht im Schlimmsten Fall dann drei Punkte auf einer Fläche (den eigenen Messpunkt und dem der anderen Sensoren) und kann nicht unterscheiden, welcher Messpunkt von ihm kommt. Die Messpunkt werden allerdings nur in periodischen Abständen sichtbar, weil die Modulationsfrequenz von Sensor zu Sensor minimal voneinander abweicht und nur in diesen periodischen Abständen identisch ist.

Eine erste Idee war dann eine Abschattung der Sensoren gegenseitig, sodass der Sensor nur noch einen eigenen Messpunkt sieht. Das hat leider nur für einen bestimmten Bereich funktioniert. Die einzige Lösung ist also, dass der Roboter pro Messung nur einen Sensor pro Richtung aktiviert. Das ist nicht optimal, aber leider gibt es keine andere Lösung. Dazu haben wir vor jeden Sensor in die Versorgungsspannung einen Transistor gebaut und die entstandenen Steuerleitungen von jedem Sensor zum Controllerboard geführt:

Steuerleitungen

Benötigt werden nur drei Pins am Mikrocontroller, da ja in jede Richtung ein Sensor gleichzeitig an sein darf. Nach einiger Programmiererei (da das ganze seeeehr zeitkritisch ist, weil wir ja so schnell wie möglich die neuen Werte der Sensoren haben wollen und die Kamera auch so schnell wie möglich ausgelesen werden muss) haben wir dann aber 100%ige Werte bekommen, ohne Rauschen.

Im folgenden Bild stellt das blaue Signal den Analogausgang eines Sensors dar und das gelbe Signal den Zeitpunkt, zu dem die Analog/Digital Wandlung im Mikrocontroller durchgeführt wird:

Wandlung

Man sieht, dass das Ausgangssignal zunächst ca. 3,5V liegt (der Sensor ist dann ausgeschaltet (!)). Der Sensor wird dann eingeschaltet (Signal fällt auf 0V) und der Sensor braucht ca. 45ms (rauschendes Signal, ca. 3V) bis er seinen Analogausgang wieder aktualisiert hat (Signal fällt) und der Mikrocontroller das Signal auslesen kann. Direkt danach wird der Sensor bzw. die Sensorgruppe wieder abgeschaltet und die nächste Sensorgruppe aktiviert. Da sieht das dann genau so aus.

Da wir so maximal drei Sensoren pro Seite abfragen, brauchen wir insgesamt 150ms, bis alle 10 Sensoren am Roboter einmal abgefragt wurden. Das ist auch das Maximum, wenn der Roboter länger brauchen würden, müsste die Geschwindigkeit, mit dem er durch den Parcours fährt, reduziert werden, weil er sonst zu träge reagiert.

Ein weiteres (kleineres) Problem, was wir dann beobachtet haben, ist, dass Sensoren einer Seite unter Umständen bei gleicher Entfernung nicht das gleiche Signal ausgeben, was zu Folge hat, dass sich der Roboter über die Differenz zweier Sensoren nicht mehr an der Wand anpassen kann. Deshalb haben wir für jeden Sensor noch eine Messreihe genommen und bekommen die Werte nun fast Millimetergenau und linear.

Nachdem wir das Problem endlich lösen konnten, werden wir uns nun weiter der Optimierung und ich mir meinem Facharbeitsthema widmen, bei dem ich mich ja mit der Implementation von SLAM auf unserem Roboter beschäftige… Mal sehen, was daraus wird, weitere Informationen dazu kommen noch. :)

Softwareanpassung und Zeilenkamera!

Nachdem die Hardware soweit fast fertig war (nur noch eine Erkennung der schwarzen Fliesen fehlt(e)), haben wir uns intensiv mit der Anpassung der Software beschäftigt. Besonders in Sachen Karte und Navigation haben wir einiges getan; wir haben viel optimiert, angepasst und Fehler ausgebessert. Wenn wir auf alle Details eingehen würden, wären wir morgen mit dem Auflisten noch nicht fertig, aber wir können sagen, dass der Roboter nun in der Lage ist, relativ zuverlässig eine Karte zu erstellen, alle Fliesen abzufahren, wieder zum Startpunkt zurückzukehren und dabei ist es egal, wo im Labyrinth der Roboter gestartet wird! Das hat sehr viele Vorteile und macht alles wesentlich zuverlässiger.
In Sachen Software steht als nächstes neben Verbesserungen und Optimierungen eine Implementation eines Algorithmus an, mit dem wir den Roboter während der Aufzeichnung und Navigation an eine andere Stelle des Labyrinths setzen können (natürlich nach Mitteilen der neuen Position per Inkrementalgeber), nachdem der Roboter sich zum Beispiel verfahren hat. Es müssen dann nämlich alle Markierungen bis zu dem Punkt gelöscht werden, damit der Algorithmus zur Navigation sinnvoll weiterarbeiten kann. Alternativ kann man den Roboter einfach machen lassen und, wenn der Algorithmus keine Lösung findet (theoretisch beim Startpunkt ist) den Roboter einfach automatisch die Karte neu starten lassen. Dann ist zwar der gespeicherte Startpunkt weg, dafür kassiert man keine Strafpunkte für einen Eingriff. Muss man eben abwägen.
Des Weiteren muss dann bald eine neue Erkennung der Rampe implementiert werden, damit die Karte 100%ig autonom ist (zuvor hat der Roboter die Rampe und somit einen Wechsel der Etagen mithilfe der Karte erkannt, das ist aber nicht gut). Das sollte allerdings auch recht schnell erledigt sein. Danach ist eigentlich nur noch perfektionieren, perfektionieren und nochmals perfektionieren angesagt.

Zuvor muss aber noch eine zuverlässige Erkennung der schwarzen Flächen implementiert werden. Der Sensor selbst muss sich weit vorne am Roboter und zudem 6cm über dem Untergrund befinden, damit die Bodenfreiheit nicht eingeschränkt wird. Ein einzelner Phototransistor mit kleinem Öffnungswinkel und eine High-Power LED wollten wir nicht nutzen, da die LED recht viel Energie verschwendet. Nach einigem Hin- und Her haben wir uns vorerst entschieden, mit einer Zeilenkamera (TSL1401) zu experimentieren. Es werden lediglich 3 Pins benötigt:

  • Pin 1: Starte Belichtung
  • Pin 2: Clock
  • Pin 3: Analogausgang

Pin 1 wird gesetzt (ab jetzt wird belichtet), gleichzeitig kann oder muss Clock an- und ausgeschaltet werden, bei jedem Clock wird der Analogausgang der Kamera mit dem ADC des Mikrocontrollers ausgelesen. Wenn Pin 1 nochmal gesetzt wird, endet die Belichtung, die nächste startet und parallel kann das letzte Ergebnis ausgelesen werden. Hört sich schwieriger an, als es ist (die Implementierung der I²C Wärmesensoren hat uns mehr Arbeit gemacht 😀 ). Die Kamera hat eine Auflösung von 1×128 Pixel und einen einstellbaren Fokus. Man bekommt dann eine Linie mit Grauwerten, woraus man erkennen kann, ob sich da eine schwarze Fläche vor dem Roboter befindet oder nicht. Wie oben erwähnt, muss die Belichtungszeit selbst geregelt werden. Dabei gibt es ein Problem: Angenommen, die Kamera sieht komplett schwarz oder komplett weiß. Wie soll sie das dann unterscheiden? Man hat ja keine Referenz mehr. Und da ist das Stichwort schon: Referenz. Einfach ein weißes Stück Papier vor die unteren Pixel der Kamera gelegt. Das Blatt Papier muss immer weiß sein, darauf wird also geregelt. Wenn dann ein großer Sprung in den Grauwerten ist, ist da eine schwarze Fliesen.
Die Kamera hat allerdings einen Haken: Sie muss ständig mit dem Mikrocontroller kommunizieren (der muss ja ständig die Belichtungszeit regeln und parallel auslesen), der Mikrocontroller hat aber kein richtiges Multitasking. Also muss das Hauptprogramm nebenbei laufen. Die Hauptschleife benötigt aber schon ca. 20ms, dann könnten wir die Belichtungszeit nur in 20ms Schritten einstellen (wir brauchen aber mindestens 5!), weshalb die Kamera in einem Timer laufen muss. Der Timer wird beim STart des Roboters konfiguriert, unterbricht das Hauptprogramm in entsprechenden Abständen und führt dann einen entsprechenden anderen Teil aus (in dem Fall also das Auswerten der Kamera). Da gibt es aber noch ein paar Konflikte (da in dem Timer ja auch die Analogeingänge ausgewertet werden müssen; Wenn dann eine laufende Analogwandlung (beispielsweise eines Entfernungssensors) unterbrochen wird und danach an der Stelle weitergemacht wird, kommt da Müll raus), die wir hoffentlich noch in den Griff kriegen. Mal sehen.
Die Kamera wird vorsichtshalber noch von einer High-Power-LED unterstützt, die automatisch dazugeschaltet wird, wenn es SEHR dunkel ist (was normalerweise nie passiert).
Mal sehen, wie gesagt kriegen wir das hoffentlich noch auf die Reihe, bei der Kamera stößt unser Mikrocontroller allerdings langsam an seine Grenzen. Ansonsten haben wir schon eine andere Idee parat, dazu dann aber ggf. mehr. 😉

Zeilenkameramodul: Links die Kamera, rechts die LED mit Schaltregler.

Modul: Rückansicht

 

Und eingebaut im Roboter. Hier wird die Problematik vielleicht noch etwas besser deutlich.

Roboter 2014: Hardware (fast) fertig!

Nach einigen Lieferverzögerungen sind vor kurzem endlich die letzten Teile angekommen und der Roboter konnte endlich komplett zusammengebaut werden:

Roboter Queransicht

Komplettansicht des Roboters. Im Display wird unser überarbeitetes Logo angezeigt.

Aktuell fehlt noch der Untergrundsensor und zwei Motoren (wie in einigen Bildern zu sehen ist, ist das Getriebe auf der einen Seite größer. Leider wurden uns dort die falschen Motoren geliefert. Die richtigen wurden bereits nachgeliefert und befinden sich momentan im Zoll, dürften also spätestens nächste Woche ankommen, dann kann endlich richtig mit der Programmierung und ersten Tests angefangen werden).

Hier ein paar weitere Bilder:

Seitenansicht

Seitenansicht. Der An/Aus-Schalter ist steckbar mit der PowerUnit Platine verbunden. Wir haben vorerst nur insgesamt zwei Wärmesensoren angebaut. Das Kabel des Akkus unten wird natürlich beim Einsatz des Roboters richtig befestigt.

Frontalansicht

Frontalansicht. Rechts sieht man eindeutig das etwas breitere Getriebe, was für eine andere Untersetzung der Motoren auf der Seite sorgt. Die richtigen Motoren wurden uns bereits nachgeleifert und sollten nächste Woche ankommen.

 

Top-Ansicht

Top-Ansicht: Der Roboter im Kartenmodus (Bildschirm) von oben. Rechts sieht man die Platine für die Opfer LEDs und den Inkrementalgeber/dem Button.

Geöffneter Roboter

Geöffneter Roboter. Zum Debugging (Vermutung auf Hardwarefehler) müssen lediglich vier Schrauben gelöst werden, dann kann der Roboter aufgeklappt werden. Nun hat man Zugriff auf alle Kabelverbindungen und Platinen.

PowerUnit

Detailansicht der PowerUnit. Unten die Spannungsanzeige, oben die Steckverbinder für Schalter, Akku und Mainboard (gesichert durch Standard Sicherung). Unten die Aufteilung der zwei NXT-Ports auf vier Motoren (Parallelschaltung/Auswertung der Inkrementalgeber auf den vorderen Motoren).

Untergrundsensor

Untergrundsensor: Erste Experimente laufen. Weitere Infos, wenn es so weit ist. ;)

Weitere Fotos (später) in unserer Galerie.

 

RoboCup 2014: Überarbeiteter Roboter Teil 1: Hardware

Wie schon im letzten Beitrag von kurz nach den deutschen Meisterschaften, die jetzt schon fast drei Monate her sind, erwähnt, haben wir uns in letzter Zeit intensiv mit einer überarbeiteten Version unseres Roboters beschäftigt. Wir haben aus unseren Fehlern gelernt:

  • Keine LEGO Teile mit einem Selbstbau kombinieren:
    Wir dachten, wir hätten mit den LEGO Teilen insofern einen Vorteil, dass man sehr flexibel ist und einfach Teile auswechseln kann, beim Wettbewerb vielleicht bei anderen Teams fragen könnte, aber das (zum Glück) nicht nötig. Man ist mit den recht großen und klobigen LEGO Teilen eher recht unflexibel. Außerdem sind die LEGO Motoren nicht so robust, wie eigentlich gedacht – Nach zwei Jahren Betriebszeit kann da schon mal ein Motor kaputt gehen (indem er einfach von jetzt auf gleich blockiert).
  • Alles durchplanen:
    Wir haben bei unserem letzten Roboter nicht von Anfang an alles berücksichtigt und den Roboter bzw. nur die Aluminiumteile auf Papier geplant. Wenn man etwas erweitern möchte, muss bzw. mussten wir „aufstocken”, also unschön noch einen riesen Sensorkopf oben drauf setzen, weil einige Sensoren nicht eingeplant waren. Dieses Mal haben wir alles mit CAD durchgeplant – dazu später mehr.
  • Sollte eigentlich selbstverständlich sein, dazu hatten wir aber letztes Jahr, wie man gesehen hat (und wir auch gefühlt haben) keine Zeit mehr:
    Jeden Fall berücksichtigen und immer vom schlimmsten Fall ausgehen. Wenn einmal etwas schief läuft, kann es immer wieder passieren, d.h. jeden Fehler, egal, wie klein oder wie groß er ist, ernst nehmen.

Es hab da noch ein paar Kleinigkeiten, auf die hier nicht näher eingegangen wird.

Jetzt endlich zum neuen Roboter: Der alte Roboter war ja nicht komplett „falsch” (wie im Video zu sehen). Im Gegenteil, vieles hat sehr gut funktioniert! Problem war, dass wir vor den deutschen Meisterschaften zu wenig Zeit hatten, ein Eingriffsprogramm zu entwickeln (insgesamt waren wir bis Ende 2012, also zwei Monate vor dem ersten Wettbewerb, mit der Hardware beschäftigt). Natürlich darf auch das beim Wertungslauf nicht passieren, aber wie gesagt: Immer vom schlimmsten Fall ausgehen. Anfangs, direkt nach dem Wettbewerb, haben wir die Schuld auf die relativ Leistungsschwache Elektronik geschoben und wollten unbedingt auf was schnelleres umsteigen (Mikrocontroller mit ARM Kern (32bit), wir benutzen einen AVR (8bit) – Vor allem Speicherplatz und Geschwindigkeit waren verlockend, aber auch der sinnvolle Einsatz von C++. Außerdem sind ARMs zeitgemäß und werden immer öfter eingesetzt). Wir haben uns jedoch letztlich dagegen entschieden, wobei natürlich der finanzielle Aspekt keine kleine Rolle gespielt hat.
Bei guter Programmierung ist das System egal. 😉

Bei der Mechanik und speziell beim Fahrwerk musste aber unbedingt etwas passieren. Der alte Roboter war, da er komplett „handgefertigt” war, mehr oder weniger krumm und schief. Das hat es unmöglich (da eben (für uns) unberechenbar) gemacht, den Roboter 100%ig zuverlässig durch das Labyrinth fahren zu lassen. Deshalb haben wir uns wie gesagt für die Planung am Computer via CAD entschieden. Basismaterial, also das Chassis, sollte aus Plexiglas bestehen: Billig, leicht zu bearbeiten, extrem robust. Das Plexiglas sollte aber nicht von Hand bearbeitet, sondern Lasergeschnitten werden. Preislich macht das fast keinen Unterschied. Dafür hat man dann ein perfektes Ergebnis.

Plexiglasplatten halb transparent – unten Chassis (6mm Stärke) zur Aufnahme der Motoren und sämtlicher Elektronik, oben die „Bumperplatte” (3mm Stärke), die zur Begrenzung des Roboters und zum Befestigen der Sensoren und der Bedieneinheit dient.

Probleme hatten wir auch mit dem Schwerpunkt des Roboters, was mit den LEGO Motoren aus Kunststoff zusammenhing. Für den neuen Roboter nutzen wir „richtige“ Metallmotoren – vier Stück an der Zahl (das Konzept mit dem Allradantrieb hat sich bewährt, auch bei anderen Teams). Dabei werden später zwei Motoren pro Seite parallel angeschlossen, damit die alte Elektronik weiterverwendet werden kann. Der Akku befindet sich später zwischen den Motoren – so weit wie möglich unten.

Vier Motoren, griffige Räder, ein Akku in der Mitte

Wie oben bereits erwähnt, sollte die Elektronik und das Sensorkonzept vom letzten Jahr weiterverwendet werden. Die Elektronik hat allerdings nun zwei Schwachstellen:

  1. Wir haben letztes Jahr vergessen, quasi das gesamte „Power Management” mit auf die Platine zu setzen, dazu zählen eine Sicherung (deshalb ist uns bei einem Kurzschluss des Akkus schon einmal eine Leiterbahn verbrannt, die wir zum Glück überbrücken konnten) und der Spannungsteiler zum Messen der Akkuspannung.
  2. Die Aufteilung der zwei Motoranschlüsse auf vier Motoren
Platinenansicht

Platinenansicht auf 1. Ebene: Von links n. rechts: IMU – Mainboard – Power Unit

Deshalb haben wir uns dazu entschieden, für ein paar € dafür eine eigene Platine zu erstellen. Es ist zwar möglich, das Ganze irgendwie fliegend aufzubauen, aber da zu erwarten ist, dass so oder so viele Kabel verlegt werden müssen, macht das ein Debugging bei fehlerhafter Hardware später schwierig bis unmöglich. Auf der Platine befinden sich die oben erwähnten Einheiten. Da wir die Motoren parallel schalten, müssen sich die Motoren auf einer Seite gleich schnell drehen, weshalb auch nur ein Encoder pro Seite ausgewertet werden muss.

Power Unit – rohes Platinenlayout

Das Sensorkonzept hat uns sehr gut gefallen und sollte gleich bleiben: Pro Seite zwei Sensoren (einer vorne, einer hinten) zum Ausrichten, dann noch pro Seite ein Sensor in der Mitte zum Geradeausfahren bzw. Erstellen der Karte. Die IMU hat auch sehr gut funktioniert und wird weiter benutzt. Genau so das Display, dazu im nächsten Artikel aber mehr.

Roboter: Komplettansicht. Die vier Kegel stellen den Öffnungswinkel der Wärmesensoren dar.

Die nötigen Teile für den Roboter sind bereits bestellt, wahrscheinlich wird die Hardware also gegen Ende der Sommerferien (ca. 2 Wochen) stehen.
Lediglich der Sensor zur Erkennung der schwarzen Flächen fehlt noch. Wir haben schon eine Idee parat, dazu aber mehr, wenn es so weit ist.

CAD-Software

Deutsche Meisterschaften: Vorbereitung: Endspurt

Noch drei Tage bis zum Beginn der deutschen RoboCup Meisterschaften 2013 in Magdeburg, das heißt ENDSPURT! In den letzten zwei Wochen konnten wir einiges verbessern. Wir haben verschiedene kleine Fehler in der Software und in der Hardware behoben, die auf Anhieb gar nicht aufgefallen sind, aber einiges ausmachten. Der Sensor zum Erkennen der Sackgassen befindet sich so nun in der Mitte des Roboters, die Fahranweisungen wurden auf die neuen Entfernungssensoren umprogrammiert, ein recht schwerwiegender Fehler in der Hardware, der zeitweise bei Stößen Kurzschlüsse oder Busabstürze und somit einen Neustart verursacht hat, wurde entfernt, ein gebrochener LEGO-Verbinder, der den Kontakt der Zahnräder verhinderte wurde ausgetauscht und vieles mehr.

Des Weiteren haben wir den Algorithmus von Gaston Tarry implementiert. Wir fahren nun sehr einfach und recht zuverlässig alle Fliesen des Labyrinths ab um alle Opfer (auch auf möglichen Inseln) finden zu können, des Weiteren stoppt der Roboter automatisch auf der Startfliese. Der Algorithmus selbst ist super, Probleme kann es aber geben, wenn der Roboter die Orientierung verliert (wenn er beispielsweise sehr ungünstig gegen eine Wand fährt, aber dagegen sind die Taster bzw. Bumper vorne am Roboter sehr effektiv). Da müssen nur noch Feineinstellungen gemacht werden, dann klappt das Ganze (hoffentlich) gut.

Generell werden wir in Magdeburg aber etwas auf Glück setzen müssen. Wir haben ja nur zwei Optionen:

  1. Wir deaktivieren die Karte und folgen zuverlässig der rechten Wand
    –> Es werden keine Fehler passieren, dafür werden wir definitiv aufgrund der Geschwindigkeit unseres Roboters nicht unter den ersten zwei Plätzen landen (vielleicht 3. oder 4.).
  2. Wir benutzen den Algorithmus und die Karte und riskieren eine vordere Platzierung
    –> Wenn alles klappt, werden wir mindestens 2. Platz, da nur noch ein anderes Team eine Karte nutzt. Wenn Fehler passieren, werden wir vielleicht nur auf dem 5. oder schlechteren Platz landen, aber das kann uns ja egal sein, da nur die Qualifikation zur WM wichtig ist und wir die mit Option 1 sehr wahrscheinlich nicht schaffen würden.

Wir haben uns logischerweise für die zweite Option entschieden (nur so haben wir Chancen auf eine Qualifikation). Das muss sein. Sehr wahrscheinlich werden wir den Roboter aber noch rechtzeitig zuverlässig (genug) durch den Parcours fahren lassen können, da wir morgen und übermorgen noch jeweils ca. 2 Stunden Zeit zum Testen im großen Parcours der Schule haben und Donnerstag den ganzen Nachmittag in Magdeburg.

Wir werden also zuversichtlich aber wahrscheinlich mit einem mulmigen Gefühl in den Wettkampf gehen. 😀

Roboter 2.0 – mit Karte!

Nachdem wir uns nun mit dem 3. Platz bei den Vorqualifikationsturnieren in Hannover für die German Open, also die deutschen Meisterschaften, in Magdeburg qualifiziert haben, bereiten wir uns nun auf diesen nächsten Wettbewerb vor (bzw. haben wir schon intensiv in der Zeit, in der wir hier leider inaktiv waren). In Hannover haben wir festgestellt, dass unser Fahrgestell (wieder 😀 ) große Probleme mit der Rampe hat. Der Schwerpunkt war zu weit unten, der Radabstand zu klein. Mit einem überarbeiteten Fahrgestell, bei dem die sowohl die Räder, als auch die Motoren weiter auseinander sind, sodass die Auflagefläche größer ist und der Akku zwischen die Motoren passt, haben wir gehofft, nun auch Rampen mit 25° Neigung bewältigen zu können.

Konstruktion 2.0

Theoretisch klappte das auch, der Roboter fällt so nicht runter, allerdings ist die Kraft der Motoren zu klein, wobei die Motoren selbst nicht das Problem sind, viel mehr gab unser 7,2V System nicht genug Power her. Die Geschwindigkeit der Motoren muss geregelt werden, damit der Roboter immer gleichmäßig schnell ist. Das funktioniert nur, wenn genug Ressourcen zur Verfügung stehen. Wirklich regeln konnten wir allerdings nur bei Geschwindigkeiten unter 50% der Maximalleistung, da darüber immer automatisch Vollgas gegeben wird, um die Wunschgeschwindigkeit erreichen zu können (ein Beispiel: Wir möchten den Motor auf 100% laufen lassen. Volle Kraft wird zwar erreicht, wenn der Akku voll ist, dann stehen aber keine Kapazitäten mehr zum Regeln zur Verfügung. Falls der Roboter also z.B. die Rampe hoch muss, müssten die Motoren sich schneller drehen, da mehr Kraft aufgewandt werden muss, das ging aber nicht, da schon alle Kapazitäten ausgenutzt waren). Wir müssen außerdem schneller fahren können, um Zeit zu sparen. Ein weiteres Beispiel nun zum neuen 12V System: Der Akku soll auf 100% geregelt werden (es sollen also 9V ankommen). Es stehen nun auch Ressourcen nach oben zur Verfügung, um die Geschwindigkeit zu halten. Zudem sackt die Spannung mit der Zeit bis minimal 9V zusammen, beim alten System waren es 6V, womit man schon fast nichts mehr machen konnte.

Nachdem die Konstruktion fertig war, traten Probleme mit den Encodern auf, die uns insgesamt ca. 2 Wochen Zeit gekostet haben! Die verwendeten LEGO Motoren haben integrierte Quadraturencoder, bei denen jedoch nur ein Kanal über einen Hardwareinterrupt ausgewertet wurde, sodass nur nach oben gezählt wurde, auch, wenn der Motor rückwärts gedreht hat.

Modifikation für Quadraturencoder (zwei Kupferlackdrähte)

Bei hohen Drehzahlen darf das aber nicht gemacht, da müssen beide Kanäle ausgewertet werden, da sonst der Encoderwert nicht mehr stimmt. Nach einer kleinen Änderung auf der Platine werden nun beide Kanäle ausgewertet, nun nicht mehr über ein Hardwareinterrupt, sondern über einen Timer, der mit einer Frequenz von 10kHz aufgerufen wird, sodass auch noch hohe Geschwindigkeiten gemessen werden können.

Nachdem das funktionierte, haben wir die restliche Hardware angepasst. Dazu zählen eine neue Bedienplatine (also mit Inkrementalgeber zum Einstellen von Parametern etc. und dem An-/Ausschalter), da die alte auf die Schnelle gemacht war (keine Buchsen an der Platine, alles eher flüchtig, deshalb auch schon Wackelkontakte, was natürlich generell schlecht ist).

Durchgebrannte Versorgungsleitung auf der Platine

Aufgrund eines Flüchtigkeitsfehlers gab es auch direkt mal einen Kurzschluss in der Versorgungsleitung, der mal eben so die Hauptleitung auf der Platine hat durchbrennen lassen (da ist ein Strom mit mehreren Ampere geflossen, die Leitung auf der Platine hat natürlich den höchsten Widerstand und raucht ab). Zum Glück ist dabei nichts weiter kaputt gegangen, die Leitung konnte einfach überbrückt werden.

Des weiteren haben wir die Infrarot Wärmesensoren links und rechts befestigt sowie die Ultraschallsensoren und den Orientierungssensor auf den höchsten Punkt:

Fertiger Roboter

Auf dem Bild sieht man auch schon die neue Aufteilung des Displays und die Karte (auf dem Bild wird nur eine Beispielkarte angezeigt). Die Wände können schon einzeln abgerufen und geändert werden, natürlich auch auf dem Display dargestellt werden, der Roboter kann die Karte aber noch nicht autonom erstellen und damit umgehen, das kommt als nächstes.

Beispielkarte (Zahlen teilweise aufgrund großer Belichtungszeit der Kamera verschwommen)

Für weitere Fotos siehe Picasaweb.