Thema: Autonomer, kompakter Roboter zur Kartierung und Navigation

Hallo Jan,

was ist denn nun so einzigartig an deinem Umgang mit Steuer und Regelungstechnik?
Ok, pc am Roboter haben nicht alle. Und als Elektroniker (BTW:Zu so einem wird man notgedrungen wenn man sowas vor hat) .. Baut man schließlich doch keinen Modellbau-Kram in den Bot.
Tja und Native-Java-Hacks und der gleichen schrecken einen SW-Entwickler auch nicht wirklich. Praktische Erfahrungen zur Relativität von Echtzeit sammelst du schließlich auch irgendwann usw.

Also erkläre dich bitte genauer

Viele Grüße
Christian

Hallo Jepp,

seit längerem nochmal ein schönes Roboterprojekt.
Ich gehöre zwar auch eher zu denen, die die Hardware selber bauen aber dennoch kann ich deine Argomentation gut nachvollziehen, du musst dir eben kaum Gedanken um den Bau der Hardware machen. Ich finde aber das macht die Thematik Robotik aus, dass man eben nicht nur das Gebiet Programmierung hat. Aber das ist ein anderes Thema und das soll hier ja nicht diskutiert werden.

Ich interessiere mich sehr für das Thema Katierung und Navigation, daher finde ich dieses Projekt auch so toll. Leider schreibst du sehr wenig zu deiner Software. Hast du diese selber geschrieben, der Screen mit den Chips sieht sehr interessant aus, könntest du evtl. mal einen größeren Screen von deiner Software machen und diese etwas näher beschreiben? Wie erfasst du die Daten aus enem Scan? Wie Visualisierst du diese?

Freue mich auf deine Antworten und wünsche dir weiterhin viel Erfolg.

Zitat von RP6conrad

Schones project. Aber ein Panzer Antrieb ist nicht das ideale Basis für odometrie. Bei Gerade ausfahren stimmt die Wegstrecke noch einigermasse, aber sobald gedreht wird ist die genauigkeit weit weg. Und so werd es schwierig um eine Karte abzulegen. Moglicherweise hilft eine gyro, aber der hat naturlich Drift. Muss wiederum kompensiert werden mit etwas anderes. Ein magnetokompass naturlich !! Aber inhaus sind die auch nie wirklich genau.

Hallo, erstmal freue ich mich über das Interesse.
Was den Antrieb angeht, setze ich auf die unkomplizierte Austauschbarkeit. Der Kettenantrieb des Spielzeugpanzers soll ein Anfang sein, einen zweiten Unterbau habe ich die Tage fertiggestellt. Einige hart gesottene Roboterbauer werden bei der Bauteilauswahl wohl die Nase rümpfen.. Bilder kommen noch.
Kettenantriebe wirken auf mich wesentlich flexibler, was die Steuerung der Fahrtrichtung angeht. Bei einem vierrädrigen Fahrzeug mit zwei lenkenden Rädern dachte ich erst an Wenderadius, evtl. Differenziale, Radumfang, Auflagefläche, Gewichtsverteilung usw. usw.
Ich fahre Quad, dabei führt die starre Hinterachse bei variierender Untergrundbeschaffenheit zu den wildesten Fahrmanövern. - Macht Spaß, zur präzisen Kartierung trägt es sicher nicht bei.

Für die Bewegung wollte ich erstmal (unter Innenraumbedingungen) Vorwärts- und Rückwärtsbewegung zulassen. Bei der Rotation die Vorgabe von 90 Grad machen.
Eine Kombination aus den Daten des Beschleunigungssensors, Drehzahlgebern auf den Antriebsachsen und, vielleicht sogar noch zuverlässiger, die Erfassung der Umgebung durch die Sensortürme.
Ich will vorerst versuchen, eine möglichst präzise Erfassung der translatorischen Bewegung zu erreichen. Dafür sollte der Beschleunigungssensor theoretisch ausreichen. Dazu muss ich sagen, dass das Vorhaben momentan sehr unpräzise arbeitet und ich die Drehzahlgeber zur Sicherheit nachträglich verbaut habe.
Eine zweifache Integration über die Zeit (der Beschleunigungswerte) gibt allgemein eine Strecke - aktuell klappt nicht mal die erste Integration zur Berechnung der Geschwindigkeit. Die Wegstreckenmessung per Drehzahlgeber will ich die nächsten Tage programmieren.

