Anubis IV - vierbeiniger Laufroboter

[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?

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!

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 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 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.