Anubis IV - vierbeiniger Laufroboter

[LeeMajors]

Hallo zusammen,

nachdem ich schon seit 2014 - immer mal wieder - hier im Forum Fragen stelle und nach Tipps frage, wollte ich dann auch mal ein halbwegs fertiges Projekt vorstellen - quasi als Ergebnis eures Inputs! ;-)


https://www.youtube.com/watch?v=3aXoK0X_6TA&ab_channel=MarcusWengenroth


3D Konstruktion & Druck
Der Roboter wurde in 3D konstruiert und die Teile bei Shapeways gedruckt. Das Modell davor (https://www.youtube.com/watch?v=esmmn6JMYlo&ab_channel=MarcusWengenroth) hatte ein Kumpel mir mit seinem 3D-Drucker erstellt. Inzwischen hab ich mich bei solchen Projekten wirklich von 3D-Druckern verabschiedet - aus folgenden Gründen:
- Die Geometrie muss den Beschränkungen des 3D Drucks folgen. D.h. die Teile sind z.B. in einer Dimension stabiler, als in der anderen.
- Die Ergebnisse sind viel ungenauer als bei Shapeways Versatile Plastic
- Die Ergebnisse sind viel instabiler.
- Dadurch muss die Materialstärke größer werden, d.h. der Roboter wird klobiger und ungelenkiger.
- Der Arbeitsaufwand ist enorm - wenn man die ganzen Fehldrucke berücksichtigt, weil der Drucker wieder an die Grenzen gestoßen ist.
- Die Kosten fürs Filament sind auch nicht zu unterschätzen, wegen Fehldrucken und stärkerer Materialstärke.
- Bei den gängigen 3D Druckern - oder erst Recht bei den Resin Druckern - ist der Druckbereich zu klein.

Der ganze Körper ist hier ein Stück, was viel Stabilität bringt und den Bau vereinfacht.
An einigen Stellen nutze ich Schnappverschlüsse statt Schrauben. Z.B. die Schalterkonsole kann einfach ohne Schrauben nach oben geklappt werden.
Die Füße haben eine 2-teilige Sohle, dazwischen ist jeweils ein Drucksensor. Der ganze Fuß kann 4mm einfedern. Der Grund ist, dass einmal das Gewicht etwas abgefangen wird, aber vor allem, dass ich 4mm vor der Bodenberührung schon weiß, dass der Boden nur noch 4mm entfernt ist. Latenz ist ja bei sämtlichen Sensoren und Aktoren ein Problem ist. Durch die 4mm kann ich hier etwas entgegenwirken.

Gewicht: Inkl. Akku 3.020g


Elektrik
Nach vielen Tipps von euch habe ich die Elektrik so einfach wie möglich gehalten. (Hab ja selber keine Ahnung davon ;-)). Die Energie kommt aus einem 5200mA 3S Hobbyking Lipo, der mit 363g für die Kapazität relativ leicht ist. Wenn man nicht rumläuft, hält der Akku ca. 4 - 5 Stunden, wie es bei der Lauferei ist, weiß ich noch nicht.
Die Spannung geht dann zu 6 Schaltern, 4 Schalter für die Servo-Stromversorgung für jedes Bein und 2 Schalter für 2 Spannungsregler für 2 Raspis und einen WLAN-Accespoint-Client. Da keine weitere Spannungsstabilisierung nötig ist, sind die Einschaltströme sehr gering und können ohne komplexere Elektronik einfach so über die Schalter laufen.

Servos: Ich benutze die recht teuren Dynamixel XM430-W350 Servos. Nachdem ich mich jahrelang mit RC-Hobby-Servos rumgeschlagen habe und nun relativ sicher war, dass ich den Roboter zum laufen bekomme, hab ich mich dazu entschlossen. Im Gegensatz zum Hobbyservo haben die Dynamixel folgende Vorteile:
- viel geringeres Spiel des Servorades - der Roboter wird weniger wackelig
- sehr präzise und unkomplizierte Ansteuerung
- die aktuelle Position und der Strom werden zurückgegeben
- die Kraft, mit der gearbeitet wird ist genau über mA justierbar (die RC-Servos arbeiten immer mit voller Kraft und können bei falscher Programmierung dann den eigenen Roboter zerstören)
- die Servos können in Reihe angeschlossen werden. Bei Anubis sind z.B. 3 Servos eines Beins in Reihe verbunden. D.h. die dicken Kabelbündel fallen weg.
- uvm.
D.h. ich kann zu jeder Zeit auslesen, in welcher Stellung sich der Roboter gerade befindet.

Rechner: Die Rechner sind 2 Raspi 4B. Eigentlich könnte man jetzt das WLAN der Raspis nutzen um darauf zuzugreifen und die 2 Raspis selber mit einem LAN Kabel verbinden. Ich hab mich allerdings für einen externen WLAN-Accesspoint entschieden, den ich im Client-Modus betreibe. Der Accesspoint hat einen 3fach Gigabit-Switch eingebaut, wo ich 2 Raspis einfach einstecken kann. Auf den Raspis ist WLAN & Bluetooth ausgeschaltet.

Der 1. Raspi ist grob für die Bewegungen zuständig, der 2. wird später die Bilder der 3D Kamera interpretieren und in einen 3D Raum umsetzen. Diese Aufgabe ist sehr rechenintensiv und würde die Bewegungsberechnungen stören - daher der 2. Raspi.

Es gab bei den 2 Raspis folgende Möglichkeiten:
- Beide benutzen ihr eigenes WLAN für die Kommunikation nach außen und Gbit-LAN für die Kommunikation untereinander - die WLANs haben sich aber gegenseitig gestört, ich hatte immer mal wieder Ausfälle von einigen Sekunden.
- Nur ein Raspi benutzt WLAN, Raspi 2 ist mit LAN an Raspi 1 angeschlossen und nutzt das WLAN des 1. - Dann hat der Raspi 1 allerdings mit routen auf alle Fälle wieder mehr zu tun und der sollte ja wichtigere Aufgaben erfüllen... und außerdem ist das Raspi WLAN eben auch nicht so stark, wie das des Access-Points.
- Ich habe mich dann für diesen Router entschieden: https://smile.amazon.de/gp/product/B07GBXMBQF/ref=ppx_yo_dt_b_asin_title_o06_s00 der die Jobs übernimmt und theoretisch sogar einen 3. Gbit-Anschluss hat.

