Menü
Aktuelles
Von:
Filter

schulprojekt

R

r2d2

New member
an einer weiterführenden technischen schule möchte ich folgendes projekt durchführen :

ein ardumower (also die mechanik so etwa wie bei euch) mit einem arduino oder einem stm32f3discovery (weil da kompass, acc usw. schon drauf sind), ausgestattet mit folgenden funktionen :

- per odometrie/gps erstellte karte (array mit 10x10cm pixeln) von der wiese
- randerkennung über ne kamera vorne nach unten gerichtet (+beleuchtung ?), damit farbauswertung
- kollisionserkennung mit acc und motorstrom (oder raddrehzahl ?)
- objekterkennung mit ultraschall
- home finden nach karte und feinpositionierung mit led im ladehäuschen

navigation : alle überfahrenen pixel werden 1 gesetzt. an istposition wird geprüft, welche richtung den kleinsten summenwert
der pixel ergibt (=am wenigsten gemäht). dann wird dahin gefahren. nach ein paar metern wiederholung.

bei neuem mähvorgang irgendwie neujustierung / optimierung der karte.

programmierung in c++ objektorientiert.

-> denkt ihr das ich da total auf dem holzweg bin, oder würdet ihr sagen daß man das so bauen kann ???
 
Hallo Reiner,

was Du unter anderen vor hast ist gleichzeitige Lokalisierung und Kartierung (Simultaneous Localization and Mapping = SLAM) und auch für den Ardumower ist dies geplant (zunächst einfach nur zur Echtzeit-Anzeige der aktuellen Roboter-Position).

Ein paar Deiner Ideen (zur Lokalisierung und Kartierung) sind hier bereits zusammengetragen: http://wiki.ardumower.de/index.php?title=Sensor_fusion
Da sich die Fehler über (die relative Messung) Odometrie und Kompass aufsummieren, müsste der Fehler über eine absolute Messung korrigiert werden. GPS wird uns eine Genauigkeit jenseits von Gut und Böse liefern (+- 4 Meter), im Optimalfall wird man eine Genauigkeit von (+/-1 Meter) erhalten, aber leider nur bei Rasenflächen wo kaum Bäume, Häuser stehen. GPS wäre also nur eine Speziallösung.

Woran Du vermutlich noch nicht gedacht hast ist die Feldstärke der Schleife als absolute Position zu benutzen: http://wiki.ardumower.de/images/4/4a/Ardumower_localization.png
Um Lokalisierung und Kartierung gleichzeitig durchzuführen wird typischerweise ein SLAM Algorithmus benutzt und typischerweise benutzen die meisten einen 360 Grad Entfernungs-Sensor (Lidar) hierfür. Dieser Sensor muss es aber nicht zwangsläufig sein.

Wenn man nun 2 Spulen benutzt (eine links, eine rechts), bekommt man ständig 2 Messwerte die nicht auf viele mögliche Positionen der Feldstärkenkarte passen, d.h. man kann dann über einen Partikel-Filter die korrekte Position herausfiltern und diese wird während der Fahrt immer eindeutiger (wahrscheinlicher).

Hier eine Simulation wo der Partikel-Filter eingesetzt wird - in diesem Fall wird aber nur Lokalisierung durchgeführt, die Karte der Feldstärkenverteilung ist dem Programm bereits bekannt (und fest). https://www.youtube.com/watch?v=wLzi5HJiZoQ
(Programm findest Du im Github im Verzeichnis "sim" - die IDE kann fertig hier heruntergeladen werden: http://wiki.ardumower.de/index.php?title=Sensor_fusion#SLAM_simulation)
Ein richtiger SLAM Algorithmus müsste also noch zusätzlich die Kartierung anhand der Feldstärken mit durchführen.

Vieleicht könnten wir so etwas zusammen entwickeln? Also Kartierung und Lokalisierung anhand von Odometrie + Gyro + Kompass + GPS + Feldstärke.

Gruss,
Alexander
 
das freut mich daß hier so schnell ne antwort kommt. danke alexanderg !

zur gemeinsamen entwicklung : das ist bei mir immer ein wenig ein zeitliches problem, weil sich schulprojekte über längere abschnitte hinziehen, mehrere monate minimal. beginnen wird das (bis auf eigene vorversuche meinerseits) erst im september. wenn du aber soviel geduld hast : sehr gerne !!

die feldstärke habe ich nicht vergessen, sondern absichtlich weggelassen. mit einer genauen kompassmessung (wichtig ist eine präzise deklinationskompensation) kann man denke ich schon sehr genau gerade fahren und drehen. ich hab da gute erfahrungen mit einem segelroboter. ich will im klartext keine drahtschleife legen, das ist doch unelegant ;-)

