aufwendiges Open Source Projekt

[Black Dragon]

Hallo zusammen,

wir sind drei Informatikstudenten(ferner jede Menge Leute, die uns unterstützen würden) und planen ein Open Source Projekt, womit der Schwerpunkt natürlich auf einer komplexen Programmierung liegen wird.
Unser Roboter soll erstmal zwei gegenüberliegende, durch Schrittmotoren angetriebene, Räder haben. Ferner soll es ein drittes frei bewegliches, nicht angetriebenes Rad geben. Praktisch so wie beim ER1 von Evolution, mit dem schon einige Erfahrung vorhanden ist.
Ferner kommen wahrscheinlich zwei Kameras drauf um Stereosicht zu ermöglichen, Akku und Rechner mit W-lan, USB.
Da schon Erfahrungen im selbst bauen von Motorsteuerungen vorhanden sind und notfalls noch ein Elektrotechniker-Vater, gehen wir davon aus, dass die Elektronik klappen wird.
Im Moment fragen wir uns wie wir das Fahrgestell(Ein besser Begriff fällt mir gerade nicht ein) herstellen sollen.
Ziel soll es sein, dass der Roboter möglichst genau gearbeitet wird. Dies betrifft die Positionen der Räder und der Kameras und vielleicht später der sonstigen Sensoren.
Ich denke es wird hier so ziemlich jedem klar sein, dass es bei der Bildverarbeitung praktisch ist, wenn man nach einem Fahrbefehl genau weiß wo die Kamera gelandet ist.
Ferner soll es möglich sein den Roboter zu reproduzieren, also genau nachzubauen.
Wir dachten an Plexiglas, doch ich sehe uns schon tagelang herum Feilen und Schmirgeln. Und ob dann ein genaues Duplikat gelingt ist auch fraglich.
Hätte vielleicht jemand einen Tipp für uns?

[logbuch]

Genau gearbeitete Bauteile die auch reproduzierbar sind, das geht am einfachsten, wnn ihr die CNC-Fräsen/Lasercutten lässt. Beim Lasercutten ist der Vorteil, dass die Teile nichtmehr nachbearbeitet werden müssen.

mfg logbuch

[pacer_one]

Du könntest einfach immer 2 Teile gleichzeitig fertigen.
Die Frage ist aber, wie genau muss es den werden und wo muss es genau sein? Welche Funktion des Roboters benötigt diese Genauigkeit.

Was soll der Roboter später machen? Ich nehme mal an autonom navigieren mit Hilfe seiner Stereo-Kamera. Warum dann aber Schrittmotoren, gibts dafür Gründe?

[Black Dragon]

@logbuch:
Wir haben auch drüber nachgedacht ob wir da jemanden kennen würden, der uns das fräsen könnte, leider ohne Erfolg.
Ich weiß zwar nicht wie viel das kosten würde, wenn wir uns an eine Firma wenden würden, doch letztendlich müssen wir das ja von unserem BAFöG/Nebenjobs bezahlen und es summiert sich.
Vielleicht bauen wir unseren ersten Versuch einfach auf Holz.

@pacer_one:
Also die angetriebenen Räder sollten parallel sein und der Abstand zwischen ihnen, sowie die Mitte, bekannt(besser natürlich vorbestimmt). Dann sollen Positionen der Kameras bezüglich den Rädern und zueinander genau bestimmt werden.
Schrittmotoren sollen genutzt werden damit die Fahrbefehle richtig umgesetzt werden z.B. "fahre 4 Meter gerade aus"(und zwar wirklich gerade) oder "drehe 90° nach Links". So soll auch die relative Position möglichst genau für die Bildverarbeitung bestimmt werden.

Klar ist nichts perfekt, deswegen muss so ein Roboter auch kalibriert werden. Doch das sollte sich in Grenzen halten.
Also den ER1(1,8° Schritte), den kann man ohne regelmäßig zu kalibrieren folgende Strecke fahren lassen(Maße geschätzt, ich hatte da nur zugesehen): 5m geradeaus, 90° links, 2m geradeaus, 90° links, 5m geradeaus, 90° links, 2m geradeaus, 90° links. Und das Teil steht am Ende nur wenige cm von seiner Startposition entfernt.

[kyodai]

Hi,

du hast es mit "möglichst genau" schon ganz gut getroffen. Wenn du nämlich anhand der radposition messen möchtest ist genau das der Knackpunkt.


Hier hat sich gerade ein andere Forenuser monatelang damit abgemüht, denn er hatte es sich zur AUfgabe gesetzt den Roboter zum kartografieren des Raumes zu verwenden. Er hatte die ursprünglichen Räder verworfen und dann auf Präzisionsarbeit gesetzt. Ach was rede ich da, schau es dir doch mal selber an, er hat nicht nur eine sehr exakte beschreibung des Aufbaus und der Platinen bereitgestellt, sondern auch den Sourcecode der pfiffigen Raumberechnung gleich mitgeliefert. ich bin mir sicher daß die das helfen wird.

https://www.roboternetz.de/phpBB2/viewtopic.php?t=52226

[homedom]

Hi,
also mit Bildbearbeitung etc kann ich noch nicht dienen, aber ich glaub da seit ihr die Experten drin. Wie soll der Roboter denn aussehen? Und warum muss er dupliziert werden können? Serienproduktion?
Das mit dem genau ist so ne Sache. kyodai hat ja grad auf mein Projekt verlingt. Also mit Schrittmotoren seit ihr denk ich mal gut bedient. Jetzt kommt es darauf an, dass der Radius den die Räder einschließen (hoff man versteht was ich mein) und der Radius der Räder selbst so berechnet wird, dass man mit einer bestimmten Anzahl an Schritten eine genau definierte Strecke zurücklegt. Wenn ihr euch meine Doku anschaut wisst ihr denk ich was ich mein. Vlt kannst du dich ja mal mit mir in Verbindung setzten wegen des Chassis. Besitz eine CNC-Fräse. Bin zwar noch nich der Profi im CAD/CAM, aber ich sammel immer mehr Erfahrung darin.
gruß, homedom

[Gert11]

Hi Black Dragon,

Fräskapazität zum "Selbstkostenpreis" könnten wir zu Verfügung stellen (Großraum Köln Bonn) !
Was mich interessiert: Was habt ihr bisher konkret zur Bildverarbeitung, da ich in dieser Richtung auch weitermachen möchte?
Gruß Gert

[Black Dragon]

@kyodai: Danke nochmal für den Verweis. Das Forum ist schon sehr voll, ich konnte bisher die meisten Projekte überfliegen, so hatte ich bereits die Bilder gesehen, doch die Ausarbeitung übersehen.

@homedom: Die Idee ist es, dass sich möglichst viele Leute unseren Roboter nachbauen können(einschließlich uns selbst, wenn mal was Geld über ist), nur so kann das Projekt anwachsen. Einer für alle reicht nun mal nicht. Wobei es natürlich immer noch fraglich ist wie oft der erste Versuch dupliziert wird, denn es werden sich schnell Verbesserungen finden.
Schon mal Vielen Dank für dein Angebot, wir werden dich bestimmt schon bald mit Fragen löchern.

