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

[HaWe]

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":

// 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.

[Mxt]

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

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.

[HaWe]

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.

[Mxt]

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:

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:

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.

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.

[HaWe]

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.

[Mxt]

Du hattest ja letztens diesen Benchmark. Da sind Matrixmultiplikationen drin. Mehr braucht man für Richtung a) im Prinzip nicht.

[HaWe]

ja, diese einfachen Dinger habe ich mal irgendwo abgeschrieben, weil ich damals schon wusste, dass man ohne Matrizen für IK nicht auskommt (und um IK geht es ja ebenso), daher habe ich sie schon mal in den BrickBench mit reingenommen.
Beide Richtungen sind also wichtig:
a) Eingabe aller Einzelwinkel => Endposition des Greifers samt seiner Stellung (Eulerwinkel yaw, pitch, roll),
b) Eingabe einer Raumkoordinate samt Winkelstellung des Greifers => Berechnung aller Einzelwinkel

Aber wenn dir das bisschen schon reicht mit der Matrizenmultiplikation für so eine Lib, dann machs einfach damit

[HaWe]

ja, das klingt nach einem guten Ansatz, eben noch ein nur theoretisches Konzept, wobei noch rechts/links-Rotationen in manchen Teilarm-Achsen zu berechnen wären, nicht nur Abwickeln rauf/runter, samt Berechnung der Orientierung des Greifers (Schachfiguren senkrecht von oben mit den Fingerspitzen und Öffnung zur Seite, eine Flasche von beliebigen Seiten waagerecht mit der ganzen Hand, für schräg liegende Objekte mit einer diagonalen Position annähern und greifen...)
Aber wenn du so eine Lib mal in einem ersten Teststadium fertig hast, sag bitte gleich Bescheid, dann teste ich es hier gleich aus!

[HaWe]

inzwischen hat sich herausgestellt, dass 5 DOF zu wenig sind, gebraucht werden 6 DOF für den Arm (auch für seitwärts-Drehung im Unterarm für die Zange), unabhängig von zus. 1 DOF (auf/zu) für die Zange - im Wesentlichen ähnelt er "großen" Kuka Roboterarmen:

\   /
 \ /      finger length       50 mm
 |-|  6   claw spread   
  |       metacarpal length   55 mm
  |       
  o   5   metacarpal rotate
  |     
  |       wrist length        95 mm
  |     
  v   4   wrist tilt       
  |       
  |       forearm segment2    50 mm
  |       
  o   3   forearm rotate
  |
  |       forearm segment1   100 mm
  |
  v   2   elbow tilt     
  |       
  |
  |       upper arm length   180 mm
  |
  |         
  v   1   shoulder tilt
  |
  |       shoulder height     15 mm
  o   0   trunc rotate horiz   
  |     
  |       trunc base          85 mm
  |
 ___      floor

Leider hat der oben erwähnte Autor aber bisher seine angekündigte Lib weder für 5 noch für 6 DOF weiter entwickelt, es ist in den allerersten Anfängen stecken geblieben. Vermutlich ist er selber überfordert, auch ich kriege es ja mit meinen rudimentären Kenntnissen über Matrizen und anayltische-Geometrie nicht hin.
Also noch mal zurück auf Los:
Wer kennt brauchbare, auf den oben skizzierten Arm anwendbare Libs, wo man nur die Länge der Arm-Segmente und die Orientierung der Knick-/Dreh-Achsen definieren muss, und dann FK und RK Funktionen frei nutzen kann?