beim gps hab ich die selben erfahrungen wie du, für differentielle messung noch so eben brauchbar (z.b. position hold beim quadrocopter) ist die absolute genauigkeit unbrauchbar (beim segelboot haben wir z.b. ein fehlerband von +/- 10m als realistisch gemessen. fraglich ober der einbau überhaupt lohnt.

du hast mich mit einer ganzen latte von mir neuen begriffen versorgt, da brauch ich jetzt ne weile um das alles einzuordnen (slam, lidar..).

grüße, reiner
 
Hallo Reiner,

zeitlich sind wir ja flexibel, wir könnten z.B. die Idee einfach schon mal per Simulator prototypisch umsetzen und sehen was machbar ist. Ein Anfang wurde ja bereits gemacht.

Jeder Sensor wird mit einer bestimmten Fehler simuliert (Normalverteilung - Mittelwert und Abweichung). Dasselbe für die Roboterbewegung (Schlupf).

Gerne können wir auch GPS noch mit zum SLAM Algorithmus dazunehmen, ich verspreche mir (wie Du) nicht allzu viel davon, aber hineinnehmen sollte man es.

Je genauer die Roboterbewegung (Drehung, Distanz) geschätzt werden kann, umso besser wird auch die Lokalisierung funktionieren. Da werden uns der Kompass und der Gyro helfen.

Der Partikelfilter (welcher uns die "Lösung" der aktuellen Position liefert) funktioniert wie folgt: man verstreut zufällig über die Karte eine bestimmte Anzahl von virtuellen Robotern (d.h. Partikeln, z.B. 100), jeder Partikel bekommt zunächst eine hohe Wahrscheinlichkeit. Nun fährt der Roboter und die Partikel werden in dieselbe Richtung wie der Roboter bewegt (dabei sinkt die Wahrscheinlichkeit des Partikels). für jeden neuen Meßwert (beispielsweise Feldstärke und GPS) wird für jeden Partikel berechnet, wie wahrscheinlich dessen Position zur Karte passt (dabei steigt u.U. die Wahrscheinlichkeit). Sinkt die Wahrscheinlichkeit eines Partikel zu stark, wird dieser von der Karte entfernt. In die Nähe von Partikeln mit hoher Wahrscheinlichkeit werden einfach neue Partikel zufällig hinzugefügt (Subsampling). Und das Spielchen wiederholt sich. Der Mittelwert (Position) aller Partikel-Wahrscheinlichkeiten ist die aktuell geschätzte Roboterposition.

Da Position wie auch die Roboter-Bewegung mit Wahrscheinlichkeiten besetzt sind, ist so ein Partikel-Filter ein gutes Instrument um damit zu rechnen und die "beste" (wahrscheinlichste) Lösung zu erhalten. Welche Sensoren wir alle verwenden ist dem Filter egal.


Gruss,
Alexander
 
Nachtrag: es muss übrings nicht zwangsläufig eine Schleife verlegt werden um eine Feldstärke zu erhalten.

Das (nicht homogene) Magnetfeld am Boden kann bereits zur Lokalisierung verwendet werden wie man in diesem Video sehen kann. Hier wird wieder der Partikel-Filter eingesetzt :) (im Fuss befindet sich ein 3D Kompass-Sensor und ein IMU)
https://www.youtube.com/watch?v=eavk1akiLV4
Wie stark allerdings laufende Motoren das relativ schwache Magnetfeld dabei stören ist eine zu klärende Frage.

http://de.slideshare.net/patrickrobertson/hex-mag-slam-ipin-2013-02
 
ich brauch jetzt erstmal ein wenig zeit, sonst komm ich hier nicht nach. ich will dich ja nicht ausfragen, sondern das zeug selber verstehen ;-)

ein paar details trotzdem :

zur referenzierung hab ich mir ne optisch geführte rückfahrt ins ladehäuschen gedacht, dort ist dann der bekannte referenzpunkt.

unklar ist mir der nutzen des gyro in x/y-ebene. die bekannten exemplare driften doch so stark im offset, daß eine winkelbestimmung übers integral eigentlich nicht klappt (deshalb beim copter ja auch die fusion mit dem acc). der kompass hat all diese probleme nicht, und wenn er gut kompensiert ist (dazu brauch ich natürlich die neigungswinkel in x und y, aber das geht, siehe oben, über fusion aus acc und gyro in den jeweiligen achsen) ist er auch sehr genau.

kalman kann ich vergessen, das liegt außerhalb der mathematischen möglichkeiten meiner teilnehmer. es muß mit anschaulich zu verstehenden algorithmen gehen. sensorfusion ist schon grenzwertig.

ach übrigens : was bedeutet : "Ardumower Sponser" eigentlich ?
 
