Schlagwort: Roboter

Er fährt!

Nachdem im vorigen Beitrag gezeigt wurde, was alles nicht geht, und wie auch in der letzten Sendung meines Podcasts erwähnt, kann ich heute sagen: Kaum 7,5 Jahre später… und er fährt! ;-)

Sicher noch nicht perfekt und im hier auch noch sehr langsam, aber die „Richtung“ ist erkennbar. Nun gilt es noch die Parameter etwas zu optimieren, damit er auch noch durch die Tür fährt. Derzeit ist dieser Abstand dem Roboter noch zu eng. Alle diese Werte, wie diese „Durchfahrweite“, die per Kosinussatz anhand der Laserlinien ermitteltwird, können übrigens in der GUI „live“ über einen Settingsdialog geändert werden.

 

Hindernisumfahrung – Erstes Ergebnis

Wie im vorigen Beitrag gezeigt, fuhr der Roboter beim Starten nicht in die Richtung, die vom obstacleCheckThread schon lange ermittelt wurde. Der Fehler wurde gefunden und nun sieht das Ganze schon etwas besser aus. Noch nicht perfekt, aber es geht in die richtige Richtung – im wahrsten Sinne des Wortes:

PS.: Natürlich ist dieses nicht die Endgeschwindigkeit, aber zum Testen erstmal ganz angenehm.

 

Hindernisumfahrung – Erste Analyse

Wie im vorigen Beitrag gezeigt, schafft es der Roboter gerade hervorragend mutig gegen ein Hindernis zu fahren – ohne auszuweichen. Um herauszufinden, woran es liegt, wurde nun die Fahrt des Bots etwas präziser aufgezeichnet. Zuvor wurde der TFT-Bildschirm ummontiert, so dass diese endlich in Fahrtrichtung zeigt und auch von oben etwas besser erreichbar ist. Hier das mit der Hand gedrehte Video:

Es ist etwas wackelig, da ich die Kamera nicht fest auf dem Roboter montieren konnte. Sie würde trotz aufgesetztem Weitwinkel-Objektiv zu weit nach hinten vom Bot abstehen. Und ich möchte mir nicht vorstellen, was passiert, wenn der Roboter sich dann dreht und die Kamera mit Halterung irgendwie abbricht, stürzt oder ähnliches…

Was ist also im Video oben passiert? Hier sieht man erst einmal die Richtung in die der Bot fährt:

Wie man sieht, ist der grüne Bereich der Laserlinien der für den Roboter befahrbare Bereich und der Roboter hat als sogenannte „preferred direction“ bereits links gewählt – Erkennbar an dem Pfeil in der GUI, der nach links zeigt:

Was macht er aber genau nicht, wenn man auf dem Touchscreen auf „Start“ klickt? Richtig. Nach links fahren. Denn obwohl der obstacleCheckThread die ganze Zeit aktiv ist (sonst würde der Pfeil nicht nach links zeigen), fährt der Roboter geradeaus – und fährt komischerweise auch weiter geradeaus. Normalerweise sollte der obstacleCheckThread sofort die Info per Qt’s Signal und Slot Mechanismen an alle beteiligten Prozesse senden, dass es nach links gehen. Hier gilt es also, einen schönen Bug zu finden! Bleibt dran…

Hindernisumfahrung mit Hindernissen

Nach vielen vielen Code-Updates und dem kompletten Rewrite des sogenannten obstacleCheckThreads, war es endlich an der Zeit, den Roboter drauf los zu lassen. Hello world… ;-)

Es gab zwar beim Testen ein- oder zweimal Abstürze, beim Betrieb der Software unterm Mac (Roboter war „aufgebockt“, Fahrpogramm gestartet), diese konnten aber bislang nicht reproduziert werden.

Um es gleich vorweg zu nehmen: Alles funktioniert eigentlich einwandfrei. Jedoch „erkennt“ der Roboter die Hindernisse derzeit noch zu spät. Obwohl bereits die langsamste Fahrgeschwindigkeit gewählt wurde und auch das Entfernen des sleep commands aus laserThread und obstacleCheckThread keine Beschleunigung brachte, reichte dies alles nicht aus, den Roboter dazu zu bringen, schnell genug auszuweichen.

Im Moment habe ich ehrlich gesagt keine Idee, woran es liegen könnte… Genug der Worte, hier die einzelnen Videos.

Hier sieht man, wie der Roboter – wie im späteren Fahrbetrieb – mit dem onBoard-PC läuft, jedoch noch „aufgebockt“:

Beim zweiten Video sieht man, wie der Roboter „richtig“ fährt und auch dem ersten Hindernis brav ausweicht, aber dann unmotiviert (leider aus dem Bild) bei einem Hindernis festhängt, dann aber wendet um anschließend mutig Richtung Werkbank zu fahren. Vor lauter Schreck bleibt er er jedoch vor dem Hindernis stehen und aktiviert den Zustand „alles voller Hindernisse“ (Blitzlicht an, alles stoppen):

Nun wurde kurzerhand ein Laptop auf den Bot „befestigt“ (Festplatte zuvor vom Roboter auf den Laptop geclont) um zu Testen, ob der onBoard-PC vielleicht zu langsam ist. Sieht aber nicht danach aus. Auch das klappt nicht wie gewünscht:

