Autonomer, kompakter Roboter zur Kartierung und Navigation

Druckbare Version

16.03.2010, 14:10
Jepp

Autonomer, kompakter Roboter zur Kartierung und Navigation

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
16.03.2010, 19:37
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
16.03.2010, 21:11
Jepp

Zitat:

Zitat von UlrichC

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.

Zitat:

Zitat von UlrichC

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.

Zitat:

Zitat von UlrichC

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.
16.03.2010, 21:29
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.
16.03.2010, 23:32
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.
17.03.2010, 08:43
Jepp

Zitat:

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.
17.03.2010, 10:07
Jepp

Zitat:

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. ;)
21.03.2010, 15:01
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.
25.03.2010, 16:05
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
25.03.2010, 18:25
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
26.03.2010, 20:01
Jepp

Zitat:

Zitat von 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

Oh, klingt spannend. Hast du dazu irgendwo was öffentlich?
Wenn du speziell Sensoren mit Adapterboard für die Phidgets suchst: http://www.eztronics.nl/webshop/cata...products_id/91
Das Board lässt sich direkt auch mit anderen IR-Sensoren verbinden. Bei dem Shop hab ich nun drei Mal bestellt und bin sehr zufrieden.
Wenn es dir sonst "nur" um die Sharp Sensoren geht, gibt es wie schon erwähnt unzählige Shops (siehe Sheff).

Zitat:

Zitat von Sheff

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

Ich ärgere mich derweil mit der Wegstreckenmessung und defekten Fahrtreglern herum und hatte leider nicht viel Zeit für Tests.
Ich kann aber sagen, dass die Messwerte des Ultraschallsensors wegen der "Messkeule" teilweise stark von denen der Infrarotsensoren (an gleicher Position) unterscheiden. Flächen von vorstehenden Wandteilen erkennt der US-Sensor auf einem großen Winkelbereich. Im Kamerabild erkennt man da deutlich, dass keine Wand vorhanden ist.. eine Abtastung per IR zeigt da einen angenäherten Wandverlauf. Obacht aber wenn Zwischentüren (geöffnet) in Raumteilern mit Glasfenstern eingefasst sind. Mein Bot ist vorgestern fröhlich bei voller Fahrt gegen eine Glasscheibe gefahren und erst der "alarmierte" Beschleunigungssensor hat die Motoren stoppen lassen.. 8( An der Stelle wäre ein aktiver US-Sensor vorteilhaft gewesen.

Oft zitiertes Szenario: Tastet dein Sensor ein Objekt ab, das von oben gesehen einen Keil bildet, wird das Signal komplett abgelenkt. Wo beim US-Sensor kein Signal reflektiert wird (Totalreflektion), zeigen die IR-Sensoren zumindest noch vermeidlich entfernte Wände. Etwas gurgeln nach "ultraschall messfehler" findet da gute Vorlesungsfolien als Einstieg.

Gruß
21.04.2010, 16:13
Jepp

Ein paar Wochen sind nun vergangen. Ich habe an verschiedenen Baustellen gearbeitet und aber EIN Problem holt mich scheinbar immer wieder ein.

Ich hatte vor drei Wochen große Probleme mit meinen Fahrtreglern. Die ursprünglich verbauten Regler hatten ja die störende Bremsfunktion, die ich auch mit extra angesetzten Wartezeiten des Programmablaufs nicht zufriedenstellend umgehen konnte. Ich habe bei Conrad zwei neue Regler gekauft. Es waren die einzigen im Sortiment, die keine Bremsfunktion haben und pro Stück unter 20€ liegen.
Conrad Regler

Bild hier

Am Tag des Einbaus hatte ich im Eifer des Gefecht einen der Regler (oder beide?) falsch angeschlossen und diesen beschädigt. Problematisch war, dass ich nicht wusste, welcher der Regler defekt und welche Bauteile betroffen waren. Ich habe einen Mitarbeiter dort nach Hilfe gefragt und, was ich nicht gedacht hätte, ist er mit mir den kompletten Schaltplan durchgegangen und hat erklärt, was den evtl. defekt sein könnte. Zuhause habe ich die Regler mit einer "Hilfsverdrahtung" noch mal unter die Lupe genommen. (Ein Foto im Anhang zeigt eine Drahtkonstruktion, die das Potential der IC-Ausgänge über die LEDs anzeigen soll.)
Es stellte sich heraus, dass die ICs in Ordnung sind und es an den Transistoren liegt. Beide haben anfangs ordentlich gearbeitet, im Laufenden Betrieb (Erwärmung) hat einer der Transistoren geschaltet und damit den Versorgungsakku kurzgeschlossen. Erkennen ließ sich das nur dadurch, dass sich die Fahrgeschwindigkeit plötzlich verringerte und sich das Kühlblech erwärmte.

Bild hier

Naja, Ersatz gekauft, neue Transistoren und zur Sicherheit auch die Dioden in dem Umfeld umgelötet und dann lief es auch. Die Potis hatten nicht "ganz" die Widerstandswerte, die aufgedruckt waren. Ich habe sie gleich im nächsten Schwung durch neue und genauere Potis ersetzt. Nun lief das die letzten zwei Wochen einigermaßen. Die Nullstellung und maximale Motorspannung lassen sich übrigens durch die Potis einstellen.

In der Zeit habe ich dann mit den "neuen" Fahrmanövern herumgetestet und der dringende Bedarf einer Motorsynchronisation hat sich breitgemacht. Die Motoren sind mittlerweile unterschiedlich eingefahren, die Getriebe verursachen unterschiedlichen Widerstand und die Fahrtregler laufen nicht gleichmäßig. Synchron waren die Kettendrehzahlen bei einer Spannungsdifferenz beider Reglerausgänge von 0,4V - im Rückwärtsgang war es wieder komplett verstellt. - Das Ganze ändert sich dann von Akkuladung zu Akkuladung.. 8(
Gelernt habe ich daraus, mich auf keinen Fall auf die festgelegten Winkel (PWM) zu verlassen.

Umgesetzt ist die Synchronisation durch einen Thread, der bei Fahrtantritt gestartet, während der Fahrt Ticks zählt (pro Tick 6,5mm Wegstrecke), nachregelt und bei Stillstand beendet wird.
Ich bin dabei die Software komplett umzustricken, die Threads anders zu organisieren und die nächsten Tage soll die Netzwerkfunktionalität dazukommen. Also eigentlich brav, unspektakulär mit am Codezeilen schieben..
Heute war es dann wieder soweit - beim Testen des Thread Management steuert einer der Regler den Rückwärtsgang nicht mehr korrekt. Vorwärts klappt, Stoppen klappt aber Rückwärts dreht dann nur noch eine Kette.

Hat jemand einen Tipp? Ich brauche einen bzw. zwei günstige Regler (30€ pro Stück wäre ok), die Vorwärts- sowie Rückwärtsdrehrichtung zuverlässig beherrschen ;) und KEINE Bremse haben.
1A Maximalstrom sollte kein Problem sein und betreiben würde ich die gerne mit 7-8 Zellen.

Ich habe eben noch das Modell entdeckt. Zum selbst bauen - aber vorerst keine Lust mehr auf Löterei. :/
"Volksregler"
22.04.2010, 19:51
the_muck

Hallo,
irgend wie komme ich gerade nicht ganz mit ;), wie misst du denn die Drehzahl der Motoren oder Antriebsräder?