Auf dem Raspi 1 ist ein selbstgebauter Hat, wo ich mehrere IC2 Module draufstecken kann, dort ist ein 8 Kanal 12Bit A/D Wandler wo ich 4 Kanäle für die Spannungsüberwachung und 4 Kanäle für die Drucksensoren der Füße nutze. Ebenfalls kommen dort die Stromversorgungen der Beine an und werden auf die entsprechenden Buchsen für die Servos verteilt.

An einem IC2 Anschluss befindet sich ein BNO055 Lagesensor, der u.a. auch die fusionierten Daten von Gyro, Magnetometer und Beschleunigung bereitstellt. (Sensorfusion ist recht kompliziert und auch leistungshungrig, weshalb es prima ist, wenn das im Chip automatisch passiert.) Die Lage kann ich mit einer Latenz von 0.12s auslesen, was sehr viel schneller ist, als vorher über einen über USB angeschlossenen Sensor.

Ansonsten sind die Raspis erstaunlich leistungsfähig. Der Vorgänger hatte einen StickPC verbaut = schwerer und teurer. Ich denke, Linux als Betriebssystem macht schon viel aus und bremst um Welten weniger als Windows.

Vorne ist noch eine Intel RealSense D435 verbaut, damit Anubis später autonom die Umgebung erkundschaften kann.

Software
Auf den 2 Raspis läuft das normale Raspberry Pi OS. Die Logik der Roboters ist in Python 3 programmiert. Außerdem gibt es ein Web-Frontend auf Apache Basis, also php, html, clientseitig Javascript. Die Kommunikation zwischen Website (Client) und Python passiert in Echtzeit über eine Websocket-Verbindung. Der Game-Controller lässt sich prima über JavaScript auslesen und an den Roboter übertragen. Ebenfalls gibt es einen Simulationsmodus, wo Anubis vereinfacht über WebGL angezeigt werden kann und in Ruhe - ohne Angst um Servos und Mechanik - die Bewegungen getestet werden können.

Nach einigen Anlaufproblemen hab ich dann die Inverse Kinematik auch in den Griff bekommen - es hat nur recht lange gedauert, bis der Groschen gefallen ist. Damit Anubis nun überall hinläuft, wo ich ihn hin haben will, definiere ich einfach die Position und die Lage des Körpers und die Füße müssen sich entsprechend anpassen. Zunächst mal heben die sich, grob gesagt, rauf und runter (in z-Achse). Wenn sie auf dem Boden sind, bleiben sie, wo sie sind, ansonsten wird ein entsprechendes Ziel berechnet. Diese Schleife schaffe ich mit 120 Durchläufen pro Sekunde. D.h. 120x pro Sekunde wird auch ein neues Ziel berechnet. Auf diese Weise kann ich gerade gehen, aber auch Kurven laufen oder mich auf der Stelle drehen. Und weil das so eindrucksvoll ist, kann man der Körper auch in jede Richtung neigen.

Kosten
Der größte Kostenfaktor sind natürlich die Servos mit 12 x EUR 240,- = EUR 2.880, der 2. Kostenfaktor der 3D-Druck: EUR 610. Der Rest hängt dann von der Ausbaustufe ab. Braucht man die 3D Kamera und einen 2. Raspi + Router, oder kommt man mit einem aus - ich schätze, dass ich alles in allem bei ca. EUR 4.000,- gelandet bin.


Das wars erst mal - ich hoffe, dass ich da noch mehr hinbekomme! :-D

Grüße, Marcus

[Gerdchen]

Hut ab, ganz großes Kino! Am Ende des Videos dachte ich schon, nach dem "Überholmanöver" schwenkt der Robi zum Trinknapf und will dem armen Hundi was wegsaufen.:p

Mich würde interessieren, wie die Halbarkeit der Sevos bei dieser Dauerbelastung aussieht.


Gerdchen

[oberallgeier]

Hallo Marcus - darf ich mal kurz was sagen? Kompliment. Was für ein sauberes Stück, eine richtige Augenweide !

Bei den Kosten hätte ich etliches mehr geschätzt. Aber Mannstunden dürfte eine je Euro fast zu wenig sein!? Wie lange wars denn? Wenn Du das verraten willst.

Frage2: sind die vier Beine weitgehend gleich in Mechanik und Software?
Frage3: gibts dazu Vorstudien?

Weiter viel Erfolg und - nochmal : Kompliment !

[inka]

alle achtung, gefällt mir!

[LeeMajors]

@Gerdchen: Naja, noch halten sie! :cheesy:
Wie gesagt, es sind die ersten Läufe, aber ich glaube, die Servos stecken einiges weg. Die sind nicht wie die RC-Servos. Wenn man die bei der Endposition weiter dreht, gehen die zügig kaputt. Bei den Dynamixel kann man die Kraft einstellen. Wenn man die noch stärker weiter dreht, fahren die einfach wieder zurück. Wenn ich z.B. 500mA einstelle, ist das so ein Bisschen wie eine Feder.
Von daher hoffe ich einfach mal, dass die lange durchhalten, zumal ich die nur mit ca. 50% der möglichen Kraft betreibe.

@oberallgeier: Meinen ersten Roboter hab ich 2014 angefangen, richtig zu Ende gebaut hab ich Renate https://ilumi.de/3dvisualization/Renate und den Vorgänger. (S. YouTube Link oben). Das ganze ging über Jahre und die ganzen Erfahrungen fließen hier natürlich ein. Die Software und die Skripte wurden natürlich auch immer weiter entwickelt. D.h. ich hab nicht bei 0 gestartet.

Mit Anubis IV hab ich im August angefangen.