Bild hier  

Was die Rotation des Bots angeht ist ein Gyroskop in meinem Umfeld wohl erste Wahl. Eine Rekalibration ließe sich ja vor der Drehung durchführen. Über einen Magnetkompass hatte ich auch nachgedacht. Evtl sogar das Verbauen eines aktuellen Smartphones, da die ja mittlerweile über soviel Sensorik auf kleinem Raum verfügen, dass selbst Augmented Reality Anwendungen laufen. HTC Magic und das iPhone 3GS fallen mir da ein. Beide bringen Magnetkompass, Beschleunigungssensor und für Feldtests sogar gleich noch GPS mit. Fällt aber wegen der Kosten raus. Zudem hätte ich vorher noch Aufwand, den Schnittstellenzugriff nachzulesen. - Genug geträumt..
Ich werde auch bei der Rotation auf der Stelle auf meine IR-Sensordaten und die Drehzahlgeber setzen und schauen, was ich mit dem Vergleich der internen Karte erreichen kann.

Bild hier  

Ich habe Bilder zur ersten Erfassung der Beschleunigungssensordaten und dem Messbereich (Winkel) der Sensortürme angehängt.

Zitat von daniel.weber

Ich interessiere mich sehr für das Thema Katierung und Navigation, daher finde ich dieses Projekt auch so toll. Leider schreibst du sehr wenig zu deiner Software. Hast du diese selber geschrieben, der Screen mit den Chips sieht sehr interessant aus, könntest du evtl. mal einen größeren Screen von deiner Software machen und diese etwas näher beschreiben? Wie erfasst du die Daten aus enem Scan? Wie Visualisierst du diese?

Hallo, das Thema Kartierung und Navigation gibt so unendlich viel her, dass ich meinen Arbeitsaufwand für den Unterbau minimieren und das Feld den Maschbauern und Zerspanungsmechanikern überlassen will. Vielleicht ergibt sich im Laufe der Zeit ja, dass ich an ein robusteres Fahrwerk komme.


Bild hier  

Zum bisherigen Softwarestand:
Kommt alles. Ich brauch jedes mal Ewigkeiten um einen Post zu erstellen, lese mir alles mehrfach durch und versuche Schrift- und Formfehler zu finden. Ich habe derzeit lediglich ein paar kleine Programme zum Umgang mit den Phidgets und Messwerten geschrieben, die bisher Teilbereiche abdecken.

Bild hier  

Ein Programm lässt den Bot geradeaus fahren und bei Kollisionsgefahr (durch die 5cm IRs) etwas rotieren, danach seine Fahrt fortsetzen.
Ein Anderes erweitert die Funktion oben um die Verwendung der 80cm IR-Sensoren. Die Sensortürme schwenken dabei gleichmäßig hin und her. Wird im Schwellbereich von 10-20cm ein Hindernis entdeckt, liefern die Scanthreads die Distanz und die ermittelten Winkel des Turms an den Hauptstrang der Anwendung. Diese stoppt die Motoren und macht eine Konsolenausgabe.

Für die Darstellung der Messwerte in der Ebene nutze ich die Standardelemente wie Linien und Ovale von Java Swing, für die dreidimensionale Darstellung der Messwerte verwende ich Java Bindings for OpenGL (JOGL). Beide Vorgehen haben sich bewährt und sind für OS X, Linux und Windows ohne ausschweifende Frickelei nutzbar.

Zur Visualisierung habe ich verschiedene Bereiche begonnen.
Angefangen habe ich, den Umgang mit den IR-Sensoren zu testen. Ich wusste anfangs nicht, dass in den Sharp Sensoren ein PSD verbaut ist und dass sich damit sogar verhältnismäßig präzise ein dreidimensionaler Raum erfassen lässt. <BittenichtZUernstNehmen> Verhältnis im Bezug der Anschaffungskosten und Größe eines Sharp IR-Sensors und eines SICK Laserscanners. Ok, der Vergleich ist schon flexibel hergeholt aber ich war erstaunt, was mit den IR-Sensoren machbar ist. </BittenichtZUernstNehmen>

