- Akku Tests und Balkonkraftwerk Speicher         
Ergebnis 1 bis 10 von 31

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

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    HaWe
    Gast
    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.

  2. #2
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    04.09.2011
    Ort
    Hessen
    Beiträge
    707
    Zitat Zitat von HaWe Beitrag anzeigen
    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.

  3. #3
    HaWe
    Gast
    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.

  4. #4
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    04.09.2011
    Ort
    Hessen
    Beiträge
    707
    Du hattest ja letztens diesen Benchmark. Da sind Matrixmultiplikationen drin. Mehr braucht man für Richtung a) im Prinzip nicht.

  5. #5
    HaWe
    Gast
    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

  6. #6
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    04.09.2011
    Ort
    Hessen
    Beiträge
    707
    Da geht ja was:
    https://github.com/bolderflight/Eigen
    Von einer der wichtigsten oben verlinkten Libs gibt es einen Port für den Teensy. Damit dürfte einiges aus dem Roboticbereich darauf laufen, ROS oder die Robotics Library der TU München verwenden alle Eigen.

  7. #7
    HaWe
    Gast
    das ist jetzt vielleicht ein kleiner Mosaikstein, aber nicht die Lösung der TOP Frage...
    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

  8. #8
    HaWe
    Gast
    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!

  9. #9
    HaWe
    Gast

    6-7 DOF robot arm

    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:

    Code:
    \   /
     \ /      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?

Ähnliche Themen

  1. Hilfe für Inverse Kinematik
    Von fredyxx im Forum Software, Algorithmen und KI
    Antworten: 7
    Letzter Beitrag: 18.05.2016, 11:28
  2. inverse kinematik für quatropoden
    Von glitsch im Forum Software, Algorithmen und KI
    Antworten: 19
    Letzter Beitrag: 11.09.2012, 07:48
  3. Inverse Kinematik
    Von AndyTrendy im Forum Allgemeines zum Thema Roboter / Modellbau
    Antworten: 12
    Letzter Beitrag: 03.11.2008, 18:47
  4. Mega8 Inverse kinematik hexapot
    Von hopix im Forum Bauanleitungen, Schaltungen & Software nach RoboterNetz-Standard
    Antworten: 1
    Letzter Beitrag: 11.03.2008, 08:12
  5. inverse Kinematik / humanoide Roboter
    Von siroks im Forum Buchempfehlungen
    Antworten: 4
    Letzter Beitrag: 05.09.2007, 16:57

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  

fchao-Sinus-Wechselrichter AliExpress