.: Vinculum :. - Hexabot

[HannoHupmann]

Nun dann will ich es mal weiter erklären:

Wie wir alle wissen ist die inverse Kinematik in der Lage aus jeder beliebigen Position der Fussspitze (solange sie sich im Arbeitsraum des Beins befindet) die Gelenk-Winkel für Fuss, Knie und Hüfte auszurechnen.

Nur wie gebe ich diese "beliebigen Positionen" vor?
Ich hab zum einen einen festen Bewegungsablauf (A) wenn das Bein von seiner Endstellung zurück in die Anfangsstellung bewegt wird. Dabei befindet es sich in der Luft und die Bahnkurve die dabei abgefahren werden soll kann vorgegeben werden. So wie das bei ikarus_177 auf der Homepage unter Schritte zu sehen ist.

Für den Teil der Bewegung (B) bei dem der Fuss auf den Boden steht gibt es zwei Möglichkeiten:
1) Die Bahnkurve wird auch hier vorgegen. Dann sind aber keine Anpassungen an den Boden oder die Bewegungsrichtung möglich
2) Die Bahnkurve wird berechnet, entsprechend der Bewegungsrichtung (vorwärts, rückwärts, seitwärts mit Drehung oder alles zusammen) und Lage des Körpers.

Ich würde gerne den 2) Ansatz verfolgen, d.h. eine Bahnkurve quasi dynamisch generieren. Mittels eines Lagesensors soll der Roboter später erkennen ob er schräg steht und diese soweit möglich ausgleichen. Daraus folgt natürlich, dass sich auch die Beinstellung verändert. Ich möchte dem Roboter auch gerne Bewegungen vorgeben können wie z.B: "laufe gerade aus und dreh dich dabei einmal um 360°" für einen Hexa theoretisch ohne Probleme machbar, nur überlagern sich hier das Bewegungsmuster "nach vorn" und das "drehen". Ich brauch also eine mathematische Beschreibung die aus meiner Vorgabe errechnet wie die Fussspitzen sich bewegen müssten um die Aufgabe zu erfüllen (die Gelenkswinkel errechnen sich ja dann aus der IK).

Ich hoffe jetzt ist es etwas klarer.

[HeXPloreR]

Leider weiß ich nun nicht wie diese Beschreibung aussehen könnte, aber kann man nicht einen beweglichen zusätzlichen Bezugspunkt setzen auf den sich dann die Fußpunkte beziehen?

Wenn man den Buzugspunkt etwa 20cm links ins Koordinatensystem legt, dann läuft er quasi einen 40cm Kreis (mit Köpermittelpunkt) drum rum. Der Kreis wird umso größer je weiter der Punkt links oder rechts weg bewegt wird ( Am sinnvollsten wird es sein da etwas zu begrenzen z.B alles drüber = gradeaus laufen, weil sonst wird es ja nur ein recht großer Kreis)). Wenn man den Punkt wieder näher zum (normalen) Körpermittelpunkt bewegt, wird der Kreis kleiner und kleiner bis es eine Drehung um die eigene Achse wird.
Sobald sich der Bezugspunkt auf einer Seite innerhalb der Beine bewegt, wird die Drehung eingeleitet, da sich die Beine auf der Seite nun entgegengesetzt bewegen müssten
Dazu kann man dann noch die Bewegungsrichtung mit Schrittweite einrechen - per Kompass möglicherweise...

[ikarus_177]

@Hanno: als ich mich noch aktiv mit meinem Hexa beschäftigt hatte, erschien mir folgender Weg am zweckmäßigsten / einfachsten:
Meinen Beincontrollern (die die IK für die Beine berechneten und die Servos ansteuerten) bekommen vom Master (der für die übergeordnete Bewegungssteuerung zuständig ist) nicht die absolute Wunschposition des Beines übermittelt, sondern stets ein gewisses dX / dY / dZ. Um die Datenübertragung weiter zu vereinfachen, war diese Schrittweite immer fix eingestellt (man sollte natürlich einen relativ kleinen Wert nehmen, um die Bewegung "flüssig" aussehen zu lassen); alles was der Beincontroller vom Master empfing, waren Kommandos a là "Bewege Fußspitze um 1 dX / um -1dY usw...".