Hier wäre auch noch ein Modul ...
http://www.shop.robotikhardware.de/s...roducts_id=112
22.04.2010, 21:58
Jepp

Zitat:

Zitat von the_muck

Hallo,
irgend wie komme ich gerade nicht ganz mit ;), wie misst du denn die Drehzahl der Motoren oder Antriebsräder?

Hi, ich messe die Motordrehzahl an einer "Abzweigung" im Getriebe.
5 Motorumdrehungen werden auf 3 Radumdrehungen untersetzt (20:12 Zähne)

Ich verwende aktuell einen Microschalter (mit Kipphebel woran eine kleine Rolle montiert ist) und erfasse damit zwei Nocken einer Achse (nenne ich jetzt mal Nockenwelle).
So hätte ich ja bei direktem Abgriff der Motorachse nur 2 Nocken pro Motorumdrehung. Um das zu erhöhen habe ich die Motorachse zu Nockenwelle um 1:3 übersetzt (8:24 Zähne).
Das ergäbe dann bei 5 Motorumdrehungen 15x2 Nocken - also 10 Einschaltsignale (steigende Flanken) pro Radumdrehnung.
Zusätzlich zu den Einschaltsignalen lassen sich auch die Ausschaltsignale verwenden wodurch ich pro Radumdrehung auf insgesamt 20 Flanken bekomme.

Pro Radumdrehung lege ich, optimistisch und ohne Schlupf, 130mm zurück. Also 6,5mm pro Flanke.

Zitat:

Zitat von the_muck

Hier wäre auch noch ein Modul ...
http://www.shop.robotikhardware.de/s...roducts_id=112

Danke für den Tipp. Das Board sieht so ganz gut aus, PWM ist auch dabei und wahrscheinlich sauber ansteuerbar. Bei dem Board stören die mich die zwei zusätzlichen Leistungen pro Motor für die Steuerung der Drehrichtung..
Ich muss gestehen, dass ich mir die Pulsweiten von Modellbaufahrtreglern noch nie mit einem Oszilloskop angeschaut habe. Da wird wahrscheinlich einfach die mittlere Pulsweite als Mittelstellung genommen und die Motorrichtung durch unter- oder überschreiten der Mittelstellung definiert. </Vermutung>
Ich werde mich in dem Shop dort noch mal umschauen.
23.04.2010, 10:10
the_muck

Hallo,
20 Impulse pro Radumdrehung finde ich recht wenig und mit der Mechanik holt man sich ja wieder Spiel in die Regelung + das Entprellen des Microschalters. Ich habe mir mal eine PI Regelung für einen Motor gebaut der mit 32 Impulsen bei 500-5000 u/min arbeitet das funktionierte mit Messung der Flanken-Zeit sehr gut und ist ist schnell.

