5 DOF Roboterarm: Arduino-Programme für Kinematik u. inverse Kinematik?

hallo,
ich vermute, es gibt nur sehr wenige, hoffe aber dennoch wenigstens ein paar hier im Forum, die sich damit auskennen und es auch schon benutzen:

Wer hat Erfahrung mit Arduino-Programmen für 5-6 DOF Roboterarme für Kinematik u. inverse Kinematik?
Literatur gibt es zwar zuhauf, aber extrem vermathematischt und mit irrsinnig viel Matrizenrechnung, die mich ehrlich gesagt überfordert, um sie in arduinisch zu programmieren.

In meinem Fall handelt es sich um diesen Robotarm hier (5 drehbare Achsen plus Greifer, die erste Ache (Schulter) und die letzte Achse (Handgelenk) vor dem Greifer sind rotierbar entlang der Auslenkung, die anderen knicken senkrecht zur Auslenkung) :

https://www.ebay.de/itm/Assembled-6D...53.m1438.l2649

Was das Ziel sein soll:
Nach Definition der Armlängen und Rotationsachs-Dimensionen (Knicken oder rotieren innerhalb der Achse) sollte man folgendes machen können:

a) Kinematik:
Wenn man eine beliebige Kombination von Drehwinkeln für jede einzelne Achse eingibt (alpha, beta, gamma, delta, epsilon), dann soll als Ergebnis die absolute Raumposition (x,y,z) errechnet werden (z.B. für die Greifer-Mitte);

b) Inverse Kinematik:
Nach Eingabe einer absoluten Ziel-Koordinate (x,y,z) z.B. für die Greifer-Mitte soll für alle Servos eine Lösung für die erforderlichen absoluten Drehwinkel berechnet werden, sodass man sie per analogWrite-pwm dann dorthin bewegen kann (es gibt u.U. mehrere Lösungen, welche man dann bekommt oder verwendet, wäre dann noch zu überlegen).

Wer kennt sich damit selber wirklich gut aus?

Hmm, immer noch nicht weiter gekommen?

Ich kenne mich mit Deiner Problemstellung nicht aus. Aber ein Tipp von mir:
Die Position auf einer Kreisbahn kannst Du über den Radius berechnen. Stichwort: Berechnungen im Kreis oder Kreisberechnungen.
Damit kannst Du die Positionen ausrechnen, die Du auf einer Kreisbahn, ausgehend von einem Mittelpunkt (die Achse eines Motors) unter Angabe des Radius (Armlänge/Armteillänge bis zum nächsten Gelenk), maximal erreichen kannst.
Ist eine Position nicht erreichbar, müsste man auf den nächsten Drehpunkt übergehen (zum Beispiel einen zurück) und von dort aus rechnen.

Gemacht habe ich das noch nicht, aber das wäre mein Ansatz.

MfG, Moppi

Ich denke der Lösungsweg ist nicht das Problem. Es wird halt jemand gesucht, der ihn gehen soll.

Weg a) geht im Prinzip so
https://de.wikipedia.org/wiki/Denavi...Transformation

Weg b) macht man wohl heute meist mit einer Kombination aus
https://de.wikipedia.org/wiki/Jacobi-Matrix
https://de.wikipedia.org/wiki/Pseudoinverse

Eigentlich muss man das aber nicht wirklich wissen, weil es diverse C++ Bibliotheken gibt, die das schon fertig können.
http://roboop.sourceforge.net/
https://moveit.ros.org/
http://www.orocos.org/kdl
Die sind aber nicht geeignet, weil keine fertigen Portierungen auf Arduino existieren oder möglich sind.

Auch Rechnen mit mehr Handarbeit mit den gängigen C++ Matrix Libs wie z.B.
http://eigen.tuxfamily.org/index.php?title=Main_Page
http://arma.sourceforge.net/
ist wohl nicht gefragt, weil es zumindest keine fertigen Portierungen auf Arduino gibt.