Ansonsten: Die Beine sind komplett gleich, bis auf die Tatsache, dass die Seitenservos für die hinteren Beine gespiegelt sind. Und die Vorstudie ist eben der 3D-Druck Anubis.

@inka: Dankeschön!

[Moppi]

Ich finde alles super. Tolle Sachen!


Die Bildverarbeitung etc., damit muss man sich doch intensiv auseinandersetzen.
Wie hast Du denn damit angefangen? Hattest Du da schon schulische Vorkenntnisse, oder alles von Anfang an selbst erlernt?
Hattest Du Bücher, wo Du Dein Wissen drauf aufgebaut hast, oder wie hast Du das angehäuft?


Freundlichen Gruß
und weiter so! - Klar :)
Moppi

[morob]

ich bin wirklich begeistert, kompliment.

du hast ohne ros gearbeitet, wenn ich das richtig verstehe? man kann also komplexe sachen in der roboter entwicklung auch ohne ros realisieren.

stephan

[Rabenauge]

Mir gefällt der auch sehr. Kompliment!
Aber ne kleine Lanze für RC-Servos (auch wenn ich die Wahl der Dynamixel absolut richtig finde- würd ich auch so machen) muss ich mal brechen: bitte, nich immer von den Billigsten ausgehen.
Auch da gibts durchaus welche, die man im normalen Betrieb _nicht_ kaputt bekommt.
Nur nich eben fürn 20er...
Auch in spielfrei (sagen wir, kein mess-oder fühlbares) gibt es das.

Was mich brennend interessiert: warum tippelt der so- der benutzt ja kaum 5 Grad der möglichen Servoausschläge- ist das nur weil "noch nicht fertig" oder hat das andere Gründe?

[LeeMajors]

@Moppi: Noch macht die Kamera nichts - außer, dass man den Videofeed streamen kann.
Die 3D Kamera wirft quasi ein 16Bit-Graustufen-Bitmap raus, aus dem man genau den Abstand zwischen Pixel und Kamera auslesen kann. Wenn ich jetzt die Roboterposition und Lage kenne, kann ich die erfassten Punkte ebenfalls entsprechend drehen und verschieben und weiß dann, wo im Raum die Hindernisse sind.

Vorkenntnisse sind:
- Programmieren seit 1981
- 2 Semester Mathe
- Fotoausbildung
- 3D Grafiker seit 1996
- Webprogrammierung seit ca. 2000
- und son Bisschen mit Elektronik im geringen Maße hab ich auch seit Kind gemacht...

Irgendwie hat das alles zusammen gepasst für so ein Projekt.

@morob: Irgendwie war mir ROS ein zu großes unbekanntes Gebilde. Ich bin auch ein Fan davon, alles selber zu machen. Und so lange ich auf ca. 100 Durchläufe in der Sekunde komme, müssten die Bewegungen hinreichend geschmeidig werden. Ein "Bisschen" ROS ist auf dem 2. Raspi installiert. Da geht es aber im Grunde nur um den Treiber für die 3D-Kamera.

@Rabenauge: Ja, ist richtig. Aber die kosten dann auch eher um die EUR 100,-.
Wegen tippeln: Bei der Gangart sind immer 2 Beine diagonal oben und 2 unten. D.h. er hat die ganze Zeit eine instabile Haltung. Bliebe er so stehen, mit 2 Beinen oben, würde er also sofort umkippen. Je schneller man dem entgegenwirkt, desto weniger Zeit hat er zum kippen, aber je unruhiger wird er auch. Momentan benutze ich den Lagesensor auch nicht. Ich bin auch nicht sicher, ob ich den trotz nur 0.12s Latenz sinnvoll zum Gleichgewicht halten einsetzen kann. Momentan sind die Beinpaare nur jeweils 0.25s in der Luft...
Vielleicht kann ich diese Latenz verringern, wenn ich nur den Gyro benutze... mal gucken.
Grundsätzlich kann man das Gehüpfe bei schwereren Robotern - wegen der Massenträgheit - langsamer machen. Der hier wiegt nur 3kg. Der kleinste, mir bekannte und agile Roboter dieser Art wiegt 5kg, der A1 von Unitree: https://www.unitree.com/products/a1
Ich werde aber auch noch mit der Fußstellung experimentieren. Wenn die Füße unten dichter beisammen stehen, müsste sich das Kippverhalten auch verbessern, aber die Stabilität insgesamt verringern. Das wiederrum könnte ich dann über den Lagesensor ausgleichen...

Grüße, Marcus

[Moppi]

Ich glaube, Dir fehlt dann eine zusätzliche Bewegung, oben in der Hüfte, um die Beine auch nach innen und außen stellen zu können. So könnte man vielleicht das Gleichgewicht besser in den Griff bekommen.
Shapeways Versatile Plastic: welches Verfahren verwenden die denn?
Jetzt ist mir klar, warum Du so hohe Druckkosten hattest.

MfG

[LeeMajors]

Die Beine können sich nach innen und außen bewegen - sonst könnte der ja keine Kurven laufen. Jedes Bein hat 3 Servos. Das erste, was fest mit dem Body verschraubt ist macht eben diese Innen- Außenbewegung. Das nächste ist daran in dem "Körbchen" befestigt, für die Vorne- & Hintenbewegung, der 3. Servo ist der Ellenbogen.

Wegen Shapeways: Versatile Plastic ist das Produkt. Das wird dann mit dem Lasersintherverfahren gedruckt.

Grüße, Marcus

[Moppi]

Doch 3? - Ich habe den Dritten gefunden, musste ich nur etwas suchen. :) Danke, für den Hinweis!

Es gibt auch Hunde, denen ein Bein fehlt. Können die nicht auf laufen?
Kennt wer die Sage vom dreibeinigen Hund, zu Görlitz? (https://www.goerlitz.de/Die_Sage_vom_dreibeinigen_Hund.html)

Wahrscheinlich ist der Regelmechanismus nicht schnell genug, um das Gleichgewicht - auch im Gang - genau genug herzustellen? Du kannst den Körper nicht kippen / ein Bein verlängern, durch anwinkeln des Fußes oder aus der Hüfte heraus. Irgendwie müsste das Gewicht verlagert werden. Oder Du baust ein Gewicht oben drauf, dass sich bewegen lässt, um den Schwerpunkt zu ändern. Hast Du so was vielleicht noch vor?


MfG

PS: der Link, für etwas Abwechslung ;)

