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.Zitat von Holomino
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
Indoors ganz interessant, besonders für Fussballroboter etc., aber
a) schecht für Odometrie und
b) schlecht für draußen, weil sie schnell verdrecken und
c) auch sehr schlechten Grip haben
Wenn wir schon beim Sammeln von Antriebsarten sind: SynchroDrive gibt's auch noch.
Entsprechende Räder gehn draussen natürlich auch- aber die üssen dann _wirklich_ gross sein.
Mein RC-Monstertruck (ein 1:10er) hat Räder mit 120mm Durchmesser- die selben wie der Wild Thumper.
Damit geht, wenn man geschickt fährt, eine Bordsteinkante _geradenoch_.
Halbwegs ordentlicher Rasen auch, im höheren Gras machts keinen Spass mehr.
Von daher würde ich die, bei HaWe's Anforderungen, als das Minimum ansehn.
Allerdings haben die das selbe "Problem" wie Ketten: wenn man ein vierrädriges Fahrzeug damit baut (meinetwegen auch sechs Räder), ist die Odometrie auch nicht mehr besser...insofern: im Zweifelsfall _sind_ Ketten geländegängiger.
Räder haben hauptsächlich einen Vorteil (abgesehen von dem beschriebenen Szenario: Parkett-oder Fliesenboden, wo man mit Gummiauflagen auch was machen kann): man kann deutlich schneller fahren.
Zwar kann man auch Kettenfahrwerke bauen, die Highspeed-tauglich sind, aber das ist dann deutlich aufwendiger.
Also, HaWe: wie willst du lenken, um eine saubere Odometrie hinzukriegen?
Bei allem, was mit ner Panzerlenkung funktioniert, kannst du es vergessen.
Irgendwann "später mal" hab ich vor, einen Wild Thumper "in richtig" zu bauen: das Antriebskonzept von dem Ding ist nämlich gut: drei Räder pro Seite, jedes mit eigenem Motor, das ergibt ne Geländegängigkeit fast wie mit Ketten, aber ohne viel Aufwand auch die Möglichkeit, schnell zu fahren.
Die Getriebemotoren vom Thumper gibts mit und ohne Encoder, in verschiedenen Ausführungen- gute Sache!
Die Federung dagegen ist Unsinn: die brauchts nicht, wie gesagt: ich kenne diese Reifen. Die fangen das Nötigste lässig ab. Da kann man auch mit verschiedenen Einlagen experimentieren (Schaumstoff rein, das ist im RC-Modellbau, woher diese Räder stammen, üblich).
Und das völlig offene Chassis müsste man halt durch ne richtige Wanne ersetzen.
Allerdings: so ein Rad trägt, na sagen wir mal vorsichtig 2 Kilo.
Also mit zwei Kisten Bier wird das nix- oder man braucht ganz viele.
Also HaWe: wie stellst du dir die Lenkung vor?
Grüssle, Sly
..dem Inschenör ist nix zu schwör..
Naja, andere Konzepte basieren ja auch nicht unbedingt auf der Odometrie als Hauptnavigationsmerkmal (Ich mag mich da gewaltig irren, aber ich glaube nicht, dass bei autonomen KFZs jemand auf die Idee gekommen ist, den Lenkausschlag in die Positionsberechnung einzubeziehen). Im Zweifelsfall verkommt die Weg- oder Geschwindigkeitsmessung an den Rädern eben zum Ist-Wert der Motor-Regelschleifen.
Was mir allerdings jetzt schon nach ein paar wenigen Stunden Recherche über die Konfiguration entsprechender Antriebe bei der von HaWe angepeilten Last und Größe deutlich missfällt: Dat wird nisch janz billisch. Wo ich bei kleineren Unterhaltungsmodellen für den Antriebsstrang (Räder/Motoren/Treiber/Akkus) vielleicht 30 Euro ausgebe, kann ich für was Größeres mal schnell noch ne null hinten dran hängen.
Was ich bemerkenswert fand: Ich hab mir mal die Ardumower-Seite angeschaut. Selbst die bieten ein kleines Modell "für Entwicklungen/Tests in der Winterzeit" an. Auch da finde ich die Idee wieder, eine Plattform auf unterschiedliche Anwendungen zu skalieren.
Geändert von Holomino (27.05.2019 um 10:12 Uhr)
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