Leistungsfähigerer Nachfolger für RP6?

[HaWe]

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

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.

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

[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

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

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]

das modulare Konzept samt SLAM finde ich gut, nur war meine Idee eben ein wirklich praktisch einsetzbarer, größerer Haus- und Gartenroboter mit stärkerem Antrieb und leistungsfähigerer MCU (ESP32, M4, Raspi), nicht nur ein kleines Modell.
Die Radencoder müssten allerdings Rotationsencoder sein.