Allgemeiner Aufbau minibot

Mein Roboter

An dieser Stelle möchte ich zeigen, welche Komponenten aktuell bei meinem Roboter minibot verbaut sind und was diese so kosten können.

Mein Roboter „minibot“
Allgemeiner Aufbau minibot weiterlesen

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

 

Zweiter Test mit ARM-Board

Hier der zweite Test mit dem frisch gelöteten ARM-Board mit dem STM32F4 STMicroelectronics und dem komplett neu geschriebenen Code. Die Software läuft hier komplett auf dem Roboter unter Linux, so wie er später selbstständig „durch die Gegend“ fahren soll:

 

Warum die Kinect Sinn macht – trotz Laserscanner

 Für die, die sich fragen, warum die Kinect denn zusätzlich zum bereits vorhandenen Laserscanner nötig ist, hier ein paar Erläuterungen. Ein Vorteil des Laserscanners ist seine hohe Reichweite. Das kommt sicher im Umfeld einer Wohnung oder eines Hauses sicher kaum zum Tragen, ist aber nicht zu verachten. Vor allem aber ist der Laserscanner, dessen normales Einsatzgebiet Sicherheitsbereiche in der Fabrikation mit extrem hohen Anforderungen ist, sehr zuverlässig. Eine optische Erkennung, die auf Software basiert kann derzeit nur ungenauer sein, als die bereits seit langer Zeit im Einsatz befindliche und erprobte Hardware.

Der wesentliche Nachteil des Laserscanners gegenüber der Microsoft Kinect Kamera ist aber, dass er nur zweidimensional scannt. Die Laserstrahlen breiten sich wie ein Fächer nur auf einer Ebene aus. Um das deutlich zu machen wurde im Folgenden ein Päckchen vor dem Roboter als "Hindernis" platziert – einmal hochkant, so dass es in den Scanbereich des Laserscanners hineinragt und einmal flach auf dem Boden liegend, so dass die Laserstrahlen über das Päckchen hinweg gehen. Und so sieht das Ganze dann aus:  

  

 Deutlich zu erkennen, dass im linken Screenshot das Päckchen von der Software als Hindernis erkannt wird (hellroter Bereich="Hindernis", grüner Bereich = "frei") während auf dem rechten Bild das Hindernis nur von der Kinect dargestellt wird (weiße grobe Umrisse links unten in dem schwarz-weiß-Bild), für den Laserscanner aber alles "frei" scheint (grün).

Anmerkung: Die Software wertet die Kinect-Daten noch nicht aktiv aus, sondern zeigt sie nur als Bild an.

Schematischer Aufbau direcs1

Auf dieser Seite ist der aktuelle schematische Aufbau des Roboters direcs1 dargestellt:

Stand: 04.04.2011

 

Laserscanner und Touchscreen verkabelt

 Heute wurden nun der Laser und der Touchscreen auf dem Roboter verkabelt, denn so wie es sich hier darstellt, konnte es für den endgültigen Betrieb natürlich nicht bleiben:

Ein Stromanschluss für den Laserscanner war vom alten Scanner noch vorhanden. Der Touchscreen, der mit 12V betrieben wird, benötigte jedoch noch eine Anschlussbuchse. Da dazu die Verteilerplatine ausgebaut werden musste, wurden bei der Gelegenheit zwei zusätzliche Buchsen für 5V und 24V als Reserve mit verbaut:

    

Und das Ergebnis kann sich doch sehen lassen, oder?