.: Vinculum :. - Hexabot

[HannoHupmann]

Siehe "Fehlschlag der Woche" meine Servos liegen gerade unerreichbar in der Packstation ich muss also erst mal am Montag und nächste Woche einen Weg finden an die übrigen 4 Servos ran zu kommen. Dann hab ich aber auch genug für das Projekt (gut die Hüftservos könnten noch durch bessere ersetzt werden, da sind gerade die Restbestände verbaut und das sind so 5€ Servos).

Die Platinen wollte ich als nächstes aufbauen, allerdings muss ich da auch noch ein paar Teile beim Reichelt bestellen. Die Platinen sind deswegen so günstig, weil ich die privat gemacht bekomme und daher eigentlich nur Versand und Material zahlen muss.

Ja hoffentlich geht es nun mal :-D

[HannoHupmann]

Ich hätte schwören können, dass ich 6 Stück vorbereitet habe, naja muss ich eben nochmal zwei machen.

[HannoHupmann]

Hat eigentlich jemand eine Idee wie ich die Traktorie im µC abspeichern kann? Vielleicht als Bahnkurve mit vielen eigenen Punkten? Irgendwie muss dem Bein ja die Bahn vorgegen werden die die IK nachfährt.

Falls sich überhaupt noch jemand für das Projekt interessiert, ich hab langsam das Gefühl nur noch selber in dem Thread zu posten.

[ikarus_177]

Ich verstehe die Frage nicht so ganz
Willst du die Bahnkurve des Fußpunktes während einer Vorwärtsbewegung speichern und dann nachfahren, oder die während eines Schrittes?

Wieso willst du überhaupt die Kurve speichern, und nicht Punkt für Punkt berechnen und jeweils anfahren?

[rolber]

Hallo Hanno !

Mich würde die Servocontroller Platine interessieren. Ist es der hier vielfach besprochene Atmega8 für 20 Servos oder hast Du was neues entwickelt?
Lese dein Projekt eigentlich durchgehend mit, aber solange für mich alles klar ist, beschränke ich mich ausschliesslich aufs mitlesen.
Weiterhin viel Erfolg !

Roland

[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