@Gert11:
Auch dir Danke.
An Bildverarbeitung haben wir an sich nichts eigenes. Dafür haben wir durch die UNI jede Menge Erfahrungen in dem Bereicht, bzw. einschlägig bekannten und vielmals offen implementierten Algorithmen gesammelt(durch Anwenden sogar). Eigenes in Richtung Bildverarbeitung habe ich zwar auch schon am Fraunhofer Institut entwickelt, doch für unsere Zwecke nicht nutzbar. Jedoch recherchieren ich seit längerem für ein Diplomarbeitsthema in Richtung Modellbildung/Bildverarbeitung. Wenn es nach mir geht, wird es wohl viel mit SLAM zutun haben. z.B. http://www.youtube.com/watch?v=uXqDA4do_s0&feature=related Hier wird keine stereo Kamera genutzt, die Kamera ist frei beweglich, wird teilweise unruhig geführt, es stehen keine weiten Daten zur Verfügung und es ist RealTime. So einen Ansatz kann man natürlich leicht mit der Odometry eines Roboters fusionieren um bessere Ergebnisse zu erhalten.
Letztendlich sind wir gerade erstmal beim Planen, immerhin braucht das Projekt eine Struktur, praktisch eine API. Nach der Bildverarbeitung soll es natürlich weitergehen, dann geht es um Entscheidungsfindung und Planung. In der Hinsicht haben wir schon einiges gemacht.

[kyodai]

Die Frage ist was genau du erreichen willst. Ich dachte erst bei Bildbearbeitung daß du einfach nur ein paar pics zur Unterhaltung sammeln willst.

Wenn es dir rein um SLAM geht - also erstellen einer map und definition der Position des Roboters in dieser, dann sollte dir homedoms ansatz an sich schon langen, denn er hat ja bereits praktisch bewiesen daß die Kartographie mit seinem Aufbau schon erstaunlich exakt möglich ist.


Hier geschieht die Kartografie einfach über "abrollen", also exakte Messung der Bewegung des Roboters. Hierbei brauchst du weder Bildbearbeitung noch eine Kamera.

Das Youtube Video zu dem du verlinkt hast zeigt einen anderen Ansatz mit gleichem Ziel, hier ist der Fokus aber in der Veränderung der Bilddaten und berechnen der Bewegung anhand von Fixpunkten im Bild. Beide Ansätze sind sicherlich pfiffig und realisierbar, aber meiner EInschätzung nach ist die methode mit der "Erkennung von markanten Punkten" im Bild" sehr viel fehleranfälliger. Ich habe mit ähnlichen techniken experimentiert um bewegung im Bild zu erkennen und das ganze funktioniert toll mit einer festinstallierten kamera innen, aber außen bei Wind und in der Bewegung ist es unmöglich, da die Bilddaten sich zu unerwartet ändern. Am schluß war die Software schon wirklich sehr gut, aber jeder Windhach der die Äste eines Baumes leicht bewegen lässt macht die Daten total kaputt und jedes Grad neigung ebenfalls. Es ist sicherlich möglich was die Studenten da in dem Youtube Video vorhaben, aber in der Praxis wird es sicherlich schwierig mit der Methode, schon in der Dämmerung oder bei flackerndem Licht fängt die Methode total an zu spinnen.Der Ansatz von Hoedom ist sicherlich auch nur sehr bedingt für unebenes terrain draußen zu gebrauchen aber meienr Meinung nach sehr viel unaufwändiger, fehlerunanfälliger, preiswerter und leichter zu realisieren.

Vielleicht gibt es aber noch mehr wege und möglichkeiten zum Ziel zu kommen. Vielleicht ist es sogra möglich beide technologien zu kombinieren - aber das bedeutet natürtlich noch mehr Aufwand.


bevor du jetzt schon 100 cnc gefräste Bodies bestellst - Tip aus der Praxis - Erst einmal einen funktionierenden "Proof of concept" bauen, dann viele Leute mit den ersten Prototypen testen lassen und die verbesserungsvorschläge in version 2.0 einfließen lasssen, testen und dann version 2.0 in Massen produzieren lassen. Ansonsten kann es passieren daß du am Ende bemerkst daß dein 1000 mal hergestellter Body eiegntlich etwas anders sein müßte um optimal zu funktionieren und dann wandelt es sich in Frickel-ware.

[Black Dragon]

Wie schon erwähnt es soll später auch um "Entscheidungsfindung und Planung" gehen. Auch sollen später mal mehrere Roboter miteinander interagieren(globale Planung). Es ist nicht ohne weiteres möglich größere Räumlichkeiten(oder bei so einer Türschwelle wie ich sie zwischen Flur und Wohnzimmer habe) allein durch Odometry abzutasten, die Lokalisierung muss laufend korrigiert werden.
Das youtube-Video ist gewiss von keine Studenten mehr, gibt zwei Gruppen, die es im bereich von SLAM soweit gebracht haben und soweit ich weiß haben schon alle ihren Dr. die publizieren. Es ist nun mal der aktuelle Stand der Technik. Es geht hier ja auch schon um Objekterkennung und genau das würde mich sehr interessieren.
Wenn man außer Hause ist, dann kommt man mit SIFT in einer Großstadt gut klar.
Letztendlich möchten wir ja etwas komplexes machen und Kameras sind der Stand der Technik(auch wenn andere Sensoren natürlich ihre Berechtigung nicht verlieren). Gutes 3D mapping, mit Objekterkennung, geht nur mit Kameras und wie man an dem Video sieht, ist selbst der fahrende Roboter nicht so wichtig.
Wir möchten auch nicht ohne Ende Roboter bauen, ist für uns ja eher Mittel zum Zweck(wobei das Hardware nahe Arbeiten uns auch interessiert, da dies in der UNI zu kurz kommt). Ein einziger, jedoch genau gearbeiteter und mit der Option auf Vervielfältigung reicht uns für den Anfang.

[homedom]

Hi,
hab dann noch nein paar Fragen die mich interessieren. Soll da ein ganzer "rechner" drauf, oder nur ein Mikrocontroller (wohl eher ARM) mit Linux? Wie groß soll das ganze werden? Und in welchem Zeitraum soll das realisiert werden?
gruß, homedom

P.S.: Weiß net ob dus gesehen hast,hast ne PN von mir

[Black Dragon]

also die Tendenz geht zu Debian.
drauf soll aus kostengründen sowas(ist überhaupt nicht endgültig, haben uns das erstmal rausgesucht um mit einer Größe und Leistungsaufnahme rechnen zu können) wie ASRock A330GC mit 2*Intel Atom 330. Da wären wir mit Speicher bei ca. 90 Euro. Ferner ist es natürlich interessant echte Parallelität zu haben. Wir sind für Vorschläge gern offen.

Einen Zeitplan haben wir nicht erstellt. Wer Zeit hat, der macht eben voran.
Zeitraum schon gar nicht, so ein Projekt endet wohl nie, denn wenn auch mal die Hardware mal komplett erneuert werden sollte, die Software wird fortentwickelt.

[Black Dragon]

Hallo zusammen,
ich würde gern noch mal beim Antrieb Rat einholen, da wir bisher nur auf die Erfahrungen von homedom zurückgreifen könnten, bei dem ich mich nochmal an dieser Stelle bedenken möchte.
Wir wollen uns beim Fahrgestell am ER1 orientieren, es sollen also zwei Räder von Schrittmotoren angetrieben werden. Aktuell schätze ich, dass unser Roboter mit allem um die 5 kg wiegen wird. Der Roboter soll einfach und günstig nachzubauen sein. Dabei sollen die Lebensdauer, sowie die Genauigkeit, mit der die Fahrbefehle ausgeführt werden, nicht auf der Strecke bleiben.
Für beide Vorschläge gilt: In diese weißen Blöcke sollen noch Kugellager rein. Mitten durch kommt noch jeweils eine Bodenplatte. Beim zweiten Vorschlag müssen dann natürlich zwei Löcher für Rad und Zahnrad rein.

