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.