aufwendiges Open Source Projekt

[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