Bild hier  Bild hier  

Die Messwerterfassung per Infrarot und Ultraschall in der Ebene hatte ich mit der 2D-Darstellung ausprobiert. Da wird sich noch zeigen, welche Winkel, Oberflächenbeschaffenheit usw. die Messwerte wie Beeinflussen. Eine Erkenntnis der ersten Tage war z.B., dass die Horizontale/Vertikale Montage des Sharp große Auswirkungen auf die Erfassung von Ecken und Kanten hat. - Wusste ich bis dato nicht. Dahinter steckt wohl das Triangulationsprinzip des Sensors. (In der Herstellerdoku stand auch etwas zur Montage)

Ich habe die Sensortürme zeilenweise scannen lassen und dazu die 3D-Visualisierung geschrieben. Für Entscheidungsfindung des Bots ist das sicher uninteressant, für mich ist es aber immer wieder ein Aha-Erlebnis. Bilder von Ergebnissen hänge ich an. Ich rechne hierbei, wie auch in 2D, die ermittelten Polarkoordinaten in das kartesische Koordinatensystem um und stelle die Punkte im Raum durch verschieden große Klötze um. Die Größe eines "glutSolidCube" ist abhängig von Entfernung und Winkelschrittweite. Die Farbe zeigt den Abstand zum Sensor und dabei auch dessen Messbereich an. Infrarot: Grünfärbung bei 80cm Entfernung, Rotfärbung bei 10cm, alles außerhalb des Bereichs gilt als Messfehler. Bei Ultraschall setze ich z.B. eine Entfernung von 6,5m als grün.
Die Visualisierung kann dann (hoffentlich) später neben den Werten der IR und US-Sensoren auch die, durch den Laser und Webcam erfassen Punktwolken darstellen.

Meine Erfassungsunternehmungen beziehen sich aktuell immer auf den Stillstand des Bots. Bewegung UND Kartierung zur gleichen Zeit gibt es derzeit nicht.

Ich hoffe, dass es erst mal aufgekommene Neugier stillt. Ich muss was tun, sonst komme ich heute zu nix mehr.

Hallo,
ich will nun zusammenfassen, was ich die letzten Wochen an dem Bot gemacht hab und bisher unterschlagen hatte.

Es wurde mir mit den 10cm IR Sensoren etwas zu heikel. Sie sitzen an der Unterseite des Holzbretts und waren dadurch nicht wirklich vor kleinen Objekten geschützt. Ich musste die Bauteile schon einige Male wieder zurechtbiegen wenn ein Motorstopp nicht ausgelöst und die Sensoren als Abschlepphaken umfunktioniert wurden.
Ich hatte noch Aluminium Lochblech von den Sensortürmen übrig. Das passt von der Länge her ganz gut an die äußeren Kanten, also Dremel + Feile raus und losgelegt. Zum Glück waren ausreichend Löcher vorhanden, dass man fast gezwungen ist, einigermaßen gradlinig verlaufende Kanten zu produzieren. Noch nie habe ich mir so sehr eine Abkantbank gewünscht. Letztlich hat es der schwedische Schreibtisch auch getan.

Bild hier  

Wie schon angekündigt, wollte ich einen alternativen Unterbau anstelle des Spielzeugpanzers testen. Der Panzerunterbau leistet für die Vorwärtsfahrt gute Dienste, bei der Rückwärtsfahrt kam es aber immer häufiger zu Streiks. Das Getriebe scheint sich unter Last zu verformen. Bei der Vorwärtsfahrt werden die Zahnräder scheinbar zusammengepresst, bei der Rückwärtsfahrt entfernen sie sich voneinander. Abgebrochene Zähne, knarrende Geräusche und unfreiwilliger Leerlauf waren die Folge. In der Bucht habe ich für einen Euro eine weitere Panzerwanne mit Getriebe und Motoren ersteigert, aber auch die hielten nur wenige Wochen.