Hier mal ein "RC Signal" das geht über die Pulsbreite wie du gesagt hast
http://www.youtube.com/watch?v=K_KUtNSWuhc

1,5ms Mitte, 1ms "unten", 2ms "oben", bei ~ 45Hz

Mit den beiden Leitungen zum ansteuern gebe ich dir recht aber ich finde die Methode genauer/definierter. Bei meinen RC Modellen hatte ich immer wieder Aussetzer der Steller so das dass Auto einfach mal langsam fuhr auch wenn es eigentlich stehe sollte ;).

Ich weiß das du auf Kettenantrieb setzen willst, irgend wie finde ich aber wenn man sich durchs Forum liest das dies der aufwändigste Weg ist. Die mechanische Beanspruchung ist halt nicht ohne und die Positionierung wenn sich das Fahrzeug in Winkel XY° drehen muss ungenauer. Welchen Unterbau verwendest du denn jetzt, Lego oder den Panzer?! Mehr Bilder davon wären nicht schlecht.

Ich würde mir für erste Versuche immer so was bauen

Bild hier

Also 2 angetriebene Räder mit einem Stützrad...

aber ich denke für einen Unterbauwechsel ist es zu spät ;).

Im laufe der Zeit stellte sich bei mir heraus das nichts über solide Mechanik geht, die kleinen Roboter müssen mehr leisten als man zuvor denkt.

Darf ich fragen was du Schulisch / Beruflich machst?
24.04.2010, 18:38
Jepp

Zitat:

Zitat von the_muck

Hallo,
20 Impulse pro Radumdrehung finde ich recht wenig und mit der Mechanik holt man sich ja wieder Spiel in die Regelung + das Entprellen des Microschalters. Ich habe mir mal eine PI Regelung für einen Motor gebaut der mit 32 Impulsen bei 500-5000 u/min arbeitet das funktionierte mit Messung der Flanken-Zeit sehr gut und ist ist schnell.

Hier mal ein "RC Signal" das geht über die Pulsbreite wie du gesagt hast
http://www.youtube.com/watch?v=K_KUtNSWuhc

Danke für den Hinweis zur PI-Regelung. Ich bin noch nicht lang in dem Robotik-Thema und hatte bisher nur vermutet, dass es dazu doch eine Notation geben "müsste". Durch Herumprobieren kam ich auf die MotorSyncThread Idee. Der Thread bildet das Verhalten offenbar ähnlich ab, ich will mich da (auch noch) einlesen.
Ein (Statistik) Thread verwaltet die einkommenden Events der Drehzahlgeber und berechnet dazu Geschwindigkeit, Ticks/Sekunde usw.. Der MotorSyncThread verwertet die Hochrechnungen, die zurückgelegten Wegstrecken und regelt die Motoren so nach, dass die Differenz der Wegstrecken möglichst null ist.

Zitat:

Zitat von the_muck

Mit den beiden Leitungen zum ansteuern gebe ich dir recht aber ich finde die Methode genauer/definierter. Bei meinen RC Modellen hatte ich immer wieder Aussetzer der Steller so das dass Auto einfach mal langsam fuhr auch wenn es eigentlich stehe sollte ;).

Du hast mich schon fast überzeugt, solch einen Controller anzuschaffen. Die feinere Steuerung der PWM ist mit meinem aktuellen, fast binären Zustand nicht zu vergleichen. Einzige Bedingung ist, dass ich den Controller direkt mit dem InterfaceKit ansteuern kann. Das InterfaceKit hat eine 5V Spannung auf den Ausgängen und begrenzt den Ausgangsstrom auf rund 20mA (müsste ich nachmessen).
Ist die Kombination mit meinem IFK so möglich? Ich habe nicht konkretes zu den Eingangsspezifikationen von "IN_A" und "IN_B" gefunden.

Zitat:

Zitat von the_muck

Ich weiß das du auf Kettenantrieb setzen willst, irgend wie finde ich aber wenn man sich durchs Forum liest das dies der aufwändigste Weg ist. Die mechanische Beanspruchung ist halt nicht ohne und die Positionierung wenn sich das Fahrzeug in Winkel XY° drehen muss ungenauer. Welchen Unterbau verwendest du denn jetzt, Lego oder den Panzer?! Mehr Bilder davon wären nicht schlecht.

Ich verwende den LEGO Unterbau. Aktuell sind die Conrad-Regler verbaut. Gestern habe ich mich noch durchgedrungen und den dritten Transistor des defekten Reglers gewechselt. - Nun läuft die Mühle vorerst wieder.
Die vorhandenen Bilder verlinke ich gleich noch mal, dass auch Unangemeldete davon was sehen können. Weitere suche ich mal raus, ansonsten habe ich den YouTube Link in meiner Signatur eingetragen. Da hab ich zumindest etwas ältere Fahrerei von vor der Softwareumstellung und mit den alten "BremsNervReglern" hochgeladen.

