Menü
Aktuelles
Von:
Filter

Rasenmäher mit Navigation

W

werner

New member
Hallo,
Mein Roboter ist seit Ende 2009 im Bau und mehr oder weniger in Betrieb, hier im Forum wurde er schon als damfinos Roboter erwähnt, dann beschreibe ich ihn besser selbst.
1) Aufbau/Mechanik: Aus Aluprofilen und Alu und Kunststoffplatten zusammengebaut. Mähteller ebenso mühsam aus Alu geschnitten, mit freistehender Abdeckscheibe wie beim Automower. Spart sehr viel Leistung ein.
Fehler: zu viel Alu beeinträchtigte die Schleifen Sensoren, Getriebe waren zu schwach
2) Funktionen: was hier besonders ist, ist die eingebaute Karte, es wird mitgezählt wo gemäht wurde und wo nicht, und es kann mit A* Navigation jeder Punkt angefahren werden.
Nachteil: steht und fällt mit der Positionserkennung, derzeit Odometrie mit Kalibrierung an Schleife, Kompass, GPS. Ultraschall wurde/wird getestet.
3) Soft/Hardware: alles in C geschrieben, derzeit 2 Atmega 1284, einmal wegen RAM für die Karte, der andere wegen 2 UART. Grundsätzlich sind zeitintensive Berechnungen in Tasks unterteilt. Alles wird 4x in der Sekunde berechnet, aber die Tasks sind leicht zeitlich versetzt, dazwischen bleibt genug Zeit für das restliche Programm.
4) Was fehlt:
100% verlässliches fahren zur Ladestation. Die Schleife kann man nicht ideal verlegen, zB müsste sie an einer Stelle mitten am Weg sein. Daher ist die Navigation ein Muss um eine brauchbare Stelle an der Schleife zu erreichen.
5) Was ist derzeit in Arbeit:
- Andriod APP als Monitor und Fernbedienung
- Ultraschallbaken mit Synchronisation über Bluetooth
- bessere Drehzahlmessung an den Antriebsmotoren, PI Regler wären schon implementiert.

Was erwarte ich mir hier? - neue Lösungsansätze für die Positionsbestimmung, mein Ansatz und Wunsch war immer alles am Roboter zu haben und nicht noch eine Programmiersprache zu lernen.

Was ich bieten kann: Erfahrung mit Odometrie und A*, sowie stabilem und leichten low-tec Fahrwerkbau mit Säge, Feile und Bohrmaschine.:)
 
Hallo Werner,

ich finde es besonders toll dass sich jemand meldet, der bereits viel eigene Erfahrungen mit der Software-Entwicklung von Mährobotern gemacht hat. Unser Projekt ist so angelegt, dass nicht eine Person alles machen muss. Wir erhoffen uns davon, dass wir weiter kommen als andere wenn sich jeder das heraussuchen kann, was er gut kann. Dann ist es natürlich sehr wichtig, dass die Ergebnisse so dokumentiert werden, dass sie jeder andere versteht und umsetzen kann.

Du bist herzlich eingeladen zum Fachsimpeln in vielen Themen hier im Forum :) - insbesondere gibt es auch Themen zur Positionserkennung basierend auf Odometrie, GPS und Kompaß mit Kalibrierung an Schleife (es gibt auch eine Simulation auf der Projektseite hierzu). Ein weiterführender Ansatz den wir verfolgen ist der sogenannte Kalman-Filter. Er ist mit etwas Theorie verbunden und wir hoffen es lohnt sich damit weiter zu beschäftigen. Es gibt auch einige Simulationen/Berechnungen mit SciLab hierzu.

Die Einteilung des Forums in verschiedene Themen ermöglicht uns (hoffentlich) alle Themen zur Mährobotik möglichst getrennt und mit vielen Leuten aus verschiedenen Fachrichtungen zu bearbeiten.

Gruss,
Alexander
 
Hallo Alexander,