Das ist alles, was ich beitragen könnte, ist aber keine fertige Lösung, daher zu verwerfen.

Ich halte von so fertigen Sachen nicht wirklich viel. Es sei denn, es wäre sehr sehr kompliziert. Dass man nicht selbst einen Lösungsweg suchen könnte. Es gibt für viele , per mathematischer Formel sehr komplizierte Sachen einfache Lösungswege, auch für 8-Bit-Computer oder 16 Bit Computer. Als Beispiel sehe ich immer auf Doom, was ich als erstes 3D-Spiel hatte. Echtzeit 3D-Berechnung der Grafik-Engine hätte mit komplexen mathematischen Formeln, auf den damaligen leistungsschwachen Computern gar nicht funktioniert. Da werden Punkte im 3D-Koordinatensystem in Echtzeit auf einer 16MHz-CPU berechnet. Innerhalb Bruchteilen von Sekunden sind das oft mehr als 8 Punkte pro Objekt. Wenn man dann sieht, wie es gemacht wird, staunt man, wie einfach die Lösung gewesen ist. Daher denke ich, lohnt es, zu versuchen, das selber zu lösen. Da weiß man hinterher, warum es funktioniert oder warum auch etwas nicht funktioniert.

Richtung a) ist nicht rechenaufwändig. Ohne das würde kein Industrieroboter funktionieren. Ging natürlich schon mit den allerersten und bevor es überhaupt Prozessoren als eigenständiges IC gab.

Mit b) ist das zumindest "live" während der Bewegung anders. Bei den japanischen Robotern, mit denen ich an der Arbeit zu tun habe, kam das erst bei den Modellen in den 1990ern, die schon 32 Bit Prozessoren hatten (damals Intel i960).

wer immer die inverse Kinematik auf Arduino selber portieren möchte, möge das gerne tun!
Bewährt hat sich wohl die Denavit–Hartenberg Konvention
https://en.wikipedia.org/wiki/Denavi...erg_parameters

IMO wäre es als User-Schnittstelle am einfachsten, und für verschiedene Robotarm-Designs am flexibelsten, wenn der Nutzer seine Robotmaße einfach eingeben könnte in eine Reihe von arrays. Statt die genauen Achs-Positionen einzugeben, könnte man sich auch auf "TILT" fürs abknicken und "ROTATE" fürs drehen in der Armlängsrichtung beschränken, für lineare Aktuatoren und auch für die virtuelle Greifposition in der Zange auch Typ "LINEAR":

Code:

---

// cusomize your arbitrary robot arm dimensions and design.

#define MAXJOINTS 6


Jtype[0] = ROTATE; // turntable joint
Jangl[0] = 270;  // max turn angle
Lleng[0] = 95;  // turntable height in mm

Jtype[1] = TILT; // shoulder joint
Jangl[1] = 180;  // max turn angle
Lleng[1] = 105;  // upper arm length in mm

Jtype[2] = TILT; // elbow joint
Jangl[2] = 180;  // max turn angle
Lleng[2] = 97;  // forarm length in mm

Jtype[3] = TILT;  // wrist tilt
Jangl[3] = 90;    // max turn angle
Lleng[3] = 65;  // wrist length: not exaclty linear mounted!

Jtype[4] = ROTATE;  // metacarpal rotate.
Jangl[4] = 90;      // max turn angle 
Lleng[4] = 50;    // metacarpal  length

Jtype[5] = LINEAR;  //  longitudinal finger length (not opening!!)
Jangl[5] = 0;    // virtual grab position, no motor used  (claw open/close external cmd)
Lleng[5] = 60;  // finger length = grab area length metacarpal to fingertip

---

Bild hier  

und das Robot-Programm verkettet dann diese Werte zur Kette der Teil-Arme, in dem es sie in seine Matrizen einsetzt.

Für mich persönlich überschreitet das meine Kompetenzen bei weitem, sonst würde ich es selber machen.
Daher, insb. @moppi: wenn du es dir zutraust: Immer gerne!

Zum Rechnen würde sich sicher ein M3 (Due) oder auch ein M4 mit fpu anbieten.

Zitat:

---

Zitat von HaWe

IMO wäre es als User-Schnittstelle am einfachsten, und für verschiedene Robotarm-Designs am flexibelsten, wenn der Nutzer seine Robotmaße einfach eingeben könnte in eine Reihe von arrays,
[...]
und das Robot-Programm verkettet dann diese Werte zur Kette der Teil-Arme, in dem es sie in seine Matrizen einsetzt.

---

Das ist im wesentlichen das Vorgehen bei dem oben verlinkten Roboop, auch wenn da eine etwas andere Schreibweise verwendet wird. Hier ein auf die Schnelle im Code gefundenes Beispiel für den historischen Unimation Puma 560

Code:

---

const Real PUMA560_data[] =
  {0, 0, 0, 0, M_PI/2.0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.35, 0, 0, 0,
  0, 0, 0, 0.4318, 0, 0, 0, 0, 17.4, -0.3638, 0.006, 0.2275, 0.13, 0, 0, 0.524, 0, 0.539, 0,
  0, 0, 0.15005, 0.0203, -M_PI/2.0, 0, 0, 0, 4.8, -0.0203, -0.0141, 0.07, 0.066, 0, 0, 0.086, 0, 0.0125, 0,
  0, 0, 0.4318, 0.0, M_PI/2.0, 0, 0, 0, 0.82, 0, 0.019, 0, 0.0018, 0, 0, 0.0013, 0, 0.0018, 0,
  0, 0, 0, 0.0, -M_PI/2.0, 0, 0, 0, 0.34, 0.0, 0.0, 0.0, 0.0003, 0.0, 0.0, 0.0004, 0.0, 0.0003, 0,
  0, 0, 0, 0, 0, 0, 0, 0, 0.09, 0.0, 0.0, 0.032, 0.00015, 0.0, 0.0, 0.00015, 0.0, 0.00004, 0};

---

Vorwärts- und Rückwärtskinematik macht dann die Lib. Aber diese Software ist für Microsoft Visual C++ gedacht, von 1996 bis 2013 aktiv entwickelt worden und hängt von der schon reichlich veralteten C++ Matrizenlibrary newmat ab. Um das in die Arduino IDE hineinzukriegen wäre schon einiges an Detailwissen erforderlich.

Die anderen Libs habe ich mir noch nicht im Detail angesehen.

ja, ich sagte ja selber: extremst kompliziert, für mich ZU kompliziert, ich bin ja absolut nicht vom Fach.
Ein anderer User, der selber auch Robotik studiert, drückte es so aus:
"What would have to be done for such a library is to have an algorithm that assigns these DH parameters automatically based on the parameters the user inputs into it; For each joint i: Theta_i, D_i, Alpha_i, A_i. I think why this hasn't been implemented on Arduino yet is because it is a very difficult problem to generalize and Scientists aren't really interested in implementing things like this for Arduino. As I have said before, all this have been implemented in Matlab in Robotics Toolbox and it is very powerful. I find it very hard though to implement this in an Arduino library, but I guess it's not impossible, it just has to get a bit limited that's all. But note that not anyone can do this, it takes someone with knowledge within this area to implement a library for this."


PS,
bei "meinem" obigen Robotarm kommt erschwerend dazu, dass die vorletzte Achse einen Zwischen-Winkel nach oben hat, weil die Servos aufeinander montiert sind und nicht hintereinander, und daher der Rest dann nicht mehr in der Fluchtlinie liegt, sondern nach oben abgeknickt ist. Wie man das mathematisch beschreibt, ist mir noch völlig schleierhaft.

