Wie es weitergeht: Überarbeitung des Roboters

Insgesamt sind wir sehr über unser Abschneiden bei den deutschen Meisterschaften 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 haben 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 messen kann, aber für eine Hinderniserkennung ist das weniger gut geeignet, da unter Umständen Hindernisse in einem toten Winkel stehen können, die Hindernisse also einfach von den Sensoren übersehen werden). Dagegen helfen Ultraschallsensoren, da sie das gesamte Sichtfeld des Roboters abdecken können.

Bei der WM werden die neuen Regeln zu Einsatz kommen. 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 dazu 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 hellen 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.

Veröffentlicht unter teamohnename.de | Kommentare deaktiviert für Wie es weitergeht: Überarbeitung des Roboters

Tag 4: Deutsche Meisterschaften „German Open“ in Magdeburg: Finale und Siegerehrung

Der vierte Tag – langsam wurde es spannend. Wir waren zwar schon ziemlich sicher auf dem 2. Platz (damit sich das geändert hätte, hätten wir einen sehr schlechten letzten Lauf und ein anderes Team einen sehr guten Lauf abliefern müssen), bei den Plätzen unter dem zweiten Platz sah es aber schon etwas enger aus.

Wir haben nichts mehr am Roboter geändert und nur noch auf unseren Lauf gewartet. Dieser sah zunächst sehr gut aus – alle Opfer wurden korrekt erkannt – der Roboter hat sich dann aber an einem Hindernis aufgehangen. Normalerweise fängt unsere Kollisionserkennung sowas ab, die Dose befand sich aber genau im Toten Winkel unseres dafür zuständigen Sensors. Der Roboter hat dann natürlich seine Position in der Karte verloren und wir haben abgebrochen – warum genau wissen wir selbst nicht, wahrscheinlich in der Aufregung? Wir hätten auf jeden Fall den Roboter neu in den Parcours setzen können und hätten den Startbonus noch bekommen können. Aber das änderte wie gesagt nichts an unserer Platzierung. Nochmal passiert uns sowas aber nicht 😉

Zwischenzeitlich dachten wir dann doch, dass uns ein anderes Team überholen könnte, aber da es über das Zeitlimit von 8 Minuten kam, konnte auch hier der Startbonus nicht in Anspruch genommen werden.

Letztlich sind wir dann, wie vermutet, auf dem 2. Platz gelandet. Insgesamt ärgern wir uns schon etwas darüber, da wir, wenn wir die Opfer zu Beginn des Wettbewerbs nicht (falsch) erkannt hätten, sogar 1. werden können (erstaunlicherweise waren wir schneller als der 1. Platz, der in Hannover noch schneller war als wir). Aber egal, wir sind voll und ganz zufrieden mit unserer Platzierung.

Wahrscheinlich haben wir uns somit für die WM in Brasilien qualifiziert, die Quoten wurden allerdings noch nicht veröffentlicht, sicher ist das also noch nicht. :/

Die Fotos aus Magdeburg haben wir ins Webalbum hochgeladen, auch zu finden in der Galerie.

Veröffentlicht unter German Open, teamohnename.de | Kommentare deaktiviert für Tag 4: Deutsche Meisterschaften „German Open“ in Magdeburg: Finale und Siegerehrung

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!

Veröffentlicht unter Infos | Kommentare deaktiviert für Tag 3: Deutsche Meisterschaften „German Open“ in Magdeburg: Zwei Wertungsläufe

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. 🙂

Veröffentlicht unter German Open, teamohnename.de | Kommentare deaktiviert für Tag 1 + 2: Deutsche Meisterschaften „German Open“ in Magdeburg: Setup und erster Wertungslauf

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.

Veröffentlicht unter teamohnename.de | Kommentare deaktiviert für Kollisionserkennung und Optimierungen

German Open 2014: Was wir planen zu tun…

Nachdem wir bei den Vorqualifikationen in Hannover den 2. Platz belegt haben, bereiten wir uns auf die deutschen Meisterschaften „German Open“ 2014 in Magdeburg vor.

Bis heute waren wir noch mit unseren Facharbeiten beschäftigt (dazu bald mehr 🙂 ), weshalb recht wenig bis gar keine Zeit für den Roboter blieb. Generell wollen wir aber soweit nichts mehr ändern, der Roboter hat schließlich gut funktioniert. Lediglich in Richtung Kollisionserkennung wollen wir etwas Neues anfangen. Probleme gab es, wenn der Roboter recht nah an einer Wand war, er also noch keine Gelegenheit hatte, sich optimal anzupassen, und sich an der Wand ein Opfer befindet:

Roboter Problem

Wenn der Roboter schräg (auf das rot markierte Opfer [Fall 2] oder generell eine Wand [Fall 1]) aufkommt, bleibt er unter Umständen daran hängen und er verliert die Orientierung in der Karte. Um das Problem zu beheben, wollen wir mehr mit den nach vorne zeigenden Entfernungssensoren arbeiten. Wenn diese auf einmal eine sehr niedrige Distanz erkennen, muss der Roboter etwas nach links bzw. rechts korrigieren.