Trotz dieses einfachen Systems ließen sich damit alle Bewegungen realisieren, auch Überlagerungen von Bewegungen waren ohne weiteres möglich (z.B. um schräg zu gehen werden die Kommandos "+1dY" und "+1dX" abwechselnd gesendet, die Häufigkeit der beiden Befehle zueinander bestimmt, wie "schräg" gegangen wird; Drehungen während Bewegungen funktionieren ähnlich). Die Stärke des Konzepts ist aber auch gleichzeitig seine Schwäche: alle Bewegungen der Beine werden in einem roboterfesten Koordinatensystem gemessen, dessen Ursprung im Montagepunkt der Beine am Roboterkörper liegt. Das macht es extrem einfach, den Roboter etwa fernzusteuern, da alle Kommandos stets "aus Sicht des Roboters" ausgeführt werden, und er sich nicht in einem absoluten - ortsfesten - Koordinatensystem bewegt.

Das Problem ist, dass der Master (bzw. deine Instanz, die den Pfad bestimmt) bei überlagerten Bewegungen, die Drehungen beinhalten, seehr viel zu rechnen hat, wenn du Manöver wie deine 360°-Drehung während des Geradeauslaufens ausführen willst - schließlich läuft der Roboter (aus seiner Sicht) am Ende "rückwärts".

Der "Königsweg" für einen IK-Bewegungsapparat - aus meiner heutigen Sicht - würde ein globales, ortsfestes Koordinatensystem haben, in dem sich der Roboter bewegt. Aus dem Robotermittelpunkt und seinen Drehungswinkeln in den drei Achsen (quasi den Parametern, mit deren Hilfe der Roboter gesteuert werden kann) werden die globalen Positionen der Befestigungspunkte berechnet, diese fließen zusammen mit den Bodenpunkten der Beine (die - während das Bein am Boden ist - im globalen System konstant bleiben!) in die Berechnung der eigentlichen IK ein.

Zum Thema Neigungsausgleich: willst du die Neigung eines konstant schiefen Bodens ausgleichen, oder auf unregelmäßig unebenem Gelände laufen? Ersteres würde wahrscheinlich einfach über eine Winkelmessung (im Optimalfall mit Gyroskopen + Beschleunigungssensoren und einem Kalmanfilter zur Datenfusion) und entsprechende Korrektur möglich sein (ein geschlossener Regelkreis wäre denkbar). Zweiteres benötigt Sensoren, die feststellen können, ob ein Bein nun tatsächlich am Boden ist (Ich habe festgestellt, dass es bei Tastern das Problem gibt, dass diese eventuell nicht sicher schließen, wenn das Bein schief am Boden aufkommt). Die Anpassung an das Gelände erfolgt dann bei den Schritten, indem sich die Beine solange absenken - aber auf keine feste Höhe - bis ein fester Bodenkontakt hergestellt ist. Neigungsmessungen wären wohl auch hier notwendig, um eine absolute Referenz zu haben.

Schöne Grüße

[HannoHupmann]

Das Konzept hab ich bisher auch verfolgt bei meinem Phoenix². Da habe ich dem Roboter vorgegeben "laufe x schritte gerade aus oder Schräg" oder "drehe dich um 270°" allerdings war gerade aus laufen ein unterschiedlicher Algorithmus als drehen. Ich habe damals keine Überlagerung hin bekommen. Für den Vinculum wollte ich nun die Überlagerung von "gerade, schräg usw" und "drehen" schaffen und noch den Höhenausgleich. Auch diesmal wird es wieder ein ortsfestes Roboterkoordinatensystem geben und ausgehend von diesem werde ich die Fussbewegung berechnen lassen. Vermutlich wird es auf ein Koordinatensystem hinaus laufen, welches immer nach Norden ausgerichtet ist, aber sich mit dem Roboter bewegt. D.h. Drehungen verändern das Koordinatensystem nicht und bei translatorischen Bewegungen wandert das Koordinatensystem mit.

Mein erster Ansatz ist nicht so weit weg von euren Ideen - was mich sehr beruhigt.

Zum Neigungsausgleich: Erst mal geht es mir nur um "schiefen Boden" die Option mit dem "unregelmäßig unebenen Gelände" kommt irgendwann später, denn hier muss die Höhe jede einzelnen Beins individuell angepasst werden. Hier wäre aber eine Rückmeldung von den Beinen sehr hilfreich und die hab ich nicht implementiert. Der Lageausgleich lässt sich aber recht gut über ein Gryo+Beschleunigungssensor+Kalmanfilter erschlagen.