[Rabenauge]

Mir geht es weniger um die schnellen Schritte-sondern darum, dass er grössere machen können sollte.

Ich mein: so schafft der ja keine Bordsteinkante, von Treppen ganz zu schweigen.
Generell aber denke ich, das könnte er bei der Geometrie, beides.
Aber dazu muss er halt auch grössere Schritte können.

[LeeMajors]

@Moppi & Rabenauge:
Der Roboter hat die gleichen Freiheitsgrade wie die kommerziellen Roboterhunde, also Spot & Co. Die Winkel sind zwar nicht so hoch, weil auf Grund der Servos der Kram anders konstruiert werden muss, aber natürlich viel höher, als im Video. Aber er kann sich natürlich auch in jede Richtung neigen, bzw. kippen oder das Gewicht verlagern, das sieht man auch im Ansatz am Anfang im Video. Wie gesagt, es sind die ersten Schritte... Gegen Ende gebe ich auch einmal etwas mehr "Gas", da stolpert er etwas.

Es ist einfach so, dass je größer die Schritte, die Stabilität leidet. Momentan gehe ich von einer idealen Welt aus, wo der Boden komplett gerade ist, der Roboter nicht wackelt und keinerlei Spiel in der Mechanik ist. Später werde ich den Lagesensor einbeziehen und auch die echte Position der Beine prüfen um "Missständen" entgegen zu wirken.
Außerdem ist der echte Schwerpunkt momentan zu weit hinten. Das hat zur Folge, dass er, wenn er nur auf dem Stand hüpft, nach hinten geht. Das wird auch noch korrigiert...

Ob der richtige Treppen steigen wird, weiß ich noch nicht. Im Vergleich: Spot kann Treppen steigen, der ist aber 3x so groß. D.h. für Anubis: Der müsste 3x so hohe Stufen schaffen, wie Spot um eine normale Treppe hoch zu kommen.


Grüße, Marcus

[Holomino]

Ein geiles Gerät.

[Defiant]

Ich mag die beiden Vierbeiner :)



Der 1. Raspi ist grob für die Bewegungen zuständig, der 2. wird später die Bilder der 3D Kamera interpretieren und in einen 3D Raum umsetzen. Diese Aufgabe ist sehr rechenintensiv und würde die Bewegungsberechnungen stören - daher der 2. Raspi.

Da bin ich neugierig, hast du das schon getestet ob die Threads sich in die Quere kommen? Reicht es nicht dem Thread der Bewegungsberechnungen in den SCHED_FIFO oder SCHED_RR Scheduler zu verschieben? Würde ich sowieso machen, wenn die Berechnungen so kritisch sind.

[schorsch_76]

Cooles Teil! :cool: :cool: :cool:

Hut ab!

[LeeMajors]

@Defiant:
Die Scheduler Geschichte kannte ich noch gar nicht - die muss ich mir mal ansehen. Ansonsten sehe ich mir über htop an, wie die Auslastungen sind. Der 2. Raspi schwitzt schon ordentlich, wenn er den Kamera-Feed streamt. Der Job, die Depth-Map in für Anubis passende Raum-Koordinaten umzubauen, wird er ohnehin nicht mit 30fps o.ä. schaffen - ist auch nicht nötig. Ich lasse ihn so schnell rechnen, wie er kann - und dann werden planmäßig inkl. Streaming 3 Kerne auf Anschlag stehen.

Deswegen ist mir das zu unsicher, darüber auch die Bewegungen zu steuern.

Die Bewegungsberechnung ist eigentlich auch gar nicht soooo rechenintensiv. Ich könnte die auf ca. 150 rounds per second stabil laufen lassen. Aber, die 12 Servos müssen ja in jedem Durchgang mit einigen Werten ausgelesen und gesetzt werden. Das dauert auch bei 4Mbit/s Verbindung so lange, trotz ausgelagertem Thread, dass ich momentan bei knapp 120rps lande - was völlig ok ist.
D.h. der Raspi 1 hat noch Luft und Raspi 2 werde ich am Anschlag betreiben.

@schorsch_76: Dankeschön!

Inzwischen habe ich auch noch ein paar andere Problemchen gelöst. Wenn er im Stand gehen sollte, ist er z.B. nach hinten gegangen. Durch Änderungen der Beinbewegung tut er das nun nicht mehr. Er dreht noch leicht, das werde ich aber durch den Lagesensor in den Griff bekommen. Allerding ist diese schnelle Schrittfolge, in der sich alle 0.25s ein Beinpaar hebt und senkt, genau die richtige Frequenz für diese Größe und dieses Gewicht. Alles andere wackelt furchtbar rum. Er ist zwar schon um Welten stabiler als der Vorgänger, aber er ist mir immer noch wackliger, als mir lieb ist. Immerhin konnte ich die Geschwindigkeit jetzt auf maximal 15cm/s erhöhen...

Ich poste demnächst noch mal ein Filmchen! :-)

Grüße, Marcus

[Defiant]

