Erster fahrender Roboter

Hallo,

Nach diversen kleineren Projekten und Vorüberlegungen habe ich jetzt mein erstes größeres (zusammenhängendes) Projekt in Angriff genommen.
Für die meisten mag es Vielleicht jetzt nicht besonders spektakulär klingen, trotzdem ist es für mich ein großer Schritt und ich bin mit sicher ich werde dabei einige Fragen haben.


Technische Daten bis jetzt:
- Abmessung 25x25cm x 27cm
- Rahmen aus 4-Kant Holz
- Tamiya Twin Gearbox mittig des Gehäuses
- 1 Kugelrad zur Ballance
- AtMega32 zur Ansteuerung
- Motortreibermodul für 2 Motoren
- 2 Tastsensoren an der Vorderkante
- 2 zusätzliche Zahnräder mit Löchern oberhalb des Getriebes für die Odometrie
- 2 Gabellichtschranken zur Odometrie-Messung


Projektstatus bis jetzt:
(Stand 19.09.2012) Erste freie (unkoordinierte) Fahrmanöver mit Anstoß-Erkennung durch die Tastsensoren.
(Stand 27.09.2012) Der Roboter hat jetzt eine Platinenbefestigung in Sandwichbauweise bekommen. Außerdem wurde das Fahrgestell etwas umgebaut.
(Stand 05.10.2012) Die Odometrie funktioniert jetzt mittlerweile. Hier ist derzeit zwar nur eine Genauigkeit von ca 2.5cm zurückgelegter Wegstrecke möglich, aber immerhin ist es ein erster Schritt in Richtung Navigation und Umfahren von Hindernissen.
(Stand 16.10.2012) Ziel erreicht: Anfahren von mehreren Punkten (Wegmarken) in Folge.

Nächstes Ziel:
- Finden und Anfahren eines Festen Punktes (Parkposition).
- Umfahren von Hindernissen. (vermutlich mit A-Star Navigation)
- Kommunikation mit PC (USB oder Wlan).
- Datenlogger auf SD-Karte.
- LCD-Display zur direkten Ausgabe von geloggten Werten.
- Kartografierung der Wohnung für die A* Navigation.


Anhang 23332

--------------------------------

So soviel mal zum aktuellen Status.

Jetzt zum nächsten Schritt, dem Auffinden eines Zielpunkts.
Und dazu hab ich mir auch schon ein paar Gedanken gemacht, zu deinen ich gerne eure Meinung hätte. Vermutlich denk ich hier auch mal wieder viel zu kompliziert.

Optimum für diese Situation wäre ja vermutlich, das der Roboter seine eigene Position in der Ebene, sowie die exakte Position des Ziels im in der Ebene kennt, daraus dann den entsprechenden Vektor berechnet, die Richtung einschlägt und hinfährt.
Dazu müsste der Roboter aber eben nicht nur seine eigene Position in der Ebene kennen, sondern außerdem noch dauerhaft seine Lage und Position in der Ebene überwachen können.

Wenn ich jetzt die komplette (mögliche) Fahrebene außer Acht lasse, kann ich das ganze System ja eigentlich auf die Verhältnismäßige Lage zwischen aktueller Position und Position des Zielpunkts reduzieren und spar mir dadurch doch einiges an Aufwand.
Breche ich das Problem jetzt noch einmal auf kleinere Bröckchen herunter, reduziert sich das Problem auf 4 Teile:

- Ausrichten des Roboters in Richtung des Ziels
- Fahren zum Ziel
- Kontrolle ob das Ziel schon erreicht ist
- Entsprechende Kurskorrektur (sowohl Winkel als auch Distanz)

Zur Ausrichtung auf das Ziel brauch ich ja wohl einen elektronischen Kompas. Alternative wäre Triangulation, aber die kann ich in dem Fall ja erst wärend der Fahrt anwenden, also der Winkel der Fahrtrichtung errechnet sich dann ja durch den Vergleich der Position zu Zeitpunkt 1 und Zeitpunkt 2, so wie beim Autonavi.

Also mein Lösungsvorschlag wäre der folgende:
- Ich errechne mir den benötigten Winkel um genau aufs Ziel ausgerichtet zu sein.
- Dann wird der entsprechende Winkel durch Drehung des Roboters um seine eigene Achse eingestellt.
- Jetzt wird einfach mal drauflos gefahren.
- Kommt es zu einer Abweichung im Winkel (zB durch Unebenheiten im Boden, Schlupf der Räder, etc) wird das möglichst sofort korrigiert.

-> hier können sich dann aber Fehler in den Winkelabweichungen aufsummieren, mal Abgesehen davon das ich noch absolut keine Messung der Weglänge habe