Ich stimme dir in den Punkten Kettenantrieb, Beanspruchung und Rotation zu.
Die Kette erschien mir am sinnvollsten weil ich das Panzer Modell einfach noch liegen hatte und mir die Fortbewegung durch geradeaus, rückwärts, 90° linksrum, 90° rechtsrum einfach vorkommt. Ein Gefährt wie der c´t Bot hat doch sicher seine Schwierigkeiten mit Türschwellen, Teppichen und kleinen Hindernissen oder?

Zur Rotation hatte ich in einem früheren Post die Schwenkbereiche der Servotürme skizziert. Ich habe heute einige Klassen zur Karten- und Messwertverwaltung begonnen und die Umrechnung der Koordinatensysteme komplett überarbeitet. Der Roboter soll vor und nach der Rotation eine lokale Karte erzeugen und die Messwerte vergleichen. Dadurch, hoffe ich, den Rotationswinkel erfassen und als "gelernte Aktion" ablegen zu können.

Zitat:

Zitat von the_muck

[...]aber ich denke für einen Unterbauwechsel ist es zu spät ;).
Im laufe der Zeit stellte sich bei mir heraus das nichts über solide Mechanik geht, die kleinen Roboter müssen mehr leisten als man zuvor denkt.
Darf ich fragen was du Schulisch / Beruflich machst?

Ein Unterbauwechsel ist kein Problem, alles Wichtige ist unter bzw. an dem Holzbrett verbaut. Ich hoffe noch, irgendwann ein robusteren Unterbau ergattern zu können. Auf der Industriemesse habe ich die Tage einige Roboter und speziell auch separate Unterbauten in Aktion gesehen. Leider sind die, auch wenn ich bereit bin Geld für das Thema zu lassen, absolut nicht in meinem Rahmen.

Klar darfst du - ich studiere angewandte Informatik, Vertiefung Computergrafik und Visualisierung.
25.04.2010, 20:04
the_muck

Hallo,
ein "Industrie" Chassis muss es ja nicht sein, schau mal hier nach den Rasen oder Saug Robotern aber wenn du das mit den Stellern in den Griff bekommst dann sieht es doch nicht schlecht aus. (Und ich mag Lego ;)).

Für die Regelung gibt es hier im Wiki einen super Beitrag und auch einiges zu Gabellichtschranken, die Ergebnisse der PI Regelung am Motor fand ich faszinierend, nie wieder ohne ;).

Bei deinen Interfaces musst du schauen was sie für PWMs können die Meinungen im Netz zur Frequenz sind unterschiedlich und sehr vom Motor abhängig, aber kHz Bereich sollte es sein denke ich.
Interessant das bei dem RN Board nirgendwo die Spannung steht aber 5V Logik ist es ;).

http://www.phidgets.com/index.php

hier habe ich leider nichts über PWMs gefunden...

Ich finde das Projekt sehr interessant!! Hier im RN geht es meist um Mechanik, Elektronik, Sensorik und Programmierung auf Hardware ebene. Du bist ja schon eine Ecke tiefer in der Programmierung ;). Halt uns auf dem Laufenden...
25.04.2010, 22:16
Jepp

Zitat:

Zitat von the_muck

Hallo,
ein "Industrie" Chassis muss es ja nicht sein, schau mal hier nach den Rasen oder Saug Robotern aber wenn du das mit den Stellern in den Griff bekommst dann sieht es doch nicht schlecht aus. (Und ich mag Lego ;)).

Für die Regelung gibt es hier im Wiki einen super Beitrag und auch einiges zu Gabellichtschranken, die Ergebnisse der PI Regelung am Motor fand ich faszinierend, nie wieder ohne ;).

Wie cool ist das denn? Während du den Beitrag geschrieben hast, war ich dabei eine alte PS/2 (Kugel-)Computermaus zu zerlegen. Das Resultat nach frickeln, dremeln und etwas Löterei: Zwei Lichtschranken mit jeweils ca. 40 Zähnen auf der Encoderscheibe (falls man das so nennen kann). Mit der Lichtschranke wäre ich die erwähnten mechanischen Probleme los und könnte meine Flanken pro Radumdrehung von 20 auf 400 steigern. Phototransistor sowie IR-LED habe ich eben spontan direkt an ein InterfaceKit angeschlossen. Das scheint zu klappen, am Eingang kann ich An/Aus Zustände erfassen. Stellt sich noch die Frage, bis zu welcher Frequenz die Eingänge maximal arbeiten.. Die nächsten Tage.

Bild hier Bild hier

Den Umbau in eine kleine Box mit Welle o.Ä. schiebe ich ebenfalls vorerst, derzeit gibt es leider zu viel Anderes zu tun. - Hätte ich das mal vorher gewusst.. :-/

Zitat:

Zitat von the_muck

Bei deinen Interfaces musst du schauen was sie für PWMs können die Meinungen im Netz zur Frequenz sind unterschiedlich und sehr vom Motor abhängig, aber kHz Bereich sollte es sein denke ich.
Interessant das bei dem RN Board nirgendwo die Spannung steht aber 5V Logik ist es ;).
http://www.phidgets.com/index.php
hier habe ich leider nichts über PWMs gefunden...