Diese Problematik hat uns schon letztes Jahr die Qualifikation zur WM gekostet und soll deshalb dieses Jahr vermieden werden. 🙂

Das sollte auch recht schnell implementiert sein und den Roboter nochmal etwas zuverlässiger machen.

Veröffentlicht unter teamohnename.de | Kommentare deaktiviert für German Open 2014: Was wir planen zu tun…

RoboCup Qualifikation in Hannover: Zusammenfassung

Beim Wettbewerb direkt hatten wir leider keine Zeit, unsere Blog-Artikel direkt hier zu posten, weshalb wir sie im Folgenden alle in diesem Artikel zusammenfassen.

Tag 1: Setup

Wie versprochen hier der Artikel für den ersten Tag. 🙂
Heute war Setup und es nicht so viel Besonderes passiert. Wir konnten einfach den ganzen Tag den Roboter testen. Am Anfang hat es noch hier und da gehakt, was aber einfach mit den Feineinstellungen des Roboters zusammenhing, die noch für den Parcours der Schule angepasst waren. Ein weiteres Problem gab es mit einem vorderen Entfernungssensor, der uns plötzlich nur noch Entfernungen bis ca. 20cm ausgegeben hat. Wir haben diesen Sensor dann testweise gegen einen der neuen Entfernungssensoren ausgetauscht, die bis zu 50cm funktionieren. Das war recht schnell erledigt, der Roboter hat dann auch schon super funktioniert.

Die Rampe war das größte „Problem“, aber auch das war nach Einstellen der Parameter behoben.

Insgesamt war der Tag wenig Ereignisreich. Morgen ist unser erster Wertungslauf um 11:50 Uhr, mal gucken, was dabei rumkommt 🙂

Tag 2: Erste Wettläufe

Heute standen die ersten beiden der drei Wertungsläufe an, nachdem wir noch etwas Zeit zum weiteren Testen des Roboters hatten. Der Roboter lief beim Testen sehr zuverlässig, wenn auch das ein oder andere Mal etwas recht knapp war. Hoffen und Bangen, dass nun ausgerechnet beim Wertungslauf etwas schief läuft, gibt es also immer 😉 Der erste Wertungslauf war dann perfekt, abgesehen davon, dass der Schwellwert für die Zeilenkamera zum Erkennen der schwarzen Flächen nicht richtig eingestellt war, weshalb die schwarzen Flächen einmal durchfahren wurden. Der Roboter muss dann an den Anfang des Raumes gesetzt werden; Nach aktuellen Regeln darf dem Roboter manuell die neue Position in der Karte mitgeteilt werden. Normalerweise würde der Roboter dann erneut durch die schwarzen Fliesen fahren, weil der Schwellwert und der berechnete Wert genau so wie vorher sind, allerdings haben wir hier einen Vorteil mit der Karte, denn der Roboter fährt dann normalerweise nicht erneut auf besuchte Fliesen. Insgesamt hatten wir so 230 von 250 möglichen Punkte, ein gutes Ergebnis.

Der zweite Wertungslauf verlief ohne besondere Vorkommnisse und wir konnten die in dem Parcours maximal mögliche Punktzahl von 250 Punkten erreichen. 😀 Aktuell stehen wir auf dem zweiten Platz. Der dritte Platz folgt mit einem Abstand von 100 Punkten.

Morgen ist noch der Finallauf (gewertet werden die besten 2 aus 3 Läufe) und dann war es das auch schon. Fotos folgen dann im Laufe der Woche, da die Internetverbindung hier recht langsam ist…

Tag 3: Finallauf und Siegerehrung

Auch jetzt gibt es nicht so viel zu schreiben 😀 Nachdem wir Einiges getestet haben und einige weitere Feineinstellungen vorgenommen haben, hatten wir als letztes Team unseren Wertungslauf, auch dieses Mal mit voller Punktzahl.

Wir haben letztlich den 2. Platz belegt und sind voll und ganz zufrieden damit. Unsere Punktzahl ist identisch mit dem ersten Platz, der Roboter war nur 1,5 Minuten langsamer.

Somit haben wir uns für die deutschen Meisterschaften in Magdeburg vom 2. bis zum 5. April qualifiziert. Wir freuen uns auf jeden Fall! 😀

Fotos findet ihr hier.

Veröffentlicht unter German Open, teamohnename.de | Kommentare deaktiviert für RoboCup Qualifikation in Hannover: Zusammenfassung

Vorbereitungen: Qualifikationsturniere in Hannover

Montag beginnt nun der Wettbewerb in der Saison 2014 für uns. In den letzten beiden Wochen haben wir uns, nachdem wir die Fehler in den Entfernungssensoren behoben haben, auf die Optimierung in Sachen Genauigkeit beim Fahren, besonders aber in Sachen Schnelligkeit konzentriert. Der Roboter fährt nun, obwohl die Sensoren früher drei mal schneller abgefragt werden konnten, genau so gut wie bevor die Probleme mit den Sensoren aufgetreten sind. Bei letzten Tests am Donnerstag ist unser Roboter leider die viel zu steile Rampe runtergerutscht und hat einen Plexiglaschaden erlitten, der aber einfach zu kleben sein sollte und die Funktion des Roboters nicht beeinträchtigt. Insgesamt sieht es sehr gut aus. 🙂 Wir freuen uns auf den Wettbewerb.

