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)
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
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)
das leben ist hart, aber wir müssen da durch.
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...
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?
Geändert von schorsch_76 (16.11.2020 um 17:27 Uhr)
...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
ich bin von der bewegung immer wieder fasziniert.
das leben ist hart, aber wir müssen da durch.
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/...nematics/11759
Komischerweise bin ich auf andere Formeln gekommen - war aber egal - klappt genau so gut.
Grüße, Marcus
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
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/...nematics/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:
Code: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
Danke für den Einblick
Lesezeichen