Leistungsfähigerer Nachfolger für RP6?

[inka]

nur als idee, aber vielleicht könnte man endlich mal omniwheels verwenden?

[HaWe]

nur als idee, aber vielleicht könnte man endlich mal omniwheels verwenden?

Indoors ganz interessant, besonders für Fussballroboter etc., aber
a) schecht für Odometrie und
b) schlecht für draußen, weil sie schnell verdrecken und
c) auch sehr schlechten Grip haben

[Holomino]

Wenn wir schon beim Sammeln von Antriebsarten sind: SynchroDrive gibt's auch noch.

[Rabenauge]

Entsprechende Räder gehn draussen natürlich auch- aber die üssen dann _wirklich_ gross sein.
Mein RC-Monstertruck (ein 1:10er) hat Räder mit 120mm Durchmesser- die selben wie der Wild Thumper.
Damit geht, wenn man geschickt fährt, eine Bordsteinkante _geradenoch_.
Halbwegs ordentlicher Rasen auch, im höheren Gras machts keinen Spass mehr.
Von daher würde ich die, bei HaWe's Anforderungen, als das Minimum ansehn.
Allerdings haben die das selbe "Problem" wie Ketten: wenn man ein vierrädriges Fahrzeug damit baut (meinetwegen auch sechs Räder), ist die Odometrie auch nicht mehr besser...insofern: im Zweifelsfall _sind_ Ketten geländegängiger.

Räder haben hauptsächlich einen Vorteil (abgesehen von dem beschriebenen Szenario: Parkett-oder Fliesenboden, wo man mit Gummiauflagen auch was machen kann): man kann deutlich schneller fahren.
Zwar kann man auch Kettenfahrwerke bauen, die Highspeed-tauglich sind, aber das ist dann deutlich aufwendiger.

Also, HaWe: wie willst du lenken, um eine saubere Odometrie hinzukriegen?
Bei allem, was mit ner Panzerlenkung funktioniert, kannst du es vergessen.

Irgendwann "später mal" hab ich vor, einen Wild Thumper "in richtig" zu bauen: das Antriebskonzept von dem Ding ist nämlich gut: drei Räder pro Seite, jedes mit eigenem Motor, das ergibt ne Geländegängigkeit fast wie mit Ketten, aber ohne viel Aufwand auch die Möglichkeit, schnell zu fahren.
Die Getriebemotoren vom Thumper gibts mit und ohne Encoder, in verschiedenen Ausführungen- gute Sache!
Die Federung dagegen ist Unsinn: die brauchts nicht, wie gesagt: ich kenne diese Reifen. Die fangen das Nötigste lässig ab. Da kann man auch mit verschiedenen Einlagen experimentieren (Schaumstoff rein, das ist im RC-Modellbau, woher diese Räder stammen, üblich).
Und das völlig offene Chassis müsste man halt durch ne richtige Wanne ersetzen.
Allerdings: so ein Rad trägt, na sagen wir mal vorsichtig 2 Kilo.
Also mit zwei Kisten Bier wird das nix- oder man braucht ganz viele.

Also HaWe: wie stellst du dir die Lenkung vor?

[Holomino]

Naja, andere Konzepte basieren ja auch nicht unbedingt auf der Odometrie als Hauptnavigationsmerkmal (Ich mag mich da gewaltig irren, aber ich glaube nicht, dass bei autonomen KFZs jemand auf die Idee gekommen ist, den Lenkausschlag in die Positionsberechnung einzubeziehen). Im Zweifelsfall verkommt die Weg- oder Geschwindigkeitsmessung an den Rädern eben zum Ist-Wert der Motor-Regelschleifen.

Was mir allerdings jetzt schon nach ein paar wenigen Stunden Recherche über die Konfiguration entsprechender Antriebe bei der von HaWe angepeilten Last und Größe deutlich missfällt: Dat wird nisch janz billisch. Wo ich bei kleineren Unterhaltungsmodellen für den Antriebsstrang (Räder/Motoren/Treiber/Akkus) vielleicht 30 Euro ausgebe, kann ich für was Größeres mal schnell noch ne null hinten dran hängen.

Was ich bemerkenswert fand: Ich hab mir mal die Ardumower-Seite angeschaut. Selbst die bieten ein kleines Modell "für Entwicklungen/Tests in der Winterzeit" an. Auch da finde ich die Idee wieder, eine Plattform auf unterschiedliche Anwendungen zu skalieren.

[HaWe]