wenn ich richtig sehe haben schon 2 Mitglieder einen Testaufbau durchgeführt, daher wäre es am einfachsten wenn diese die Grundlagentests weiterführen.
Ich habe in der Praxis unter den oben genannten Bedingungen massive GPS Probleme, etwa dass der Roboter Richtung Süden fährt, Odometrie das richtig berechnet, aber die GPS Positionen in die entgegengesetzte Richung nach Norden! wandern und so die errechnete Position falsch korrigieren.
Um das zu lösen arbeite ich an Ultraschallbaken, das ist aber leider noch sehr rudimentär im Arbeitszimmer aufgebaut.

DGPS wäre viel besser, da ich sonst an die 10 Ultraschallbaken benötige nur um den Bereich rund ums Haus abzudecken.

LG!
 
Hallo Werner,

man muss glaube ich statistisch an die Sache herangehen (der Kalman-Filter macht das so änhlich - siehe auch unter Kalmnan-Filter hier im Forum). D.h. Odometrie bekommt eine hohe Gewichtung. Wenn nun die durch Odometrie ermittelte Position zu stark von der GPS-Position abweicht, wird die Position schrittweise Richtung GPS-Position korrigiert. Dasselbe kann man für ein Auftreffen auf die Schleife machen bzw. mit der durch die Schleifen-Feldstärke ermittelte Position. Auch der aktuelle Kurs der Position wird mit einer Gewichtung durch den Kompaß korrigiert. Ziel ist eine Fusion aller Sensoren mit Gewichtungen. Die Gewichtungen richten sich nach der "Zuverlässigkeit" der Sensoren. Diese ist aber nicht konstant sondern ändert sich mit der Güte "Prediktion" des entsprechenden Sensors. Schau mal beim Thema "Kalman" hier im Forum vorbei, wir sind da leider noch am Anfang, aber das wäre ein Ansatz! :)

NACHTAG: D.h. es gibt ein "Modell" mit Modellparametern wie sich der Mäher überhaupt bewegen kann (Bewegungsgleichung, beispielsweise kann er nicht springen oder sich seitwärts bewegen, sondern nur mit einem bestimmten Wert in eine bestimmte Richtung fahren). Es müssen also "nur" noch für jeden Schritt die aktuellen Modellparameter geschätzt werden.

Da kommt der Kalman-Filter ins Spiel. Es wird beim Kalman aus der unmittelbaren Vergangenheit ermittelt wie gut die verschiedenen Sensoren diese Modellparameter vorhergesagt haben, um daraus eine Gewichtung der Sensoren für die unmittelbare Zukunft zu ermitteln. Dynamische Anpassung der Gewichtung quasi. Jeder Sensor selber hat ebenfalls eine "Bewegungsgleichung" (z.B. kann der Kompaß nur für Drehbewegungen beitragen, Odometrie hingegen hat eine andere Bewegungsgleichung) mit welcher die "Prediktion" durchgeführt wird und womit ermittelt wird wie gut diese war.

Natürlich verliert die Schätzung im Laufe der Zeit an Wahrscheinlichkeit (falls sie nicht durch anderer absolute Sensoren wie z.B. Schleifen, d.h. Sensoren mit höherer Güte korrigiert wird), aber mit so einer Schätzung erreichen einige Projekte/Publikationen (Roboter-Projekte mit Kalman-Prediktion) erstaunlich hohe Genauigkeiten :)

Gruss,
Alexander
 
Der vorige Beitrag sollte in eine andere Rubrik, steht jetzt auch dort, ein gekapptes WLAN hat da Verwirrung gestiftet...

Eine Gewichtung der Parameter hatte ich schon getestet, mit jemanden der das an Modellflugzeugen schon umgesetzt hatte. Problem war das GPS, ein Modellflugzeug ist schnell genug damit die neue Position weit genug von der alten entfernt ist um trotz aller Abweichungen einen Kurs und wahrscheinliche Position berechnen zu können.