@Defiant:
Die Scheduler Geschichte kannte ich noch gar nicht - die muss ich mir mal ansehen. Ansonsten sehe ich mir über htop an, wie die Auslastungen sind. Der 2. Raspi schwitzt schon ordentlich, wenn er den Kamera-Feed streamt.
ok, dann noch ein paar zusätzliche Infos. Ich hatte 2013 in meiner Abschlussarbeit (https://reposit.haw-hamburg.de/handle/20.500.12738/6172) mal einen Test auf einem Dual-Core ARM Prozessor durchgeführt. Es hat etwa 100 Busy-Loops Threads gebraucht, bis der SCHED_FIFO die Periodendauer von 16.67ms nicht mehr einhalten konnte. Nur so als Tip, da ein Rpi4 doch ca. 1A benötigt und es sicherlich von Vorteil für die Laufzeit wäre wenn man einen einsparen könnte.

[morob]

@Defiant:
Die Scheduler Geschichte kannte ich noch gar nicht - die muss ich mir mal ansehen. Ansonsten sehe ich mir über htop an, wie die Auslastungen sind. Der 2. Raspi schwitzt schon ordentlich, wenn er den Kamera-Feed streamt. Der Job, die Depth-Map in für Anubis passende Raum-Koordinaten umzubauen, wird er ohnehin nicht mit 30fps o.ä. schaffen - ist auch nicht nötig. Ich lasse ihn so schnell rechnen, wie er kann - und dann werden planmäßig inkl. Streaming 3 Kerne auf Anschlag stehen.

Deswegen ist mir das zu unsicher, darüber auch die Bewegungen zu steuern.

Die Bewegungsberechnung ist eigentlich auch gar nicht soooo rechenintensiv. Ich könnte die auf ca. 150 rounds per second stabil laufen lassen. Aber, die 12 Servos müssen ja in jedem Durchgang mit einigen Werten ausgelesen und gesetzt werden. Das dauert auch bei 4Mbit/s Verbindung so lange, trotz ausgelagertem Thread, dass ich momentan bei knapp 120rps lande - was völlig ok ist.
D.h. der Raspi 1 hat noch Luft und Raspi 2 werde ich am Anschlag betreiben.

...


ok, dann noch ein paar zusätzliche Infos. Ich hatte 2013 in meiner Abschlussarbeit (https://reposit.haw-hamburg.de/handle/20.500.12738/6172) mal einen Test auf einem Dual-Core ARM Prozessor durchgeführt. Es hat etwa 100 Busy-Loops Threads gebraucht, bis der SCHED_FIFO die Periodendauer von 16.67ms nicht mehr einhalten konnte. Nur so als Tip, da ein Rpi4 doch ca. 1A benötigt und es sicherlich von Vorteil für die Laufzeit wäre wenn man einen einsparen könnte.

@LeeMajors, schon mal überlegt den stream auf 10fps runter zu setzen?
@Defiant, schicke arbeit, muss ich mir mal heute abend in ruhe durchlesen.

ich würde auch 2 rpi einsetzen, die bildverarbeitung benötigt doch eine menge leistung und wenn zwei cams einsetzen will, ist das in meinen augen sowieso besser.

[LeeMajors]

Der Stream ist momentan schon bei 12fps und der Raspi ist schon eingebaut und läuft. Ich möchte da einfach nicht ans Limit gehen und etwas Luft haben.
Außerdem fand ich es auch interessant, Daten zwischen den beiden Rechnern auszutauschen:
Momentan läuft da einmal eine Websocket-Verbindung und zum anderen nutze ich auf dem Raspi 1 /dev/shm/, einem Verzeichnis, welches im RAM liegt. Das ist einfach auch auf dem Raspi 2 gemountet und der Datenaustausch ist super schnell.
Dort arbeite ich auch mit einer SQLite Datenbank und die Performance ist wirklich verblüffend. Dort werden vom Lagesensor z.B. Daten reingeschrieben, wann welche Lage vorlag, sowie die theoretische Position im Raum. (Jeder Sensor/Kamera, etc. hat ja seine eigene Latenz. Die der Tiefenmap liegt bei 0.25s, bis sie im python Skript verarbeitet werden kann, die des Lagesensors bei 0.12s.) Später kann ich dann bei einer Depth-Map auf die "alte Lage" zugreifen und so die Hindernis-Positionen des Raums berechnen. Dass der Roboter inzwischen schon ein paar cm weiter gelaufen ist, ist im Prinzip ja nicht schlimm, da der Lagesensor weit nach vorne guckt.

...soweit schon mal die schöne Theorie! :-p

[morob]

ich finde die sache mit den gemouteten verzeichnissen die bessere lösung, weil websocket bedeutet immer overhead.
schon mal an csv file gedacht? (nur ein gedanke)

[LeeMajors]

Ich setze beides ein. Für die Clientverbindung brauche ich ja auf alle Fälle Websockets. Und für Push-Nachrichten zwischen den Raspis auch.
Was soll ich ansonsten mit csv files anfangen!? Als Alternative zur Datenbank? Ich muss doch gezielt Datensätze auslesen...

[schorsch_76]

Was hat denn dein Hundi am Auge? Hoffentlich nichts schlimmes..

Was natürlich bei den Servos auch von Vorteil ist: Du gibst ihnen ihre Verfahrsätze per TTL/RS485. Du brauchst kein exaktes Timing für die Steuerimpulse wie bei RC Servos. Hab das Datenblatt durchgelesen. Scheint schon sehr gut zu steuern zu sein. Absolutwertgeber ... Top

EDIT: Hast du die Inverse Kinematik von Grund auf programmiert (Gleichungslöser?) oder eine Bibliothek verwendet wie OpenRave (http://openrave.org/)?

[LeeMajors]

...unsere Hundi-Oma hat kürzlich ein Auge rausbekommen. Da war sie eh blind, Augendruck war zu hoch. Aber sie hats gut weggesteckt und alles ist wieder gut. :-D

Hier ist ein kleines Update, wo die Benutzeroberfläche eingeblendet ist:


https://youtu.be/_Gs2PQQFbd4

Grüße, Marcus

[morob]

ich bin von der bewegung immer wieder fasziniert.

[LeeMajors]

Die IK ist von Grund auf programmiert. Was meinst du mit Gleichungslöser? Im Grunde sind das ne Handvoll Berechnungen mit Dreiecksformeln...

Ich denke, wichtig ist, dass man nicht versucht, einen "Schritt" zu programmieren, oder sowas wie "um die Kurve" laufen. Ich denke, da wird man wahnsinnig. So ganz grob gesagt hebt der die Füße abwechselnd hoch. Wenn die Füße auf dem Boden sind, müssen sie da bleiben und wenn sie in der Luft sind wird bei jedem Durchlauf (also so 100x pro Sekunde) das Ziel neu berechnet. Vereinfacht sollen die unterhalb des Beinansatzes sein + dem Geschwindigkeitsvektor, so dass der Fuß quasi etwas schneller ist, als der Körper. (+ noch so eine Handvoll Parameter ;-)

Letztlich hat man dann immer 2 Punkte pro Bein im Raum: Da wo das Bein anfängt und da wo der Fuß auf dem Boden ist. Das muss dann die IK lösen, was im Grunde aber nicht so schwer ist, weil es bei den 3 Servos in der Anordnung nur eine sinnvolle Lösung gibt.
Die Seite zeigt, wie man es machen könnte: https://www.robotshop.com/community/forum/t/inverse-kinematics/11759
Komischerweise bin ich auf andere Formeln gekommen - war aber egal - klappt genau so gut. ;-)

Grüße, Marcus

[schorsch_76]

Die IK ist von Grund auf programmiert. Was meinst du mit Gleichungslöser? Im Grunde sind das ne Handvoll Berechnungen mit Dreiecksformeln...
...

Na dann löst du ja doch Gleichungen. :)

Die Längen der Dreieckskanten (Schenkel) ist ja bekannt. Du weißt wo sie stehen und wo du hin willst. Es könnten theoretisch mehrere Winkel möglich sein aber jede Achse hat einen möglichen Bereich. Dadurch reduziert sich das. Ich hab zwar noch keine IK programmiert ist aber sicher anspruchsvoll :)

