Think Modular

[Moppi]

Hallo,


finde ich zunächst mal gut, dass es doch so schnell was geworden ist, dass Du das hier so ausführlich rein setzt!
Also erst mal großes Danke dafür!


Zwar etwas schwer zu verstehen, wenn man nicht in der Materie drin steckt, aber ich kann den Rahmen erkennen.


Ich weiß, dass andere wieder Vorschläge haben (werden).


Ich habe auch meine eigene Vorstellung, wie mein Roboter mal funktionieren soll. Ich gehe dabei sicher ähnlich,
aber wieder anders vor. Mein Gedankengerüst auf dieses Modell zu übertragen, fällt mir eher schwer.




Ich versuche mal ein Brainstorming:


aufkommende Fragen:
- Programmierwerkzeuge und welche Programmierumgebung ist notwendig
- worauf ist die Software lauffähig, benötigte Hardware (Mindestanforderungen)
- wie lässt sich die Software weiter entwickeln


was ich mir vorstellen könnte (Wünsche):
- Softwareausführung möglichst lauffähig auf vielen Geräten (Desktop-Computer, Mikrocomputer, Betriebssystem egal)
- einfach, leicht zu bedienen = kurze Einarbeitungszeit
- benötigte Hardware: alles was gängig ist an AVR bzw. favorisieren würde ich die Arduino-Serie (ab Nanao aufwärts) und die ESP für WIFI
- Programmierungebung wäre hier Arduino - IDE in C++, mit allem, was es dazu gibt und geben wird


Protokolle / Datenverbindungen:
- UART/Serial, I2C


Speicher erweiterbar:
- SD-Karte, Filesystem(?), Speichergröße (ESP)?




- Hardwaremodule?




Anzumerken ist, dass jeder, aufgrund dessen, was er bisher gebaut hat oder noch baut, irgendwie vorbelastet ist.
Deswegen könnten wir jetzt alle unsere Ideen in relativer Kurzform vorbringen? Holmino war nun recht ausführlich, das muss ich nicht noch mal machen,
habe an anderer Stelle schon sehr viel geschrieben, was ich zurzeit mache. Inkas Vorhaben kennen hier eigentlich auch alle.


Vielleicht finden sich noch mehr und wir sammeln, was jedem so einfällt?



Freundlichen Gruß

[jmoors]

Ich denke auch schon längere Zeit über einen DIY-Robi nach. Zuerst dachte ich an einen R2D2 ähnlichen Robi, wie im Droidbuilders-Portal ein paar mal beschrieben. Ich hatte mir auch die R2D2s der Astroch-Mechs auf der MakerFair in Dortmind angeschaut und kann dazu nur eins sagen: Respekt! Das sind klasse Show-Roboter für Events, aber nichts für mich, denn ich will eine Art technische Versuchsplattform.

Daraus resultiert Anforderung 1: Das Teil soll eine technische Experimentierplattform sein, d.h. modular erweiterbar. Ich möchte alle möglichen Sensoren darauf montieren können, u.a. auch in einem drehbaren Turm, um zum Beispiel Geräusche mit einem Mikrofon-Array orten zu können