Vorschlag mit Zahnriemen:
http://www.homedomsoftware.de/uploads/OpenRobotAntrieb1.JPG
http://www.homedomsoftware.de/uploads/OpenRobotAntrieb2.JPG

Vorschlag ohne Zahnriemen:
http://blackdragon.digital-dogz.com/roboter/OpenRobotAntrieb_direkt.jpg
http://blackdragon.digital-dogz.com/roboter/OpenRobotAntrieb_direkt_oben.jpg
http://blackdragon.digital-dogz.com/roboter/OpenRobotAntrieb_direkt_rechts.jpg

Weitere Detail können gern diskutiert werden. Z.B. das Rad besser nach außen legen oder Zahnrad und Rad direkt aneinander.

Ich weiß schon mal, dass der erste Vorschlag wohl nicht so ganz günstig ist, jedoch auch aus Erfahrungen mit dem ER1, dass das eine super Kraftübertragung ist mit absolut 0 Spiel und langer Lebensdauer.
Würde das auch für den ersten Vorschlag gelten?
Es gibt ja diverse Profile für Zahnräder und Zahnriemen/Zahnriemenräder, hat da jemand einen Tipp zu?

Danke

[HannoHupmann]

1) Wer Plexiglas verwendet ist selber schuld bzw. hat das Forum nicht aufmerksam gelesen.

2) Zahnriemen müssen immer vorgespannt werden. Meistens über Spannrollen. Kleine Winkelfehler zwischen den Achsen von Motor und Rad werden vom Zahnriemen ausgeglichen. Es ist denkbar die Achse des Rades zu Federn.

3) Zahnräder müssen exakt positioniert werden zueinander. Kleine Abweichungen bei den Achsen führen zu unerwünschter Reibung und Spiel (es war ja Genauigkeit gewünscht). Vorteil gegenüber Zahnriemen ist, dass der Motor auch um 90° gedreht montiert werden könnte.

Für Antriebskonzepte empfehle ich die Modellbausparte die hat bereits sehr gute Antrieb-Rad-Verbindungen im Angebot.

Jeder Zahnriemen hat ein anderes Profil weil es für einen anderen Einsatzzweck vorgesehen ist.

Und weils so schön ist noch einen kleinen Einwand zur Genauigkeit. Ich kenne kein Lebewesen welches besonders genau oder exakt navigiert und ich sehe auch bei einem Roboter nicht die Notwendigkeit dazu.

[Ceos]

mangelnde genauigkeit stellt gesteigerte ansprüch an komplexe korrekturalgorithmen, die jedoch verbrauchen rechenleistung und sind daher meist unerwünscht ^^ ... lebewesen arbeiten extrem stark parallelverarbeitend daher brauchen sie keine exakte steuerung, wenn die fehlerkorrektur so leistungsfähig ist

ich würde bei der konzeptionierung des antriebes dringend die konzeptionierung der bewegungs-sensoren mit einplanen (was ich damit meine sind odometrie, GPS, ACCs, oderoderoder ... eben alles um die bewegung des roboters zu beobachten)

denn diese daten müssen zuverlässig sein!!

schlupf an den rädern kann durchaus erhebliche probleme beim bblinden navigieren verursachen ... mit meinem asuro habe ich zum beispiel messdaten mit einem elektronischen kompass korrigiert um die exakte position nach dem fahrvorgang aufzuzeichnen

ohne manuelle neupositionierung konnte ich den asuro so auf einem 2x2 meter feld ungefähr 30 mal von einer beliebigen position zur anderen navigieren, bis die virtuelle mit der realen position nicht mehr übereinstimmte

ohne kompensation stand der asuro meist schon nach dem 5ten mal irgendwo aber nie da wo man es laut odometrie erwartet!

[Black Dragon]

1) Wer Plexiglas verwendet ist selber schuld bzw. hat das Forum nicht aufmerksam gelesen.

Da habe ich wohl etwas übersehen, hab paar Projekte mit Plexiglas mir angesehen + den rn-wissen Artikel. Leider wurden nicht sonderlich Nachteile gennant, werde mich aber nochmal umsehen



3) Zahnräder müssen exakt positioniert werden zueinander. Kleine Abweichungen bei den Achsen führen zu unerwünschter Reibung und Spiel (es war ja Genauigkeit gewünscht). Vorteil gegenüber Zahnriemen ist, dass der Motor auch um 90° gedreht montiert werden könnte.

was versteht man hier unter Abweichungen? Bzw. wie schwer ist es die notwendige Genauigkeit zu erreichen?




Und weils so schön ist noch einen kleinen Einwand zur Genauigkeit. Ich kenne kein Lebewesen welches besonders genau oder exakt navigiert und ich sehe auch bei einem Roboter nicht die Notwendigkeit dazu.
Da muss ich mich Ceos anschliessen. Durch die Parallelität im menschlichem Gehirn ist die Rechenleistung eines Roboters ein Witz. Bisher gibt es keine autonomen Roboter, die nur im Ansatz fähig wären, das zu Leisten, was jeder Mensch kann, da sollte man sich keine Steine in den Weg legen durch schlecht ausgeführte Bewegungsbefehle.

[Hessibaby]

Mit dem "Dreirad", also zwei angetriebene Räder und Schlepprad wirst Du niemals reproduzierbare Fahrwege erzielen. Alleine der Schlupf in den Zahnflanken ( egal ob Riemen oder Rad ) bringt bei jeder Drehbewegung einen Abrollfehler, da Du nicht immer auf der virtuellen Mitte des kurveninneren Rades drehst. Ohne Erfassung der Soll-/Istdifferenz geht´s nicht.
Die größte Genauigkeit erzielst Du mit einem absolut symetrisch aufgebautem knickgelenktem Fahrzeug.

[HannoHupmann]

Die Alternative heisst Lexan und ist Plexiglas um längen überlegen in den Materialeigenschaften.

Jetzt zur exakten Navigation. Da habt ihr was falsch verstanden. Ich sehe keine Notwendigkeit für einen Roboter absolut genau zu navigieren, für mich würde eine relative genauigkeit völlig ausreichen.

Aber jeder darf das so machen wie er meint.

[Black Dragon]

@Hessibaby: Dass die Hardware kalibriert werden muss ist klar.

@HannoHupmann: Letztendlich ist es - wie so oft - eine Frage des Preises. Auf den ersten Blick auch eine der Beschaffungsmöglichkeiten, da der Wunsch besteht, dass sich jeder einfach den Roboter nachbauen kann und Plexiglas selbst mal eben bei ebay zu bekommen ist.



Klar ist nichts perfekt, deswegen muss so ein Roboter auch kalibriert werden. Doch das sollte sich in Grenzen halten.
Also den ER1(1,8° Schritte), den kann man ohne regelmäßig zu kalibrieren folgende Strecke fahren lassen(Maße geschätzt, ich hatte da nur zugesehen): 5m geradeaus, 90° links, 2m geradeaus, 90° links, 5m geradeaus, 90° links, 2m geradeaus, 90° links. Und das Teil steht am Ende nur wenige cm von seiner Startposition entfernt.
Und das möchte ich in etwa auch gern haben. Der ER1 hat übrigens eine Auflösung von ca. 0,248mm beim Vorwärtsfahren, ich würde mich auch mit weniger zu frieden geben.

EDIT:
Hab nochmal geschaut, an Material gibt es ja einige Möglichkeiten. Alu, Makrolon(soll das gleiche wie Lexan sein? Auf jeden Fall bessere Bezugsmöglichkeiten) gibt es z.B. auch noch. Ich denke wir werden uns mit diesem Thema noch beschäftigen.
Jedoch weiß ich immer noch nicht welche Antriebsidee insgesamt besser ist.(Besser zu verwirklichen, Preis/Leistung, Verschleißfester, kein Spiel)