[LeeMajors]

Janee... ;-)
Mit den Gleichungen hast du so gesehen Recht, aber die IK ist eben nicht sooo anspruchsvoll, weil es eben nicht mehrere Möglichkeiten gibt. Es gibt meistens 2 Möglichkeiten, in dem man das Knie nach hinten oder vorne knickt, aber es gibt keine Lösungsmengen.

Den Link hab ich oben ja schon gepostet: https://www.robotshop.com/community/forum/t/inverse-kinematics/11759 ...aber da sieht man, wie man sukzessive die 3 Winkel der Servos ausrechnen kann. Und wie man auch sieht - es sind nur 3 Formeln und fertich!

Bei mir sieht das so aus:


def moveFeetAbsolute(self, id, p):
error = 0
self.tmp[0] = (p - self.anubis['position']) * self.Rt # Die Position der Base wird abgezogen und um die Lage von Anubis zurückgedreht.
p = self.tmp[0] - self.npLegBase[id] # Die LegBase wird ebenfalls abgezogen, damit das Bein im 0-Punkt startet

# In p ist nun der Punkt gespeichert, der vom 0-Punkt aus über die 3 Gelenke j1 - j3 erreicht werden soll.

j1 = math.atan2(p[1], -p[2]) * self.rad2deg
lengthYZ = math.sqrt(p[1] * p[1] + p[2] * p[2])
t = math.sqrt(p[0] * p[0] + lengthYZ * lengthYZ) / self.legLength

if t > 1.0:
t = 1.0
error |= 1

if t < -1.0:
t = -1.0
error |= 1

gamma = 2 * math.asin(t) # Winkel des Ellenbogens
alpha = (self.deg180_2rad - gamma) / 2
j2 = (alpha - math.atan2(p[0], lengthYZ)) * self.rad2deg
j3 = (gamma - self.deg180_2rad) * self.rad2deg


return self.defineServoGoalPosition(id, error, j1, j2, j3)


Grüße, Marcus

[schorsch_76]

Danke für den Einblick :)

[oberallgeier]

Hallo Marcus!
.. Mit den Gleichungen hast du so gesehen Recht .. IK .. nicht sooo anspruchsvoll .. gibt meistens 2 Möglichkeiten, in dem man das Knie nach hinten oder vorne knickt ..Jaaa, durch geeignete Beschränkung der Allgmeinheit - ähhh - der Lösungsmenge kann man da einiges vereinfachen. Und Deine Rechnerei sieht ja wirklich gut aus!