Erst mal muss der Roboter auf "eigenen Füßen" stehen und da mir immernoch die letzten 4 Servos - dank der deutschen Post - fehlen geht es nicht weiter.

[HeXPloreR]

Ohne eine Rückmeldung der Fußspitze wird es schwierig, denke ich. Allein dadurch das der Roboter seine Lage verändert, die vom Sensor gemessen wird, würde ich nicht machen. Denn dann drückt dieses eine Bein kurzfristig ein mehrfaches des Gewichts, für das möglicherweise nicht ausgelegt ist. Das kann nicht gut sein, und hat mir schon einen AX-12 Getriebe zerlegt.

Ich plane etwas ähnliches wie diesen Fühler vom catapilar...nur etwas verstärkt und in der Bewegung begrenzt.
Etwas ähnliches würde der Analogstick von einem Play_statio_pad wohl auch leisten. Allerdings wird dafür das Gewicht dann bei Dir schon kritisch sein?

[HannoHupmann]

Oh beim Phoenix² ging es ganz prima ohne Rückmeldung der Servos. Im Prinzip vertrau ich einfach darauf, dass die Beine da ankommen wo sie nach Vorgabe sein sollten. Die Rückmeldung würde mir ja nur ermöglichen zu prüfen ob sie da angekommen sind und falls nicht einzugreifen. Für die ersten Schritte wird es so gehen müssen, später implementiere ich vielleicht eine geeignete Art der Rückkopplung, wobei ich hier wohl eher auf DMS Streifen als auf Potis zurück greifen würde.

[HeXPloreR]

Ja, ich meine ja auch für später.

[HannoHupmann]

Gestern hat die Post es endlich geschafft mir meine PIN für die Packstation zukommen zu lassen. Auf einmal ging es dann doch per SMS und egal.... ich habe meine letzten vier Servos bekommen. Jetzt muss ich die natürlich erst mal testen (ich hatte ja schon genug ausfälle und die dann Mühsam wieder ausgebaut) und kalibrieren. Danach kann ich sie Einbauen und der Roboter steht endlich auf 6 Beinen.

[HannoHupmann]

So Bein Nummer 5 ist fertig. Die nächsten Tage wird Nummer 6 fertig und dann hoffe ich, dass die Beine alle "laufen" allerdings hatte ich in Gelenk F3 ein unschönes Knattern und die Analyse hat ergeben, dass hier wieder ein Zahnrad zerstört wurde. Diese Plastikgetriebe halten einfach nichts aus. Sobald die Servos mechanisch blockiert werden geht das Getriebe kaputt.

Aus meinem defekten Servo konnte ich ein Zahnrad "verpflanzen" aber ich denke es ist nur ein Notbehelf. Über kurz oder lang werden alle Servos mit Metallgetriebe ausgerüstet!

Jemand ne Idee wie ich ein SO-24 Bauteil auf einer Lochrasterplatine anschliessen kann? Ich würde meine Schaltung zur LED Steuerung gerne erst testen bevor ich sie auf eine Platine brenne.

[Geistesblitz]

Was meinst du eigentlich mit "mechanisch blockiert"? Versucht, über den Anschlag hinaus zu fahren? Sowas sollte man schon konstruktiv vermeiden, sonst ist es kein Wunder, dass das Getriebe hops geht. Ansonsten sind irgendwelche gewichtskompensierenden Komponenten wirklich sehr hilfreich, falls das mit den Beinmassen zu tun haben sollte.

Mit dem SMD-Bauteil wird wirklich ein bisschen fummelig. Ich hab mir mal ein Adapterboard aus normalen Platinenmaterial geschnitzt und da den IC mitsamt ein paar Stiftleisten raufgelötet, Funktion noch nicht getestet. Ansonsten hab ich auch schon gesehen, den IC auf einen Brocken Heißkleber zu kleben und dann die Beinchen mit dünnem Draht mit dem Rest zu verlöten, aber dazu braucht man wirklich eine ruhige Hand. MisterMou müsste wissen, von welchem Konstrukt ich schreibe