[pacer_one]

ich glaube ihr hängt euch zu sehr an der Genauigkeit auf.
Der Schlupf der zwischen Fahrzeug und Boden auftritt, dürfte nicht zu vernachlässigen sein. Wenn ihr schon eine Kamera einbaut, könntet ihr diese doch nutzen um Ziele anzupeilen und den Kurs zu korrigieren.
Und da ihr ja komplex programmieren wollt, wäre es ja ein Armutszeugnis, wenn ihr durch höchst genaue Teile (die teuer sind) um eine Positionsreglung herum kommen wollt

Ich würde vorschlagen ihr baut erst mal einen Prototypen auf und testet diesen. Dann bekommt ihr Erfahrungswerte. Da könnt ihr dann auch Plexiglas nehmen. Und wenn ihr die Anbauten (Motoren etc.) justierbar macht, könnt ihr eure Genauigkeit 'Einstellen'.

[Black Dragon]

Ich habe langsam das Gefühl, dass ich mich erklären muss:
- Wenn wir ein Fahrzeug, das vornehmlich für den Außeneinsatz gedacht wird, dann nehmen wir ein absolut symetrisch aufgebautes knickgelenktes Fahrzeug. Da wir aber erstmal ganz viel programmieren müssen und laufen testen werden, ist es einfach(und warm) zuhause zu bleiben. Aufgrund der Enge sollte sich dort der Robot möglichst auf der Stelle drehen können und bei einem Kettenantrieb hätte ich da diverse bedenken z.B. haben wir hier so einen wuscheligen Teppich, also lieber ein "dreirad".
- klar gibt es Schlupf und ich finde das sehr interessant, denn in der UNI ist der Boden so extrem griffig, dass wir uns damit nicht beschäftigten mussten(aber auch nicht konnten, es ist nicht möglich alle Probleme auf einmal zu lösen). Ich denke man kann mit einer Beschleunigungsrampe(Wie wir wie selbstverständlich eingeplant haben) da einiges erreich und ich möchte sowieso nicht, dass der Roboter mir bei jeden Fahrbefehl einen Burnout auf dem PVC Boden hinlegt. Fern ist selbst der Mensch in der Lage verschiedene Untergründe bezüglich ihrer Griffigkeit zu beurteilen oder zu spüren. Es wäre doch ebenfalls interessant dies ins Bewegungsmodel des Roboters mit rein zu modellieren und die zu verwendeten Beschleunigungen bei unterschiedlichen Böden zu lernen. Das geht aber nur, wenn die Differenz zwischen dem was der Roboter tun soll und was er macht nicht sowieso schon Bauartbedingt sehr groß ist.
- Was die Ansätze angeht, dass wir durch hinzuziehen anderer Sensoren(Kamera(s)) die Position des Roboters ständig korrigieren müssen, dies ist absolut klar und wir haben auch darin Erfahrung. Aber 1. kann man natürlich mit einem Roboter, der relativ zum Menschen genau Fahrbefehle ausführt einige Dinge mehr machen und dies ist absolut ok, denn der Roboter hat bezogen auf dem Menschen sehr viele Nachteile, also warum nicht auch einen Vorteil nutzen? Und 2. läuft so eine Korrektur bei den meisten probabilistischen Filtern(z.B. Kalman oder Partikelfilter) in 3 Phasen ab: deterministischer Drift, stochastische Diffusion und Messung/Korrektur(bitte nicht an den Begrifflichkeiten aufhalten, da ich zu dem Thema eine Arbeit abliefern musste, könnte ich hier 20 andere Wörter hinschreiben, je nachdem was man liest). Wenn jetzt die Diffusion zu stark ist, dann konvergiert die Abschätzung langsamer/schlechter. Das kann man natürlich(wie schon Ceos aufgeführt hat) durch zum einen komplexe Algorithmen ausgleichen(und es ehrt mich, dass hier wohl einige denken, dass wir bei fast 0, bezogen auf die Software, anfangen und es besser machen alles alle UNIs auf unserem Planeten) und("oder" ehr selten) mehr Ressourcen Beanspruchung(Dies ist mal nicht einfach mal nur eine Preisfrage. An dieser Stelle kann man wohl nie genug haben.) Konkreter: Ich bin absolut in der Lage einen Roboter aufgrund von Bilddaten, sagen wir, ziemlich genau 4m geradeaus zu regeln und notwendige Algorithmen, die ich noch geeignet zusammenstellen/erweitern müsste, habe ich auch schon auf dem Rechner. Das würde den Roboter aber so ziemlich auslasten und für komplexe Entscheidungsprozesse bleibe nicht mehr genug. Ich kann dann aber sagen, der Roboter könne mit billigen, schlecht zusammengebauten Teilen, geradeaus fahren *freu*!
- Ich finde es absolut verwirrend, wenn ich gleichzeigt die Resonanz bekomme höherwertigere Materialen nutzen zu müssen, gleichzeitig aber die Qualität der Verarbeitung zurückschrauben soll.
- Ich wundere mich, dass hier offenbar auch viele Leute das Konzept des ER1s nicht mögen oder als nicht gut befinden. Wir möchten nicht ohne Grund das Fahrwerk ähnlich aufbauen. Zum einen haben wir damit sehr gute Erfahrungen gemacht. Ferner gilt, so weit ich weiß, der ER1(und der Scorpion ebenfalls von Evolution), aus der Informatikersicht als einer der ganz wenigen, käuflich zu erwerbenden, ernst zunehmenden Roboter(bei speziellen Anwendungen gibt es bestimmt auch mal Ausnahmen). Das liegt daran, dass er eine gute Plattform zum programmieren liefert und das möchten wir eben haben. Und wenn ich mal meine Algorithmen herauszufordern möchte, dann kann ich die Fahrbefehle immer noch mit einem Gaußrauschen überlagern.

Ich fasse also zusammen:
Wir haben nicht das Problem, dass wir probabilistische Wege gehen und möglichst alle zur Verfügung stehenden Daten geeignet fusionieren müssen, denn 1. ist uns klar, dass es notwendig ist. 2. Sind wir Informatiker, dies das sowohl theoretisch(Und allein die mathematischen Grundlagen, die uns in zwei Jahren Grundstudium beigebracht wurden, sind nicht zu vernachlässigen) und praktisch oft genug gemacht haben. und 3. sind wir mit unserem Roboter gar nicht im Ansatz soweit, obwohl sogar schon Algorithmen vorhanden sind.

Wir möchten in dem uns möglichen Rahmen einen möglichst guten Roboter bauen. Ich gehe davon aus, dass wir für die Programmierung erste mal genug Erfahrung haben, doch beim Bau viel zu wenig, da löchere ich bisher nur homedom mit Fragen. Ich gehe auch davon aus, dass der erste Versuch viele Verbesserungsmöglichkeiten aufzeigen wird, ich wünsche mir aber, dass der zweite Roboter brauchbar wird und nicht erst der zehnte, weswegen ich hier um Meinungen zur Antriebsidee gebeten habe. Denn auch hier ist mir klar, dass es nicht ausreicht, dass ich mal ausgefranste Zahnräder durch Originalersatzteile ausgetauscht habe um von Erfahrung zu sprechen. Ich weiß dass uns ein Zahnriemen teurer kommt, dafür beim ER1 gut funktioniert. Offensichtlich sind wir genau an dieser Stelle auf Erfahrungen anderer Personen angewiesen, denn wir haben weder das Geld noch die Zeit(wird sind nicht faul, doch es gibt z.B. eine Regelstudienzeit) beides auszuprobieren.

