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++)
Geändert von HaWe (30.10.2020 um 17:48 Uhr)
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.Zitat von Moppi
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.
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
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
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 - - -
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.
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.
Geändert von Holomino (23.05.2019 um 00:13 Uhr)
"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)
@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üß...
Berechtigungen
Zitieren
Lesezeichen