Montag ist erst noch den ganzen Tag Setup, wir können also am Parcours unter Wettbewerbsbedingungen testen und Dienstag beginnt der Wettbewerb. Mittwoch sind dann die Finalläufe und die Siegerehrung. Wir werden versuchen, Euch via Twitter auf dem aktuellsten Stand zu halten, jeden Abend wird aber auch ein neuer Artikel erstellt. Versprochen 😉

Veröffentlicht unter teamohnename.de | Kommentare deaktiviert für Vorbereitungen: Qualifikationsturniere in Hannover

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. 🙂

Veröffentlicht unter teamohnename.de | Kommentare deaktiviert für Entfernungssensoren und ihre Tücken…

Rampe und wie es weiter geht

Nachdem wir durch die Tiefensuche die Effizienz und Zuverlässigkeit des Roboters extrem steigern konnten, haben wir einige weitere kleinere Bugs beseitigt, darunter einige, die etwas mit der Rampe zu tun hatten.

Zum Einen werden nun auch die schwarzen Fliesen, die nicht vom Roboter überquert werden dürfen, richtig von der Tiefensuche umfahren. Diese wurden zu Beginn nicht richtig als nicht-befahren Fliesen vom Roboter erkannt (wir markieren ja jede befahrene Fliese, die schwarzen Flächen wurden nicht befahren, nicht markiert und die Tiefensuche dachte nun, das wäre die nächstgelegene, unbesuchte Fliese, der Roboter konnte aber keine Route dort hin finden (dürfen ja nicht befahren werden) und startete deshalb nach kurzer Zeit neu). Jetzt funktioniert das aber soweit. Auch der Ersatzsensor, der eingreift, wenn die Kamera versagt, funktioniert sehr gut und sehr zuverlässig.

Die Rampe sollte diese Saison universeller in die Karte eingezeichnet werden können, als letztes Jahr (da haben wir die Rampe einfach anhand der Position des Roboters erkannt; Das hat auch gut funktioniert, aber dieses Jahr sollte es ja egal sein, wo der Roboter startet; da kann man sowas deshalb nicht machen). Die Rampe wird nun mithilfe des Orientierungssensors erkannt und in die Karte eingezeichnet, unabhängig von der Position des Roboters. Der Roboter erkennt, wenn die Rampe zu Ende ist und wechselt in die obere Ebene des Speichers der Karte und macht dort normal weiter. Wenn er wieder runterfahren will, wird das nicht erneut über den Neigungssensor erkannt, sondern über die gespeicherte Position der Karte.
Wir betrachten die Rampe in der Karte als Verbindung der Ebenen. Wenn wir an einer Stelle in der Karte, an der sich die Rampe befindet, z.B. bei der Nachbarfliese abfragen, ob der Roboter dort bereits war, wird direkt der Wert der Fliese des oberen Rampenendes zurückgegeben. Auch, wenn wir den Roboter eine Fliese geradeaus fahren lassen und er dabei die Rampe überqueren muss, wird das wirklich nur als eine Fliese geradeaus gesehen. Die Rampe wird also quasi ignoriert und stellt im Programm eine Sprunganweisung zur nächsten Ebene dar.
Außerdem ist es nun möglich, den Roboter in der oberen Ebene starten zu lassen (wichtig, falls er, warum auch immer, oben neu starten sollte). Dann werden in der Karte die obere und untere Ebene vertauscht, wenn er die Rampe befahren hat.

Im Prinzip haben wir nun einen Wettbewerbsfähigen Roboter, von uns aus könnte es heute losgehen. 🙂
Als nächstes werden wir uns etwas damit beschäftigen, Hindernisse in die Karte einzuzeichnen und diese zu umfahren. Hindernisse können eine beliebige Form und Größe haben, sind aber mindestens 20cm groß und haben mindestens vier Ecken. Sie können überall platziert, es ist aber gewährleistet, dass der Roboter noch einen Weg um die Hindernisse finden kann. Ein Hindernis kann also auch so aussehen:

 

 

 

 

 

 

Wir haben schon einen Plan, wie wir sie in der Karte einzeichnen, aber dazu mehr, wenn wir den umgesetzt haben.

Im letzten Artikel haben wir auch etwas von Selbstortung erwähnt. An unserer Schule stehen die Facharbeiten an und ich werde mich etwas näher damit beschäftigen, einen Algorithmus zu entwickeln, der zum Einen erkennen kann, wenn die Position des Roboters nicht mehr mit der Karte übereinstimmt und zum Anderen ggf. sich selbst in der Karte wiederfindet und dann mit der Opfersuche weitermacht. Auch dazu aber mehr, wenn es soweit ist.

Veröffentlicht unter teamohnename.de | Kommentare deaktiviert für Rampe und wie es weiter geht