Rotationsproblematik - Koordinatentransformation

[ikarus_177]

Hallo,

ich habe ein kleines Problem, das auf den ersten Blick zwar trivial aussieht, für mich jedoch artet es immer mehr ins Philosophische aus, je länger ich drüber nachdenke. Vielleicht hat ja einer von euch eine Idee, wie man das ganze angehen könnte.

Ich mache derzeit für meinen Hexapod die inverse Kinematik in C neu. Ich betrachte in meinen Überlegungen stets nur ein Bein. Der Roboter soll programmtechnisch durch seinen Mittelpunkt (der sich irgendwo im 3D-Raum befindet), dem Punkt, an dem das Bein den Boden berührt, und durch 3 Winkel, die die Drehungen des Roboterkörpers im Raum angeben, bestimmt werden.
Nehmen wir an, der Roboter befindet sich mit seinem Mittelpunkt im Ursprung des Koordinatensystems, der Bodenpunkt befindet sich irgendwo im 1. Quadranten. Der Roboter ist weiters in allen drei Achsen geneigt. Die Drehwinkel sind bekannt, sie werden ja durch die Steuerung/den Benutzer vorgegeben.
Weiters bekannt ist der Montagepunkt des Beines am Roboterkörper, wenn sich dieser im Ursprung befindet und keinerlei Drehung aufweist, also quasi die Standardposition bei Programmstart.

Da sich mit geneigtem Roboterkörper schwer rechnen lässt, ist mein Ansatz, die Drehungen des Körpers "auszudrehen" also den Körper in den jeweiligen Achsen um die jeweiligen (negativen) Winkel wieder in Ruhelage zu bringen. Der Bodenpunkt muss dabei natürlich mitgedreht werden, die relative Lage dieses Punktes zum Körper soll ja nicht verändert werden. Danach bräuchte ich den Montagepunkt des Roboters, der ja nun mit dem Standard-Montagepunkt gleichbedeutend ist, in den Nullpunkt zu schieben, den "verdrehten" Bodenpunkt mitzuschieben, und die Gelenkswinkel zu bestimmen.

Aber: wie annulliere ich nun die Drehwinkel des Körpers? Sprich, mit welcher Achse fange ich an? Ich weiß ja nicht, in welcher Reihenfolge die Drehungen erfolgt sind, sodass ich sie durch Umkehrung wieder rückgängig machen könnte.
Andererseits könnte ich ja so tun, als würde ich mir den Befestigungspunkt des Beines ausrechnen, indem ich zuerst um die x-, dann um die y- und schließlich um die z-Achse drehe, um danach den Punkt durch Umkehrung wieder zurückzubewegen. Da ja die Rotation des Bodenpunktes von der des Körpers abhängt, müsste diese Reihenfolge auch für den Bodenpunkt gelten. Dann müsste aber auch jede andere beliebige Folge gültig sein, und doch bringt jede dieser Möglichkeiten ein anderes Ergebnis zutage.

Wo liegt der Haken, wo hab ich was entscheidendes übersehen?

Danke fürs lesen und noch einen angenehmen Abend,
ikarus_177

[ähM_Key]

Mach mal bitte ne Skizze von dem Problem und wie das Bein augebaut ist.
Das hilft vl. schon sehr viel weiter.

[Besserwessi]

Die Reihenfolge der Drehungen kann man nicht vertauschen.

[hosti]

Das heisst es ist egal in welcher reihenfolge, richtig?

[PicNick]

WIr haben da auch schon herumgehirnt, vielleicht findest du was, was du brauchen kannst
http://www.rn-wissen.de/index.php/Spinnenbeine_%28Hexapods%29

[ikarus_177]

Hallo und guten Morgen,

danke für die Antworten!


Das heisst es ist egal in welcher reihenfolge, richtig?
Das ist es eben nicht, ich habs ausprobiert ;-)

Hier mal eine kleine Skizze:

http://ires.roboterbastler.de/downloads/Skizze.png