Ich dachte mir "Was früher gut war, wird heute sicher auch noch gut sein!" Und was sicher einige Roboterbauer hier die Haar zu Berge stehen lässt:
Ich habe mir einen LEGO Bulldozer gekauft! Ein richtig großes Modell wollte ich schon immer mal aufbauen und LEGO Technic hatte ich nun auch einige Jahre nicht mehr in den Händen.
Bei der Auswahl war mir wichtig, dass es einen Kettenantrieb hat, möglichst starke Motoren mitbringt und ausreichend groß ist, die schwere Technik zu tragen. Das Modell 8275 wiegt nach dem Zusammenbau rund 1,6kg und kommt mit vier 9V-Motoren. Zwei kleine PowerFunctions Motoren für Schaufel und "Kralle" und zwei PowerFunctions XL genannte Motoren. Die XL-Motoren sind intern durch zwei Planetengetriebe untersetzt und haben damit an der Ausgangswelle ein Drehmoment, das ich zumindest für Kunststoffspielzeug so nicht erwartet hatte. Die Motordrehzahl wird beim Standardmodell weiter untersetzt. 5 Umdrehungen der Motorwelle führen zu 3 Radumdrehungen, eine Radumdrehung legt über die Kunststoffkette eine Strecke von 130mm zurück.

Bild hier  

Ich habe von dem Modell entfernt was ich nicht benötige und die gewonnenen Teile zur Führung der Räder und Ketten verwendet. Bei der Fahrt auf dem Teppich sind sie ein paar Mal von den Antriebsachsen gerutscht. Was die Odometrie angeht, hatte ich erst vor, ein Rad hinter dem Kettenfahrzeug mitzuführen. Quasi ein kleiner "Wegstreckenmessungs-Beiwagen".
Dann wäre es zwar möglich die zurückgelegte Strecke bei Geradeausfahrt UND Drehung auf der Stelle zu messen. Es gäbe aber auch zwei Antrieb-zu-Untergrund Kontaktflächen, die Fehleranfällig sind. Da an dem InterfaceBoard noch einige Digitaleingänge frei sind, habe ich die Getriebe etwas erweitert und pro Antriebswelle eine Übersetzung mit Knocken und Microschalter verbaut. Ein paar Tests haben gezeigt, dass sie funktionieren und ordentlich schalten. Im Programmablauf habe ich dazu noch nichts umgesetzt.

Bild hier  Bild hier  

Gestern Abend habe ich mich statt der Verarbeitung von Sensordaten nun mit der Fortbewegung des Bots beschäftigt. "Live"bild der Webcam, Steuerung des Bots bei SSH und VNC sind durch die Verwendung des Netbooks frei Haus geliefert. Gefahren bin ich normal per Tastendruck, stopp wenn irgendein Sensor ein Hindernis unterhalb der gesetzten Distanzen erkennt.
Jeder fängt klein an, also erstmal ein einfaches reaktives System umsetzen. Ich habe hier ein Buch liegen, dass einen Rug-Warrior zitiert und dessen Funktionsweise beschreibt. Subsumtionsarchitektur nennt man so etwas scheinbar. Bei dem Programmablauf werden die vier IR-Sensoren an den Ecken des Bots als (meist berührungslose) Stoßfänger genutzt.

Bild hier  

Ich habe ein Video zu dem "späten" Ergebnis hochgeladen.
http://www.youtube.com/watch?v=cWfUYIHPTIk

Eine störende Funktion, die ich zwar bemerkt aber bisher nicht also SO störend empfunden hatte ist die im Fahrtregler eingebaute Bremse. Ich habe nun Stunden herumprobiert, diese Bremse irgendwie durch das Senden von Steuersignalen auszutricksen, bin bisher aber nur zu einem Ergebnis gekommen. Die Software muss nach einen Bremsvorgang zwei Sekunden warten, bis die nächste Ansteuerung der Motoren erfolgen kann. Dadurch die der gesamte Fahrtverlauf total stockend aus. Ich könnte die Motoren umpolen und einfach umgekehrt ansteuern. Dann hab ich die Bremse aber beim Wechsel der Fahrtrichtung Rückwärts->Vorwärts. :-/
Im Video kann man das Herumgestotter nach einer Kollisionserkennung gut erkennen. Eigentlich soll der Bot vor Änderung der Fahrtrichtung ein Stück zurücksetzen.

Falls jemand einen Trick zur nervigen Bremse kennt - immer raus damit.