aufwendiges Open Source Projekt

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

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

Damit fing es an:

Zitat:

---

... 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 ...?

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.

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.

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.

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?

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.

Zitat:

---

Zitat von Black Dragon

[...]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
//EDIT: Link korrigiert.

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.