Der erste Teil des Bildes zeigt den Roboter, der in einer Achse gedreht ist, wenn man von vorne draufschaut. Die beiden Bodenpunkte der Beine liegen logischerweise am Boden. Um jetzt einfacher rechnen zu können, möchte ich den Körper (ggf. um alle Achsen) so drehen, dass er "parallel" zum Koordinatensystem liegt. Natürlich müssen die Bodenpunkte mitgedreht werden, deren Abstand und Ausrichtung relativ zum Körper müssen ja gleich bleiben. Das zeigt das zweite Teilbild.
Wenn der Roboter (so wie hier) nur in einer Achse geneigt ist, ist die ganze Sache ja einfach; ich drehe einfach um den gleichen Winkel wieder zurück in die Ausgangslage. Wie aber drehe ich, wenn der Roboter in allen Achsen geneigt ist; sprich, welche Achse kommt zuerst dran?

Viele Grüße
ikarus_177

[mare_crisium]

ikarus_177,

Du hast recht: Die Reihenfolge der Drehungen ist nicht egal. (Siehe z.B. Anhang). Wenn Du aber für die Hin-Transformation eine bestimmte Reihenfolge der drei Drehungen festlegst, und für die Rück-Transformation genau die umgekehrte verwendest, dann sollte es klappen ;-) . Das Verfahren ist im Anhang auf Seite 3 auf der linken Folie angedeutet.

Ciao,

mare_crisium

Edit: Anhang gelöscht wg. Upload-Quota

[PicNick]

Wie immer man es berechnet, aber auf einer Schiefen Ebene würde man eher so eine Haltung einnehmen (um sich abzustützen)

[dennisstrehl]

Ich habe ein ähnliches Problem und noch keine Lösung dafür.

Was mir dazu einfällt: Für kleine Drehwinkel ist die Reihenfolge der Drehungen egal, wenn man keine mathematisch exakten Ergebnisse braucht. Man könnte also, wenn man eben keine kleinen Winkel hat, die Drehungen in Schritte zerlegen, die jeweils kleiner als z.B. 5° sind. Dann führt man abwechselnd die Drehungen um x- und y- Achse aus, bis der gewünschte Drehwinkel erreicht ist.

Oder?

[vohopri]

Hallo,

das kommt jetzt nur darauf an, wie deine dir bekannten Orientierungswinkel definiert sind. Daraus kannst du eine Rehenfolge oder eine Umrechnung ableiten. Vor Allem kommts da immer drauf an, ob man Winkel zu Achsen, oder Winkel zu Ebenen hat. Das schaut oft aufs erste Hinsehen alles gleich auf, aber beim Verarbeiten zeigen sich gemeinerweise dann die Feinheiten.

@ Dennis: der Versuchung zu so einer Näherungslösung würde ich widerstehen. Denn erstens gibt es eine exakte Lösung und zweitens wirst du die Fehler nicht mehr los (weder numerisch noch in den schwammigen Definitionen die man so einführt).

@ Philipp: Das Verwenden eines Koordinatensystems, das am chassis ausgerichtet ist, ist einmal sicher vernünftig. Poste doch mal ganz exakt, wie die Verdrehungswinkel vorliegen und wie sie definiert sind.

grüsse,
Hannes

[HeXPloreR]

Hallo,

warum möchtest Du überhaupt dieses "herausdrehen" machen? ich meine, der Zusatnd auf dem oberen Bild ist doch eigentlich der gleiche wie der unten...das Koordinatensystem der Füße (Raumkoordinate) zu drehen macht doch nur Sinn, wenn sich auch tatsächlich der "Boden" neigt - und da auch nur um z. B. Bewegungen auszugleichen. Das soll hier aber wohl nicht gemeint sein.

Aber Du schreibst etwas geht vom Roboter aus, also würde ich statt die Raumkoordinaten zu drehen das Roboterkoordinatensystem drehen. Normalerweise sollten sich dann die Wert einstellen die Du laut deiner Bilder etwa haben müsstest. Und mit denen solltest Du dann auch Deine Verdrehung hinbekommen.
Tatsächlich ist es doch von der Berechnung her egal ob Du die Raumkoordinaten zu den Roboterkoordinaten drehst, oder die Roboterkoordinaten zu Raumkoordinaten. Wichtig ist allein das Du das dann immer so berechnest und nicht plötzlich mittendrin etwas tauschst oder anders machst. Hast Du nach so einem Fehler ggf schon gesucht?

Du hast doch zwei Koordinatensysteme oder?

mfg

[ikarus_177]

Hallo,

