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?was sollte dann DAS:Zitat von Moppi
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?was sollte dann DAS:
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.
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.
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.
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
hallo,
@fabqu: ja, genau so hatte ich es eigentlich auch gemeint, wobei man evtl doch auch aus Vereinfachungsgründen die ein oder andere wirklich gute und preiswerte Fertigplatine vom Chinesen standardmäßig mit einbinden und "anstöpseln" könnte (ohne dass ich jetzt eine spezielle schon im Auge hätte).
PS,
edit:
Ich selber könnte z.B. gar nicht selber löten, wegen einer zunehmenden Augenerkrankung.
Geändert von HaWe (24.05.2019 um 12:22 Uhr)
nur als idee, aber vielleicht könnte man endlich mal omniwheels verwenden?
gruß inka
stimmt, das war damals bei der entwicklung der RP6-erweiterungen anders...
gruß inka
kein preemptives Multithreading - das war für mich der Grund, für viele Apps eine Alternative zu Arduinos zu suchen und teilw. zum Raspi mit Posix pthread zu wechseln.
Keine Frage, was seine Performance mit 4Kern-cpu, USB, Multimedia, Grafik und Bildverarbeitung (gtk, qt, opencv) angeht, ist er allen Arduinos haushoch überlegen -
- aber jetzt kann ihm der ESP32 fast das Wasser reichen.
Seine Entwickler haben "echte" C++ std Funktionen implementiert, und nun läuft sogar std::thread mit preemptivem Multithreading, unglaublich.
Dabei hat er immerhin eine 2-Kern-cpu mt 240MHz und fpu (1 Kern nur für WiFi), die WiFi/Webserver-API ist fast ähnlich simpel wie beim esp8266, nur beim RAM wird etwas "gemogelt", weil für stat. RAM "nur" 160 MByte zur Verfügung stehen und weitere 160MByte nur als zusätzliches dyn. RAM auf dem Heap per malloc, doch auch daran arbeiten sie, um es auch statisch zur Verfügung zu stellen.
Dabei lässt er sich wie ein Arduino Uno, Mega oder Due über die Arduino IDE programmieren, und sein UART steht als Serial1 (RX1/TX1) zusätzlich zu USB-Serial zur Verfügung. Wifi fordert zwar ein paar ADC Port-Pins ein, aber was bleibt ist fast ein Nano mit Raspi Zero Performance. Hier könnte ich mir z.B. vorstellen, für mehr schnelle und pwm-fähige digitale Pins oder spezielle Arduino-R3-Shields noch ein 2. Arduino-Huckepack-Board per UART dranzuhängen - was allerdngs auch für den Raspi in ähnlicher Weise nötig sein wird.
Für einen RP6-Nachfolger wäre der ESP32 (meiner ist ein Adafruit Feather ESP32 mit 480x320 Touchscreen) neben Raspi 2/3 und Raspbian+wiringPi definitiv ein super Kandidat.
Berechtigungen
Zitieren
Lesezeichen