Die Station als Referenzpunkt wäre mir zu wenig an Daten - wenn wir auf 10-20cm kommen wollen brauchen wir ständig absolute Meß-Daten (also während sich der Roboter bewegt), da sonst der Fehler schon nach wenigen Sekunden ansteigt. Eine Kombination aus GPS und Feldstärke als ständige absolute Meßdaten wäre denkbar.

Ein Beschleunigungssensor liefert stark verrauschte Daten:
https://nxttime.files.wordpress.com/2011/08/imu_accel.jpg
Daher nimmt man typischerweise den Gyro zur Hilfe: https://nxttime.files.wordpress.com/2011/08/imu_gyroscope.jpg
Da der Gyro driftet, kombiniert man beides mit Kalman-Filter. Ist alles schon im Ardumower IMU Code so drin :). X- und Y-Achse sind damit gelöst, den Drift in Z-Achse kann man dann mit Kompass kompensieren (wieder Kalman). Auch das ist im IMU Code bereits enthalten.

Anschaulich ist alles solange man es gut erklären kann. Eine gute Erklärung kann man erst liefern wenn man das Thema richtig verstanden hat. Also ist der Schlüssel das Verständnis des Algorithmus. Und dazu gehört bestimmt auch Fragen, Fragen, Fragen ... :)

Auch muss man das Rad nicht neu erfinden - viele SLAM-Algorithmen findet man als fertig anwendbare C++ Bibliotheken. Natürlich muss man die Grundidee verstehen, sonst nützt einem das alles nichts.

"Ardumower Sponsor" sind wohl die Leute die aktiv an der Projekt-Entwicklung mitarbeiten, d.h. z.B. Code oder Schaltpläne beisteuern.
 
Die Schleife mag zwar als störend empfunden werden, liefert allerdings die allerbesten Voraussetzungen für eine präzise und permanente Ortung des Roboters. Ich habe den Prototypen mal weiter ausgebaut. Die Mathematik hinter dem Particle Filter ist nicht schwer, am Besten kann man sie optisch veranschaulichen:

1. Wir starten mit dem "Worst Case" (in Realität ist die Position bekannt da er normalerweise an der Ladestation startet dessen Position ja bekannt ist). Der Roboter bewegt sich noch nicht und der Filter hat zunächst überhaupt keine Idee wo der Roboter (schwarzer Kreis) sich befindet. Daher generiert er 1000 zufällige Vermutungen wo der Roboter sein könnte. Das sind die weissen Kreise im Bild. Der Mittelpunkt aller Partikel wird ebenfalls berechnet und angezeigt. Das ist der blaue Kreis in der Mitte. http://wiki.ardumower.de/images/0/0e/Particlefilter1.png
2. Der Roboter bewegt sich nun und entsprechend den Steuerbewegungen für den Roboter werden auch die Partikel bewegt. Der Roboter erhält ständig Meßwerte womit er nun die Plausibilität der Partikel anhand einer Karte überprüfen kann. Nach ein paar weiteren Roboterbewegungen sind schon viele falsche Vermutungen "herausgeflogen", da diese nicht gut zu den Messwerten der Karte passten. Neue Messwerte sind in der Nähe "guter" Partikel hinzugekommen (nicht gut sichtbar, da diese sich teilweise überlagern). http://wiki.ardumower.de/images/b/b3/Particlefilter2.png
3. Der Filter ist sich nun relativ sicher wo sich der Roboter befindet. Der Positions-Fehler ist auf 0.5m gesunken. Alle Partikel liegen nun in der Nähe der realen Roboterposition. http://wiki.ardumower.de/images/4/44/Particlefilter3.png
4. Der Fehler ist weiter abgesunken auf 0.2m (der durchschnittliche Fehler liegt sogar deutlich niedriger) http://wiki.ardumower.de/images/5/5a/Particlefilter4.png
Ich finde das ein interessantes Ergebnis. Ich habe es mit einer rechteckigen Schleife ausprobiert und es funktioniert dort ebenfalls.

Der nächste Schritte wird sein, dass der Roboter die Karte zunächst selber erstellt indem er die Schleife einmal komplett abfährt.

PS: Der Code ist hier zu finden: https://github.com/Ardumower/ardumower/tree/simulator/sim
 
die kernaussage ist mir noch unklar :

"Nach ein paar weiteren Roboterbewegungen sind schon viele falsche Vermutungen "herausgeflogen", da diese nicht gut zu den Messwerten der Karte passten."

was meinst du mit "nicht gut passten" ? das können doch eigentlich (ohne weitee sensorik, nur schleife außenrum) nur partikle sein, die sich über den schleifenrand hinaus bewegt haben, oder ?

(vermutung : du denkst an die magnetfeldmessung..)
 
Hallo Rainer,