danke für die vielen Vorschläge!

@mare_crisium: Danke für das Dokument, bis auf den Text versteh' ich aber leider Bahnhof ;-)
Du hast recht: wenn ich für die Hin-Transformation eine Reihenfolge festlege, und die für's zurückdrehen umkehre, müsste es funktionieren. Das Problem dabei ist aber, dass ich keine "richtige" Hin-Transformation habe. Ich weiß ja nur den Mittelpunkt des Roboters und den Bodenpunkt des jeweiligen Fußes. Ich könnte mir zwar den Befestigungspunkt des Beines am Roboter ausrechnen, indem ich den "Ausgangspunkt", also den Standard-Befestigungspunkt bei keiner Neigung, um die drei Achsen drehe (da könnte ich mir ja eine beliebige Reihenfolge ausdenken). Danach dreh ich den Befestigungspunkt mit der selben Reihenfolge wieder zurück, und nimm den Bodenpunkt gleich mit. Da der Befestigungspunkt dann sowieso wieder am Anfang steht, könnte ich mir diese Rechnerei gleich sparen. Dann aber müsste die Endlage des Bodenpunktes aber bei jeder Reihenfolge gleich sein, weil das Programm ja nicht wissen kann, mit welcher Reihenfolge ich den Befestigungspunkt Hin- und wieder zurücktransformiert habe - das ist aber leider nicht so. Irgendwo verständlich?

@PicNick: stimmt natürlich, das zweite Teilbild soll auch nur rein eine "Verdrehung" des ersten sein, sodass der Körper waagrecht steht.

@vohopri: Die Winkel sind (derzeit) als "Abweichungswinkel" des Befestigungspunktes von der Nulllage definiert - also Winkel zu Achsen. In der ersten Version der IK hatte ich nur ein Koordinatensystem, in dem sich der Roboter immer in Nulllage befand, und sich die Bodenpunkte unter dem Körper wegbewegen bzw. drehen. Das hatte den Vorteil, dass es zwar für den Anfang relativ überschaubar und einfach bleibt, leider war damit ein geneigtes Laufen o.ä. nur sehr schwer möglich. Deshalb wollte ich nun zwei Koordinatensysteme verwenden, eines, in dem sich der Roboter im Raum bewegt und auch dreht, und ein zweites, in dem der Roboter wieder in Nulllage ist, und die Bodenpunkte entsprechend gedreht werden. Ich wollte nun vom ersten aufs zweite Koordinatensystem umrechnen, indem ich zuerst den Robotermittelpunkt in den Ursprung schiebe, und danach um die jeweiligen Achsen drehe, sodass der Roboter schließlich parallel zum zweiten Koordinatensystem steht. Dieser Ansatz ist eigentlich aus dem heraus entstanden, da ich noch nicht herausgefunden hab', wie ich (einfach) den Gelenkswinkel (z.B. mit einem Tangens) ausrechne, wenn der Roboter als ganzes geneigt ist, und der Winkel, wenn ich von oben (also parallel zur z-Achse im Ortsfesten Koordinatensystem) auf den Roboter schaue, durch dessen Rotation verzerrt ist.

@HeXPloreR: dürfte der Großteil schon oben stehen ;-)

Viele Grüße
ikarus_177

[HeXPloreR]

Hi,

Deine Gelenkwinkel sollten sich daraus ergeben das Du das Roboterkoordinatensystem auf die Achsen des Bots legst...und daraus deine Neigung an den Coxa-Gelenken mit der IK + oder - einrechnest.

Dein maximaler Drehwinkel ergebt sich doch aus deiner Roboter-Goemetrie (inkl. Beinpositionen) / Servostellwinkel. Und den bekommst Du wenn dein RoboterKOS sich auf dem RaumKOS dreht. Deine Füße sind am Raum festgemacht, und der Körper dreht quasi frei MIT seinem "KOS"=Koordinatensyste.

Das laufen mit komplett einseitig gesenktem Körper ist allgemien sowieso nicht das gleiche laufen wie "normal", weil ja die Gelenkwinkel "runtergedrückt" werden, also eingeschränkt in der möglichen Bewegung sind. Entweder liegen die zur Berechnung vorliegenden Winkel außerhalb von 90°/deine IK rechnet ggf nicht bis 180° - was wohl auch noch etwas schwieriger dann wird.