In dem uralten Thread von JackBauer (https://www.roboternetz.de/community/threads/30344-Algorithmen-zur-Bahnplanung) habe ich zusammen mit Sternthaler und mare_crisium zum Thema Bahnplanung (Algorithmen zur Bahnplanung) diskutiert (https://www.roboternetz.de/community/threads/30344-Algorithmen-zur-Bahnplanung?p=293884&viewfull=1#post293884) ; wir waren dabei auch über sinnvolles "weglassen" gestolpert. Ich hatte 1980/81 auf nem 8086er ne Bahnplanung entworfen; zu der Zeit fuhr man noch PTP. Damals gabs den 8086 ab Werk in Westentaschenmengen (wurde noch selbst abgeholt *gg*). Da der mit transzendenten Funktionen nix am Hut hatte und der zugehörige Numbercruncher auch nicht wirklich Tempo machte, hatte ich die ganze Rechnung mit Anlehnung an Herrn Pythagoras abgewickelt - ne Wurzelberechnung reichte *gg*. (Daß dahinter ne Parameterisierung nicht ableitbarer Funktionen lag, TCP-Bahn im Raum, siehe Schema (https://www.roboternetz.de/community/attachment.php?attachmentid=10130&d=1192020381) , war schon fast unbedeutend. TLDR : trotzdem Textauszug (https://www.roboternetz.de/community/attachment.php?attachmentid=10131&d=1192033796)). Mit nem Zylog Z80 @ 2 MHz, später 4, hatte ich noch nen passenden Numbercruncher mit eingebunden und da liefs (immer noch ohne Winkelfunktionen) schon ganz ordentlich; der Z80 machte damals schon 16-bit-Arithmetik. Wenn ich dagegen Deine ATAN2´s sehe - später Neid.

Sorry, ist längst Geschichte.

[LeeMajors]

*g*... das war allerdings schon recht fortschrittlich. Meine erste Roboter-Erfahrung hab ich ca. 10 Jahre später gemacht. Ein Greifroboter mit 4 Freiheitsgraden aus Fischer-Technik. Gesteuert wurden die 4 Motoren über Relais, die wiederum über die Centronix-Schnittstelle parallel angesteuert wurden. Und weil ich damals ja noch keine Kameras oder sonstige Sensoren zur Verfügung hatte, hab ich dem Rechner die Bewegungen vorgemacht, in dem ich den Arm über einen Joystick bewegt habe. Die Zeiten, welcher Motor dann wie lange in welche Richtung laufen musste, hab ich gemessen und die ganze Geschichte wieder abgespielt. So konnte ich dann souverän einen Schlumpf von Position A mit Roboterarm zu Position B bewegen! :cheesy:

[LeeMajors]

Einbindung der Tiefenkamera
Ich benutze eine Intel Realsense D435. Diese hat 2 Infrarotkameras im Augenabstand und einen IR-Laserprojektor, der ein Muster auf die Umgebung wirft. Damit wird in der Kamera eine 3D-Tiefenmap berechnet, deren Pixel quasi in mm den Abstand zur Kamera angibt. Außerdem ist noch ein mittelprächtiger RGB-Sensor verbaut, so dass man auch ein Videobild hat. Leider ganz am Rand, so dass das RGB-Bild nicht dem 3D-Bild entspricht. (Geht auch nicht, weil zwischen den IR-Kameras der IR-Projektor sein muss...)


https://youtu.be/s9XDNc2KPXM

Diese Informationen werden dann so umgerechnet, dass bei einem Raster (hier 5x5cm) die höchste Stelle gefunden wird. Die Rechnerei ist im Grunde nicht sooo kompliziert, schwierig ist es, das ganze möglichst schnell zu machen. D.h. es wird viel mit Numpy gearbeitet, womit ich mich nicht besonders gut auskenne. Immerhin schaffe ich so 3-4 Durchgänge pro Sekunde, was eigentlich ausreichen sollte.

Der nächste Schritt ist jetzt, Bewegungs- und Orientierungsdaten mit einzubeziehen. Insbesondere wird dann schwierig, die verschiedenen Latenzen von Kamera, Lagesensor und Bewegungsdaten in Einklang zu bringen.

Grüße, Marcus

[morob]

bist du sonst zufrieden mit der d435, das teil liegt bei mir auf dem wunschzettel, grins, für ein größeres projekt, demnächst mehr in diesem forum.

[LeeMajors]

Ich bin damit zufrieden. Die Kamera leistet für ihre inzwischen 180 EUR sehr viel. Für ca. EUR 90 mehr gibt es noch eine Version mit einem BMI055 dazu. Das ist ein Gyro + Beschleunigungssensor. Der ist Teil des BNO055, den es von Adafruit für EUR 50,- gibt. Der Preisunterschied könnte trotzdem gerechtfertigt sein, weil der Sensor vermutlich in der Kamera ausgelesen und mit den Tiefendaten verrechnet wird. Ich hab den BNO055 separat fast genau im Nullpunkt des Roboters über I2C angeschlossen und kann die Daten mit einer Latenz von ca. 0.12s auslesen.

Die Kamera kann sogar selber Punktwolken aus den 3D-Daten berechnen. Leider hat die Umrechnung in Numpy-Arrays so lange gedauert, dass die eigene Berechnung über Numpy schneller war. Die Möglichkeiten sind jedenfalls enorm.

Mir fehlt noch eine intel T265 zum Glück - damit ist relativ genaues Positionstracking im Raum möglich. (EUR 220,-...)

[morob]

ich habe eine 3 punkt konstruktion, als ist die bewegung im raum nicht so wie bei dir :)
ich weiß aber nicht, welche von den kameras für mich wirklich die besten lösung ist. die t265 hatte ich noch gar nicht auf dem schirm.

[LeeMajors]

Naja, die Kameras machen was komplett unterschiedliches. Die D435 gibt Tiefeninformationen, die T265 gibt Position & Lagedaten. Und wenn man dann noch einen ordentlichen Live-Stream haben möchte, braucht man eigentlich noch eine 3. Kamera...

[morob]

also doch d435 und eine imu noch dazu :)
an eine zusätzlich kamera habe ich noch gedacht als rpi cam.

ich habe gerade gelesen das es eine d435i gibt, welche die imu schon integriert hat, allerdings ca. 90€ teurer als ohne imu.

hast du ein raspbian auf dem rpi oder ein ubuntu?

[HeXPloreR]

Hallo Marcus,

ich möchte auch mein Lob an Dich abgeben. Dein Anubis ist wirklich sehr gut gelungen =D> - (verneige mich, höchsten Respekt)

Baue bitte diesen Kopf an den Roboter, dann hast du einen "richtigen Wachhund"( https://www.youtube.com/watch?v=mEAz-72ZjKE )

Viele Grüße und bleibt gesund
Jörg

[LeeMajors]

Huhu Jörg, vielen Dank für die Blumen!
Ich muss mich tatsächlich immer bremsen, mich nicht total mit solchem verspielten Kram zu verzetteln... ;-)

Kleines Update zum Anubis:
Im Augenblick bin ich dabei, die Daten der Tiefenkamera mit Position und Ausrichtung zu kombinieren... *puh*

Nebenbei hab ich heute mal eine andere Geometrie konstruiert. Langsam nähere ich mich immer mehr Spot an...

35342

Er ist etwas kürzer, die Beinlänge ist von 30 auf 25cm verkürzt, er ist sehr viel stabiler gebaut und er hat die Achsen für Seiten und Vorwärtsbewegung nicht mehr in einem Punkt.
Die Konstruktion wird, obwohl sie klobiger aussieht, trotzdem deutlich beweglicher sein.
Vor allem hoffe ich, dass er dann nicht mehr so wacklig ist...

Grüße, Marcus

[morob]

Hast Du jetzt D435 und T265 im Einsatz oder nimmst Du eine D435 und eine IMU?

[LeeMajors]

