PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Autonomer Roboter, SLAM, dynamische Routenplanung -> Mindestanfordung an die Hardware



AlexJ
12.05.2012, 15:47
Seid gegrüßt, ich bin auf ein Projekt angesetzt worden und überlege mir ein grundsätzliches Konzept.
Und dafür brauch ich unbedingt ein wenig Erfahrungsaustausch, ob die mir vorliegende Hardware etwas taugt.

Danke an alle, die schon bis zu dieser Zeile gelesen haben.:cool:

Ablauf

Vorbereitung: (durch den Roboter zu ermitteln, aber ein Mensch kann helfend eingreifen)
Lokalisierung / Kartierung auf einer Strecke mittels LSM111 von Sick(Echtzeit Laser-Entfernungsmesser), Odometrie (Inkrementalgeber) und Gyroskop (braucht man noch mehr für SLAM ?)
--> Zunächst, gezieltes Erlernen einer ca. 300m (!) langen Strecke(Outdoor, direktes Sonnenlicht), diese ist ebenerdig mit ein paar klar erkennbaren (aus Sensor-Sicht) Objekten im Weg. (siehe Anhang)

Nach diesem Lernprozess muss dann der Roboter folgende Aufgabe völlig autonom bewältigen: (siehe Anhang "Strecken Skizze")
-Navigation von einem bekannten Startpunkt aus (auf der zuvor ermittelten Karte),
autonome Routenplanung zu einem Objekt das sich anhand seiner Farbe und Form(gelber Beutel) sich von der Umgebung abhebt
(eine monoculare Kamera wird von einem separaten System ausgewertet und teilt der Hauptrecheneinheit dann ggfs. eine Richtung mit)
Dieses gelbe Objekt liegt wahrscheinlich 300m weit vom Startpunkt aus entfernt auf einem ca. 10mx10m großen Platz (keine genau Position vorgegeben, dynamische Programmierung notwendig)
-Wenn dieses Objekt gefunden wurde --> es aufsammeln (das klappt schon)
-Mit dem Objekt die 300m zurück zum Startpunkt fahren

Grob gesagt muss der Roboter Navigieren/Aufsammeln und wieder Zurückfinden

Jetzt kommt meine Frage dazu:
Welche Platform/Recheneinheit/Steuerung muss man mindestens ansetzen, um vernünftig damit arbeiten zu können ? (bzw. die genannte Aufgabe lösen zu können)
(es sollten schon Leistungsreserven übrig bleiben, damit die Recheneinheit nicht am Limit betrieben wird für ggfs erweiterungen der Software)

Zur Zeit habe ich ein ausschließlich C-kompatibles Board liegen (Stellaris® LM3S2965 (http://www.ti.com/lit/ug/spmu024a/spmu024a.pdf))
"256-KB flash memory, 50-MHz operation" sind Kennwerte aus der verlinkten Doku

Das ausschließlich C genutzt werden kann, macht es schon schwer einen SLAM-Algorithmus zu finden.
http://openslam.org/tinyslam.html
TinySlam ist das einzige mir bekannte in C
Aber..
hier hat man tinyslam bereits ausprobiert (http://www.real-time.de/archiv/ez11/EZ11_Engelhardt.pdf) bei einer Kartierungsaufgabe mit einem deutlich leistunsfähigerem System (500MHz etc)
und trotzdem musste man den Algorithmus optimieren um das System echtzeitfähig zu bekommen (siehe obere Verlinkung)

Seh ich das richtig, dass ich mit meinen 50MHz mir dem Slam in die Haare schmieren kann ?

Mit dankbaren Grüßen, Alex

damfino
13.05.2012, 09:12
Hi Alex,

statt eines Gyros würde ich einen Kompass verwenden, finde das einfacher. GPS kann auch helfen wenn die Karte bekannt ist.

Ansonsten, es gibt ja nicht den SLAM Alogrithmus, sondern viele verschiedene Ansätze, die man so weit vereinfachen kann dass es auch mit einem langsamem System funktioniert.
Ich bastle mir gerade ein Atmega-fähiges System mit 8 Ultraschallsensoren in 45° angeordnet. Das vereinfacht schon mal die Auswertung und Datenmenge. Die Karte ist im Prinzip bekannt (Rasterkarte), aber die kleinen Hindernisse werden von selbst eingetragen. Es wird bei jeder Positionsbestimmung im Prinzip ein Kartenvergleich 5x5m der Ultraschallsensoren und der globalen Karte vorgenommen, bei >70% Übereinstimmung wird die neue Position übernommen. Und nach SLAM werden erst danach neue Hindernisse in die Karte eingetragen, bzw ungültige gelöscht. Ich mach das einfach über einen Zähler: >20x Hinderniss erkannt => wird berücksichtigt, kein Hinderniss an dieser Stelle, Zähler runtersetzen.
Ablauf bei mir: zuerst wird von der letzten gültige Position über Odometrie die aktuelle Position ermittelt, und dann in 1m Umkreis von dieser Position aus verglichen ob es mit den Ultraschallwerten eine bessere Übereinstimmung gibt. Wenn ja, wird die neue Position übernommen, wenn nein kommt der Vergleich mit den GPS Daten. So soll der Robi von eine beliebigen Startposition aus seine aktuelle Position ermitteln können.
Und das ganze läuft auf einem Atmega1284p mit 16Mhz. Programmiert ist es schon, der Robi braucht aber noch 1-2 Wochen bis er zusammengebaut ist.

LG!