ich wollte zeigen dass die Induktionsschleife nicht nur die Grenze des Rasen präzise beschreibt sondern auch im innern zur präzisen Ortung dienen kann. Die Feldstärke der Schleife ist überall auf der Rasenfläche zu messen und verteilt sich wie folgt (Feldstärke nimmt von der Schleife ab und außerhalb ändert sie zusätzlich ihr Vorzeichen): http://wiki.ardumower.de/images/d/d5/Perimeter_signal_strength.jpg
Der Ardumower mißt bereits ständig diese Schleifen-Feldstärke überall auf dem Rasen mit seiner Spule (blauer "mag" Plot): http://wiki.ardumower.de/images/2/26/Perimeter_plot_signal_strength.png
Wenn wir jetzt annehmen dass wir bereits eine Karte aller Feldstärken (Feldstärken-Karte) haben können wir ja viele (1000) Vermutungen anstellen wo der Roboter überall sein könnte (Partikel setzen) und die tatsächliche gemessene Feldstärke mit den Partikeln auf der Feldstärken-Karte vergleichen und jedem Partikel so eine Gewichtung geben (paßt gut bis paßt nicht gut). Da es viele Stellen gibt welche dieselbe Feldstärke haben (Ringe: http://wiki.ardumower.de/images/7/76/Perimeter_gradient.png) werden zunächst viele Partikel "überleben". Der Roboter bewegt sich und so werden auch die Partikel bewegt und es wird wieder verglichen. Langfristig werden aber nur Partikel überleben, welche die exakte Position des Roboter beschreiben.

Meine Simulation hatte so eine Feldstärken-Karte des Rasens schon (je stärke rot umso stärker die Feldstärke - blau zeigt Vorzeichenwechsel der Feldstärke an): http://wiki.ardumower.de/images/d/dc/Ardumower_perimeter_magneticfield.png
Natürlich muss man erstmal so eine Feldstärken-Karte haben und das wäre der nächste Schritt um die Simulation perfekter zu machen (Roboter fährt schleife ab, ermittelt Kontur und berechnet damit Feldstärken-Verteilung).

Gruss,
Alexander
 
jep, das passt.
trotzdem werde ich zunächst (ich hab ja zeit ;-) ) zunächst in eine andere richtung gehen : ich werde (nach rechnung) versuche machen, wie genau ich die endposition nach einer fahrtstrecke rein imu-sensorisch ermitteln kann.

aufbau : wir haben so kleine spielzeugroboter in der schule, atmega-prozessor und zwei dc-motoren, statt nem 3. rad ein tischtennisball.

sensorik : inkrementgeber an den motoren, kompass, gyros und acc.

grobe methode : wenn ich mit nem pid ein ziel anfahre (eher : eine richtung), und die regelabweichungen sauber aufintegriere, müßte ich innerhalb der sensorgenauigkeit den realen endpunkt rauskriegen. (bei nem tauchroboter geht das auch nicht viel anders, der hat weder gps noch irgendwelche fixpunkte.)

erste rechenaufgabe : gibts ne chance, mit den acc den schlupf zu ermitteln ? ich schau mal, was für ein postionsfehler rauskommt, wenn ich den maximalfehler eines acc über eine strecke 2 mal integriere.
 
Fehler nur mit acc: Wenn man einen Messfehler von 0.01 m/s^2 annimmt, hat man bereits nach 20 Sek. einen Positionsfehler von 2 Metern erreicht (wegen der doppelten Integration kummuliert sich der Positionsfehler quadratisch : 0.1 m/s)

Wenn man nur sehr kurze Intervalle betrachtet, hätte man eine gute Chance einen Schlupf zu erkennen.

Bin gespannt was Du herausfindest :)
 
kurzer bericht zum stand der dinge : mit nem asuro-roboter habe ich probiert, die ganze sensorik mal aufzubauen. also kompass, farbsensor, wlan und ultraschall. am arduino mega recht simpel, programmiert in c++ objektorientiert (funktionen als klassen geschrieben). läuft alles, aber die mechanik ist schrott. also zweiter versuch mit dem modellwägelchen vom ardumower-shop.

ziel : das ding fährt gerade bis entweder ultraschall oder farbsensor sagen daß die wiese aus ist. punkt merken. halbe strecke zurück, 90° drehen, wieder bis rand fahren. punkt merken .... damit entsteht ne karte im speicher, mit 10x10cm großen pixeln (reicht der speicher für so ein großes array ?). beim fahren (=mähen), auch schon vorher beim kartebasteln, werden die überfahrenen pixel = 1 gesetzt. so krieg ich ne info, wo noch nicht gemäht ist. immer da wo die meisten 0-er in einer richtung sind, fahr ich hin.

erster schritt : wie genau kann ich gradeausfahren ? als sensorik hab ich den kompass (neigungskompensiert) und die beschleunigungsmesser (ob die viel bringen fragt sich..). mal sehen, ich berichte wenn das ding fährt.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben