Leistungsfähigerer Nachfolger für RP6?

[Moppi]

@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?

Und tschüß...

[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

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

für jemand, der damit privat ein wenig herumbasteln will, mag das eine interessante Herausforderung sein, aber hier stimmen weder die Größe (Ziel: ca. 30x50cm), noch ist sichergestellt, dass sich überhaupt 2 einzelne vorhandene Antriebsmotoren mit Encodern nutzen lassen und sich das ganze auch in einen Differentialantrieb mit Arduino-H-Brückensteuerung umbauen lässt, und daher halte ich es als Basis für ein Community-RP6-Nachfolgeprojekt für ungeeignet.

[Rabenauge]

Du wirst _nichts_ geeigneteres, als halbfertig-Lösung finden-was jemand bezahlen will.
Deine Vorstellungen sind das eine, aber die Wirklichkeit sieht halt so aus, dass niemand solche Monster "redy for robot" in ausreichenden Stückzahlen herstellt, damits erschwinglich wird.

Ist ja nicht so dass es _derartige_ Plattformen nicht gäbe- wenn du _das_ bezahlen willst...das ist dann eher im vierstelligen Bereich.
Und damit für 99% der Roboter-Bauer uninteressant.