-> Ich könnte jetzt einfach hergehen, und sagen zähle für alle Winkel-Abweichungen nach Rechts eine Variable +1, für alle Abweichungen nach Links zähle -1. Ist am Ende die Variable (annähernd) 0 dann sollten sich die Fehler in Grenzen halten, andernfalls weiß ich in welcher Richtung ich Falsch stehe, aber noch nicht wie weit.
Wenn ich jetzt zB immer nach gefahrenen 5 Sekunden die Winkel kontrolliere und eine Abweichung feststelle weswegen ich die Variable hochzählen müsste, dann kann ich ja auch davon ausgehen das diese Winkeländerung statistisch gesehen nicht plötzlich passiert ist sondern ein schleichender Prozess war, den ich durch eine Kurve mit Ausgangssteigung 0° und Endsteigung x° beschreiben kann. So bekomme ich eine errechnete Abweichung in die entprechende Richtung. Wenn ich diesen Fehler jetzt aufsummiere, könnte ich am Ende der Fahrstrecke die Ausrichtung bzw. Fahrdauer korrigieren und anpassen, das der Roboter zumindest rechnerisch am Zielpunkt stehen sollte.
Nachdem ich aber weiterhin nicht die Fahrstrecke, sondern nur die Fahrzeit messen kann gibts hier wieder gewisse Ungenauigkeiten.

-> Wäre hier Triangulation anhand von 2 markanten Punkten links und rechts des Ziels sinnvoll? Einerseits könnte ich dadurch auch die zurückgelegte Strecke bis auf Ungenauigkeiten errechnen, andererseits könnte ich dadurch auc hdie Fehler verringern.
Da würde ich dann zwei Sharp-Infrarotsensoren auf Servos setzen und die so wärend der Fahrt dauerhaft auf die markanten Referenzpunkte ausgerichtet halten.


So, was haltet ihr jetzt davon? Gibt es da eventuell andere Möglichkeiten? Wie habt ihr das Problem gelöst?

LG
ijjiij

Ok andere Idee, von dir ich aber auch noch nicht genau weiß ob die so funktionieren wird. Daher hätte ich hierzu gerne eure Meinung, ob das Ganze so dann praktikabel ist und funktioniert.

Also mein Gedanke war, eines der Getriebe-Zahnräder anzubohren. Durch das hier entstandene Loch könnte ich dann mit einer Gabellichtschranke direkt im Getriebe digital die Umdrehungen messen.
Die Lichtschranke würde ich aber eben auf eines der Getriebezahnräder ausrichten und nicht auf das Antriebsrad, einerseits weil hier mehr Platz zu sein scheint, andererseits hab ich durch die Übersetzung im Getriebe hier noch eine höhere Umdrehungszahl und kann dann exakter messen.

Stimmt das soweit? Kann ich bei so höheren Umdrehungszahlen überhaupt noch richtig Messen? Also bekomme ich hier dann überhaupt noch exakte Messwerte?

Hi,

hübsches Projekt und dazu eine anspruchsvolle Aufgabenstellung.

Zitat:

---

Zitat von ijjiij

... Wäre hier Triangulation anhand von 2 markanten Punkten ... sinnvoll? ...

---

Nein, Triangulation wie Du sie möchtest funktioniert sinnvoll nur mit mindestens drei Baken, siehe dazu hier (klick).

Zitat:

---

Zitat von ijjiij

... zwei Sharp-Infrarotsensoren ... auf die markanten Referenzpunkte ...

---

Das geht leider gelegentlich total schief, weil die Sharps ja eigentlich für einfache Erkennungsaufgaben konstruiert wurden. Die können je nach Betrachtungswinkel gleiche Gegenstände z.T. sehr ungleichmässig sehen. Das ist hier ausführlich vorgestellt (klick schon wieder). Leider gibts zum üblichen Hobbybudget kaum etwas besseres, Du kannst also so arbeiten, muss Dich aber auf Fehler und Ungenauigkeiten einstellen. Übrigens sollte man Sharps gut entstören (klick).

Zitat:

---

Zitat von ijjiij

... eines der Getriebe-Zahnräder anzubohren ...

---

Auch Odometrie geht nur halbwegs genau. Es hängt damit zusammen, dass Antriebsräder meist einen - je nach Untergrund wechselnden - Schlupf haben. Daher ist die Messung nie ganz genau. Testfahrzeuge der Automobilindustrie verwenden daher zum GENAUEN Messen der Fahrgeschwindigkeit ein nachlaufendes, sehr leichtes Rad . . .

Jedenfalls - viel Erfolg.

So, erstes Kleines Status-Update:

Ich habe die Stroversorgug jetzt von 4 AAA Batterien deutlich erhöht. Der Roboter läuft jetzt mit 12 (2*6) AA Batterien. Außerdem habe ich ihm einen Festspannungsregler auf 5V verpasst damit das Ganze System etwas stabiler und länger laufen sollte.
Die 12 Batterien sind jetzt alle seriell geschaltet, eventuell werde ich mal testen jeweils die beiden "6er Packs" parallel zu schalten. Die Spannung wäre dann ja immernoch ausreichend.

Keine großen Fortschritte aber immerhin tut sich was! Eventuell stelle ich heute Abend mal ein Bildchen von der aktuellen Version online, falls das irgendwen interessiert... :)

PS: Noch habe ich leider keine weiteren Experimente zur Odometrie oder ähnlichem gemacht, dafür hat mir bis jetzt leider die Zeit gefehlt.

So, und weiter gehts mit der Stromversorgung...

Nach einem diesmal etwas längerem Testlauf ist mit aufgefallen, dass bei längerer Fahrzeit erstens der Festspannungsregler relativ warm wird, und andererseits anscheinend die Leistung langsam zusammensackt. Daher werd ich wohl jetzt wirklich von 18V auf 9V runtergehen und hoffe das sich das dadurch ändert.

Nachdem ich jetzt das kleine Problem mit der Stromversorgung gelöst habe, habe ich jetzt erstmals den Roboter am Boden statt wie bisher am Tisch getestet.

Dabei sind mir mal wieder ein paar unerwartete Kleinigkeiten aufgefallen die es jetzt zu beheben gilt.
Es handelt sich um kleinere Probleme mit der bisherigen Konstruktion in Kombination mit den Unebenheiten im Parkett. Soll heißen, der Roboter bleibt mit seinen Kugelrädern "hängen" und hebt so die Antriebsräder aus wodurch die dann den Bodenkontakt verlieren. Folgerung daraus ist dann wohl, das ich das komplette Design nochmal überdenken muss und vermutlich jetzt vorerst doch die Antriebsräder an die Vorderseite des Bots legen werde und die Kugelräder auf die Hinterseite. Geht zwar so leider auf Kosten der Einfachheit beim Fahren, aber vorläufig ist das wohl die bessere Lösung.

Alternativ könnte ich auch noch vorläufig mal nur eines der Kugelräder entfernen, und dafür dne Schwerpunkt des Bots verlagern um ein Kippen zu verhindern. Auf jeden Fall hab ich hier wieder was zu tüfteln.

So, es hat wieder kleine Fortschritte gegeben.
Der Roboter hat sein neues Design bekommen, die Platinen sind jetzt in einer Art von Sandwichbauweise von Platten übereinander befestigt.

Jetzt gehts ans Redesign der Anstoßerkennung.
Die erste Frage die sich mir jetzt stellt ist natürlich, an welche Ports / Pins ich die Tastsensoren am besten anschließe. Prinzipiell war der Plan, sowohl die Tastsensoren als auch in weiterer Folge die Radencoder für die Odometrie auf die Pins PB0-4 zu legen.

Wäre es da sinnvoll, die Taster über einen Interrupt (PB2 - INT2/AIN0 oder PB3 - AIN1/OC0) zu legen? Andererseits, kann man wirklich 2 oder mehr Taster auf den PB2 legen?
Dann hätte ich PB0 und PB1 (T0 und T1) für die Odometrie frei.

Was würdet ihr hier empfehlen?

PS:
Im ersten Beitrag gibts Fotos vom Roboter bis jetzt! :)

EDIT:
Ich hab mich jetzt dafür entscheiden die beiden Taster einfach auf PB0 und PB1 zu legen.
Leider sind nach meinen jetzigen Tests schon wieder ein paar ungereimtheiten aufgetaucht von denen ich mir teilweise nicht ganz sicher bin ob sie Software oder Hardware bedingt sind.

1.) Der Roboter wird mit der Zeit immer merklich langsamer, das ist dann vermutlich Hardwarebedingt, wobei ich mir irgendwie nicht ganz vorstellen kann das meine Stromversorgung für die aktuelle Bauweise nicht ausreichen sollte.

2.) Löst der Roboter manchmal "Anstöße" aus, obwohl weit und breit kein Hindernis war. Auf jeden Fall sehe ich so zumindest, das das Zurücksetzen am Hindernis gut funktioniert. Ob das ein Software oder Hardware Fehler ist weiß ich lieder noch nicht, er muss auf jeden Fall gefunden und ausgebessert werden bevor die nächsten Tests mit komplexeren Aufgaben starten können.

3.) Kommt der Roboter in unvorhergesehene Zustände. Bei der normalen Fahrt soll die grüne LED leuchten, beim Zurücksetzen vom Hindernis dann die rote, solange bis die normale Fahrt wieder aufgenommen wird und die grüne LED wieder angeht. Was jetzt (gegen Ende der etwa 5 minütigen Testfahrt) passiert ist, ist das plötzlich beide LEDs angingen und der Roboter anfing sich im Kreis zu drehen, bzw. seltsame Fahrmanöver auszuführen obwohl keiner der Tastsensoren gedrückt war.
Auch hier bin ich mir nicht sicher ob es sich um einen Software oder Hardware Fehler handelt. Eventuell hängt dieses Phänomen ja mit der deutlich geringeren Geschwindigkeit des Bots am Ende des Tests zusammen. (Batterie low?)

Wie dem auch sei, die erste Testfahrt war sehr aufschlussreich und hat neuen Stoff für Grundlagenexperimente gebracht. Wenn ich die Problemchen nach und nach in den Griff bekomme, bin ich gespannt wies dann weiter aussehen wird.

Ich bräuchte bitte Hilfe / Tipps von jemandem der sich auskennt. Also ich habe beide Batterie-Packs gemessen, sie haben eine Verbleibende Spannng von jeweils 8,96 Volt, dahinter liegt ein Festspannungsregler der die Spannung auf 5V regelt.
Am Input des Festspannungsreglers messe ich 8,96 Volt.
Am Ausgang des Festspannungsreglers messe ich 5.05 Volt.
Am Eingang des Controller-Boards messe ich 5.04 Volt.
Wenn die Motoren anfangen zu drehen bringt mir die Spannung zusammen auf zwischen 4,02 und 3,96 Volt.

Woran liegt das? Kann ich den Fehler umgehen, indem ich die Spannungsversorgung von Controller und Motoren trenne? Also zwei komplett getrennte Stromkreise verwende?
Muss ich dann zwei getrennte Festspannungsregler einsetzen, also für jeden Battierie-Satz einen eigenen Festspannungsregler?
Oder kann es daran liegen, das die verwendeten 12 AA Batterien einfach zu schwach/leer sind?

Wäre so ein Akku-Pack ausreichend, um sowohl Motoren als auch Controller zu versorgen, ohne das die Spannung zusammenbricht? Oder bräuchte man auch hier 2 getrennte Stromkreise?
http://www.conrad.at/ce/de/product/2...r/?ref=detview

So, nach einem bastelreichen Wochenende hab ich mal wieder ein kleines, sehr erfreuliches Status-Update.

Als Stromversorgung dienen jetzt 2 RC-Racingpacks mit 3700 mAh und 7,2V, eines komplett für den Controller und eines für alle "Stromfresser" (Motoren etc.). Ein zweiter Festspannungsregler versorgt jetzt die Motoren in einem getrennten Stromkreis mit 5V Versorgungsspannung.
Beide Stromkreise teilen sich einen gemeinsamen An-Aus-Schalter.

Die Software wurde weitestgehend überarbeitet und verfeinert, vor allem wurden einige Fehler ausgebessert und ich hab mich mal an die Kapsellung diverser Funktionen gemacht um die Übersichtlichkeit zu wahren. Einige neue Funktionen wurden schon mal hinzugefügt, auch im Hinblick auf die zukünftigen "Einsätze" des Roboters.

Als nächstes werde ich mich wohl an die (mehr oder weniger) genaue Fahrtstreckenmessung wagen, also meinem Roboter Lichtschranken zur Odometrie verpassen. Danach werd ich Softwaremäßig versuchen, die Wegstrecken und Drehungen so exakt wie möglich hinzubekommen, als ersten Schritt bzw. Grundlage zum Auffinden eines bestimmten Punktes in der Ebene.

So, mal wieder ein kleines Update von mir: Die Odometrie ist eingebaut und getestet!

Zwar ist die Genauigkeit derzeit mit 2,45cm pro Viertel-Umdrehung des Rades noch sehr bescheiden, aber immerhin funktioniert die Odometrie soweit mal ganz zufriedenstellend und ohne größere Schwankungen. Der erste große Erfolg ist damit, nach einer langen Serie von immer wiederkehrenden Fehlschlägen, Problemen und Fehlern, endlich zu verzeichnen.

So, die ersten zwei Punkte der Zielsetzung sind hiermit dann mal offiziell angearbeitet!

Nachdem ich die letzten Tage die Odometrie auf eine Messgenauigkeit von 10mm reduziert habe, und damit auch die Messung der Winkel verbessert habe, konnte ich heute neue Funktionen zur Fahrt einfügen. Die Anfahrt von einer beliebigen Anzahl an Punkten in der Ebene ist so also möglich, indem mittels Vektoren der Drehwinkel und die Fahrstrecke zwischen dem aktuellen Aufenthaltsort und dem Zielpunkt errechnet wird.

Damit sind also die ersten zwei Ziele die ich mit gesetzt habe erreicht. Als nächstes geht es an die selbstständige Umfahrung von Hindernissen. Dafür will ich in weiterer Folge die A-Star Navigation verwenden, wobei die für den Anfang wohl noch etwas "stark" ist und viel Speicher brauchen wird.