Leistungsfähigerer Nachfolger für RP6?

[HaWe]

ziemlich viele Buchstaben, Rabenauge, aber hast du den TOP und die Nachfolgeposts nicht ganz gelesen?
1.) geht's auch um deutlich leistungsfähigere Motoren und
2.) um ein Fahrgestell, das möglichst sowohl indoor- als auch outdoor- (Rasen-) tauglich ist, nicht aber für schweres offroad-Terrain - festgelegt zu Ketten oder Räderantrieb war bisher nichts.
3.) zu den µCs, wie schon ausgeführt: von mickrigen AVRs als "Großhirn" (inl. Mega) halte ich absolut nichts: Dann schon lieber den Due oder den GrandCentral im gleichen Platinen-Layout.

Über die Art der Räder/Ketten kann man sich dennoch unterhalten, wenngleich ich von Ketten für schwere Fahrzeuge absolut abraten würde:
entweder rutschen sie auf Parkett oder glattem Marmor/Granitboden oder sie reiben mächtig auf langflorigem Teppich und ziehen beim Drehen auf der Stelle teilweise Fäden raus, und wegen des starken Schlupfs vor allem in Kurven sind sie nicht odometriefähig. Ich habe/hatte einen solchen in mehreren Ausführungsvarianten, ich kann nur davon abraten.

Wirklich große Gummiräder (Pneus mit geeignetem Profil) halte ich für besser, gerade auch für höhere Schwellen.

Wenn jemand aber ein Fahrgestell drucken kann, in Kleinserie, stabil genug auch für höheres Gewicht und Belastung (1 Kiste Bier oder wenigstens ein paar Sixpacks sollten sie schon transportieren können), dann wäre das doch schon ein super Einstieg.

[damfino]

Komisch, bei meinem Rasenmäher kam ich mit dem Mega nie ans Rechenlimit, mir ging nur der RAM aus.
Das Ding machte Odometrie, A* Wegberechnung, Partikelfilter zur Positionsberechnung, GPS, 3 Motoren regeln, LCD und Bluetooth Ausgabe, usw.
Wenn man sich die Mühe macht die Berechnung auf Festkomma und Winkelberechnungen über Look-up Tables zu machen flutsch das wie nix.
Aber wenn man das Gleiche unter Arduino mit float aufgesetzt hätte, wäre es natürlich in die Hose gegangen. Da braucht es natürlich einen ARM Prozessor damit man die Odometrie auf 0.001° Abweichnung berechnen kann aber in der Wirklichkeit der Roboter bei einem Steinchen schon unbemerkte >1° Abweichung reinbekommt.

Und das Ding ist leichter Echtzeitfähig zu bekommen wie andere Plattformen.

Ich würde das trennen, Motoransteuerung und Sensoren wie Motordrehzahl über Microcontroller, Bedienoberfläche und das ganze BlingBling mit Raspi und Co.

[HaWe]

ja, für Motorencoder und pwm gebe ich dir prinzipiell Recht,
allerdings kann das für 2-3 Encodermotoren auch der Raspi und auch der ESP32 schon selber, ganz alleine, ohne Zusatzboards
- und 2 Encodermotoren reichen ja auch zunächst für ein einfaches Transportvehikel.
Und zuwenig RAM bei AVRs ist ja auch mein eigenes Gegenargument.

Was Echtzeitfähigkeit angeht ist ein ESP32 für GPIO r/w aber sogar 40x (vierzig! mal!) schneller als ein AVR, und das gilt sogar auch für einen Raspi 2 oder 3, auf dem nebenher ebenfalls noch HDMI, WiFi, UART/Bluetooth, WL USB-Keyboard/Maus und eine USB cam laufen (C mit pigpio, wiringPi, pthread, trotz Linux root-Zugriffe auf den Kernel). Das habe ich selber schon gemacht, es funktioniert einwandfrei.
Was viele nicht wissen: man kann für den Raspi sowohl pthread-Priorities höher definieren als für default-OS-threads, als auch sogar bestimmte cpu-Cores fürs eigene Programm reservieren und für den Linux Kernel komplett sperren (letzteres war bisher aber noch nicht einmal nötig). Allerdings gelten diese Vorteile nur für C, nicht für Python.

Den ESP32 betreffen Kernel-Zugriffe aber ja überhaupt nicht, und WiFi wird von seinem 2. core ja ganz unabhängig gesteuert.

Aber wir können es trotzdem so stehen lassen mit einem AVR Zusatzboard, denn (leider) funktionieren auch manche fertigen Shields nicht mit 3.3V Technik (es sei denn man entwickelt es selber).

[Holomino]

Wenn jemand aber ein Fahrgestell drucken kann, in Kleinserie, stabil genug auch für höheres Gewicht und Belastung (1 Kiste Bier oder wenigstens ein paar Sixpacks sollten sie schon transportieren können), dann wäre das doch schon ein super Einstieg.

Möglich ist alles, aber man kommt sehr schnell an die Grenzen des Bauraumes eines 3D-Druckers.
Und so richtig Spaß kommt bei großen Teilen auch nicht auf, weil der Druck doch recht lange dauert. Da kann ein Fehldruck schon mal die zeitliche Verzögerung von nem ganzen Tag bedeuten. Für Spezialteile (Verbinder, Aufhängungen, ...) geht's. Solide Böden oder Wände müsste man aus Blech, Acrylglas oder Holz fertigen.

[HaWe]

gute Idee, danke!

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