Anubis IV - vierbeiniger Laufroboter

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

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

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



Grüße, Marcus