Leistungsfähigerer Nachfolger für RP6?

[HaWe]

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?

@HaWe
Und tschüß...

was sollte dann DAS:

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.

[Holomino]

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.

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

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

[HaWe]

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.

[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

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

[inka]

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

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

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