Leistungsfähigerer Nachfolger für RP6?

Druckbare Version

40 Beiträge dieses Themas auf einer Seite anzeigen

22.05.2019, 13:14
HaWe

Leistungsfähigerer Nachfolger für RP6?

hallo,
was haltet ihr von einem größeren und leistungsfähigeren Nachfolger für RP6 als Community-Projekt?

Das "leistungsfähiger" würde ich sowohl auf die Motorleistung samt entspr. H-Brücken (z.B. als Plattform auch für Rasenmäher-Robots)
als auch auf den/die verwendeten MCU/SoC beziehen (z.B. ESP32, Arduino Due/M3, SAMD51/M4 oder RaspberryPi 2/3, Programmierung: Arduino/gcc C++).

ESP32 und Raspi hätten den Vorteil der vornherein eingebauten WiFi- und auch html/Web-Server Fähigkeit (mit leider nur wenigen freien GPIOs),
M3/M4 Boards speziell mit Arduino Due/R3-Layout böten extrem viele GPIOs auch für Rotationsencoder, viele DAC und mehrere UART/USART, und sie könnten dann auch per zusätzlichem esp8266 für WiFi erweitert werden.
(edit: ) Raspi hätten den Riesenvorteil wegen preemptivem Multithreading per POSIX pthread und std::thread.

So könnte die Fahrgestell-Dimensionierung so gewählt werden, dass sie sowohl für Hausroboter passt, z.B. mit Plattform oben auch für optionale Roboterarme,
als auch, wenn man zusätzlich 1 oder 2 Messer-Rotoren darunter setzt, auch für Rasenrobbies geeignet ist.
edit: Als Größe hätte ich mir bislang etwa 30cmx50cm (BxL, d.h. gut DIN A3) vorgestellt, damit es nicht zu sprerrig ist und man es auch noch in den Zimmern gut manövrieren kann.

edit:
ergänzt um die wesentlichen Specs aus der nachfolgenden Diskussion:

Einsatzgebiet:
Parkett, Teppich, Türschwellen, gepflasterte Wege, Rasen, auch leichtes Gefälle,
kein schweres Offroadgelände
Chassis, Antrieb:
2 unabhängig angetriebene Räder mit Gummipneus und Profil für innen und außen, ca. 15-20cm Durchm.
Differentialantrieb wie Tribots, aber 2 gefederte Stützräder, keine Ketten // edit: oder besser 4 angetriebene, gefederte Räder
einfache bis max. doppelte Schrittgeschwindigkeit, steuerbar per pwm +dir-pins (z.B. wie L298, aber stärker)
jew. über 6Nm (7-10Nm) pro Antriebsachse
Rotations-Motorencoder für Odometrie
Sensoren:
SLAM-fähig (IR Distanzsensoren, Laser, GPS, evtl. Baken mit dm-Wellen)
> 10 kg Payload
Aufbau:
stockwerk-weise,
optionaler Roboteram
Programmierung:
Festlegung der MCU (vorzugsweise ESP32 oder Raspberry Pi)
Festlegung der Programmiersprache (vorzugsweise C/C++)
22.05.2019, 17:26
Moppi

Da gibt es so viele Zusatzboards und Sensoren...
Da fällt die Entscheidung schwer, was man nehmen sollte.
Ich denke, vielleicht einen Mega2560 mit einem WiFi-Shield. Da ist man dann ganz gut dabei, was die Schnittstellen angeht.
Nicht vergessen, dass viele Sensoren über I2C angeschlossen werden. Theoretisch kann man viele hintereinander hängen, aber ob das dann praktisch auch so mit allen funktioniert?

Zum Untersatz / Fahrgestell kann ich nichts sagen.

MfG
22.05.2019, 18:59
HaWe

Zitat:

Zitat von Moppi

Da gibt es so viele Zusatzboards und Sensoren...
Da fällt die Entscheidung schwer, was man nehmen sollte.
Ich denke, vielleicht einen Mega2560 mit einem WiFi-Shield. Da ist man dann ganz gut dabei, was die Schnittstellen angeht.
Nicht vergessen, dass viele Sensoren über I2C angeschlossen werden. Theoretisch kann man viele hintereinander hängen, aber ob das dann praktisch auch so mit allen funktioniert?

Zum Untersatz / Fahrgestell kann ich nichts sagen.

MfG

der Mega2560 kommt IMO nicht in Frage, denn der ist ja wieder nur ein veralteter, mickriger AVR, es ging mir aber um moderne, leistungsstarke Prozessoren, vorzugsweise mit fpu. Sogar hier im Forum gibt es ja schon eigene Projekte vom RP6 sogar mit Raspi, wenn ich mich recht erinnere.
Auch Teensy 3.5/3.6 (ARM Cortex M4) wären wschl eine gute Idee, denn dafür gibt es inzwischen schon eine std::thread Implementierung.
22.05.2019, 19:05
fabqu