Mit dem Rasenmäher ging das nicht, GPS ist nur ca 5m genau, daher der Roboter fährt 10m, und die Wahrscheinlichkeit für beide Positionen liegt gleich bei 50%. Die Zwischenpositionen schwanken auch so sehr dass man keinen Trend/Kurs berechnen kann.
Noch dazu kann es sein dass die GPS Position auf einmal um 10m springt und die nächsten Minuten auch so bleibt, welchen Daten vertraut man dann?
Spätestens beim ersten Kurswechsel (Schleife/Hinderniss) versagt dann die Trendberechnung, sie muss neu starten, benötigt einige Datensätze um den nächsten Trend zu berechnen, und steht inzwischen schon am nächsten Hinderniss an. Etwa die Situation wie hier im Simulator wenn er links unten festhängt.

Mein Roboter fährt 40cm in der Sekunde, im gleichen Zeitraum kann das GPS um 10m springen, diese Unterschiede sind zu groß, wenn man das GPS auf
 
Ich habe meinen alten Schriftverkehr bezüglich Parameterschätzung durchsucht und weiss wieder die Ursache des Scheiterns:
Mein Roboter fährt mit Variabler Geschwindigkeit, wenn das Gras plötzlich dicht ist, wird sofort auf minimum geregelt, ansonsten wird langsamer beschleunigt/verlangsamt. Damit kam die Mathematik der Positionsvorhersage nicht zurecht. Kalman Filter benötigt aber Schätzungen die ohne große Sprünge verlaufen.

Vielleicht gibt es einen besseren, einfacheren Filter als Kalman?
 
Hallo Werner,

der Roboter kennt die Geschwindigkeit (z.B. ermittelt über Odoemtrie) und das kann der Kalman-Filter berücksichtigen.

Damit wir zu einem brauchbaren (später optimalen) Filter kommen, muss meines Erachtens so vorgegangen werden:

1. Realistische Daten ermitteln. D.h. man steckt einen Pfad ab, dessen exakte GPS-Koordinaten bekannt sind (z.B. für NRW über TIM-online ermittelt). Dann fährt der Roboter diesen exakt ab (Schleifenmodus) und sammelt dabei Daten (vergangene 1/10 Sekunden, GPS, Odometrie, Kompaß etc.), z.B. CSV-Format
1/10sec,lat,lon,wheelleft,wheelright,angle
1/10sec,lat,lon,wheelleft,wheelright,angle
1/10sec,lat,lon,wheelleft,wheelright,angle
usw.

2. Jetzt beginnt der schwierige Teil - mit Hilfe einer Simulationsumgebung (z.B. scilab, siehe auch hier ) wird nun der Filter gebaut und optimiert - Das Ziel ist, dass der Filter die Position so vorhersagt, dass diese einen minimalen Fehlersumme zur exakten Position aufweist.

Ich denke nur so kommt man zu optimalen Ergebnissen (mit vielen Versuchen innerhalb kürzester Zeit), die jeder Nachvollziehen kann. Punkt 2 werde ich gerne übernehmen, Punkt 1 sollten am Besten so viel Leute wie möglich durchführen (je mehr Testdaten umso besser).

Gruss,
Alexander
 
Könnte Datenlogging relativ einfach aktivieren, gibt aber 2 Punkte die zu beachten sind:
GPS: ist auf mein Grundstück umgerechnet, Nullpunkt im SW, es wird nur ein Teil vom NMEA Datenstring ausgewertet.
Odometrie: ist ungenau und benötigt 1s damit genug Ticks pro Rad da sind ( 1 Tick =39mm Weg).

Loggen könnte ich:
pos_x_odo, pos_y_odo alle 1
pos_x_gps, pos_y_gps, richtung kompass alle 250ms

Leider geht das Bluetooth Modul nicht mit dem USB-TTL Konverter am PC, daher muss alles ins 1kB kleine EEPROM, das reicht so nur für 25s Fahrt.