Ich finde das Projekt sehr interessant!! Hier im RN geht es meist um Mechanik, Elektronik, Sensorik und Programmierung auf Hardware ebene. Du bist ja schon eine Ecke tiefer in der Programmierung ;). Halt uns auf dem Laufenden...

Werde ich. Zu den PWM und Co. habe ich einen Ausschnitt des AdvancedServoController eingefügt. Ist die "Output Controller Update Rate" evtl. die gesuchte Frequenz?

Bild hier
26.04.2010, 11:24
the_muck

Hallo,
hier ist mal was zur Drehzahl...

http://www.rn-wissen.de/index.php/Be..._mit_Drehgeber

Das Schnelle Bild vom Oszi zeigt das Signal der Lichtschranke bei ~9500 u/min mit eben der 32er Lochscheibe.

Ich habe mir die phidgets Teile mal angeschaut, eigentlich ganz nett aber irgend wie ist die Update Rate für Regelungen recht langsam finde ich. Auch das mit dem PWM Signal für den Motor sehe ich noch Problematisch, die µC haben Hardware PWMs, du müsstest das ja mit der Software stricken.

Ideal wäre es wohl für dich wenn man ein Modul hat das mit einem µC die Motoren regelt und das alles extern vom Computer macht. Du gibst die Drehzahl an (meinetwegen mit dem Servosignal) und das Modul hält diese so weit wie möglich. Aber ob es das fertig zu kaufen gibt ?!
04.05.2010, 21:30
Jepp

Zitat:

Zitat von the_muck

Das Schnelle Bild vom Oszi zeigt das Signal der Lichtschranke bei ~9500 u/min mit eben der 32er Lochscheibe.

Ich habe mir die phidgets Teile mal angeschaut, eigentlich ganz nett aber irgend wie ist die Update Rate für Regelungen recht langsam finde ich. Auch das mit dem PWM Signal für den Motor sehe ich noch Problematisch, die µC haben Hardware PWMs, du müsstest das ja mit der Software stricken.

Ist denn eine hohe Update Rate so wichtig? Ich würde naiv sagen, dass mir 20 oder 30 Takte pro Sekunde reichen sollten.

Zitat:

Zitat von the_muck

Ideal wäre es wohl für dich wenn man ein Modul hat das mit einem µC die Motoren regelt und das alles extern vom Computer macht. Du gibst die Drehzahl an (meinetwegen mit dem Servosignal) und das Modul hält diese so weit wie möglich.

Ich habe mir das empfohlene RN-VN2 DualMotor Fertigmodul bestellt, mal schauen wann es ankommt.
Ist ein µC, der die Motoren regelt bzw. das Hardware PWM, wie du es beschrieben hast, dem AdvancedServoBoard überlegen? Zeitkritisch ist meine Anwendung ja nicht. Ein Modul, dass die Drehzahl selbstständig hält - das wäre was. Aber dann ja auch schon eine "komplette" Regelung.

Zum Vorankommen der letzten Tage:
Nun ist endlich der größte Brocken der Softwareumstellung getan.
Wobei ich ja nicht weiß was noch kommt also bleiben wir bei "einem großen Brocken". ;)

Die Architektur ist grob in die Punkte
- GrandCentral, der zentralen Klasse, die alle Teilbereiche miteinander verbindet
- Kartenverwaltung, Umrechnung der Sensordaten mit lokaler und globaler Karte (Punktwolken)
- BotThreadverwaltung steuert Verhaltensmuster (als Threads)
- Eventverwaltung umfasst Ereignisempfänger, Ereignisquellen (Sensoren, Servos usw.)
- SensorAktorKomponenten ist die Gruppe von Objekten, die Hardwarekombinationen abbilden (z.B. ServoTower besteht aus Servo0, Servo1 und IR80cm)
- GUI mit 2D Swing und 3D OpenGL Darstellung
zu unterteilen.

Lokal lassen sich weiterhin direkt 2D und 3D Darstellung starten. Bisher habe ich den Roboter per VNC direkt über seine GUI gesteuert und Messwerte darüber anzeigen lassen.
Ich habe mich die letzten Wochen mit Sockets genauer auseinandergesetzt und Testprojekte geschrieben. Das ist etwas aufwändig und letztlich ja nicht mein Fokus. Ein eigenes Protokoll hätte beschrieben werden müssen.. ich habe nun eine komfortablere Lösung per Java Remote Method Invocation (RMI) umgesetzt.

Bild hier
Bild hier

Der Roboter kann nun von mehreren Clients gleichzeitig über eine GUI-Anwendung angesteuert werden. Auf dem Bot läuft quasi ein Server, bei dem sich Clients anmelden können und z.B. bei Änderungen des Kartenmaterials benachrichtigt werden. Die komplette Funktionalität, wie Fahrkommandos absetzen, BotThreads starten und die Punktwolkendarstellung ist damit von OS X, Windows und Ubuntu aus möglich. Die Prozessorlast des Bots ist, trotz des Starts aus Eclipse auf unter 3% gesunken. Die Visualisierung der Punktwolken ist komplett Sache der Clients und soll später flexibler werden.

Für Freunde der bewegten Bilder die Aufnahme des Testlaufs:
http://www.youtube.com/watch?v=8GpwtBVU4IE
05.05.2010, 10:30
RedBaron

Moin,

eine "außerparlamentarische" Frage: Diese Bleche mit den Löchern drin, die sich so gut biegen lassen. Wie heißen die und wo kriegt man die? ich habe zwei "linke Hände" und die Bleche scheinen DIE Lösung für viele meiner Probleme zu sein.

Viele Grüße
Red Baron
06.05.2010, 11:02
Jepp

Das Aluminium hatte die Abmaßen 1m x 0,5m glaub ich. Ich habe es von Bauhaus, dort gibt es eine Abteilung, wo verschiedene Bleche (mit Löchern, ohne Löcher, Alu, Kupfer usw.) einsortiert sind.
Ich beschreibe es so weil es so komische Größen sind, die man "als richtiger Handwerker" wohl eher als Verschnitt einstufen würde. Der Preis ist mit rund 10 - 15€ auch wahrscheinlich unverhältnismäßig hoch.

Bild hier Bild hier

Für eine kleine Bastelei am Rande ist es super zu bearbeiten.
06.05.2010, 11:57
the_muck

Hallo,
das "Problem" so denke ich, ist halt diese Update Rate. Wenn ich das richtig interpretiere wird die Kommunikation PC <-> AdvancedServoBoard nur mit ~31Hz realisiert. So kannst du halt "nur" 31 mal in der Sekunde den Motor nach regeln was nach meinem Gefühl zu träge wird (Die Regeleinheit müsste halt sehr schnell sein) . Das kann man aber sicher mit Matlab oder Scilab Simulieren wie das aussehen wird.
Ich bin an so einem Motor Controller dran, was mir nur gerade sorgen bereitet sind die 6 Timer für 2 Motoren die man Idealerweise bräuchte. Kann dich ja auf dem Laufenden halten, Platinen könnte ich dir dann zuschicken wenn es mal soweit ist ;).
07.05.2010, 10:17
Jepp

Zitat:

Zitat von the_muck

Hallo,
das "Problem" so denke ich, ist halt diese Update Rate. Wenn ich das richtig interpretiere wird die Kommunikation PC <-> AdvancedServoBoard nur mit ~31Hz realisiert. [...] Das kann man aber sicher mit Matlab oder Scilab Simulieren wie das aussehen wird.

Ich hab mal mein (scheinbar recht altes) Oszilloskop aus dem Keller geholt und die PWMs fotografiert. Die Schalterstellungen habe ich absichtlich auf den Bildern gelassen weil ich so ein Teil vor über 8 Jahren das letzte Mal benutzt hab und nicht sicher bin, ob die Einstellungen so optimal sind.

Verglichen habe ich das Phidget ServoController Signal mit deinem (auch sehr alten) Empfänger den ich noch im Schrank hatte. Das ist ein 4-Kanal Robbe Empfänger. Die Oszilloskopeinstellungen habe ich nicht verändert.

Bild hier
Bild hier

Zitat:

Zitat von the_muck

Ich bin an so einem Motor Controller dran, was mir nur gerade sorgen bereitet sind die 6 Timer für 2 Motoren die man Idealerweise bräuchte. Kann dich ja auf dem Laufenden halten, Platinen könnte ich dir dann zuschicken wenn es mal soweit ist ;).

Du entwickelst selbst einen Treiber? - So hat jeder seine Laster. ;)
Solang mir hier nichts abbrennt, freue ich mich über jedes Stück Hardware, dass mir keine weiteren Steine (beim Entwickeln der Software) in den Weg legt.

Mein RN-VN2 DuaMotor Board ist gestern angekommen. Soweit macht das einen guten Eindruck. Die Steuerung per Phidget Interface ist damit auch machbar. Irgendwo steckt aber leider noch der Wurm drin.
Ich habe wegen der Eletrotechnik-Nähe einen eigenen Thread aufgemacht.
https://www.roboternetz.de/phpBB2/vi...=500771#500771

Vielleicht fällt dir dazu ja etwas ein.
09.05.2010, 09:43
the_muck