[HannoHupmann]

Lexan bekommt man auch ohne Probleme im Internet, z.B. bei Ebay und es wird im Nachbau deutlich einfacher zu Handeln sein, da Lexan nicht splittert wie etwas Plexiglas.

Selbst ein Roboter mit grottenschlechter Verarbeitung ist in der Lage gerade aus zu fahren. Er wird nur öfters nachkorrigieren müssen. Da letzteres eine Frage der Software ist bin ich überzeugt, dass ihr den Teil in den Griff bekommt. Da ich Mechatroniker bin kenn ich mich mit der elektromechanischen Seite gut aus. Da ihr verlangt dass es jeder nachbauen kann gehe ich von der Genauigkeit einer Handbohrmaschine aus (die liegt bei 1mm bis 3mm) damit fährt der Roboter nicht mehr gerade auf 4m aber jeder kann ihn bauen.

Und baubedingte Ungenauigkeiten sind leicht durch Software zu kompensieren. Viel leichter als durch exakte Fertigung. Nur wird die Software seite dann halt ein bischen anspruchsvoller weil nicht mehr alles exakt umgesetzt wird.

Wenn ihr den Roboter aber wirklich so genau bauen wollt, dass er auf 4m nur eine Abweichung von 1cm hat (von der gerade linie) dann braucht ihr ne CNC Fräse und einen sehr guten Mechaniker.

[pacer_one]

Warum Hanno so auf Lexan steht, liegt wohl darin begründet, dass es einfacher zu bearbeiten ist, bzw, so robust, dass es nicht gleich beim Anziehen der Schrauben kaputt geht. Sprich Lexan bricht nicht so leicht weder bei der Bearbeitung noch später bei der Benutzung.

Was ihr versucht ist ein Werkstück mit einer CNC-Maschine zu bearbeiten die auf einem fahrenden LKW steht.
Die Fertigungsgenauigkeit ist erst mal zweitrangig. Schaut euch alle Antriebskonzepte an und macht ne Matrix mit vor und Nachteilen.

Wenn ihr euer Fahrzeug für den Ausseneinsatz plant, sind Schrittmotoren ziemlich sinnlos. Um solche Wiedersprüche aufzudecken müsstet ihr vorgehen wie bei einer Produktentwicklung.

Damit der Roboter seine Funktion möglichst gut erfüllen kann, müsstet ihr genau definieren was denn nun seine Funktion sein soll und in welcher Umgebung er sich sich bewegen soll. Die Eilerlegende Wollmilchsau gibt es nicht.
Und wenn ihr dann wisst was ihr wollt, dann solltet ihr es dem Forum übersichtlich mitteilen, dann kann man zielgerichteter helfen.

Um mal zum Ausgangspost zurückzukommen:
Den Tipp mit der CNC-Fräse habt ihr ja schon bekommen.
Wäre diese Frage damit beantwortet?

Das Problem ist, dass man sich irgendwann in sinnlosen Diskussionen verliert, was nicht mehr zielführend ist.

[021aet04]

Es gibt auch einen Nachteil von Lexan. Man darf es weder lackieren, noch mit einer Folie bekleben,...
Es dürfen also keine Lösungsmittel, Weichmacher,... verwendet werden, in welcher Form auch immer. Das Lexan wird dann brüchig.

MfG Hannes

[Black Dragon]

Den Tipp mit der CNC-Fräse habt ihr ja schon bekommen.
Wäre diese Frage damit beantwortet?

Das Problem ist, dass man sich irgendwann in sinnlosen Diskussionen verliert, was nicht mehr zielführend ist.
Das möchte ich auch nicht. Deswegen habe ich versucht nur einen Aspekt anzusprechen. Und zwar hatte ich zwei Möglichkeiten den Antrieb aufzubauen gepostet und wollte unter verschiedenen Gesichtspunkten wissen welchen Aufbau wir besser weiterverfolgen sollten. Zugegeben ich habe zunächst vergessen zu schreiben, dass der Roboter in der Wohnung herumfahren soll und dass ich z.B. mono und stereo SLAM machen möchte und für das autonome Verhalten z.B. ein Aktivierungsnetzwerk ausprobiere.

Das Chassis wird mit einer CNC-Fräse gefertigt.

[HannoHupmann]

mit eine CNC Fräse hurra, niemand kanns nachbauen. Aber wenn dieses "nachbauen" jetzt endlich vom Tisch ist können wir uns darüber unterhalten wie ein CNC Chassies auszusehen hat.

(Bevor jetzt einer sagt "niemand" so ein quatsch. Jaja wer ne CNC zu hause hat kannst nachbauen. Hat aber fast keiner und nach fertigen lassen, tja dass kann ich nen KUKA Waldundwiesen-Roboter auch, wenn ich genug Kleingeld in der Tasche hab)

[hspecht74]

Hallo,
ich arbeite selbst schon seit einiger zeit (mit Pausen) an einem ganz ähnlichen Projekt, d.h. einem Roboter in der Gewichts- und Größenordnung die Euch vorschwebt und mit gleichem Antriebskonzept. Ich habe allerdings den Vorteil, im Besitz einer kleinen CNC-Fräse zu sein.
Hier die Eckdaten:
Chassis: 2mm Alublech
Antrieb: Schrittmotore mit Zahnriemenantrieb (Antriebseinheit ebenfalls aus Alu gefräst)
Rechner: MSI Board mit Atom 270, 1GB RAM
Betriebssystem: Win XP (mit NLite kompakter gemacht) auf Bootfähiger CF-Karte
Die Sensoren werden von einem ATMega128 abgefragt, der wie alle anderen Komponenten (Motortreiber, Energieverteilung, Servotreiber) per I2C-Interface mit dem Mainboard verbunden ist.
Kommunikation mit statioaärem PC: Über WLAN

Die Erfahrungen bisher:
- Das Gewicht ist kritisch, mein Aufbau ist bisher noch reichlich schwer. Das Problem: Je schwerer das Chassis, umso größer muss der Akku werden...größerer Akku = mehr Gewicht, macht in Summe Probleme mit Schrittverlusten. Daher der Zahnriemenantrieb, ausserdem werde ich den Motortreiber austauschen gegen einen, der Beschleunigungsrampen unterstützt, um höhere Endgeschwindigkeiten zu erreichen

- Das dritte Rad ist auch so ein Ding: Bei Drehbewegungen des Roboters muss sich das Rad ja auch drehen, wenn der Winkel ungünstig ist kann das (gerade bei so hohem Gewicht) dazu führen, dass Schrittverluste auftreten


Weiter Infos zu dem Teil unter http://www.james.rumbeck.de/
Die Seite ist allerdings schon länger nicht mehr gepflegt. Bei Interesse schicke ich gerne weitere Infos und aktuelle Bilder.

Viele Grüße,

Hinrich

[Richard]

Ich würde ja gerne mittels Pixelverschiebung im Kamerabild
wie bei einer Optischen Mouse die tatsächlich zurückgelegte
Ist_Wegstreke mit der Berechneten Soll_ Wegstrecke vergleichen.