Hast Du vielleicht eine funktionierende Scilab Vorlage zum probieren? Ich würde zB probieren einfach die GPS Position, mit den HDOP Werten zur Gewichtung und dem Kompass zusammen zu mixen, daher nur nur die bekannten absoluten Informationen, und die relativen Informationen wie Odometrie zu ignorieren. Einfach mal aus Interesse, ob das vielleicht schon gute Referenzwerte ergibt.

LG!
 
@Werner:
GPS: das kann man umrechnen, also kein Problem - wichtig wäre, dass man den exakten Pfad kennt (möglichst auf 10cm genau)
Odometrie: muss man schauen, ob brauchbare gute Ergebnisse erzielbar sind, man hat ja noch Kompaßdaten

25s sollte vermutl. reichen - wichtig wäre dann vermutl. dass man dieselbe "Testfahrt" viele Male durchführt (z.B. 10), damit genügend Daten zusammen kommen.

Zum probieren habe ich bisher nur sehr abstrakt gehaltene Simulationen geschrieben (befinden sich hier in den Anhängen: http://www.ardumower.de/index.php/de/forum/navigation-odmetrie-gps/176-kalman-filter-simulation), welche aber ohne Einarbeitung in die jeweils angegebene Literatur vermutlich nicht gleich nachvollziehbar sind. Auch ist nicht ausgeschlossen, dass da noch Fehler drin sind. Ich werde mich mit dem Kalman-Filter demnächst noch weiter auseinandersetzen und realistische Daten wären ein großer Vorteil.

Gruss,
Alexander
 
Hallo Werner,

mir ist noch eingefallen dass man HDOP noch mit loggen sollte. Und evtl. besser die Odometrie Ticks (links/rechts). Man könnte evtl. ja schon alle 125ms den Filter einfließen lassen und dann ist es immer besser, je höher die Filter-Rate umso besser (für die Genauigkeit sorgt der Filter selber - wichtig ist dass die Daten mit der Frequenz vorhanden sind wie sie gemessen werden, das dürfen dann ruhig Rohdaten sein...)
 
Hallo Alexander,

Ich werde demnächst dieses Datenlogging einbauen, es gibt schon einen geordneten Datentransfer mit allen möglichen Parametern zum Nebenkontroller, da werden noch die Odometrie Ticks angehängt und fertig. Mir ist gerade eingefallen das der Nebenkontroller jetzt neu der Atmega1284 mit 4kB EEPROM ist, da kann man mehr Daten speichern :)

Datensampling geht nur alle 250ms, es basiert alles auf diesem Intervall, das zu ändern ist zu aufwändig. GPS geht auch nur mit maximal 4Hz.
Odometrie Ticks werden jede Sekunde nach der Positionsberechnung auf Null gesetzt, daher werden im Log auch die Zwischenwerte zu sehen sein.
Kompassdaten sind vom kalibrierten und 3d kompensierten Kompass, der macht das selber.

Ich könnte den Roboter 10m weit auf einem Betonweg fahren lassen, da gibt es weniger Störungen durch den unebenen Boden, und normalerweise guten GPS Empfang.
Es gäbe auch eine andere Route, wo der GPS Empfang praktisch immer Aussetzer hat.
Schleifenfart ist bei mir sehr uneben, die Räder drehen oft durch, das kann nur zum Testen eines Algorythmus verwenden, aber nicht zum erstellen.

LG!
 
Der Code der Kontroller ist angepasst, wenn es morgen nicht regnet kann ich die erste Messfahrt durchführen. Wird dann noch etwas Basteln notwendig sein um aus dem Hex File ein schönes Excel zu bekommen.
Mitgeloggt werden die Rohdaten GPS, Hdop, Odometrie Ticks, Kompass, und als Vergleich die Position nach meiner aktuellen Filterung und Berechnung.

LG!
 