Probier doch die Drehung erstmal ohne Neigung aus - also nur paralleles RoboterKOS zu RaumKOS - oder hab ich das überlesen und das hast Du schon hinter Dir?


mfg

EDIT: Übrigens kann ich Dir nur empfehlen min. zwei Beine in Abhängigkeit beim drehen zu betrachten. Vorne links - hinten rechts; vorne rechts - hinten links, mitte links -rechts.

Wie berechest Du es im Moment wenn Du schon nach z.B dem Tangens fragst? Denn soweit ich weiß geht IK nicht ohne Winkelberechnung.

Meinen Überlegungen stützen sich unter anderem auf diese Arbeit von Claudia Weiss:
http://medien.informatik.uni-ulm.de/lehre/courses/ss02/Computergrafik/ClaudiaWeiss.pdf

[ikarus_177]

Hi HeXPloreR,

danke für den Artikel!
Die IK, die ich jetzt habe, hatte nur ein Roboterkoordinatensystem. Das machte zwar die Berechnung beim Laufen und Drehen recht einfach und überschaubar, leider war aber ein gekipptes Laufen nicht so einfach möglich, weshalb ich nun "umwagonieren" möchte.

Im Prinzip ist mein derzeitiger Ansatz ziemlich gleich wie dein Vorschlag, das Roboterkoordinatensystem (das stets parallel zum Bot ist) auf die Achsen des Bots zu legen, und ein zweites (Raum-)Koordinatensystem zu verwenden, in dem der Roboter aber gekippt usw. ist. Aber wie komm ich nun auf die Koordinaten des Bodenpunktes im Roboterkoordinatensystem, also wie rechne ich die Punkte um? Mein Ansatz bestand ja in der Drehung um den umgekehrten Winkel, aber das bringt ja einige Tücken mit sich...

Viele Grüße

[Besserwessi]

Wenn man zwei gegeneinander verdrehte Koordinatensystem hat, kommt man um die Drehung nicht herum. Rechnerisch macht man das oft mit Drehmatizen, also Gebilde mit 3x3 Elementen. Damit kann man jede beliebige Drehung beschreiben und auch die Rückrichtung ausrechenen. Das ganze ist aber mathematisch nicht so ganz einfach (je nach Schule kommt das noch dran,oder auch nicht mehr) und auch nicht mehr so anschaulich. Gerade dass man die Reihenfolge der Drehungen im Raum nicht vertauschen kann ist ungewohnt.

Der Wikipedia Eintrag ist leider auch mehr zu Nachschlagen, wenn man es im Pronzip schon kennt:
http://de.wikipedia.org/wiki/Drehmatrizen

[ikarus_177]

Hi Besserwessi,

den Wikipedia-Artikel werd' ich mir anschauen, danke!

Wenn ich nun eine Koordinatentransformation vom globalen Koordinatensystem aufs lokale (Roboter-) System machen will, muss ich wohl zuerst das Roboterkoordinatensystem auf den Ursprung des globalen Systems schieben, und danach die Rotation ausführen? Dann hab' ich ja erst wieder das Problem, mit welcher Achse ich anfangen soll (nur, dass die Rotation jetzt durch die Matritzen berechnet wird)?

Viele Grüße

[Matthias1979]

Hast du nen Beschleunigungssensor drauf?

[ikarus_177]

Hi,

nein, einen Beschleunigungssensor hab ich (noch) nicht.

Ich denke, die Problemstellung lässt sich auf folgendes zusammenfassen: ich hab ein globales Koordinatensystem mit den Achsen x, y und z. Dann hab ich noch ein weiteres Koordinatensystem, dessen Ursprung irgendwo im ersten System liegt, und dessen Achsen u, v und w im Raum (des ersten Koordinatensystems) geneigt sein können. Ich habe nun einen Punkt im globalen Koordinatensystem und möchte dessen Koordinaten in mein zweites System transformieren, den Punkt also "aus Sicht" des zweiten Koordinatensystems darstellen.
Wie stelle ich das nun am besten an? Bei Rotationsmatritzen, wie sie im Artikel auf Wikipedia auftreten, hab' ich noch nicht wirklich Erfahrungswerte aufzuweisen, wie man da jetzt was berechnen kann. Im Netz findet man auch kaum "anfängertaugliches" zu dem Gebiet.