Im Augenblick habe ich eine D435 + IMU im Einsatz. Eine T265 wird aber dazu kommen, ansonsten ist eine autonome Navigation im Raum nicht möglich.
Die T265 liefert dann Position und Lage. Meine IMU bleibt aber zunächst trotzdem mal drin. Die Frage ist ja, wie die Latenzen sind. Ich schätze, ich bekomme die Lage über I2C schneller ausgelesen, als über USB.

[LeeMajors]

Ich hab mit dem Design für die nächste Version etwas weiter gemacht:
https://ilumi.de/img/uploads/Anubis5_0091a.jpg

https://ilumi.de/img/uploads/Anubis5_0091b.jpg

https://ilumi.de/img/uploads/Anubis5_0091c.jpg

https://ilumi.de/img/uploads/Anubis5_0102.jpg

[morob]

*Hut ziehen*

mal sehen wie weit ich über die Feiertage komme

[oberallgeier]

Ich hab mit dem Design für die nächste Version etwas weiter gemacht ..Chapeau! Was für ein bemerkenswertes Design. Schön, glatt, funktional - will nicht überheblich wirken, aber ganz grosse Klasse. Und, da versteht jemand wohl einiges von werkstoffgerechter Konstruktion. WENN nicht im Bild mit dem abgelegten Energieblock Renderfransen (?) zu sehen wären, ginge das als Realität durch. Nochmal zum Design: ich hatte mal mit Busse (mit Rido selbst!) zusammen arbeiten dürfen, nur ein, tonnenschweres, Industrieaggregat. Dort hatte ich ausführlich gelernt wie viel Funktion ordentlich aufgeräumt werden muss, bevor die Form so prächtig folgen kann.

Macht richtig Freude Dir zusehen zu dürfen.
.
.
.
.
.
.
Schräger Nachtrag: wenn der Hund nicht zu lang wird, könnte man dem sicher Männchen-machen beibringen. Brauchte ja nicht mal nen Gyro (https://www.roboternetz.de/community/threads/43015-Balance-halten) dazu.

[LeeMajors]

Was meinst du mit Renderfransen? Das, was aussehen soll, wie ein Teppich? Stimmt, da bin ich zu nah dran, für das Material.
Davon abgesehen ist das Teil voll von Fehlern. Da ich für Shapeways-Druck konstruiere und nicht für einen 3D-Drucker, müssen die Objekte nicht ein Klumpen sein. Daher schiebe ich oft Teile einfach zusammen. Der Nachteil ist, dass der Renderer (der übrigens Corona-Renderer heißt... :-x), an diesen Stellen kleine abgerundete Ecken erzeugt, wo keine sein sollen. Auch mit dem Schaumgummi und Gummi Mapping hätte ich mir mehr Mühe geben können, aber ich steh mehr auf prozeduralen Kram und verwende ungern Massen von Mappings. ;-)

Doof ist ja, dass man so ein Design nicht von Anfang an hinbekommt. Das ist jetzt ja schon die 3. Version... Und ein Nachteil: Beim letzten (also quasi physikalisch gerade lebenden) Anubis hätte man noch ein Manipulatorarm Platz gehabt. Das geht hier nicht, oder man müsste ihn komplett oben drauf machen, also inkl. dem Servo, was für die Drehung in der Hochachse zuständig wäre. D.h. der Aufbau würde dann sehr hoch werden. :-/

Beim jetzigen hätte das so aussehen können:
https://ilumi.de/img/uploads/Anubis4M_259d.jpg

Ich poste gleich noch mal was, wo man das Innenleben sieht, das inzwischen wirklich etwas aufgeräumter ist. ;-)

Grüße, Marcus

- - - Aktualisiert - - -

Hier sieht man das Innenleben. (Mit ganz vielen Renderfehlern! :-p)
https://ilumi.de/img/upload/Anubis5_0104.jpghttps://ilumi.de/img/uploads/Anubis5_0104.jpg

[oberallgeier]

Was meinst du mit Renderfransen? Das, was aussehen soll, wie ein Teppich? Stimmt, da bin ich zu nah dran ..Ja, genau diese Ecke. Mir schein auch, dass die Teilunterseite (Ebene) schief zur Teppichebene wäre. ABER was solls, es sind verschwindende Details in der sehr dekorativen Vorstellung.

[LeeMajors]

Das liegt vermutlich daran, dass die Beine etwas runterhängen - genau wie auf dem 2. Bild, wo Anubis "Platz" macht. Da liegt er auf den Hilfsfüßen unter dem Körper und die Beine haben Platz etwas nach unten abzuknicken.

[LeeMajors]

https://ilumi.de/img/uploads/Weihnachtsanubis.jpg

[morob]

Ich wünsche uns dies auch :)

[oberallgeier]

Danke für die pfiffigen, kerzlichen Wünsche.


.. dass man so ein Design nicht von Anfang an hinbekommt .. Beim jetzigen hätte das so aussehen können: ..Der Fluch der Entwicklungsarbeit ist ja, dass man möglichst alle denkbaren Varianten erfassen und bewerten sollte. Wobei dann der wirklich gute (industriell tätige) Entwickler viel Geld dafür verlangt/bekommt, dass er in der Lage ist einen hohen Prozentsatz von Varianten möglichst früh als nicht weiter zu beachten aussondern kann. Und hinterher auch Recht behält.

Zu Deinem "jetzigen hätte das so aussehen können": Bei der Darstellung der Designvariante mit dem Greifer sind Zwischenglieder sichtbar, die ein äußerst schlankes Mittelteil haben. Die Torsionsfestigkeit dieses Mittelteils ist äusserst dürftig (nach der Methode des genauen Hinsehens) und daher für Beine (im Bild rechts unten halb sichtbar) und Greifer-Zwischenglied ungeeignet. Deine aktuell dargestellte (verwirklichte) kastenartige Struktur sieht da für mich viel torsionsstabiler aus! Das nur als EIN Beispiel aus dem ich entnehme, dass Du da etliche Varianten durchdacht hattest. Unser "chapeau" und andere Komplimente dazu hatten wir ja schon abgeliefert.

[LeeMajors]

Ja, danke trotzdem noch mal! :-D