Hallo,
ach her je, ich glaube du verwechselst da etwas :(, was du aufgezeichnet hast sind die PWM Signale für die Servos, diese werden auf deinem Board durch Controller erstellt, dieser Controller wird, wenn ich das richtig sehe, nur 31 mal in der Sekunde aktualisiert. Die Signale müssen gleich sein, da beide Servos ansteuern die ein recht "Genormtes" Signal haben.

Für die Motoren brauchst du aber ein PWM Signal welches z.b immer eine Logische 0 hat (Motor Speed =0) und immer eine Logische 1 (Motor Speed = Max).

Code:

| = PWM Start, Flanke positiv --- = High, ___ = Low Motoer Speed = 0 |0000|0000|0000|0000... |____|____|____|____... Motor Speed = Max |1111|1111|1111|1111... |------|------|------|-----.... Motoer Speed = 50% |1100|1100|1100|1100... |--__|--__|--__|--__... Moter Speed ~75% |1110|1110|1110|1110... |---_|---_|---_|---_.....

Man Pulst einfach die Spannung mit einer recht hohen Frequenz am Motor...

Das sind nun aber zwei Paar Schuhe da du mit deinem Servo PWM diese Zustände nicht erreichst...

Ideal wäre, was ich meinte, einen Treiber Baustein zu basteln der dein Servo PWM in ein Motor PWM wandelt, die Endstufe (H-Brücke) anspricht aber gleichzeitig auch die Regelung der Motoren übernimmt...

http://www.shop.robotikhardware.de/s...roducts_id=128
10.05.2010, 17:03
Jepp

Den Zusammenhang zwischen PWM und Motoransteuerung durch das takten der Batteriespannung hatte ich verstanden.
Meine Vermutung war, dass das PWM-Signal so "selten" gesendet wird, dass es der Motortreiber als 100%, 0%, 100%, 0% Schaltdauer interpretiert also überabtastet und damit an die Motoren nur 50% der Schaltdauer weiterreicht.

Ich habe mit einem größeren High-Anteil auf der PWM Leitung gerechnet. Das Oszilloskop habe ich wieder in den Keller gebracht weil ich aus dem Motorsignal auch nicht schlauer geworden bin.

Da mein Fokus ja auf der Software liegt, habe ich mich nun entschieden ebenfalls ein Phidget-Board zur Motoransteuerung zu verwenden. Es sind leider wieder hohe Kosten im Vergleich zum RN-Treiber aber ich will vorankommen. :(
26.06.2010, 22:41
Jepp

Das Phidget zur Motorsteuerung hat sich definitiv gelohnt.
Mittlerweile ist es seit über einem Monat verbaut und arbeitet tadellos. Die Beschaltung ist denkbar einfach. USB dran, Energieversorgung dran und beide Motoren anschließen. Zusätzlich hat man noch 4 digitale Eingänge, die ich aber nicht nutze. Die Steuerung per Software lässt sich von -100% bis +100% pro Motor festlegen. Dazu gibt es die Möglichkeit, die Drehzahlsteigerung zu drosseln. Damit kann ich langsamer beschleunigen um Schlupf zu verringern und beim Bremsen die Motoren aber sofort stoppen.

Bild hier

Ich habe mich bemüht, die Aufnahme der Raddrehzahl zuverlässiger zu gestalten. Meine Konstruktion besteht aus zwei Gabellichtschranken, die die Raddrehzahl direkt von den Antriebsachsen abgreifen. Dafür habe ich die bereits erwähnten Maussensoren gestutzt und in eine legofreundliche Bauform gepackt. Das Ergebnis ist nicht mehr allzu kompakt dafür aber 100% bausteinkompatibel.

Bild hier Bild hier

Eine Radumdrehung erzeugt mit den 32 Zähnen (ich hatte vorher manuell 40 gezählt..) nun 74 Flanken, die sich auswerten ließen. "Ließen" weil sich durch die hohe Anzahl der Zähne bzw. die kleine Bauweise Probleme ergaben, die sich natürlich erst nach zwei Tagen experimentieren ergeben hatten.

Meine PhidgetBoards sind ältere Versionen und können digital rund 125 Schaltvorgänge pro Sekunde verarbeiten, analog liegt das Board laut Doku bei 65 pro Sekunde.
Da die Gabellichtschranken digital angeschlossen sind, sollte ich mit knapp zwei Radumdrehungen pro Sekunde noch grade hinkommen. Im Notfall wird halt langsam gefahren. Es stellte sich raus, dass aber bereits bei knapp 40 Ticks/Sekunde also 20 Zähnen pro Sekunde Schluss war. Sobald ich die Drehzahl erhöhe, erkennt der Phototransistor die Lücken nicht mehr ordentlich. Nach einigen Versuchen mit Sonnenlicht, im Dunkeln usw. habe ich die Lichtschranken mit etwas Pappe abgedeckt.

Ich vermute, dass die Phototransistoren bei Tageslicht soviel IR-Licht antreffen, dass sie ständig gesättigt sind und das ankommende Licht der IR-LED bei Dunkelheit nicht mehr ausreicht, die Phototransistoren durchzuschalten. Ich habe ein paar Schaltpläne zum Aufbau gefunden und diese auch mit einigen Widerständen nachgebaut aber irgendwie will das Ganze nicht so recht.

Zuletzt hatte ich noch mit ausgedruckten Encoderscheiben und meinem 5mm IR Sensor Versuche gemacht. Das Bauteil nutzt ein moduliertes IR Signal, was es wesentlich störunempfindlicher macht. Da mein analoger Eingang aber nur die 65 Schaltvorgänge pro Sekunde schafft, wäre meine Raddrehzahlauflösung nicht höher als meine bisherige Microschalter-Konstruktion. Die Gabellichtschranken lasse ich am Roboter montiert und verwende aber nun weiterhin die mit 6mm pro Tick recht grob auflösenden Microschalter.

Bild hier Bild hier
26.06.2010, 23:12
Jepp

Ich hatte mich schon eine Weile umgeschaut, wie ich erhältliche Gyroskope und Bauteile wie einen Kompass unkompliziert per Software abfragen bzw. überhaupt erstmal an das Netbook anschließen könnte. Meine Wahl wäre ein Android Hand gewesen wenn nicht zufällig vor einigen Wochen das Spatial Board mit eingebautem 3-Achsen Beschleunigungssensor, 3-Achsen Gyroskop und 3-Achsen Magnetfeldsensor (sprich Kompass) erschienen wäre.

Die Hardware wird wie gewohnt über die Phidget-API angesprochen wodurch ich keine weiteren Abhängigkeiten oder Frickelei in Kauf nehmen muss. Die Platine ist recht kompakt und wird per USB verbunden. Unter dem Holzbrett habe ich einen USB-Hub verbaut womit eine kurze Leitung USB-A zu Mini-USB ausreicht. Der Sensor ist ungefähr mittig zwischen den Sensortürmen befestigt.

Bild hier Bild hier

Die Sensortasten zu verwerten ist nicht so leicht, wie ich mir das vorgestellt hatte. Die "Anschließen und Staunen"-Beispielanwendung zeigt die Werte der Sensoren und macht Bock auf mehr. Der Quelltext liegt bisher nur in C# vor. Den Punkt hatte ich überlesen und es erstmal zu Fuß versucht. 8)
Aktuell nutze ich den Giro um meine Rotation auf der Stelle zu erfassen. Ich kenne meinen Drehpunkt ungefähr und habe den Bauteilen entsprechend Matrizen zugewiesen, die die Pose des Roboters speichern sollen. An der Software hat sich auch einiges geändert, ein paar neue Threads sind zuschaltbar, die Sensorwerte, Drehwinkel usw. ausgeben.

Vorgestern habe ich den Roboter etwas herumfahren lassen und vom Rechner aus beobachtet, was er so an Punktwolken sammelt..
Das Ergebnis ist unten zu sehen. Ich verlasse mich bei dem Scan allein auf die Microschalter-Odometrie in der translatorischen Bewegung. Beim Rotieren werden Kompass usw. zwar abgefragt, aktuell aber nur eine Achse des Gyroskops verwertet. (Der Bot fährt übrigens noch immer nicht geradeaus. Das schiebe ich noch etwas vor mir her.)

Die Punkte auf den Ständern sind erfasste Hindernisse. Die Linien, die von den Punkten wegführen, zeigen die Position des Sensors. Auf dem Untergrund ist in rot die Fahrstrecke markiert. Stellen, die vor Linien kaum noch zu erkennen sind wurden häufiger abgetastet. Eine GUI muss an der Stelle unbedingt mal her damit das übersichtlicher wird..

Bild hier

Der Roboter ist von meinem Arbeitszimmer (links oben) in den Flur (rechts oben) in die Küche gefahren (rechts unten). Die aufgenommenen Punkte werden einfach in die Karte aufgenommen, also weder geprüft, gematcht oder ähnliches.
03.07.2010, 13:54
Jepp

Ich habe einen Bildexport für die Kartierung begonnen. Es erlaubt auf Klientseite das Abfragen der aktuellen Roboterkarte, die dann lokal auf dem Rechner gespeichert wird.
Man kann die Auflösung des Bildes durch den Parameter "MillimeterProPixel" bestimmen. Idee dahinter ist, die flexible Auflösung der Karte ebenfalls auf dem Roboter zu haben damit dieser verschiedene Ansätze zur Selbstlokalisiation durchführen kann.

Bild hier

Auf der Karte lässt sich direkt der klassische Odometriefehler erkennen. Ich hatte bei der Kartierung keine Wegstreckensynchronisation gestartet wodurch der Roboter bei der Geradeausfahren nach rechts tendiert.

Auf der (theoretisch) abgefahrenen Route werden bei jedem Stopp zwei Nadeln dargestellt. Zu jeder Pose werden Ticks, Beschleunigungswerte, Magnetfeld und die berechneten Gyrowinkel gespeichert. Die grün/rote Nadel zeigt Nord und Süd an, die dunkelblaue Nadel zeigt die Orientierung der Gyroskop z-Achse.
Das untere Bild lässt vermuten, dass sich das Erdmagnetfeld offenbar schlagartig neu ausgerichtet haben muss. ;) - Der herausstehende USB-Stecker hatte sich am Tischbein verkantet und eine Drehbewegung des Roboters bewirkt. Eine kontinuierliche Aktualisierung der Roboterpose per Giro und/oder Kompass sollte die Fehlerquelle einschränken können..

Bild hier

Nächste Woche werde ich mich mit der präzisieren Kartenerstellung und einfachen Möglichkeiten der Lokalisation beschäftigen.

Euch ein schönes Wochenende!