Dann kann bei Bedarf nachgeregelt werden und ohne Regelung
wird es nie halbwegs genau. Leider bin ich mit Bildverarbeitung
eher etwas überfordert, besonders wenn das auch noch ein µC
übernehmen soll. :-(

Gruß Richard

[Black Dragon]

@hspecht74: echt ein super Projekt. So ziemlich genau das was wir auch machen möchten. Es hilft wirklich sowas mal zusehen.

@Richard: Sowas ist nicht so ganz einfach und besonders im allgemeinem Fall bräuchte man einen vollfertigen SLAM-Algorithmus. Ich kenne eine Diplomarbeit, da gilt die Annahme, dass der Roboter auf einer ebenen Fläche fährt und die Kamera etwas zum Boden hin geneigt ist. Aufgrund von Bildkorrespondenzen kann man jetzt zwischen Hindernissen und dem Boden unterscheiden(Punkte, die höher gelegen sind, "bewegen" sich in den Bildern "schneller"). Mit den Punkten auf dem Boden kann man die Roboterbewegung schätzen. Dies setz natürlich voraus, dass der Boden genug Features bietet.

[RedBaron]

Moin,

ich würde gern eine Anmerkung zum "exakten" Aufbau hinterlassen.

Wenn es euch so wichtig ist, genaue Positionen zu ermitteln, solltet ihr einmal eine Fehleranalyse betreiben (quantitativ). Überlicherweise sind Odometrie-Fehler (bei eurer Schrittmototsteuerung handelt es sich um eine solche) nicht unerheblich und zwar in der Regel aus anderen Gründen als eine unpräzise Konstruktion (wikipedia hilft!). Wenn man über Fehler redet, muss man die Quellen mit den höchsten Fehlern betrachten. Die liegen ganz bestimmt irgendwo im Prozentbereich (siehe hierzu auch vorhergehende Posts). Da nutzt es wenig, wenn man andere Quellen von 2 Promille auf 1 Promille reduziert. Da "schraubt ihr ganz bestimmt am falschen Ende".

Präzise Positionsmessungen, deren Fehler im Mittel nicht ansteigt, bekommt man nur über Peilungen.

Die besten Ergebnisse bei Koppelung erhält man über Sensoren, die die gefahrenen Wege messen (Schleppräder, umgebaute Maus-Sensoren, etc). Danach kommen Drehwinkelgeber der Antriebsräder. Am schlechtesten ist die Auswertung von Steuerkommandos mit der Annahme, dass diese auch umgesetzt werden. Genau das versucht ihr aber. Schrittmotoren gehen da noch einigermaßen, aber eben nur einigermaßen.

Viele Grüße
Red Baron

[Ceos]

ihr verheddert euch hier in der theorie !!! betrachtet doch mal das problem von einer anderen seite!!

statt die präzision ins uunermessliche zu trieben, oder die gesamte rechenleistung in die navigation zu versdchwenden sollte man bei der planung des antriebs auch GLEICH SOFORT die navigation mit einzuplanen!!

es hilft nichts, wenn man einen überteuren antrieb konzeptioniert, der am ende doch nciht soo genau arbeitet wie erhofft

andererseits bringt es auch nichts, wenn man einen billigantrieb in 2h zusammenschustert und dann 2monate rumknobelt bis die navigation läuft nur um dann festzustellen, dass ihr noch nen FPGA braucht um die restlichen aufgaben erledigen zu können

die diskussionen sind alle nur grundsätzlich und führen so zu nichts ... plant erstmal den roboter bis hin zur fremdgesteuerten navigation (kompass unterstützt, GPS, kameragestützt oder was auch immer) vielleicht eine aufstellung an die anforderungen mal machen und dann darüber weiterdiskutieren welche navigationsmittel neben einem "relativ" präzisen antrieb noch notwendig sind

EDIT: "blinde" navigation setzt eigentlich immer einen absoluten bezugsrahmen vorraus(GPS) ist die auflösung zu gering nützt das bei einem kleinen roboter garnichts

oder ist sie mit lokalen bezugspunkten (triangulation mittels signalbarken) präzise genug, ist man vom ort her eingeschränkt

ein relativer bezugsrahmen wäre auch möglich, setzt aber eine regelmäßige synchronisation vorraus ... also ortsgebunden

oder auch einen eignen bezugspunkt in einem sich verändernden bezugssystem(GPS driftet manchmal heftig) um eine ortsbezogene verbesserung der genauigkeit zu erwirken

[homedom]

Also ich find hier wird viel zu viel um die eigentliche Frage herumgeredet. Die eigentliche Frage war doch, ob der Antrieb über Zahnriemen oder Zahnräder erfolgen sollte oder es sogar ein besseres Antriebskonzept gibt. Ich glaube BlackDragon und den anderen des Teams ist klar, dass man nur durch die Schrittmotoren alleine keine 100% Genauigkeit erreichen kann. Dies ist glaub ich aber auch nicht der absolute Wunsch, denn 100% Genauigkeit gibt es (rein theoretisch) nicht. Desweiteren ist es ein Hobbyprojekt und kein Industrieprojekt wo es auch tausendstel Millimeter ankommt. Ich denke das dem Team bewusst ist, dass es neben den Schrittmotoren noch Korrekturen bedarf, aber davon war ja erstmals nicht die Rede, sondern davon wie man die Schrittmotoren am besten da einbaut.
Bezüglich der Materialwahl weiß hatte ich da auch an Plexiglas gedacht, aber ich habe auch noch keine Erfahrungen mit Lexan. Vielleicht ist das ja 10mal besser, aber dann muss man nicht, wie Hanno, einem Neuling wie BlackDragon mit 11 Beiträgen unterstellen, er hätte das Forum nicht gründlich gelesen. Klar hat er das nicht, er ist ja auch noch nicht seit 5 Jahren hier angemeldet. Ich hoffe man kann jetzt wieder zum eigentlichen Thema zurückkehren und dem Team bei der Frage nach dem Antriebskonzept weiterhelfen.
In der Hinsicht glaube ich, dass die Zahnriemen die bessere Wahl sind. Das Team hat anscheind mit dem ER1, welcher auch Zahnriemenantrieb hat, gute Erfahrungen gemacht. Das Problem mit dem Vorspannen seh ich beim ER1 nicht gelöst, habe ihn allerdings nie live gesehen. Dies könnte man meiner Meinung nach mittels einem Langloch am Motor beheben, sodass man den Motor verschieben kann bis der Riemen gespannt ist. Soviel man von meiner Seite.

gruß, homedom

[RedBaron]

Damit fing es an:

... Ziel soll es sein, dass der Roboter möglichst genau gearbeitet wird. Dies betrifft die Positionen der Räder und der Kameras und vielleicht später der sonstigen Sensoren.
Ich denke es wird hier so ziemlich jedem klar sein, dass es bei der Bildverarbeitung praktisch ist, wenn man nach einem Fahrbefehl genau weiß wo die Kamera gelandet ist.
Ferner soll es möglich sein den Roboter zu reproduzieren, also genau nachzubauen. ...

Was im 2. Satz steht, geht nämlich definitiv nicht!

Hier ein hoffentlich einsichtiges Beispiel:
Nehmen wir einmal an, das Ding fährt wirklich super geradeaus. Dann passiert es, dass eines der Räder -das linke- über ein kleines Staubkorn fährt. Statt das Staubkorns kann auch gern etwas anderes genommen werden, eine Bodenrille, oder die Sonne scheint auf eines der Räder und daurch ändert sich sein Durchmesser, der Luftdruck im Rad oder was auch immer. Bleiben wir bei einem Staubkorn, das lässt sich einfach erklären. Einem kleinem Staubkorn, sagen wir mit einem Durchmesser von 0,5mm, also so eben noch sichtbar. Das linke Rad muss nun das Staubkorn hinauf fahren (0,5mm) und wieder hinunter (auch 0,5mm). Das macht eine Strecke von 1 mm, die das rechte Rad bei der vermeintlichen Geradeausfahrt vorwärts gefahren ist, während das linke herauf und herunter gefahren, also praktisch sthen geblieben ist. Das ergibt eine Winkelabweichung, das Gerät macht eine Kurve nach links. Fährt man weiter, gibt das einen mächtigen Versatz. Mit einem Bisschen Trigonometrie (Tangens) kann man das genau berechnen.

Das sind die Fehlerquellen, die bei Präzisionsüberlegungen berücksichtigt werden müssen. Ein durch "blindes Navigieren" gesteuertes Gerät fährt niemals dahin, wo es hin soll. Da hilft genaues Bauen überhaupt nichts. Auch keine CNC-Fräse oder ein Lasercutter...

Das einzige, was man mit einer präzisen Bauweise verbessern könnte, wäre die Genauigkeit der relativen Postion der verschiedenen Komponeten zueinander. D.h. die Kamara befindet sich immer genau 35,2 mm oberhalb der Motorenachsen. Aber wie sieht es denn dann mit den Toleranzen der zugekauften Bauteile z.B. der Kamera aus ...?

[Black Dragon]

Klar geht es nicht, dass man nach einen Fahrbefehl absolut genau weiß wo man sich nun befindet. Schon gar nicht alleine auf Grundlage des Fahrbefehls, aber auch insgesamt muss man mit Wahrscheinlichkeiten arbeiten. Wie viele SLAM Algorithmen gibt es wohl, die ohne die Rückmeldung des Antriebs auskommen(und andere Sensoren kommen bei uns erst später)? Ich habe hier zwar selbst einen in diesem Thema gepostet(von der Oxford Active Vision Group), doch dieser liegt in O(n^2) (n = Anzahl der Feature) und arbeitete nur mit 100 Feature zu dem Zeitpunkt als das Video entstand(Frage der Rechenleistung). Für SLAM mag das reichen, für einen autonomen Roboter, der nicht irgendwo gegen fahren soll eher nicht.

Ich bin aber lernfähig und werde nun jedes einzelne Wort etwas mehr überdenken, wenn ich es hier eintippe. Ich hätte schreiben sollen, dass ich das gern möglichst genau hätte, in einem Rahmen, dass der Aufwand nicht ins unermessliche steigt, ich aber(im Gegensatz zur Schlagbohrmaschine, Hammer, Zahnräder aus der Stereoanlage-Methode) Daten des Antriebs zum fusionieren mit der Bildverarbeitung nutzen kann. Noch konkreter: wenn ich beim ER1 am Rad rüttele, dann bewegt sich absolut nichts. Ich wollte wissen ob es auch so gut ohne Zahnriemen geht, oder dieser dafür unbedingt sein muss.

Zu deinem Beispiel, du hast da einige Annahmen, die alle die Abweichung hochtreiben:
-Das Material des Rads gibt nicht nach
-Das Staubkorn gibt nicht nach
-Das Staubkorn ist bei dir ein Quader und nicht eher eine Kugel.
-Das Staubkorn ist für ein solches extrem groß(Wobei natürlich mal dreck auf dem Boden liegt)
-Dein Raddurchmesser geht gegen 0mm, nur so kann der Roboter den Quader senkrecht hoch und runter fahren. Der Umfang geht ebenfalls gegen 0. Leider geht dann aber der Weg, den der Roboter fährt auch noch gegen 0.

Wenn ich allein nur auf den untersten Punkt eingehe und meinem Roboter Räder mit min. 100mm(Größe beim ER1) Durchmesser gebe, dann komme ich auf eine Abweichung bei deinem Quaderförmigen riesen Staubkorn von 0,047mm.

[bjoerng]

Hat zwar nichts mit Mechanik zu tun, aber: Ich würde auf jeden Fall noch eine "visuelle Odometrie" basierend auf Fundamentalmatrixschätzung hinzufügen. Die schätzt die Bewegungsrichtung und besonders die Rotation extrem gut und haut damit das größte Problem, die von RedBaron skizzierte Rotationsfehlschätzung, schon mal von vornherein 'raus. Und ist nicht so schwer zu realisieren. Damit reduziert sich das Problem weitgehend auf die Filterung der verrauschten Länge der Bewegung.

Was SLAM angeht, ist z.B. FastSLAM sehr nahe an O(n) dran, aber das aktuelle Monte-Carlo-Kalman-VSLAM ist meiner Erfahrung nach sehr fehleranfällig. Besonders natürlich immer in der Tiefenschätzung, aus der man später die Bewegungslänge ableiten kann. Also kommt man mMn ohne Filterung über die Odometriedaten nicht aus.

Die Oxforder Active-Vision-Jungs arbeiten übrigens (soweit ich weiß) immer noch mit ihrem initial bekannten und vermessenen Kalibrierobjekt. Das wäre für mich für einen robust arbeitenden mobilen Roboter nicht akzeptabel. Da finde ich PTAM (auch aus Oxford, http://www.youtube.com/watch?v=F3s3M0mokNc ) schon viel interessanter: Punkte tracken, bis gewisse Entropie erreicht, dann mit Fundamentalmatrix 3D-rekonstruieren, mit dem Resultat die Kameraposition in 3D tracken und auf die Skalierung pfeifen, weil's die menschliche Wahrnehmung ja auch tut. Wenn man dann sogar noch eine grobe Skalierung aus der Odometrie hat und sich ein paar SIFT-Merkmale merkt, kommt man mMn schon sehr weit. Oder Stereo-Kameras, dann hat man die Skalierung gleich und braucht (theoretisch) gar keine Odometrie mehr.

[Black Dragon]

danke, interessanter Beitrag.

Ich persönlich denke, dass derzeitig noch keine praxisnahe(Autonomer Roboter navigiert mit einer Kamera) Lösung existiert, zumindest habe ich noch nichts gesehen, was mich überzeugt hätte.
Die meisten SLAM-Algorithmen haben gemeinsam, dass im Vordergrund die Lokalisierung steht, es geht weniger um eine Karte der Umgebung. Als folge davon werde in der Karte nur ganz wenige(dafür sehr stabile) LandMarken hinterlegt, die zwar die Lokalisierung sehr gut ermöglichen, leider jedoch kein grobes Bild der Umwelt bieten.
Ich finde, dass der FastSlam 2.0 Ansatz, wo die mit einem Auto durch dem Victoria Park gefahren sind, durchaus sehr interessant ist. Durch den Einsatz des Partikelfilters wird einem da sogar ein Loop Closing geschenkt.
FastSLAM 2.0, vSLAM und auch MonoSLAM(Davision) kommen auch relativ gut mit Störungen wie Verdeckung oder bewegten Objekten klar.

Bekannte Objekte zur Kalibrierung zu verwenden finde ich weniger schlimm, den Part könnte man auch entfernen, doch den Skalierungsfaktor zu haben kann manchmal durchaus interessant sein. Ich denke, dass in Zukunft auch Datenbanken mit bekannten Objekten verwendet werden(es wird wohl ein notwendiger Schritt sein um einem Roboter mehr Intelligenz beizubringen), so dass aufgrund dieser eine Skalierung stattfinden könnte. So weit ich weiß gibt es auch bei PTAM eine einfache, ungenaue Skalierung, zumindest beim ersten veröffentlichen Algorithmus, sollte der Benutzer mit einem Tastendruck ein Bild aufnehmen, dann die Kamera 10cm(natürlich nicht perfekt machbar) zur Seite bewegen und dann wieder eine Taste drücken.
Bei PTAM finde ich sehr interessant, dass die Karte so dicht wird. Im Paper zur verbesserten Version von 2008 ist ein Bild zusehen, wo man die Struktur der Umwelt aufgrund der LM erkennen kann. Es gibt wohl genug LM um die Umwelt mit Polygonen zu modellieren. Leider ist die Komplexität bei der Erweiterung der Karte(O(n^3), wenn ich mich nicht irre) ein extrem großes Problem. Ich denke bei einem kleinen Raum(das absolute Maximum was die gemacht haben) ist wirklich Schluss(mit dem derzeitigen Algorithmus). Ferner gibt es bisher im Vergleich zu anderen SLAM-Algorithmen kein ernst zunehmendes Loop Closing.
Leider erwarte ich nicht, dass da noch viel(wenn überhaupt) Neues kommt, ich habe gerade nachgesehen und Georg Klein arbeit seit letztem Jahr für Microsoft(MSN).

Ich muss mir auf jeden Fall noch einen bessern Überblick verschaffen, um zu entscheiden wo drauf man aufbauen könnte. Wobei der Quellcode der ersten PTAM-Version zumindest veröffentlicht wurde, da könnte ich natürlich etwas herumexperimentieren.

An einem Erfahrungsaustausch wäre ich sehr interessiert, wobei ich im Bereich SLAM bisher nur Theorie bieten kann, was sich in den nächsten Wochen stark ändern wird.

[Jepp]

Was die "Oxforder Active-Vision-Jungs" machen ist in vielerlei Hinsicht einfach Wahnsinn. Die scheinen sich auch gut auszutoben.

Wie geht es denn mit der Software oder der Unternehmung insgesamt voran?

[Black Dragon]

Man muss sagen, dass die Oxforder auch wirklich eine große Gruppe sind und entsprechend viel machen können. Es werden im übrigen beide Ansätze aktiv weiterentwickelt.
Ich selbst beschäftige mich im Moment mit der Repräsentation der Landmarken. Um es kurz zu machen: Die Welt zentrische Repräsentation(alle Landmarkenkoordinaten werden zum Ursprung angegeben) ist ganz schlecht, da automatisch die Unsicherheit der Landmarken, die weiter weg von (0,0,0) sind steigt und zudem ein großer Linearisierungsfehler entsteht(besonders in der Abschätzung der Unsicherheit). Alternativ wird heute eher die Robozentrische Repräsentation gewählt. Die Koordinaten wenn im Koordinatensystem der Kamera erfasst. Dies hat natürlich den Nachteil, dass die Unsicherheit von länger nicht gesehenen Landmarken steigt und natürlich, dass bei jedem Updateschritt die gesamte Karte entsprechend der Bewegung der Kamera neu berechnet werden muss. An dieser Stelle würde ich gern was beitragen.

Ansonsten haben wir die ersten Zeilen Code für unseren Roboter geschrieben. Leider ging das nicht so voran wie gewollt, da wir uns sehr stark mit der Technik auseinander gesetzt haben. Insbesondere haben wir auch Schrittmotoren gegen Getriebemotoren mit Encoder getestet.
Was Leider immer noch ein Thema ist, wir müssen uns für Programmiersprachen bzw. Bibliotheken endgültig entscheiden. Solange wir noch so hardwarenahe arbeiten, nutzen wir natürlich C. Für die Bildverarbeitung bietet sich OpenCV an. Dazwischen kann man sich streiten.

[Jepp]

[...]Sowas ist nicht so ganz einfach und besonders im allgemeinem Fall bräuchte man einen vollfertigen SLAM-Algorithmus. Ich kenne eine Diplomarbeit, da gilt die Annahme, dass der Roboter auf einer ebenen Fläche fährt und die Kamera etwas zum Boden hin geneigt ist. Aufgrund von Bildkorrespondenzen kann man jetzt zwischen Hindernissen und dem Boden unterscheiden(Punkte, die höher gelegen sind, "bewegen" sich in den Bildern "schneller"). Mit den Punkten auf dem Boden kann man die Roboterbewegung schätzen. Dies setz natürlich voraus, dass der Boden genug Features bietet.
Hast du einen Link zu der Diplomarbeit?
Habe mich mal "spaßeshalber" in eine Tracking und Matching Vorlesung gesetzt. Das ist einiges an Aufwand, allein Features und Flussvektoren selbst zu implementieren. Ich würde es aber, grad vor dem Hintergrund, dass ihr mehrere Leute seid, selbst versuchen.

Ich will es auf jeden Fall mal ausprobieren. Meine Verwendung wäre eine Kamera unter dem Bot, die den Boten filmt. Dadurch (hoffe ich) Hinweise auf Translation UND Rotation zu bekommen.
Die Fummelei mit der Hardware ist echt zeitaufwändig wenn man da bei null anfängt und eigentlich ein Softwaretyp ist.. (Referenz auf meine Probleme in der Sig.)

Hier in Hannover war vor ein paar Tagen/Wochen die Industriemesse. Da waren einige Entwickler mit ihren Bots. Es ist erleichternd zu wissen, dass auch z.B. die Fraunhofer beim Kameratracking weiterhin Odometrie und möglichst viel an Sensordaten fusionieren um zuverlässigere Resultate zu erzielen.

Vorerst wird sich in die SLAM, PTAM und was es alles an Abwandlungen gibt, gelesen.. Euch weiterhin viel Erfolg!

//EDIT: Das fand ich grad sehr inspirierend: vehicle-movement-tracking (http://blog.killerschaf.de/index.php/2010/03/21/vehicle-movement-tracking)
//EDIT: Link korrigiert.

[Black Dragon]

Hey, sorry für die späte Antwort, komme im Moment zu nichts.
Die Arbeit habe ich nicht aus dem Netz, ich müsste schauen wo ich sie abgelegt habe. Sie würde dir aber eh nicht viel bringe, da gibt es passenderes.
Wenn ich dich richtig verstanden habe, dann ist die Geometrie extrem leicht zu lösen, da ja der Abstand jedes Bildpunktes bekannt ist, wenn man annimmt, dass der Boden eben ist. Bei der Aufnahme des Bodens könnte es durchaus größere Probleme geben. Ich war vor zwei Jahren auf der Vision in Stuttgart, ich würde behaupten die Hälfte der Messestände hat sich mit der Beleuchtung beschäftigt. Bei einer Kamera unter einem Roboter wird es wohl keine gleichmäßige Ausleuchtung geben. Dazu kommt, dass der Roboter stark auf die Struktur des Bodens angewiesen ist. Kleine Feinheiten können die meisten bezahlbaren Kameras kaum wahrnehmen, besonders bei problematischen Licht.
Wenn es dir wirklich nur um Translation und Rotation und nicht um eine 2D Karte geht, dann solltest du dich vielleicht mit Visual Odometry beschäftigen. Der Rechenaufwand ist vertretbar und die Ergebnisse durchaus brauchbar.

PS: Der Link geht nicht, hab's aber gefunden. Finde ich auch interessant. Jedoch finde ich die Einfachheit der Tiefeinschätzung etwas fraglich. Ohne akkurate Tiefe kann die Bewegung nicht wirklich "skaliert" werden.

[killerschaf]

Heyho,

schön, dass ihr meinen kleinen Blog gefunden habt. Nur zur Korrektur: Die Tiefenschätzung ist mehr als fraglich, hat aber nichts mit der Bewegungsschätzung zu tun.

Bin gerade aus den USA zurückgekehrt und konnte so in den letzten Wochen nichts an meinem kleinen Hobbyprojekt machen. Das wird sich aber hoffentlich demnächst wieder ändern.

MfG