Autonomer, kompakter Roboter zur Kartierung und Navigation

[Jepp]

Vorab ein herzliches Hallo an Alle!

Ich lese die Beiträge dieses Forums seit mehreren Monaten. Die Robotik finde ich seit meiner Kindergartenzeit spannend. Der Film "Nr.5 lebt" war damals aktuell und hat mich sehr beschäftigt.
Einige eurer Tüfteleien haben mich motiviert, mich tiefer mit der Thematik zu beschäftigen und einen eigenen Roboter zu bauen bzw. diesen zu programmieren.

Ich finde es etwas schwierig meinen Beitrag in einem Thread (fertig/nicht fertig) einzuordnen, da ich mit dem Aufbau des Roboters recht weit bin. Zumindest denke ich, alle benötigten Komponenten verbaut zu haben. Nun steht die Implementierung eines größeren Gesamtkonzepts an, das sich in viele kleinere Bereiche unterteilt.
Während der Programmierung werden sicherlich Änderungen im Roboteraufbau von Nöten sein.


Nun aber zum Thema:
Ich werde die bereits durchgeführten Arbeits- und Entscheidungsschritte hier posten um andere Mitleser zu motivieren, eigene Roboter aufzubauen. Was meinen Roboter von den meisten Entwicklungen dieses Forums unterscheidet bzw. was ich bisher hier im Forum nicht gefunden habe ist der Umgang mit der Steuer- und Regelungstechnik.

Ich habe mich während der ersten Überlegungen ausdrücklich gegen die verbreiteten Mikrocontroller wie ATmega, Ardunio und Co. entschieden.
Ebenfalls will ich weder in C, C++, Assembler oder anderen hardwarenahen Programmiersprachen programmieren.
Ich habe verschiedene Meinungen zu der Netbook und "Echtzeit" Thematik gelesen. C in Verbindung mit Mikrocontrollern ist auch sehr schnell aber ich werde auf gängige PC Hardware, USB als Kommunikationsbus und Java als Programmiersprache setzen.

Die Konstruktion des Roboters soll es Erlauben, den verwendeten Rechner sowie das Fahrwerk einfach auszutauschen. Also nur ein USB Kabel zu Netbook und möglichst wenige Leitungen zwischen Elektronikträger (Holzplatte) und Fahrwerk.
Der grobe, dreistufige Aufbau ist der Folgende:

Bild hier  

Für den Ablauf des Programmcodes ist ein typisches Netbook im Einsatz. In meinem Fall ein Dell Mini 9 (Inspiron 910) mit einem 1,6GHz Intel Atom, 2GB RAM und einer 16GB SSD. Das Gerät eignet sich softwareseitig da die drei verbreiten Betriebssysteme mit vertretbarem Aufwand funktionieren. Hardwareseitig ist der Einsatz auf einem "rüttelnden" Roboter kein Problem, da es eines der leichtesten Netbooks (in meinem Fall 1056g mit Akku) ist, einen geringen Energieumsatz hat und lüfterlos arbeitet. Die Solid State Disk bietet ausreichend Speicherplatz für Betriebssystem, persistentem Speicher des Programmcodes und Kartierungsdaten und sogar der kompletten Entwicklungsumgebung, Bürosoftware usw.

Zur Abfrage der Sensoren sowie die Ansteuerung der verbauten Servos und Fahrtenregler nutze ich ausschließlich Phidgets http://www.phidgets.com. Das Phidget Framework ist für Mac OS X, Linux und Windows verfügbar und kann mit vielen Programmiersprachen verwendet werden. Die Phidget I/O Boards lassen sich mit den dort vertriebenen (teils recht teuren) Sensoren verbinden, es ist aber auch beschrieben wie eigene Sensoren angeschlossen werden können.

Bild hier  
Bild hier  Bild hier  

Für die Basisfunktionalität verwende ich folgende Bauteile:
1x Heng Long Leopard A2 3809 --- Günstiger Spielzeugpanzer als Basisfahrwerk. Gekauft 2005, schleppt sich bei Nutzung von einem Defekt zum Nächsten.
1x 1018 - PhidgetInterfaceKit 8/8/8 --- Bietet den Anschluss von vier reflektiven IR-Sensoren, zwei 80cm IR-Sensoren, zwei Drucktastern und ein paar Statusdioden. (Später kamen noch zwei Rollenkippschalter zur Drehzahlmessung hinzu)
4x 1103 - IR Reflective Sensor 10cm --- Zur Erkennung von Hindernissen (Kollisionsvermeidung) zwei an der Front, zwei am Heck.
2x 1101 - IR Distance Adapter --- Adapter zur Verwendung verschiedener IR-Senoren (z.B. Sharp GP2Y0A21YK0F, 2D120 F 9X und GP2Y0A02YK0F).
2x 3521 - Sharp Distance Sensor GP2Y0A21YK0F (10-80cm) --- Zur genaueren Distanzmessung per Infrarot (Triangulation).
1x 1061 - PhidgetAdvancedServo 8-Motor --- Erlaubt die Ansteuerung von 8 Servos. Ich nutze vier Anschlüsse für die vier unten gelisteten Servos und zwei Anschlüsse für elektronische Fahrtenregler.
4x 3000 - Hitec HS-322HD Standard Deluxe Servo --- Verbaut für zwei Sensortürme dabei zwei Servos für Karussell und zwei für die Schwingen. (Nennt man das allgemein Karussell?)
2x Elektronischer Fahrtenregler von Conrad --- Günstig, kompakt und für meine Ansprüche zur Ansteuerung der Elektromotoren ausreichend. http://www.conrad.de/ce/de/product/2...HOP_AREA_32305