Da er beim vorigen Film drohte, erneut die Staffelei umzureißen (auch wegen der provisorisch befestigten, aber herausragenden Aluschiene), hier noch ein letzter „Outtake“. Ich nenne ihn mal „mutiges Hindernis-Anfahren, um dann doch zu stoppen“:

 

Test der RGB-LEDs mittels PWM

 Nachdem die Motoren des Roboters erfolgreich mit dem noch recht neuen STM-Board über PWM angesteuert wurden, musste nun noch ein Test mit den RGB-LEDs erfolgen. Hier war nicht die Frage, ob PWM funktioniert, sondern viel mehr, ob die 3,3 Volt Pegel einwandfrei mit den Optokopplern funktionieren. Die Optokoppler sind nämlich hier nötig, da die RGB-LED-Streifen mit 12 Volt angesteuert werden. Das Ergebis war aber erfreulich:

  

Übrigens die im Bild verwendeten Kabel zum Verbinden des STM-Boards habe ich bei Watterott bestellt.

Und wen es interessiert, wie die LED-Streifen angesteuert werden:

Motortest mit STM-Board über die serielle Schnittstelle

 Mittlerweile wurde der Sourcecode vervollständigt, um alle vier Motoren per PWM und mit den jeweiligen Portbits anzusteuern. Hierzu die Fotos wo die Ansteuerung über den seriellen Port erfolgt:

Hier im linken Bild rechts unten sieht man die (rote) Platine, welche die USB-Verbindung zum steuernden Rechner darstellt. Von hier aus werden (gerade in einem Terminal-Programm) die seriellen Befehle gesendet. Das USB-Kabel am STM-Baord dient nur zur Stromversorgung (und zum Flashen):

   

PWM Ergänzung

 Hier noch ein paar ergänzende Fotos zum hier beschriebenen PWM-Test mit dem STM32F4 DISCOVERY Board:

    

Kleiner Tipp noch für das Testen: Es schadet nicht, die verschiedenen Spannungen an den Kabeln zu beschriften.

 

Abschließend möchte ich hier noch ergänzen, dass es mir nicht gelungen ist, die Timer 1 und Timer 8 (TIM1 & TIM8) sowie die Timer 9 bis 14 bei gleichem Sourcecode dazu zu bewegen, die gleiche PWM-Frequenz auszugeben. Aus einem mir noch nicht klaren Grund, waren diese Timmer immer doppelt so schnell. Es funktionierte nur mit den „General-purpose timers (TIM2 to TIM5)“ einwandfrei. Die erste Vermutung, dass es teils 32-Bit- und teils 16-Bit-Timer bestätigte sich nicht. Wenn jemand einen Tipp hat, gerne als Kommentar hinterlassen!

Erste Tests mit dem STM-Board und dem Roboter

 Die Arbeit mit dem STM-Board macht Fortschritte: Beim letzten Update wurde der Code für das ARM-Board derart aktualisiert, dass 2 Bits als Ausgänge definiert wurden. Diese wurden in fliegender Verdrahtung mit einander verbunden, so dass die Eingänge des Motorcontrol-Boards direkt am STM32F4-Board angeschlossen wurden. Interessant ist hierbei, dass das Motor-Board – entgegen den 3,3 Volt des STM-Boards –  5 Volt-Logik aufweist. Das geht jedoch in dieser Richtung, da die 3,3 Volt (HIGH) am Ausgang auch als HIGH vom Motorcontroll-Board akzeptiert werden weil sie innerhalb der Spezifikation liegen. Und so sieht das Ganze dann aus:

Nun wurde das das STM-Board per USB mit dem MacBook verbunden, ein Terminal-Programm gestartet, welches Befehle an das STM-Board sendet:

   

 

 
Und: Es fuktioniert! Der Motor 1 dreht in beide Richtungen entsprechend der seriellen Befehle – wie zuvor mit dem Atmel-Board. Und im Sourcecode wurden lediglich die neuen ARM-Ports angegeben und die Befehle zum Bit-Setzen und -Löschen angepasst. Als nächstes muss geprüft werden, wie bei dem ARM-Board PWM funktioniert, damit z.B. die Motorgeschwindigkeit Richtung Motorcontrol-Board „gesendet“ werden kann.
 
Das Gute an dem Motorcontrolboard: Die benötigte PWM-Spannung Vpwh kommt hier ebenfalls mit 3,3 Volt klar (min. 3,25 Volt). Die Versorgungsspannung des verwendeten Motortreiber ICs VNH2SP30-E benötigt jedoch mindestens 5,5 Volt und maximal 16 Volt – aber diese stehen auf dem Bot ja ohne weiteres zur Verfügung.

RoboCup@Home – Video vom Team ToBI

Ein Video des RoboCup@Home 2011; der Roboter des Team ToBI:

Der Roboter ist von der Universität Bielefeld.

PS.: Das Intro ist noch falsch im Video betitelt, sorry. Wird vielleicht mal korrigiert.

 

RoboCup@Home 2011 – Team NimbRo – Die Gewinner 2011!

Hier nun das letzte Video des RoboCup@Home 2011 Finales. Es ist das Team NimbRo der Universität Bonn. Mit einer absolut beeindruckenden Leistung überzeugten sie auch die Jury und landeten darum als Ergebnis auch auf Platz 1.

Aber seht selbst: