Killough Platform - omnidirektionale Bewegung

Hi Leute!
Hat jemand von euch Erfahrung mit Killough Platformen?
Interessannt wäre hier für mich die Berechnungen von Drehwinkeln, resultierenden Geschwindigkeiten, Positionsänderungen, etc.

Wer nicht weiss was was ne Killough-platform ist schaut hier auf Seite 23 nach:

http://www.tu-chemnitz.de/etit/proau...boKing2005.pdf

die bieten zwar die primitiv - Berechung für Geschwindigkeit an, allerdings unter Auschluss von Rotation. Es gibt zwar die Möglichkleit, einen Drehwinkel in die Formel einzusetzen, dadurch ändert sich ja aber dann die Vx Vy Komponente für den Bot relativ zur Umwelt....
Autsch...das riecht ja nach ner richtig üblen Differentialgleichung.....
bin zu faul....hat jemand von euch zuviuel Zeit und mag es an Formeln rumzubasteln ? *g*

Und noch ne Frage:
zum Antrieb:
Ich dachte das ganze auf ner hexagonalen basis aufzubauen,
dann drei Schrittmotoren direkt an die Achsen, gut durchmixen und fertig...! *g*

Hab leider nicht den Überblick auf dem Schrittmotormarkt, deshalb: was würdet ihr mir für Motoren empfehlen?

Danke schon im voraus...

greetz

Flo

Ne, nix Differentialgleichung!!
http://www.ais.fraunhofer.de/BE/volk...iVolksBot2.ppt

Sehr guter Link...vielen dank *g*

können die AVRs trigonometrische Funktionen by default?

Sorry, war nicht eingeloggt.

da ich das ding erstmal nur zu testzwecken, also nur die Platform selbst bauen will sollte ja jeder halbwegs normale Schrittmotor passen, odeR?

Hab da noch ein Problem erkannt......die formln zur Bewegungsrichtung berrechnen schön und gut, aber:

Wir nehmen mal an auf dem Boden wäre ein Raster gemalt mit Koordnaten (Xb,Yb). der Roboter Navigationsalgorithmus rechnet die entsprechenden Radgeschwindigkeiten mit vorgegebener Richtung (Xr,Yr)und Geschwindigkeit aus. Solgane der bot sich nicht dreht kein Problem, da ja das interne koordniatenraster (Xr,Yr) parallel/überlappend/was auch immer zum Bodenraster (Xb,Yb) ist.

Was aber wenn der Bot sich nun dreht? Dann leigen die Koordniaten raster nicht mehr parallel.....

....

Hmmm.....könnte man vielleeicht den Winkel zwischen den beiden Koordinatensystemen während der Drehung bestimmen/mitloggen (wär ja kein Problem) und dann die Navi-routine mit modifizierten Werten (unter Breücksichtigung des Differenzwinkels) füttern ?

Um die Bewegung eines bewegten Koordinatensystems bezüglich eines festen Koordinatensystems zu beschreiben, kann man folgendermaßen vorgehen: Eine allgemeine Bewegung setzt sich zusammen aus einer Translation und einer Rotation um einen momentanen Punkt. Die Translation ist ein Vektor[x,y,z]. Die Rotation stellt man zweckmäßigerweise in einer Rotationsmatrix dar. In dieser Matrix stehen die entsprechenden Parameter die die Rotation beschreiben (Eulerwinkel, Kardanwinkel, Eulerparameter,...). Wenn du nun einen Punkt in deinem bewegten Kos hast und den mit der (inversen) Rotationsmatrix multiplizierst, bekommst du die Koordinaten, die er im Kos vor der Drehung haben würde. Wenn du nun noch den Verschiebungsvektior abziehst hast du die Position im festen Kos. Als Winkel würde ich Kardanwinkel nehmen, die sind für solche Probleme recht anschaulich.
( siehe Automobil: gieren, nicken, rollen) Wenn du also die Drehung um die z-Achse erfassen kannst, hat deine Matrix nur eine Veränderliche. Und du kannst die Position relativ einfach rückrechnen.
Ich würde mal bei Google schauen unter Kinematik, Robotik, Koordinatentransformation, Mehrkörperdynamik, Relativkoordinaten etc.

MfG Distel

ok soweit hab ich das verstanden...
sehr schön....dickes Plus *g*
da stellt sich für mich nur ein Problem:
zurückrotieren kein Problem...aber:
Woher bekomme ich den Verschiebungsvektor?
ist das der Vektor, der von dem stationären Kos-Ursprung auf den derzeitgien Standort im stat-kos zeigt und die entsprechende Länge hat?
ISt dieser Verschiebugnsvektor im stat-kos?
Ich denk mal schon, denn ich gleiche die Winkeldifferenzen ja mit der Rotation aus und verschiebe mit dem Vektor im im stat-Kos.

was ist nun aber, wenn ich abgebogen bin?

Um das Prinzip weiter zu verfolgen müsste ich sozusagen bei jeder Richtungsänderung über die zurückgelegte entfernung und die Richtung den ausgangspunkt bestimmen und den Vektor speichern. Wenn ich dann mehrere dieser Vektoren hab, addiere ich sie und bekomme den Verschiebungsvektor, ne?

Aber ich sehe ein neues problem....während ich die Translationm mit Rotation durchführe und die Mottoren dabei konstant angetrieben werden, vollführe ich ja ne Kreisbahn, deren Radius von der Rotationsgeschwindigkeit und der Translationsgeschwindigkeit abhängt....dann wäre es ja sogut wie unmöglich (gibts nich ich weiss...aber unpraktikabel) den Vektor zu bestimmen....ausser man könnte den RAdius bestimmen...hmm.....ich denk mal drüber nach *g*

aloternatvi könnte man die Motoren während der Bewegung permanent "umansteuern" sodass die Bewegung linear verläuft, der bot sich aber eben dabei dreht.......


hmmm....hmmmm....hmmmm...

Zitat:

---

Woher bekomme ich den Verschiebungsvektor?
ist das der Vektor, der von dem stationären Kos-Ursprung auf den derzeitgien Standort im stat-kos zeigt und die entsprechende Länge hat?
ISt dieser Verschiebugnsvektor im stat-kos?
Ich denk mal schon, denn ich gleiche die Winkeldifferenzen ja mit der Rotation aus und verschiebe mit dem Vektor im im stat-Kos.

---

Ja.

Zitat:

---

Um das Prinzip weiter zu verfolgen müsste ich sozusagen bei jeder Richtungsänderung über die zurückgelegte entfernung und die Richtung den ausgangspunkt bestimmen und den Vektor speichern. Wenn ich dann mehrere dieser Vektoren hab, addiere ich sie und bekomme den Verschiebungsvektor, ne?

---

Ja.

Zitat:

---

Aber ich sehe ein neues problem....während ich die Translationm mit Rotation durchführe und die Mottoren dabei konstant angetrieben werden, vollführe ich ja ne Kreisbahn, deren Radius von der Rotationsgeschwindigkeit und der Translationsgeschwindigkeit abhängt....dann wäre es ja sogut wie unmöglich (gibts nich ich weiss...aber unpraktikabel) den Vektor zu bestimmen....ausser man könnte den RAdius bestimmen

---

Eine Möglichkeit wäre vielleicht auch den großen Radius zu zerlegen. Also man hat dann viele kleine Vektoren und Drehmatrizen, die zusammen eine Kreisbahn oder Ellipse ergeben. Wenn man das in bestimmten (kleinen) Intervallen erfasst, dürfte das gehen. Es wäre dazu natürlich eine relativ große Rechenleistung notwendig.

Hi!
Hab mal n bissl rumgegoogled und dabei ein paar recht interessante Dinge gefunden.
Und zwar ham die ganzen RoboSoccer Unis da recht interessante Abhandlungen, da die eben auch das Prinzip als Bewegungsbasis verwenden.
Bin nur dübergeflogen, aber klingt sher vielversprechend...
Nur die Frage ob der kleine AVR mit den Berechnungen dann nicht überfordert ist.....mal sehen...wens interessiert, hier n paar links:
http://rsise.anu.edu.au/~nmb/omnidrive_dynamics4.pdf
http://zen.ece.ohiou.edu/~robocup/pa...57_correct.pdf
http://www.mae.cornell.edu/raff/Pape...4/nagRAS04.pdf

ich denke mal da sollte sich was brauchbares rausholen lassen *g*
(denke so an: gegeben: Ausgangsposition, Zielposition und bis dahin erfolget rotation -> Vx,Vx,Vrot oder noch besser V1,V2,V3 für jeden Motor, das müsste dann eben recht häufig, ideal: echtzeit berechnet und aktualisiert werden)

Unter http://www-2.cs.cmu.edu/~pprk/physics.html gibts ne gute Abhandlung zum Thema Navigation mit Omnidirektionaler Bewegung.

Gruss,

Andre