Im Laufe des Projekts kamen weitere Komponenten hinzu. Ich liste sie hier, der Vollständigkeit halber, gehe aber erst später darauf genauer ein.
1x 1128 - Sonar Sensor --- Kompakter Ultraschallsensor zur groben Distanzmessung bis rund 6,5m.
2x 3052 - SSR Relay Board --- Zur Schaltung externer Stromkreise per Optokoppler. Ich verwende einen zum Ansteuern des Linienlasers.
1x 1059 - PhidgetAccelerometer 3-Axis --- 3-Achsen Beschleunigungssensor (ADXL330) mit USB-Anschluss.
1x 4-Port USB HUB --- Erlaubt die Verbindung des Computers mit den drei USB-Phdigets über ein einzelnes USB-Kabel.
1x Linienlaser --- Zur Umsetzung der Entfernungsmessung per Laserlinie

Bild hier  

Für die Energieversorgung der Komponenten verwende ich einen 8 Zellen Akkublock, der mit sieben 2500mAh NiMH Mignon Akkus bestückt ist. Sieben Zellen, da die Fahrtenregler mit einer Maximalspannung von 8,4V angegeben sind. Ich hatte mal grob gerechnet, dass ich damit auf rund 2h Fahrzeit kommen sollte. Der Block versorgt die Antriebsmotoren, per BEC das AdvancedServoBoard und somit auch die Servos. Außerdem ist der Laser derzeit ebenfalls dort angeschlossen. Der gebrauchte Akku des Netbooks hält derzeit unter Last ähnlich lange durch.


Für die Funktionen des Roboters nehme ich mir in den nächsten 5-6 Monaten einiges vor:
* Selbstlokalisierung
- absolut durch Kartierung der Umgebung
- relativ per Odometrie und/oder Trägheitsnavigation (Nutzung des Beschleunigungssensors prüfen)
* flexible Nutzung der Sensoren
- Schwächen von Infrarot und Ultraschall kompensieren
- Testimplementierung eines Lasertriangulationsverfahrens
* Modulare Software Architektur
- Serveranwendung mit KI-Ansätzen, Wegfindung usw. für den Roboter
- Clientanwendung für den Fernzugriff auf den Roboter und dessen Parameter/Daten (Java Swing 2D, OpenGL 3D Visualisierung)
- Sensoren können ausfallen, Unregelmäßigkeiten erkannt werden, weitere Sensoren angeschlossen werden
- Datenstruktur zur Speicherung der Messwerte (Kartierungsdaten) als Punktwolke im 3D-Raum. (Texturen durch Webcam erfassen)

Bild hier  Bild hier  

Das war es erstmal von meiner Seite. Ich bin gespannt auf Fragen, Anregungen, Kommentare und hänge ein paar frühe Bilder an um den Entwicklungsverlauf der letzten Monate zu verdeutlichen. Im Laufe der nächsten Tage vervollständige ich den Thread weiter. Ich habe regelmäßig Videos aufgenommen und werde ich wohl nicht um einen Youtube Account rumkommen.. - wird nachgeliefert.


Gruß

Jan

[UlrichC]

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

[Jepp]

Hallo Jan, was ist denn nun so einzigartig an deinem Umgang mit Steuer und Regelungstechnik?

Einzigartig möchte ich das nicht nennen. Letztlich sind meine Bauteile doch von der Stange.
Was den Umgang an sich betrifft: Ich hatte ein Gespräch mit einem "Roboterbauer" auf der CeBit. Ich meinte, dass ich bei dem Projekt keine Lust habe Flanken zu zählen, Spannungen in Distanzen umzurechnen und mir über n mal m Pinmatrizen und deren Belegung Gedanken zu machen.
Versteh mich bitte nicht falsch, ich meine das keineswegs negativ. Mein Schwerpunkt soll hier auf Software und einfache Reproduzierbarkeit des Bots liegen. Ist der Roboter einmal fertig kann man in Software abbilden, was man mag.

Ich beschreibe das Projekt um evtl. auch Interessierte anzusprechen, die keine Getriebe montieren möchten, keine Möglichkeit haben eigene Rahmen zu fertigen oder gar Platinen zu ätzen.
Java, weil es einfach sehr simpel ist, die Servos und andere Komponenten anzusprechen. Erzeuge eine Instanz des Servocontrollers und setze Servoposition auf Winkel x. - fertig.

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.

Da stimme ich dir nicht hundertprozentig zu. Zumindest nicht mit den oben beschriebenen Komponenten. Die Lötarbeiten beschränken sich auf das Kürzen von Leitungen. Da der Ausgangsstrom des Interfaceboard limitiert ist, braucht man nicht mal Vorwiderstände für LEDs ausrechnen.

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.

Den Punkt verstehe ich nicht. Erkläre das bitte genauer.

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

[daniel.weber]

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.

[Jepp]

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.

[Jepp]

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.

[Jepp]

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.

[Gil-Galad]

Hallo
Ich bin selber mit einem Ähnlichen Projekt beschäfftigt
Ich bräuchte IR-Entfernungs Sensoren woher hast du diese gekauft
MFG Jacob

[5Volt-Junkie]

Hi,

ein ganz interessantes Projekt. Und da hätte ich gleich mal eine Frage bevor ich eigenen Thread aufmache: Irgendwo oben (viel Text....) hast du irgendwas über US- und IR-Sensorik und der Oberfläche des Hindernisses geschrieben. Bei IR ist klar - ist die Oberfläche matt oder glänzend, weiß, grau oder oder schwarz usw. Werden aber US-Sensoren auch irgendwie beeinflüsst? Ich meine, wenn du schon auf 2D/3D Ebene arbeitest, dann musstest du ziemlich viele Erfahrungen gesammelt haben.

@Gil-Galad

unter www.robotikhardware.de findest du welche

THX

Lex