Nein, nicht völlig schleierhaft ntl, man müsste die Resultierende nehmen, aber dann sind es in jedem Falle keine rechten Winkel mehr hinterher.

Zitat:

---

Zitat von HaWe

bei "meinem" obigen Robotarm kommt erschwerend dazu, dass die vorletzte Achse einen Zwischen-Winkel nach oben hat, weil die Servos aufeinander montiert sind und nicht hintereinander, und daher dann nicht mehr in der Fluchtlinie liegt, sondern nach oben abgeknickt ist. Wie man das mathematisch beschreibt, ist mir noch völlig schleierhaft.

---

Ich denke das ist kein Problem, weil es sich nur um eine Kette von Verschiebungen und Drehungen handelt.

Doom war ja ein interessanter Hinweis von Moppi, zumindest in den Computergrafik Vorlesungen hatte ich diese Matrizen. Das ist zwar schon ewig her, aber das Grundprinzip von a) ist mir soweit klar. Ich versuchs mal:

Wichtig ist zu wissen, das man jede "Roboterposition" im Raum als Koordinatensystem darstellen kann. Also als einen "Punkt mit Orientierung" aus dem die X-, Y- und Z-Achse eines in diesem Punkt liegenden Koordinatensystems "herauswachsen". Der berühmte Tool-Center-Point so eines Greifarms wird so dargestellt. Der Greifer ist an einem Punkt im Raum und zeigt in eine bestimmte Richtung.

Diese 4x4 Matrizen haben einen Aufbau, den man sich gut vorstellen kann:

Code:

---

1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1

---

Das ist die Position des Nullpunktes im Weltkoordinatensystem. Wie man sieht, stehen da Einsen drin, nicht nur Nullen. Die haben eine spezielle Bedeutung.

Erstmal zu den X,Y,Z-Koordinaten. Die Matrix vom Punkt mit den Koordinaten X= 100, Y=200, Z=300 (nicht verdreht zum Koordinatensystem) sieht so aus:

Code:

---

1 0 0 100
0 1 0 200
0 0 1 300
0 0 0 1

---

Man sieht diese drei Felder kodieren die Position im Raum.

Was machen die anderen Spalten ? Ganz einfach, das sind die drei Achsen des Koordinatensystems.

Code:

---

1 . . .
0 . . .
0 . . .
. . . .

---

Das ist die X-Achse. Ein 3D-Vector der immer die Länge Eins hat. Die drei Zahlen sind die Komponente in Welt-X Richtung, Welt-Y Richtung und Welt-Z Richtung. Weil es hier ein nicht gegenüber dem Weltkoordinatensystem verdrehter Punkt ist, zeigt die Punkt X-Achse natürlich voll und ganz in Richtung Welt-X.

Y- und Z-Achse kann man entsprechend sehen.

So, diese tollen Matrizen im Wikipediaartikel dienen jetzt dazu diese Punkte um einen X,Y,Z-Wert zu verschieben, oder um die (lokale oder Welt-) X-, Y- oder Z-Achse zu verdrehen. Diese Verschiebung und die drei Drehungen sind die Grundoperationen. Mehr braucht man nicht. Verkettet werden die Dinger in dem man sie multipliziert.

Vorwärtskinematik ist jetzt nur, das man für jeden Freiheitsgrad des Roboters so eine Matrix aufstellt, wie man von der Basis von Segment x zur Basis von Segment x+1 kommt. Da kommt die jeweilige Achsdrehung noch als Variable hinein.

Das ist Weg a). Das kriegt man im Prinzip zu Fuss hin. D-H ist nur eine Konvention, da gibt es auch andere Varianten.

schon klar, das sind die oben zitierten Matrizen, am ehesten verkettet nach Denavit–Hartenberg, und berechnet "vorwärts" und dann auch invers.
Aber wenn du das ausrechnen und programiieren kannst, das wäre großartig - ICH kann es nicht, daher suche ich eine fertige Lib.