Moin zusammen,

ich muss HaWe Recht geben. Atmels sind eigentlich zwar nett, aber nicht mehr wirklich Standard. Da müsste es ein STM, ESP, RaspPi oder wenigstens (wenn schon Atmel) ein besserer Arduino sein, damit man immerhin die Arduino IDE nutzen kann.
Ich würde klar den RaspPi bevorzugen, hätte auch Vorteile hinsichtlich der Programmiersprachen: da kann man sich aussuchen, ob man in Basic, Python, C, C++, HTML oder sonst was NodeJS programmiert!
Gute (leistungsfähige) Boards für den RaspPi im Robotik-Bereich gibt es schon, wie etwa das Gert-Bot (https://www.gertbot.com/).

Aber den Vorteil eines RP6 (alle nutzen dieselbe Elektronik-Hardware mit derselben mechanischen Hardware mit derselben Programmiersprache und sogar denselben Libraries), den gibt man hier völlig auf.

Denkbar wäre natürlich, dass man etwas diesbezüglich in der Community entwickelt, also ein Fahrgestell mit Treiberboard (ähnlich der RP6 Base Platine oder dem Arexx Wild Thumper Board) welches dann einen Steckplatz für einen RaspPi oder anderen Controller besitzt.
Bei so was wäre ich dabei!!!

Grüße
22.05.2019, 19:24
Holomino

Vielleicht sollte man im Vorfeld klären, was das Ding denn überhaupt können soll...
...oder zumindest haben soll (wer da in Sensorik denkt, möge mal die Möglichkeiten aufzählen).

Üblicherweise richten sich ja die Mittel nach dem Zweck
22.05.2019, 20:38
HaWe

Zitat:

Zitat von fabqu

Moin zusammen,

ich muss HaWe Recht geben. Atmels sind eigentlich zwar nett, aber nicht mehr wirklich Standard. Da müsste es ein STM, ESP, RaspPi oder wenigstens (wenn schon Atmel) ein besserer Arduino sein, damit man immerhin die Arduino IDE nutzen kann.
Ich würde klar den RaspPi bevorzugen, hätte auch Vorteile hinsichtlich der Programmiersprachen: da kann man sich aussuchen, ob man in Basic, Python, C, C++, HTML oder sonst was NodeJS programmiert!
Gute (leistungsfähige) Boards für den RaspPi im Robotik-Bereich gibt es schon, wie etwa das Gert-Bot (https://www.gertbot.com/).

Aber den Vorteil eines RP6 (alle nutzen dieselbe Elektronik-Hardware mit derselben mechanischen Hardware mit derselben Programmiersprache und sogar denselben Libraries), den gibt man hier völlig auf.

Denkbar wäre natürlich, dass man etwas diesbezüglich in der Community entwickelt, also ein Fahrgestell mit Treiberboard (ähnlich der RP6 Base Platine oder dem Arexx Wild Thumper Board) welches dann einen Steckplatz für einen RaspPi oder anderen Controller besitzt.
Bei so was wäre ich dabei!!!

Grüße

wenn ich dich recht verstehe:
eine gemeiname Basis sollte es ja sein, auf was man sich dann einigt, sowohl was Mechanik als auch was MCU/SoC und Programmiersprache angeht: ähnlich wie beim RP6.

Per Raspi.org wird ja nur Python supportet, C(++) ist aber per Geany IDE, wiringPi und pigpio, gtk und qt etc. auch schon ein quasi-Standard, welcher einigermaßen verbreitet und supportet wird.
Python ist mir selber ein Graus, C/C++ wäre mir lieber, aber wenn man sich auf Python einigt: warum nicht.

Motor-Treiber-Shields mit hoher Leistung aber gibt es nicht fertig, die gehen meist nur bis in die L298-Liga, gebraucht würden aber sicher 200W (12V, bei ca. 15A stall current) pro Motor, und der Raspi schafft es mit seinen GPIOs onboard ohne Shield auch nur max. 3 Rotationsencoder-Motoren zu steuern und auszulesen (insg. 5 GPIOs pro Motor: 2* encoder plus 2*dir und 1*pwm).

Aber auch ESP32 oder M4 halte ich wie gesagt für nicht schlecht, gerade wegen der sehr einfachen Arduino C++ API und IDE - und wenn dann noch MT verfügbar ist: genial IMO.

- - - Aktualisiert - - -

Zitat:

Zitat von Holomino

Vielleicht sollte man im Vorfeld klären, was das Ding denn überhaupt können soll...
...oder zumindest haben soll (wer da in Sensorik denkt, möge mal die Möglichkeiten aufzählen).

Üblicherweise richten sich ja die Mittel nach dem Zweck

Ideen können wir ja sammeln...
Hier muss man sicher auch trennen zwischen Arduino ARM vs. Raspi.
Arduino: SPI für TFT und SD, aus Performancegründen dann hier eher keine weiteren Geräte
Raspi: HDMI für TFT

daher würde ich Sensoren für den Arduino per i2c und 1 UART verwenden,
beim Raspi per i2c, SPI oder beliebig viele UARTs (onboard oder via USB).

Arduino: Cam schwierig, evtl. PixyCam,
Raspi: USB-Cam

Welche Art von Sensoren wäre dann fast egal, denn die meisten gehen ja per i2c (auch über Portmultiplexer) oder zumindest per UART.

Was es können soll: als Mobile-Robot-Basis Hindernisse erkennen und damit sicher autonom und per Fernsteuerung navigieren (im Haus zwischen Zimmern herumfahren, Hindernisse umfahren, SLAM, und draußen im Garten mit entsprechendem zusätzlichen Mähwerk den Rasen überall vollständig mähen ;) ).

zur Hinderniserkennung und SLAM kämen dann grundsätzlich Sharp IR oder Laser/LIDAR in Frage (evtl. auch Ultraschall) plus eine Sensor-Stoßstange.
Zur Navigation/Ortung wären ggf auch outdoors GPS oder indoors Baken mit dm-Wellen (indoor-GPS) möglich.
22.05.2019, 23:05
Holomino

Also AD-Wandler, PWM, GPIO, I2C, UART,...

Warum nicht nen Controller mit Firmware und aufgesetztem Bluetoothmodul als Hardwarebridge? Über BT dann das Notebook, Tablet, Smartphone, Einplatinencomputerchen,...
Im Zweifelsfall kann man sich dann auch über BT mit einer zweiten Platine verbinden.

Und wenn's Richtung Leitstand geht, dann können die auch alle Wifi.
23.05.2019, 08:12
Moppi

"Leistungsfähigerer Nachfolger" - Ist eine Frage, des Konzepts.

Beispiel:

Ein Supercomputer mit Mehrkernprozessor und meinetwegen Windows oder Linux.
Netzwerkschnittstelle, WiFi.
Komplexe Programmausführung und Berechnungen mit Java, weniger komplexe Ausführung an Peripherie mit einfachen µC.
Schnittstelle WiFi zum "Super"computer.

Unter Umständen kann die Anbindung mehrerer µC an einen Bus sinnvoll sein, weil dann mehr Aufgaben direkt physisch parallel ablaufen können.
Parallelisierung ist aber eine Frage der Endanwendung des Gerätes. Oft ist das nicht notwendig.

Warum jetzt der "Hype" gegen Arduino verstehe ich nicht.
Dafür gibts so viele Sensoren und andere Zusatzplatinen. Mit Abstand existieren dazu die meisten Quellen zu Anwendungen, als ich je zuvor gesehen habe.

MfG
23.05.2019, 08:53
HaWe

Zitat:

Zitat von Moppi

"Leistungsfähigerer Nachfolger" - Ist eine Frage, des Konzepts.

Beispiel:

Ein Supercomputer mit Mehrkernprozessor und meinetwegen Windows oder Linux.
Netzwerkschnittstelle, WiFi.
Komplexe Programmausführung und Berechnungen mit Java, weniger komplexe Ausführung an Peripherie mit einfachen µC.
Schnittstelle WiFi zum "Super"computer.

Unter Umständen kann die Anbindung mehrerer µC an einen Bus sinnvoll sein, weil dann mehr Aufgaben direkt physisch parallel ablaufen können.
Parallelisierung ist aber eine Frage der Endanwendung des Gerätes. Oft ist das nicht notwendig.

Warum jetzt der "Hype" gegen Arduino verstehe ich nicht.
Dafür gibts so viele Sensoren und andere Zusatzplatinen. Mit Abstand existieren dazu die meisten Quellen zu Anwendungen, als ich je zuvor gesehen habe.

MfG

nee, AVR macht IMO absolut keinen Sinn, viel zu langsam, viel zu wenig Speicher (siehe meine Benchmarks).
https://www.roboternetz.de/community...Brickbench-2-2

ARM Prozessoren M3, M4 oder ESP32 sind aber doch auch Arduino-IDE-kompatibel, egal ob von Arduino oder Adafruit oder Teensy, was hast du daran nicht verstanden?

Multithreading ist aber essentiell.

Bei ARM-Prozessoren für Multithreading: Arduino Scheduler (cooperativ)
Bei Teensy-Prozessoren für Multithreading: TeensyThread (preemptive)
Bei ESP32: Arduino Scheduler (cooperativ) oder auch ggf std::thread (preemptiv; angefragt, u.U. bald in Bearbeitung)
Bei Raspi: für C/C++ POSIX pthread oder C++ std::thread (beide preemptive)
23.05.2019, 11:27
Moppi

@HaWe

Zitat:

ARM Prozessoren M3, M4 oder ESP32 sind aber doch auch Arduino-IDE-kompatibel, egal ob von Arduino oder Adafruit oder Teensy, was hast du daran nicht verstanden?

Und tschüß...
23.05.2019, 13:16
HaWe

Zitat:

ARM Prozessoren M3, M4 oder ESP32 sind aber doch auch Arduino-IDE-kompatibel, egal ob von Arduino oder Adafruit oder Teensy, was hast du daran nicht verstanden?

Zitat:

Zitat von Moppi

@HaWe
Und tschüß...

was sollte dann DAS:

Zitat:

Zitat von Moppi

Warum jetzt der "Hype" gegen Arduino verstehe ich nicht.
Dafür gibts so viele Sensoren und andere Zusatzplatinen. Mit Abstand existieren dazu die meisten Quellen zu Anwendungen, als ich je zuvor gesehen habe.

:?:
23.05.2019, 15:34
Holomino

Zitat:

Zitat von fabqu

Aber den Vorteil eines RP6 (alle nutzen dieselbe Elektronik-Hardware mit derselben mechanischen Hardware mit derselben Programmiersprache und sogar denselben Libraries), den gibt man hier völlig auf.

Muss man das? Kann man die Aufgaben eines Roboters nicht modular splitten in z.B. Fortbewegung, Powermanagement, Aktoren, Sensorik, Koordination,....?
Dann könnte man doch nach Spezifikation von Schnittstellen die einzelnen Spezis im Team ihren Kram erledigen lassen (ich finde z.B. Arduino total doof) und die Sache anschließend zusammensetzen.
Solche Firmware in einzelnen Controllern verdeckt zwar abschließend die Details, aber ganz ehrlich? Wenn ich gerne nen SLAM programmiere, mag ich mich vielleicht auch nicht en Detail mit nem Inkrementalgeber auseinandersetzen.

Man sieht ja schon am ersten "tschüss" die nur bedingte Bereitschaft einzelner Personen sowohl für sich als auch für andere mitzudenken. Das geht so nicht. Bei solch einem Projekt braucht man erst einmal die ausreichende Anzahl Leute ohne Ausschlusskriterien, die in aller erster Linie den Spaß und die Bereitschaft aufbringen, sich aktiv am Projekt zu beteiligen (und wenn es auch nur der Tester ist, der keine Ahnung von der Materie hat, aber die Geduld aufbringt, sich drei Stunden vor so ein Gerät zu setzen und zu schauen, wie es fährt). Wenn Moppi also gerne AVRs in Arduinos mag, dann gibt es ganz sicher ein Modul, dass er mit nem AVR betreiben kann und dessen Schnittstelle den Rest des Teams davon partizipieren lässt.

Ich finde sowieso, es gibt viel zu viele Ansätze für ein und die selbe Lösung. Sich da auf eine technische Basis für das Gesamtprojekt einigen zu wollen, führt nur ins Chaos - und es schließt nebenbei eine Menge Interessenten aus.
23.05.2019, 17:12
HaWe

Gerade die gemeinsame technische Plattform wie beim RP6 fand ich an sich vorbildlich und nachahmenswert, und gerade für Hobbyprogrammierer sind Lernplattformen wie Arduino (in C++ Sketch für ARM cores, ESP) und/oder Raspberry Pi (in C/C++ mit wiringPi) ideal, weil man hier vereinfachte IDEs hat und bereits modular auf -zig fertige Libs zurückgreifen kann.
Auch zum Encoderlesen und Multithreading gibt es diese libs ja bereits, für beide Zielplattformen!

Eine Herausforderung wäre hier aber vor allem auch mechanischer Natur, mit entsprechend sehr leistungsfähigen Encodermotoren, die von gängigen Arduino- oder Raspishields nicht mehr angesteuert werden können.

Statt Einzelaufgaben von vornherein auf einzelne MCUs auszulagern, könnte man mit den ARMs aber alles auf 1 laufen lassen, in unabhängigen Funktionen bzw. Threads, denn dadurch spart man sich auch wieder Kommunikationsprobleme zwischen mehreren MCUs.
Was nicht ausschließlich heißt, dass man nicht zu einem ARM u.U. doch noch einen AVR hinzunehmen könnte, falls der ARM nicht reicht oder er es nicht kann, aber dann eher ausnahmsweise.
23.05.2019, 18:53
Holomino

Dagegen!

Ich finde, es sollte egal sein, ob das Ding mit Ketten läuft, mit Rädern oder huckepack auf Moppis Hexapoden. Abstrahiert ist das eigentlich nur eine Blackbox, die eine Bewegungsanforderung umsetzt und die geschätzte aktuelle Pose laufend zurückmeldet. Da kann man nen Controller mit abstrahierter Schnittstelle für spendieren.

(Für nen Rasenmäher würde ich wirklich die Spinne präferieren, das ist neu, die Geländegängigkeit ist anwendungsbezogen, und grün lackiert würde sich das Teil bestimmt gut in die Landschaft einfügen. Da hat man dann auch keine Sorgen mehr mit Motortreibern, die das Teil über die Hügel treiben müssen)
23.05.2019, 19:15
HaWe

Zitat:

Zitat von Holomino

Dagegen!

Ich finde, es sollte egal sein, ob das Ding mit Ketten läuft, mit Rädern oder huckepack auf Moppis Hexapoden. Abstrahiert ist das eigentlich nur eine Blackbox, die eine Bewegungsanforderung umsetzt und die geschätzte aktuelle Pose laufend zurückmeldet. Da kann man nen Controller mit abstrahierter Schnittstelle für spendieren.

(Für nen Rasenmäher würde ich wirklich die Spinne präferieren, das ist neu, die Geländegängigkeit ist anwendungsbezogen, und grün lackiert würde sich das Teil bestimmt gut in die Landschaft einfügen. Da hat man dann auch keine Sorgen mehr mit Motortreibern, die das Teil über die Hügel treiben müssen)

kein Problem, keiner wird gezwungen, einen RP6 Nachfolger mit standardisierter Hardware in "größer und stärker" mitzuentwickeln - ich hätte es für eine gute Idee gehalten. Dass jeder für sich allein vor sich im Kämmerlein hin fuddelt ist ja eher der Normalfall.
24.05.2019, 07:49
fabqu

Also, ich weiß nicht, ob die Diskussion hier gerade vom Typ "aneinander Vorbeireden" ist.

Die ursprüngliche Idee, einen Nachfolger zu entwickeln, bezieht sich glaube ich auf das Konzept des RP6: gleiche Mechanik, gleiche Elektronik, gleiche Libraries und daher haben alle User eine identische Basis. Wenn es also einen "Nachfolger" geben soll, finde ich, sollten wir uns an diesem Konzept orientieren. Da ist es dann nicht mehr egal, ob Kette, Rad oder Füße.

Es gibt hunderte Module für alles, was das Herz begehrt, also für Hexapoden, Copter, Kettenfahrzeuge und Dinger mit Rädern. Von und für Arduinos, RaspPis und andere. Wer also etwas in diese Richtung will, muss sich mit dem "zusammenstöpseln" der jeweiligen Komponenten aus dem Internet beschäftigen. Das genau wollen wir hier aber denke ich nicht - korrigiert mich bitte wenn ich da was falsch verstanden habe.

Anforderungen an einen RP6 aus meiner Sicht:
- gleiches Chassis (ob nun mit Rad oder Kette oder anderes)
- Gleiche Hauptplatine mit grundsätzlichen Sensoren (Bumper, IR/Laser/Ultraschall o.ä., Odometrie, evtl weitere Umweltsensoren) und Aktoren (Motoren o.ä., Servos)
- Gleiche Libraries (C? Python?)
- Evtl Module wie es sie für den RP6 gab, im Stile M32, M128, M256
- Lern(!!!)Roboter: es sollte z.B. durch gut dokumentierte Libraries und niedrige Hürden (Arduino IDE etwa) möglich sein, auch als Anfänger sich mit diesem Roboter zu beschäftigen und das Hardwarenahe Programmieren zu erlernen

Können wir uns auf diese Grundlagen einigen? Ich denke, erst dann kann man den nächsten Schritt gehen und sich Überlegen, ob der Bot krabbeln oder rollen soll und welches Hirn wir drauf stecken.

Grüße
24.05.2019, 08:25
HaWe

hallo,
@fabqu: ja, genau so hatte ich es eigentlich auch gemeint, wobei man evtl doch auch aus Vereinfachungsgründen die ein oder andere wirklich gute und preiswerte Fertigplatine vom Chinesen standardmäßig mit einbinden und "anstöpseln" könnte (ohne dass ich jetzt eine spezielle schon im Auge hätte).

PS,
edit:
Ich selber könnte z.B. gar nicht selber löten, wegen einer zunehmenden Augenerkrankung.
24.05.2019, 13:12
inka

Zitat:

Zitat von HaWe

Dass jeder für sich allein vor sich im Kämmerlein hin fuddelt ist ja eher der Normalfall.

stimmt, das war damals bei der entwicklung der RP6-erweiterungen anders...
24.05.2019, 19:34
HaWe

kein preemptives Multithreading - das war für mich der Grund, für viele Apps eine Alternative zu Arduinos zu suchen und teilw. zum Raspi mit Posix pthread zu wechseln.
Keine Frage, was seine Performance mit 4Kern-cpu, USB, Multimedia, Grafik und Bildverarbeitung (gtk, qt, opencv) angeht, ist er allen Arduinos haushoch überlegen -
- aber jetzt kann ihm der ESP32 fast das Wasser reichen.

Seine Entwickler haben "echte" C++ std Funktionen implementiert, und nun läuft sogar std::thread mit preemptivem Multithreading, unglaublich.
Dabei hat er immerhin eine 2-Kern-cpu mt 240MHz und fpu (1 Kern nur für WiFi), die WiFi/Webserver-API ist fast ähnlich simpel wie beim esp8266, nur beim RAM wird etwas "gemogelt", weil für stat. RAM "nur" 160 MByte zur Verfügung stehen und weitere 160MByte nur als zusätzliches dyn. RAM auf dem Heap per malloc, doch auch daran arbeiten sie, um es auch statisch zur Verfügung zu stellen.
Dabei lässt er sich wie ein Arduino Uno, Mega oder Due über die Arduino IDE programmieren, und sein UART steht als Serial1 (RX1/TX1) zusätzlich zu USB-Serial zur Verfügung. Wifi fordert zwar ein paar ADC Port-Pins ein, aber was bleibt ist fast ein Nano mit Raspi Zero Performance. Hier könnte ich mir z.B. vorstellen, für mehr schnelle und pwm-fähige digitale Pins oder spezielle Arduino-R3-Shields noch ein 2. Arduino-Huckepack-Board per UART dranzuhängen - was allerdngs auch für den Raspi in ähnlicher Weise nötig sein wird.

Für einen RP6-Nachfolger wäre der ESP32 (meiner ist ein Adafruit Feather ESP32 mit 480x320 Touchscreen) neben Raspi 2/3 und Raspbian+wiringPi definitiv ein super Kandidat.
24.05.2019, 20:14
Rabenauge

Ich halt nicht viel von der Idee.
Warum?
Ich mochte den RP6 nie wirklich. Meiner Meinung nach ist er, vom Konzept her, zwar zu vielem fähig, aber zu nix so richtig nütze. Kettenantrieb: cool!
Aber wenn das Ding schon mit Türschwellen Probleme kriegt, wirds etwas albern- da hätten zwei Räder und ein halber Tischtennisball auch gereicht.
Aufm Stubentisch brauch ich wirklich kein Kettenfahrwerk....
Ausserdem halte ich nichts von irgendwelchen Bibliotheken, die sich ein Hersteller (oder auch ne Community) speziell für _diesen_ Roboter ausgedacht hat.
Da hängt man dran, man benutzt sie, aber wenns mehr werden soll, hat man es schwieriger.
Von daher sehe ich es ähnlich wie Moppi: Arduino Mega 2560 (ich möchte hier denjenigen sehen, der den, als Roboter, wirklich voll ausnutzen kann, irgendwelche akademischen Benchmarks bringen es nicht), dazu aber kein Wifi-Shield.
Das braucht man nicht: gerade der Mega hat so schöne serielle Schnittstellen, wo man ohne weiteres einen NodeMCU ran tüdeln kann....wenn man Wifi eben haben will. Das tolle: nen Mega-Clone und nen NodeMCU zusammen kriegt man für...na sagen wir nen Zehner.
Was leistungsfähigeres _ist_ cool, keine Frage, aber: der RP6 wollte eher ein Anfänger-Gerät sein(isser auch, finde ich)- nun setzt mal einen Anfänger vor nen Raspi: ihr liefert ihm einige Bibliotheken und Beispielprogramme mit, er probiert die aus- und dann?
Dann sitzt er vor einem, kaum noch zu begreifenden Rechenmoster und weiss nicht weiter.
Und mal ehrlich: um ein paar Motoren (meinetwegen auch ein halbes Dutzend) anzusteuern brauch ich noch lange keinen Raspi!
Das krieg ich mitm Uno auch hin....und selbst, wenn da ein GPS und ne Tüte voller anderer Sensoren ins Spiel kommen, geht das noch lässig mit nem Arduino Mega- ausgelastet ist der damit nicht.
Ich halt nix davon, jedes Problem einfach mit geballter Rechenleistung zu erschlagen, das ist weder sinnvoll, noch nötig- und man lernt auch nix bei.

Dann das Fahrwerk: da will jeder was anderes haben. Der eine will, dass es draussen klarkommt (*handheb), dem anderen reicht eine Teppichratte vollkommen aus. Das geht, alles, wenn man gar kein "fertiges" Teil entwickelt: dem Rechner ist es nämlich egal, ob er Treiber ansteuert, die 2A bei 5v liefern, oder welche, die 15A bei 30V bringen.

Fazit: man entwickelt _entweder_ einen "Bausatz"- von denen es meiner Meinung nach genug gibt, und den dann nur Leute kaufen (oder eben bauen) werden, in deren Beuteschema das Ding passt, oder man macht es wie ich:
-das will ich haben
-das brauche ich dafür
-zeichnen, einkaufen, Lötkolben schwingen, drucken
-happy sein, wenn es läuft.

Guckt einfach mal bisschen auf Thingiverse rum, da schwirren einige Roboter rum, die teilweise recht nett sind (z.B. ein ganz niedlicher FPV-Rover mit Raspi), aber es gibt auch einzelne Kettenfahrwerke zum selber drucken (die hab ich z.B. modifiziert, an meinem Kettenrover dran), alles Mögliche.
Mit sowas ist man weit flexibler als mit einer fast-fertig-Lösung, die nur ne Weile interessant ist (ich war auch ne ganze Weile von meinem NiboBee fasziniert, inzwischen staub ich den zweimal im Jahr ab und das wars).

Viel sinnvoller wäre es, flexible Chassis zu entwickeln denn: was da so auf dem Markt ist, gefällt mir entweder überhaupt nicht (wie der völlig nutzlose Wild Thumper, der gnadenlos am eigenen Konzept vorbei rauscht), oder ist so teuer, dass ich gar nicht drüber nachdenke.
Ob dann da jemand nen Pi, eine Banane oder nen Pro Mini reinschraubt, sollte unwichtig sein.

Etwas ähnliches ist mein Kettenroboter: der ist schonmal outdoor-tauglich.
Einfach, weil er ein geschlossenes Gehäuse hat (auch oben ist der zu, ein bisschen Regen juckt den nicht)- der wäre _im Prinzip_ auch tauchfähig zu bekommen.
Trotzdem kann man ihn drinnen auch fahren.
Ich hab (der war nur für gedacht, selber gedruckte Ketten mal auszuprobieren) einen NodeMCU drin und zusätzlich nen kleinen Arduino- ich glaube, ein Micro. Gesteuert wird das Ding einfach per Handy mit ner simplen App, und er hat, ausser zwei Motoren, eigentlich nix sinnvolles (ne handvoll RGB-Led's. aber die sind eher zum Angeben da).
ABER: der hat noch Aussparungen, in die man z.B Umwelt-Sensoren (sowas wie Luftdruck, Feuchte, Temperatur) bauen kann, und innendrin genug Platz auch für einen RasPi.
Den Deckel kann man abschrauben, und durch einen anderen ersetzen, dann könnte man einen Roboterarm genauso rauf bauen wie nen Laser-Scanner oder sonstwas.
Front und Heck sind ebenfalls einzelne Teile, auch hier könnte man erweitern....genauso war die Absicht dahinter.

Einziger Nachteil: das Ding gibts nirgends zu kaufen- die Dateien könnte ich frei geben, aber man braucht nen 3D-Drucker.
Und: er ist auf das zugeschnitten, was ich vor hatte- um den wirklich flexibel zu machen, müsste man einiges umkonstruieren.
Beispielsweise hab ich Abstandshalter für die Platinen gleich mit einmodelliert, die werden also passend mit gedruckt.
Aber das ist alles machbar.

Wenn also jemand hier Lust hat, mal ein _brauchbares_ und universelles Chassis zu entwickeln, was man selbst drucken kann (ggf. mit zugekauften Teilen, es macht nicht unbedingt Sinn, auf Krampf _alles_ drucken zu wollen), bin ich dabei aber: Bedingung ist, dass die Rechentechnik _nicht_ festgelegt wird.
Da soll mal jeder sein eigenes Süppchen kochen-wie man weiter oben ja deutlich sieht, wollen das wohl die meisten auch.
Schliesslich würde _das_ niemanden dran hindern, für _seine_ Lösung dann Bibliotheken zu schreiben, und zu veröffentlichen, womit das Ganze wiede anfängerfreundlich werden kann.
24.05.2019, 21:02
HaWe

Liste der Anhänge anzeigen (Anzahl: 1)

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.
Anhang 34176
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.
25.05.2019, 10:21
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.
25.05.2019, 10:39
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).
25.05.2019, 14:00
Holomino

Zitat:

Zitat von HaWe

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.
25.05.2019, 14:03
HaWe

gute Idee, danke!
25.05.2019, 17:55
inka

nur als idee, aber vielleicht könnte man endlich mal omniwheels verwenden?
25.05.2019, 18:11
HaWe

Zitat:

Zitat von inka

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
26.05.2019, 13:23
Holomino

Wenn wir schon beim Sammeln von Antriebsarten sind: SynchroDrive gibt's auch noch.
26.05.2019, 18:20
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?
27.05.2019, 09:58
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.
27.05.2019, 20:02
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.
28.05.2019, 11:23
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:

Code:

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.
28.05.2019, 11:33
HaWe

ja, genau, so mache ich es auch schon bei meinen Fischertechnik- und Lego RCX- und NXT-Bricks seit fast 25 Jahren ;)
Die Basis sehe ich aber zunächst in der mechanischen Basis, dann in den MCUs/SoCs.
28.05.2019, 12:07
Holomino