Hier das erste Datenlog, leider habe ich gerade Probleme mit dem Robi (Mikroschalter für Bumper), so dass ich im Moment nicht mehr Daten sammeln kann.
Die Ticks der Odometrie muss ich mir noch genauer ansehen, da scheint etwas nicht ganz zu passen.

Fahrt war vom Startpunkt 750/900 nach für 9m nach Süden, Kompasskurs ist korrekt. Dann an der Schleife angestanden und die Position in y um 547cm korrigiert. Soweit korrekt, der Versatz der GPS Daten ist beachtlich, am Display wurde dazu hdop von 1 bei 7 Satelliten angezeigt.

Vielleicht kann man daraus schon erste Schlüsse ziehen.

Da ich es einfach nicht als Anhang hochladen kann, hier:
Datenlog.xls

LG!
 
Hallo Werner,

die Odometrie-Ticks sind in der Tat etwas wenig - damit kann man glaube ich keine präzise Vorhersage machen. Müsste Dein Encoder nicht mehr/bessere Informationen liefern oder hast Du schon mal daran gedacht, an dieser Stelle zu optimieren.

Gruss,
Alexander
 
Ich hab den Code fürs mitschreiben der Ticks geändert da auffällig ist dass die Werte nicht synchron gespeichert werden. Aber bei max 27U/min und 14 Ticks pro Umdrehung kommt nie eine große Zahl raus. Ich erwarte 3-7 Ticks pro Sekunde bei normaler Fahrt, Drehungen werden anders gerechnet.
Wenn man pox_y der Positionsberechnung hernimmt, reicht es für eine ausreichend genaue Berechnung, was sind schon
 
@Werner: danke - ich werde selber auch noch Messungen durchführen und dann schauen wir mal was der Filter dazu sagt. Der Filter lief mit GPS allein schon so gut da ein 5 Hz GPS-Signal angenommen wurde und zusätzlich auch noch eine statistische "Normalverteilung". Das wird in der Realität nicht der Fall sein, daher sind reale Meßreihen so wichtig. Den Schlupf könnte der Filter zu einem bestimmten Grad über Kompaß/Beschleunigungssensor/Gyro herausfiltern, jedenfalls schafft er es in der Simulation (http://www.ardumower.de/index.php/de/forum/navigation-odmetrie-gps/176-kalman-filter-simulation#1721).
 
Wenn die Kollisionsschalter umgebaut sind kann ich die nächsten Messreihen durchführen.

GPS war aufs maximum mit 4Hz eingestellt, wenn man das Log ansieht haben sich die Werte aber eher nur in weit größeren Intervallen geändert. Vielleicht kann mein Modul nicht wirklich schneller die Position berechnen.
Der Kompass (CMPS10) braucht normal 640ms für einen kompletten Sampling Durchgang für die Neigungskompensation, man müsste also immer eine Pause einlegen wenn man 100% korrekte Daten benötigt.
Updates of the tilt compensated heading occur at 75hz with the data is filtered by means of a 45 sample buffer, this means a complete refresh of the buffer is achieved every 640ms. Raw data from the magnetometer and accelerometer is available every 13.3ms.
Zum Vergrößern anklicken....

Aber zumindest sind es reale GPS und Kompass Messwerte, es sind die einzigen absoluten Messwerte die man haben kann, deswegen würde ich diese mehr berücksichtigen als zB Gyros die eine interne Drift haben.

LG!
 
Eine neue Testreihe ist unter Datenlog.xls als Tabelle 2.

Wieder mit Versatz am Startpunkt der später an der Schleife korrigiert wird.
Was mit den Ticks nicht passt muss ich mir ansehen, da gehen Daten verloren. Er fährt auf alle Fälle richtig, mit der Positionsbestimmung bin ich zufrieden, man erkennt man Ende sogar den Anfang einer Spiralfahrt. Zuvor fährt er nach Schleifenkontakt zurück, die errechnete Position passt exakt.

Daher die Ticks vorerst ignorieren, aber man kann GPS, Kompass, und errechnete Position verwenden.

LG!
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben