Leistungsfähigerer Nachfolger für RP6?

[HaWe]

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

[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

[HaWe]

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.

[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

[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

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

[inka]

ja, auch die hauptlatine. schaue bei conrad nach. vielleicht verkaufen sie noch was vom zubehör, was auch dort - im unterauftrag - entwickelt wurde.

[HaWe]

ah, ok, dann ist das ntl jetzt etwas aufwändiger, wenn man nun auch Chassis und Antrieb nicht schon fertig bekommt.
Immerhin bräuchte man aber keine neue Haupt- und Nebenplatine, wenn man Raspi+Huckepack-Arduino verwendet (wenn die Kommunikation mal bald funktioniert).

[inka]

ich habe mein lebenlang feinmechanik entworfen und konstruiert. Auch "bewegte" mechanik. Allerdings durch viele maschinen für prototypenferigung, fräs- blechbiege- und gussteile. Könnte es sein, dass du die mechanische seite etwas unterschätzst?