Leistungsfähigerer Nachfolger für RP6?

[HaWe]

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

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

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

[HaWe]

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.

du kannst ja noch _nicht_ _einmal_ _sicherstellen_, dass das Auto die _Minimalbedingungen_ erfüllt - und _solange_ ist es _zumindest_ keine _ernstzunehmende_ Option.
Zitat:

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,

Im Übrigen kosten Getriebe-Motoren kaum mehr als 20-30 EUR po Stück (siehe dein _eigener_ Link), Rest aus China, da kann etwas _von_ _Grund_ auf _selber_ zusammengebautes nicht _wesenlich_ teurer werden.
Da _du_ aber ja _eigentlich_ gar nicht daran _selber_ interessiert bist, hier mitzumachen, weiß ich auch gar nicht, ob _deine_ Bauvorstellungen mit der im _TOP_ geschilderten idee überhaupt in _Einklang_ stehen müssen.