ich bin von der bewegung immer wieder fasziniert.
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.Zitat von LeeMajors
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
Hallo Marcus!Jaaa, durch geeignete Beschränkung der Allgmeinheit - ähhh - der Lösungsmenge kann man da einiges vereinfachen. Und Deine Rechnerei sieht ja wirklich gut aus!.. 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 ..
In dem uralten Thread von JackBauer habe ich zusammen mit Sternthaler und mare_crisium zum Thema Bahnplanung (Algorithmen zur Bahnplanung) diskutiert ; 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 , war schon fast unbedeutend. TLDR : trotzdem Textauszug). 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.
Ciao sagt der JoeamBerg
*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!
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...)
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
Berechtigungen
Zitieren
Lesezeichen