Viele Grüße

[HeXPloreR]

Hey,
also ich denke das Du das nicht unbedingt benötigst bzw nur bedingt und Dir die ganze Sache nur unnötig erschwert.

Wenn man sich bewußt macht das das RoboterKOS den tatsächlichen Körper des Roboters darstellen soll.
Dein RoboterKOS endet bei den geometrischen Gegebenheiten Deines Bots, die Fußpunkte stellen gleichzeitig (oder auch nur) Koordinaten im RaumKOS dar. Damit hast Du eine Verbindung der beiden Systeme. Da sie dadurch verbunden sind braucht man eigentlich doch nichst mehr transformieren. Man sieht das es nur wichtig ist in welche Richtung Du rechnen möchtest - also vom RaumKOS zum RoboterKOS, oder von RoboterKOS zu RaumKOS - das Ergebnis sollte in beiden Fällen das gleiche sein, und Dir eine Koordinate im RaumKOS liefern nicht im RoboterKOS, denn dort kennst Du bereits die die Du benötigst. Aber nicht vergessen es ist ein Koordinate innerhalb deines beschriebenen Systems, nicht mehr und nicht weniger.
Leider kann ich Dir zu Vektoren und Rotationmatrixen auch noch nicht sonderlich viel sagen.


nfg

[ikarus_177]

Hi,

so ganz verstehe ich das noch nicht. Ich kenne die Lage der Fußpunkte ja nur im Raumkoordinatensystem, nicht in dem des Roboters. Nun möchte ich den Punkt aber auch im Roboterkoordinatensystem - in dem ich ihn ja vorher nicht kannte - beschreiben können.

Viele Grüße

[Matthias1979]

Mit dem Sensor weiß dein Hexapod wie seine Lage im Raum ist.

Z.B. Würde der Robot in deiner ersten Skizze wissen ob er "schieft" steht, oder der Boden.

[mare_crisium]

ikarus,

google doch mal nach "DIN9300"; das ist die Luftfahrtnorm, die die Hin- und Hertransformation zwischen "Himmel und Erde" regelt ;-). Da findest Du einen Link auf eine Studienarbeit (www.astro.ru.nl/~anigl/docs/ilst/study_project_iracs.pdf ), die viele Deiner Fragen bzgl. der Transformation zwischen fahrzeugfesten und ortsfesten Koordinatensystemen beantwortet. Die dort aufgeführten Verfahren und Formeln kannst Du auch auf Deinen Bot anwenden.

Warum interessiert Dich das Thema? Willst Du eine Koppelnavigation für Hexabots aufbauen?

Ciao,

Daedalus
(alias mare_crisium)

[ikarus_177]

Hi Daedalus ;-)

der Hintergrund ist einfach der, dass es erstens bequem und praktisch ist, die Koordinaten des Roboters im Raum und seine Winkel angeben zu können, die Berechnung für die IK lässt sich in einem roboterfesten Koordinatensystem aber sehr vereinfachen. Drum wollte ich die Koordinaten vom ortsfesten auf's "fahrzeugfeste" Koordinatensystem umrechnen, es hat für mich einige Vorteile.

Danke noch für den Link, der sieht interessant aus!

Viele Grüße
ikarus_177

[ikarus_177]

Hallo,

die Studienarbeit von mare_crisium war wirklich sehr hilfreich! Ich will es jetzt so gestalten, wie die Transformation auch in der Arbeit beschrieben ist, eben mit folgender "mords Matrix":

http://upload.wikimedia.org/math/8/4/4/844f7b9069c196964b1d842ea731ead2.png
http://upload.wikimedia.org/math/5/e/0/5e039cc109e7ae0fca0573193bb67cf2.png

Diese Skizze (ebenfalls aus der Studienarbeit) illustriert die Drehung um die Achsen und die Winkel recht gut:

http://ires.roboterbastler.de/downloads/Eulerwinkel.png

So kann ich mir direkt Winkel für Yaw, Pitch und Roll aussuchen, und den Bodenpunkt transformieren, und das sogar relativ komfortabel mit 6 trigon. Funktionen und einigen Multiplikationen.

Vielleicht hilfts ja noch jemanden.

Viele Grüße