@rabenauge:
Momentan diskutieren wir ja erst, entschieden ist ja nichts. Grobe eigene Ideen als Diskussionsbeitrag habe ich allerdings schon:
ich persönlich würde einen Differenzialantrieb mit 2 angetriebenen Rädern bevorzugen, plus allerdings nicht mit einem, sondern 2 gefederten passiven Stützrädern, um Stabilität gegen Wackeln und Kippen zu verbessern; optional könnte man auch noch die Antriebsräder federnd aufhängen. Als Radgröße würde ich ca. 15-25cm Durchmesser als Hausnummer anpeilen (Stützräder etwas kleiner), mit rundem Reifen-Querschnitt ähnlich Schubkarrenreifen
(edit: Mars Rover Sojourner hatte ca. 13cm, Opportunity ca. 25cm Raddurchmesser ) .
Schnell fahren ist nicht das Hauptziel, sondern eher im Rahmen von Schrittgeschwindigkeit. Unter diesen Vorraussetzungen ist Odometrie machbar, allerdings mit den bekannten Einschränkungen (u.a. bevorzugt für kürzere Intervalle und ansonsten gefiltert per Sensorfusion mit anderen Bewegungssensoren - Einzelheiten muss man entscheiden, wenn es soweit ist).
Ich wüsste jetzt kein Setup, das für Odometrie grundsätzlich geeigneter wäre, wenn man sie nutzen will.

@Holomino:
Dein Synchrodrive ist tatsächlich eine gute technische Alternative, ich habe allerdings die Befürchtung, dass es auch mechanisch sehr aufwändig und zusätzlich auch teuer werden könnte. Was den Preis insg. angeht, könntest du Recht haben, ich würde mal als Hausnummer kalkulieren
Raspberry Pi: 40,-
SD card: 10,-
Keybord, Maus: 20,-
Huckepack-Arduino: 15,-
Touch-TFT: 50,-
DC/DC-Wandler: 10,-
Akkus: 20,-
----------------
ZS: 165,- (gilt +/- für alle Baugrößen)
Preise für Sensoren kommen ebenfalls noch hinzu, auch für alle Baugrößen.

Zusatzkosten je nach Größe, Stärke und Stabilität von Mechanik + Motoren (wäre zu ermitteln)

Nimmt man einen esp32 statt eines Raspis, wäre das ganze etwas weniger leistungsfähig, aber auch ca 40 EUR billiger.

[Holomino]

Naja, ist weder "mein" SynchroDrive, noch hab ich's jemals selber gebaut (die Feinjustage der Radwinkel war mir immer ein Greuel). Aber es ist auch wieder ein Antriebskonzept, dessen Ansteuerung sich vom Differenzialantrieb unterscheidet.

Insofern bin ich immer noch Anhänger der Theorie, dass ein Fahrgestell (mit Odometrie) zwischen 20 und 1000 Euro kosten kann, was uns aber projektbezogen herzlich egal sein darf, wenn wir 2,50 Euro für nen Controller mit Schnittstelle spendieren - oder uns zumindest im Vorfeld als Option über die Abstraktion dieser Schnittstelle im klaren werden (im Zweifelsfall ist das dann nen freigelassener Stecker, der über UART oder I2C als Anschluss dient).

Um diesbezüglich etwas Fleisch in die Diskussion zu bringen (ich denke, mit Geradeausfahrt eines Differentialantriebes hat sich jeder Beteiligte hier schon mal auseinander gesetzt, mit nem über SLAM rückgekoppelten Abfahren eines Pfades auch? Keine Ahnung - Ich kanns nicht sagen.), presche ich jetzt mal einfach vor mit der Vorstellung der Bewegungsschnittstelle, die ich eigentlich stabil in den letzten Jahren verwende:

MoveManual(x,y); //Joystick - immer wieder lustig für die Kinder
Linear(distance, direction);  // Geradeausfahrt vor-/rückwärts
Turn(angle, direction); //Drehung links/rechts
MoveTo(point); //ausgehend von der subjektiven (über Odometrie bestimmten) Pose eine fließende Kombination aus Drehung und linearer Bewegung zum angegebenen Punkt.

(Kleine Ergänzung: Das Stop() ist bei mir nen MoveManual(0,0); )

Dazu kommt dann noch als Funktion, dass die subjektive Pose laufend aus den Inkrementalgebern aktualisiert wird (braucht man sowohl intern für die MoveTo-Regelung als auch extern für das Vernücken der Sensorwerte) sowie ein auszulesender, einzustellender und im EEPROM persistent zu machender Parametersatz (Regelparameter, Infos über Radabstand und Schrittauflösung, Geschwindigkeitsvorgaben).

Mehr braucht's nicht zu meinem Glück (aber auch nicht weniger). Ob das Ding nun auf zwei oder vier Rädern, auf Ketten oder Beinen läuft, ist mir egal. Den notwendigen Rest, also die Umrechnung zwischen Odometrie (subjektive Pose) und SLAM (objektive Pose) mache ich dann in beide Richtungen mit 2D-Transformationen.

Soll jetzt aber nicht heißen, dass das der goldene Weg ist. Vielleicht hat's jemand anderes besser oder kompakter drauf oder er (sie) braucht noch mehr.