Man kann sich ja auf etwas Bestehendes von Sumo über Arduino-Fahrgestell bis hin zum Ardumower einigen. Im Zweifelsfall kann man auch die Mechanik des RP6 weiter verwenden (Mechanik veraltet nicht), und nur die Elektronik gemeinsam aufpeppen.
28.05.2019, 12:19
HaWe

Zitat:

Zitat von Holomino

Man kann sich ja auf etwas Bestehendes von Sumo über Arduino-Fahrgestell bis hin zum Ardumower einigen. Im Zweifelsfall kann man auch die Mechanik des RP6 weiter verwenden (Mechanik veraltet nicht), und nur die Elektronik gemeinsam aufpeppen.

Teilweise ja -
aber für 200W Motoren (stall) und >=10kg Payload und jetzt 20cm Rädern kommt man da mechanisch/elektrisch mit dem RP6 doch nicht sehr weit, oder?
Welches fertige Fahrgestell genau samt Motorisierung stattdessen?
28.05.2019, 12:27
Holomino

Die Teile des Ardumower (https://www.marotronics.de/) gefallen Dir nicht?
28.05.2019, 14:14
HaWe

Zitat:

Zitat von Holomino

Die Teile des Ardumower (https://www.marotronics.de/) gefallen Dir nicht?

auf dieser Übersichtsseite https://www.marotronics.de/Rasenroboter leider nicht - entweder zu kein oder viel zu teuer (>400,-, auch Antriebssets knapp 200,- )
edit: 24V Technik finde ich auch nicht so gut wie 12V, und die Motoren sind doch auch etwas schwach, oder?

- oder was denkst du?
28.05.2019, 14:45
Holomino

Tja, ich denke, solange die benötigten Komponenten nicht in den Consumerbereich fallen, wirst Du es nicht viel günstiger zusammenbekommen. Die Antriebsklasse 24V fällt eher in den Industriebereich. Selbst mit Eigenbau des Getriebes über Zahnriemen oder Ketten wird's nicht wesentlich billiger (aber deutlich größer).
Sprich: bevor ich 100 Euro für ne DIY-Lösung mit Ausfallrisiko (Funktion, Lebensdauer) ausgebe, gebe ich lieber 200 Euro für eine voroptimierte Lösung mit Umtauschrecht aus.

Aber ich bin auch kein Maschinenbauer.
28.05.2019, 14:54
HaWe

hmh, ist was dran...
28.05.2019, 18:21
Rabenauge

Ist auch so.
Ein funktionierendes, und auch dauerlast-fähiges Fahrgestell zu bauen, ist nicht ganz ohne.
Selbst RC-Autos haben eine "Lebensdauer" von relativ wenigen Betriebsstunden- dann gibts Verschleisserscheinungen.
Dazu kommen dann noch Geschichten, wie die Tatsache, das man ein Rad, an dem 200W Antriebsleistung wirken, nich mehr einfach auf ne Welle klopfen kann, man braucht also ne Welle mit Mitnehmer (mindestens abgeflacht) und so weiter.
Dazu ein _vollständiger_ Dreckschutz, sonst encoderts nicht lange, und so weiter, und so fort...

Dass man, wenn man Leistung braucht, eher auf höhere Spannung setzt hat einen einfachen Grund: der Strom geht runter.
Das ist einfacher zu handhaben.

Ganz ehrlich: das 10Kilo-Fahrwerk ist schon eine recht spezielle Sache (ich z.B. würde mich mit fünf völlig begnügen), das wird nur wenige wirklich interessieren.
Alleine ein Getriebe zu finden, was diesen Antriebs-und Bremsleistungen stand hält (wenn der Brocken stubentaglich sein soll, muss er ggf. _sofort_ stoppen können, schon aus Sicherheitsgründen), dürfte ne Herausforderung sein- ggf. für die Brieftasche.

40 Beiträge dieses Themas auf einer Seite anzeigen