Da wir ein eigenes Haus haben, soll das Teil auch überall hin können. Es muss sich also auch über Treppen fortbewegen können. Deshalb schaue ich mir gerade die openDog V1-Videos von James-Bruton (https://youtu.be/0BoPoWF_FwY). Das Ding ist schon gut gemacht, aber heftig teuer: 12 Motoren á 80€ + 12 Kugelumlaufspindeln á 50 € + 12 Motor-Regler á 40€ + (vermutlich) 500€ für die Profile und Zubehör + ganz viele selbst gedruckte Teile + .... Bevor das Teil vor einem steht, hat man ganz sicherlich irgendwas oberhalb von 3000€ verbraten! Dennoch finde ich das Teil irgendwie cool. Aber mit 6 Beinen würde mir so etaws besser gefallen. Die Größe finde ich aber OK und das Teil ist Mega-Stabil!

Daraus resultiert Anforderung 2: Das Teil soll Treppen auf- und absteigen können. Das ist schon eine heftige Anforderung, auch wegen der Programmierung und Erkennung von Treppen.

Anforderung 3 wurde von Holomino schon genannt: Autarkes operieren.

Anforderung 4: Kommunikation. Der Robi soll mich z.B. per Email oder SMS anfunken, wenn etwas im Haus ist, wie eine Alarmanlage. Bedeutet: Das Teil muss einen WLAN-Adapter haben, denn Robis mit Kabel sind uncool. Der Robi soll auch eine Verbindung ins Internet haben, um mir z.B. Spotify abzuspielen --> Gute Lautsprecher!

Anforderung 5 wurde auch schon von Holomino genannt: Der Robi soll selbst zur Ladestation finden und sich selbst laden, wenn die Batterie leer läuft.

Als Steuerungsplattform habe ich mir einen zentralen RasPi gedacht, der diverse Module (Arduinos, andere RasPis) ansteuert. Jedes Modul (Mikrofon-Array, Kameras, Fortbewegung, etc.) soll seinen eigenen Computer haben.

Als Programmiersprache habe ich mir Python gedacht, da Python einfach, plattformübergreifend und universell ist. Außerdem kann man Java- und C-Libraries einbinden. Im letzten Jahrtausend hatte ich ab und an mal C und viele andere Sprachen programmiert, je nachdem, was gerade angesagt war. Somit stelle ich mir den Einstieg in Python nicht besonders schwer vor. Die Entwicklungsumgebung ist mir egal, solange sie Offline funktioniert und kein Vermögen kostet, am liebsten Open Source, damit ich keine Rücksicht auf irgendwelche Einschränkungen des Herstellers nehmen muss.

Wie denkt ihr darüber?


Gruß, Jürgen

[Moppi]

Vielleicht solltest Du Dich mit einem Hexapod-Robotern auseinander setzen? Wenn Dir das andere zu teuer ist, die Zeit zum Bau ist ja auch noch nicht eingerechnet.
Beim Hexapod kommst Du bei 18 Motoren eventuell auf 1000€, wenn Du keine Micro-Servos einsetzt. Um 20cm Stufenhöhe zu schaffen, sollte das Gerät aber auch nicht zu klein sein. Und da kommst Du an den Punkt, dass Du eher einen kleinen Roboter möchtest. Baust Du einen mit Ketten, der eine Treppe rauf fahren kann, muss der auch eine bestimmte Größe haben. Vielleicht ist ein Flugmodell, das auch fährt, dann eher was, um die Baugröße zu reduzieren. Allerdings wirst Du dann auch hier eine gewisse Größe haben müssen, um das Gewicht von wenigstens 2kg bis 3kg zu stemmen.

MfG

[Holomino]

Wie denkt ihr darüber?

Ich denke, Du solltest mindestens noch einen Arm zum Bedienen von Türklinken einplanen.

[Gerdchen]

Daraus resultiert Anforderung 1: Das Teil soll eine technische Experimentierplattform sein, d.h. modular erweiterbar. Ich möchte alle möglichen Sensoren darauf montieren können, u.a. auch in einem drehbaren Turm, um zum Beispiel Geräusche mit einem Mikrofon-Array orten zu können

Da wir ein eigenes Haus haben, soll das Teil auch überall hin können. Es muss sich also auch über Treppen fortbewegen können.

Daraus resultiert Anforderung 2: Das Teil soll Treppen auf- und absteigen können. Das ist schon eine heftige Anforderung, auch wegen der Programmierung und Erkennung von Treppen.

Wie denkt ihr darüber?

Gruß, Jürgen

Mir gefallen die Konzepte dieser beiden Rover/Roboter, besonders auch wegen der unabhängig verstellbaren Fahrwerksbeine mittels Spindelantrieb. Dadurch könnte sogar eine gewisse Treppensteigfähigkeit erreicht werden. Obendrauf ein Manipulator, oder was anderes. Als technische Experimentierplattform eventuell eine Überlegung wert. Auch der konstruktive Aufwand erscheint machbar.

https://robotik.dfki-bremen.de/uploa..._Sherpa_de.pdf
https://robotik.dfki-bremen.de/uploa...herpaTT_de.pdf

Gerdchen

[jmoors]

Ich bin gerade auf Flir.com gestoßen. Da gibt es https://www.flir.com/products/kobra/ Robots mit Kette, die Treppen steigen können. So ein System halte ich für realisierungsfähig, ohne direkt 3000€ für das Fahrgestell zu investieren. Die Ketten und Getriebe wird man sich sicherlich drucken müssen. Wäre doch eine interessante Basis.

[Gerdchen]

Ich bin gerade auf Flir.com gestoßen. Da gibt es https://www.flir.com/products/kobra/ Robots mit Kette, die Treppen steigen können. So ein System halte ich für realisierungsfähig, ohne direkt 3000€ für das Fahrgestell zu investieren. Die Ketten und Getriebe wird man sich sicherlich drucken müssen. Wäre doch eine interessante Basis.

Tolles Teil. So ein "Kettensystem" ist natürlich äußerst agil und auch einfacher zu realisieren. Kettenantriebe haben allerdings ein Problem, wenn eine Kette versagt, dann
fällt meistens das gesamte System aus. Wenn eine sofortige Instandsetzungsmöglichkeit besteht ist das auch kein Drama. Bei einem Einzelradantrieb kann auch mit nur einem funktionsfähigen Rad noch gefahren werden (bin ein Fan von solchem Raumfahrtkrempel).

[Holomino]

Man kriegt aus diesem Baukastensystem nie und nimmer ein Schiff oder ein Fluggerät zusammengeschraubt. Und auch keinen Panzer. Man kriegt nichtmal ein richtiges Rennauto oder etwas anständig Geländegängiges damit hin.

Hi White_Fox,
dunnerdieWaldFee, Du schraubst die Messlatte ganz schön hoch. Trotzdem versuche ich's mal:

Alle Plattformen haben als Bewegungsmodul die gemeinsame Eigenschaft, per innerem Regelkreis ihre Positionsänderung grob zu schätzen. Selbst Flugzeuge können das per IMU, Höhen- und Geschwindigkeitsmessung. Grob heißt hier mit Abweichungen, aber relativ schnell.
Wie Du nun über eine höhere Instanz die innere Regelung korrigierst, ist variantenreich: Korrektur über Lidar, Kamera, Radar, GPS oder die Sterne. Du wirst nicht für jede Variation ein neues Bewegungsmodul erfinden wollen.

Meine These: Wenn Du aus der höheren Instanz einer geplanten Bahn folgen willst, reicht eigentlich als Schnittstelle der Befehl MoveRelative(dx,dy,[dz]) und die zyklische Rückmeldung Moved(dx, dy, [dz]) aus dem Bewegungsmodul.
Das geht mit Fahr-/Flug-/Schwimmzeug auch um Kurven. Die Äußere Regelung zieht das Gefährt durch die Korrekturen praktisch wie am Gummiseil auf dem geplanten Pfad hinter sich her.

Erstaunlich dabei: Ein PKW hat nicht die gleichen Freiheitsgrade wie ein Panzer (kann nicht auf der Stelle drehen). Ein Flugzeug kannst Du nicht ohne weiteres auf einen Punkt hinterm Flugzeug lenken (es wird nicht rückwärts fliegen). Trotzdem bleibt die o.g. Schnittstelle zum Bewegungsmodul praktisch gleich. Den Wendekreis von Auto oder Flugzeug kannst Du nur in der höheren Instanz durch Neuplanung der Bahn berücksichtigen, weil nur die (im Gegensatz zum Bewegungsmodul) die Informationen zur Kollisionsvermeidung hat.

Es gibt sicher weitere interessante Aspekte:
Steht jmoors' spekulative Raupe vor der Treppe, wird das dann vom Bewegungsmodul oder von der höheren Instanz erkannt? Gibt die höhere Instanz also 2D-Befehle und die Raupe gibt alles, um die Treppe selbständig hochzumöllern? Oder gibt die Instanz den Befehl in 3D und das Bewegungsmodul hebt darauf brav entsprechend der Angabe der z-Komponente das vordere Kettenpaar?
Wenn ich einen Roboterarm auf einem Differentialantrieb montiere, nutze ich die Drehachse des Bewegungsmoduls? Wenn ja, wie drehe ich dann über MoveRelative(dx,dy,[dz])? Statt rauszufahren und wieder im richtigen Winkel einzuparken, wäre hier ein Turn(angle) sicher komfortabler.

Letztlich nur die Frage: Kann Dein Roboterfahrgestell das oder kannst Du Dir vorstellen, Deinem Roboter diese Schnittstelle beizubringen, so dass ich mein Programm und meine Sensorik draufbauen kann?

[Holomino]

So, nach 48h sacken lassen und meinem letzten Beitrag an WhiteFox mal hier die Frage in die Runde: Seht Ihr weitere Bezüge zwischen den Einzelteilen eines Roboters? Was wäre z.B. an Infos zwischen Akku und Navigation sinnvoll? Hat hier schon jemand z.B. die Restreichweite seines Akkus ermittelt und so das Ansteuern der Ladestation mit eingeplant? Was braucht man dafür?

[White_Fox]

Mir fehlt grundsätzlich etwas der rote Faden: Was soll das Konstrukt am Ende -- so in Etwa -- können?

Modularisierung ist schön, gut und hilfreich - keine Frage. Aber da gibt es normalerweise einen sehr eng gesteckten Rahmen.
Es soll beispielsweise am Ende auf jeden Fall ein Auto werden, die Autos sind alle irgendwie ähnlich und unterscheiden sich nur marginal: Alle haben einen Motor, alle haben ein elektronisches Unterhaltungsystem, alle haben vier Räder. Alle haben an jedem Rad eine Bremse, alle werden an derselben Achse angetrieben. Und alle Autos sind normale Straßenautos.

Man kriegt aus diesem Baukastensystem nie und nimmer ein Schiff oder ein Fluggerät zusammengeschraubt. Und auch keinen Panzer. Man kriegt nichtmal ein richtiges Rennauto oder etwas anständig Geländegängiges damit hin.

Modularisierung ist fast immer auch nur dann von Vorteil, wenn man in größeren Stückzahlen baut und entwickelt. Modularisierung bedeutet auch, technisch niemals die Anforderungen zu treffen, sondern durch die Modularisierungsforderung gibt es zusätzlich Einschnitte. Seien es z.B. ungenutzte Leitungen im Kabelbaum, eigentlich falsch gewählte Kommunikationsprotokolle (z.B. CAN für Daten, die eigentlich höhere Echtzeitanforderungen hätten) oder dergleichen.

Für Einzelstücke gibt es da kaum Vorteile. Höchstens, wenn man mehrere hinreichend ähnliche Sachen hin und wieder baut.

Die Frage wäre: Soll es jetzt ein Roboterarm werden, oder doch ein USV? Modularisieren kann man alles, und wenn man es auf Bauteilebene herunterbricht.