Roboterprofis für Ihren Erfolg
Roboterprogrammierer auf Stundenbasis engagieren
jetzt Preise und verfügbare Roboterprogrammierer anfragen

Autor Thema:  MOV/MXT Kommando - Raum- oder Werkzeugkoordinaten für a/b/c verwenden?  (Gelesen 1461 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Offline blutsauger

  • Forum Mitglied LV 5
  • *
  • Beiträge: 46
  • Bewertet: 0
Kann ich dem MOV Kommando (oder einem anderen) sagen, dass die a/b/c Parameter sich nicht auf das Koordinatensystems der Hand beziehen, sondern auf die Weltkoordinaten?
In der Teachbox gibt's da ja zwei verschiedene JOG-Modi. Die suche ich im Melfa-Basic, und vor allem brauche ich das unbedingt im Realtime Protokoll. Auch da wird sich nicht sonderlich groß ausgelassen, auf welches Koordinatensystem sich diese Werte beziehen.

Merci -
Alex.
  • finde ich gut    Danke, das hat mir geholfen    brauche Hilfe    da stimmt was nicht    Lesenswert


Mitsubishi Roboterservice
Beratung, Verkauf, Inbetriebnahmen, Wartung und Reparatur von Mitsubishi Robotern
ROBTEC GmbH ist Offizielles Robotercenter von Mitsubishi Electric

Offline blutsauger

  • Forum Mitglied LV 5
  • *
  • Beiträge: 46
  • Bewertet: 0
Um das Problem noch etwas konkreter zu beschreiben:
Ich versuche, die Ausrichtung der Hand (a/b/c) anhand von drei gegebenen Punkten im Raum zu bestimmen.
P1->P2 ist der Richtungsvektor, P3 bestimmt die Drehung um die Vektor-Achse:


                     P3
                     |
                     |
<Hand>P1============>P2


Ich kann jetzt die Winkel a/b/c um die Weltkoordinaten-Achsen damit bestimmen.

Aber der Roboter scheint a/b/c immer als Tool-Koordinaten zu interpretieren. Und das bedeutet, dass wenn ich die a-Achse drehe, die b-Achse nicht mehr parallel zur y-Achse liegt.

Im Handbuch steht, dass die a/b/c Parameter in der Reihenfolge c->b->a abgearbeitet werden, und man deshalb auf die Reihenfolge achten muss.

Bedeutet das, dass ich jetzt die Tool-Transformation auch noch rückwärts rechnen darf?

Schöner fände ich es, wenn man a/b/c _immer_ parallel zu den Weltkoordinaten angeben kann und der Roboter sich seine Rotations-Matrix daraus selber rausrechnet. Mit der Teachbox klappt das ja schliesslich auch.

Argl...  :twisted:

Alex.
  • finde ich gut    Danke, das hat mir geholfen    brauche Hilfe    da stimmt was nicht    Lesenswert

Offline Urmel

  • Global Moderator
  • Forum Legende LV 1
  • *
  • Beiträge: 1120
  • Bewertet: +16
Hallo,

uff, Mathematik an Feiertagen, aber ich werds mal versuchen.  :-| :? :huh: :denk:

Also Mov und Mxt fahren immer in Weltkoordinaten. Aber eine Bewegung in Toolkoordinaten ist in Melfa Basic nur eine Matrixmultiplikation weit weg:

P10 = ( 0, 0, 10, 0, 0, 0 )

Mov P_Curr + P10   ' Fährt 10 mm relativ in Z-Weltkoordinaten

Mov P_Curr * P10   ' Fährt 10 mm relativ in Z-Toolkoordinaten

Bei Drehungen sollte das genauso sein. Siehe
http://mitsubishi-roboter.de/files/detailed_explanations_of_functions_and_operations.pdf
Seite 132.

Bei Mxt muss man viel selber rechnen. Ob eine Bewegung da in Welt- oder Tool- oder Sonstwas-Koordinaten ist, hängt meist von der Multiplikationsrichtung ab. Mit dem Inversen von Matrizen wird da auch teilweise gearbeitet, da hast du schon recht. Mit diesen Dingen habe ich selber aber nicht so viel zu tun, das kann ich nicht auswendig aufschreiben.

Ich glaube du beschreibst gerade die Melfa Basic Funktion "Fram". Wenn man mit Mxt arbeitet, muss man sich die selbst bauen. (Ungetestete Vermutung: Vektor von P1 nach P2, Vektor von P2 nach P3, Kreuzprodukt daraus bilden. Die drei Vektoren zu Einheitsvektoren normieren, in die ersten drei Spalten der Matrix eintragen. Vierte Spalte hat die X,Y,Z-Koordinaten von P1. Wahrscheinlich noch einige Fallunterscheidungen nötig.)

Grüße

   Urmel
« Letzte Änderung: 20. April 2014, 10:03:51 von Urmel »
  • finde ich gut    Danke, das hat mir geholfen    brauche Hilfe    da stimmt was nicht    Lesenswert

Offline blutsauger

  • Forum Mitglied LV 5
  • *
  • Beiträge: 46
  • Bewertet: 0
OK, ich will das mal ein wenig weiter dokumentieren (Es handelt sich um einen 6-Achser). Folgendes Melfa-Basic Programm fährt eine geteachte Position an und verändert dann hintereinander unabhängig die Parameter a/b/c:

Servo On
Ovrd 10
'
'=====================
' Veraenderung des a-Parameters
'
P1=(+400.00,+0.00,+400.00,-90.00,+90.00,-90.00,+0.00,+0.00)(7,0)
Mov P1
For i = -90 To -60 Step 1
  P1.A = Rad(i)
  Mov P1
Next i
'
'=====================
' Veraenderung des b-Parameters
'
P1=(+400.00,+0.00,+400.00,-90.00,+90.00,-90.00,+0.00,+0.00)(7,0)
For i = -90 To -60 Step 1
  P1.C = Rad(i)
  Mov P1
Next i
'
'=====================
' Veraenderung des c-Parameters
'
P1=(+400.00,+0.00,+400.00,-90.00,+90.00,-90.00,+0.00,+0.00)(7,0)
For i = 90 To 60 Step -1
  P1.B = Rad(i)
  Mov P1
Next i


Was passiert ist, dass bei der Änderung von a und c sich die Achse J6, die nach unten schaut, einmal rechts-herum ('a') und einmal links herum ('c') dreht.
Beide Parameter a und c sind hier also nicht linear unabhängig, das verwirrt mich ein wenig.
Die Variation des b-Parameters sorgt dafür, dass sich die Hand um die physikalische x-Achse dreht, wobei ja 'b' eigentlich der y-Achse zugeordnet ist.

Meine _Vermutung_ ist, dass das Tool-Koordinatensystem anhand von a/b/c rotiert wird, und zwar in der Reihenfolgen c->b->a, wie im Handbuch angegeben. Wobei aber jeweils das Tool-Koordinatensystem wieder als Ausgangspunkt für die einzelnen Rotationsschritte verwendet wird.

Und weil ich das ja schließlich alles in Realtime programmieren will, helfen mir die Melfa-Basic Tools nur soweit, das ganze zu verstehen.

Jaja, 3D-Matrizenrechnerei am Feiertag ist echt kein Spaß!  :wallbash:

Aber ich werde berichten, was ich weiter herausfinde.

Alex.
  • finde ich gut    Danke, das hat mir geholfen    brauche Hilfe    da stimmt was nicht    Lesenswert

Offline Hermann

  • Forum Legende LV 2
  • *
  • Beiträge: 1381
  • Bewertet: +56
Eins vorweg: habe keine Ahnung von Mitsubishis. War der Meinung die bauen Autos :mrgreen:
Trotzdem solltest Du Dir vielleicht mal diesen Artikel:
http://www.roboterforum.de/roboter-forum/kuka-roboter/reihenfolge-der-rotationen/msg56517/#msg56517
von Puck durchlesen. Mir scheinen da einige Ähnlichkeiten vorhanden zu sein.
  • finde ich gut    Danke, das hat mir geholfen    brauche Hilfe    da stimmt was nicht    Lesenswert

Offline Urmel

  • Global Moderator
  • Forum Legende LV 1
  • *
  • Beiträge: 1120
  • Bewertet: +16
Hach ja, immer diese Matrizen

Ne, gleicher historischer Ursprung, aber seit den 1920ern haben die nix mit dem Autobauer mehr zu tun.

Aber du hast soweit recht, die Eulerwinkel und Matrizen sind die gleichen wie bei Kuka, nur anders hingeschrieben, A und C sind vertauscht.

Da ist richtig, sie sind nicht unabhängig. Sie sind noch nicht mal eindeutig. Zwei Positionen können unterschiedliche A,B,C Winkel haben und sind trotzdem gleich orientiert. Passiert bei der Übernahme aus Simulationen sehr häufig, das der Roboter die Positionen anders darstellt als die Simulation.

Wenn man allerdings eine Position in Matrixdarstellung hat, ist die eindeutig (bis auf die Stellungsflags, die haben aber nichts mit der TCP-Position zu tun). Aus der Matrix kann man direkt ablesen, wie das Roboterwerkzeug zur Basis steht, sie besteht nämlich aus vier 3D-Vektoren:

Exx Eyx Ezx X
Exy Eyy Ezy Y
Exz Eyz Ezz Z
0    0     0    1

Ex, Ey und Ez sind Einheitsvektoren, die in die X,Y,Z-Richtungen des Toolkoordinatensystems zeigen. Die vierte Spalte ist die Verschiebung zur Basis. Wenn man also wissen will, wie z.B. die Tool-Z-Achse zum Weltkoordinatensystem steht, nimmt man den Vektor aus der dritten Spalte. Das geht nicht direkt mit den A,B,C-Winkeln (nur in sehr einfachen Ausnahmefällen).
« Letzte Änderung: 22. April 2014, 08:19:02 von Urmel »
  • finde ich gut    Danke, das hat mir geholfen    brauche Hilfe    da stimmt was nicht    Lesenswert

Offline blutsauger

  • Forum Mitglied LV 5
  • *
  • Beiträge: 46
  • Bewertet: 0
Danke Hermann und Urmel für eure Infos. Sie decken sich mit dem, was ich inzwischen durch Reverse-Engineering rausgefunden habe.

Die 'Hin-Richtung', d.h. mit gegebenen a/b/c das Tool-Koordinatensystem auszurechnen, geht ja noch relativ einfach.

Aus einem geforderten Tool-Koordinatensystem die a/b/c rauszubekommen, war mein Ziel, und ich glaube jetzt zu wissen, wie es geht.

Ich habe es mit dem 'raumfesten Achsen' Ansatz gelöst. Wichtig dabei ist, erstmal zu wissen, wo die 0 Grad von a/b/c sind.
Es werden die Parameter a, b, c in dieser Reihenfolge abgearbeitet.
'a' dreht um die x-Achse, wobei 0 Grad die z-Achse ist.
Dann: 'b' dreht um die (Welt-)y-Achse, wobei 0 Grad ebenfalls die (Welt-)z-Achse ist.
Dann: 'c' dreht um die (Welt-)z-Achse, wobei 0 Grad die (Welt-)y-Achse ist.
Bei allen drei Parametern schaut man 'von aussen' in Richtung Ursprung auf die Achsen der Welt-Koordinaten.

Um zu einer gegebenen Soll-Orienterung des Tool-Koordinatensystems die a/b/c zu extrahieren, muss man die 3 Schritte rückwärts rechnen, d.h. erst c, dann b und dann a bestimmen, dabei immer das Tool-Koordinatensystem um den jeweiligen Parameter zurückrotieren.
Der 'c' Parameter ist dabei aber nicht einfach der Winkel zwischen den beiden z-Achsen, man muss bedenken, dass das auch einen Einfluss auf die folgenden Rotationen hat. Das bricht einem das Hirn!

In mathematischer Schreibweise sieht das immer ganz elegant aus. Muss man das programmieren, hat man es mit diversen Division/0 Problemen und wie schon erwähnt, Uneindeutigkeiten zu tun.

Interessant dabei war auch zu beobachten, dass die Stellungsmerker (flags1) eine entscheidende Rolle spielen:
In einem Fall, wo die a/b/c hübsch linear von Punkt zu Punkt interpoliert waren, hat sich die J4 + J6 Achse bei jedem Schritt einmal um 360 Grad gedreht, wobei es das garnicht gebraucht hätte. Nachdem ich flags1 von 7 auf 6 gesetzt hatte, war die Bewegung kontinuierlich.

Ich führe jetzt keine weiteren geometrischen Details aus, wen's interssiert kann mich gern kontaktieren.

Alex.

  • finde ich gut    Danke, das hat mir geholfen    brauche Hilfe    da stimmt was nicht    Lesenswert


xx
R3 Protokoll Fehler QeR510000 bei EXEC Kommando

Begonnen von blutsauger

3 Antworten
908 Aufrufe
Letzter Beitrag 04. Oktober 2013, 01:14:50
von blutsauger
xx
Virtueller Raum

Begonnen von Schubbi

2 Antworten
1502 Aufrufe
Letzter Beitrag 29. Mai 2008, 09:42:34
von Schubbi
xx
Unterschied bei Positionsberechnung P1 +P2 oder P1 * P2

Begonnen von Zvende81

3 Antworten
422 Aufrufe
Letzter Beitrag 06. Mai 2017, 15:54:29
von Urmel
xx
Koordinatensystem oder Zählrichtung von RP-3AH ändern

Begonnen von Muses

2 Antworten
1356 Aufrufe
Letzter Beitrag 05. Oktober 2010, 17:31:54
von Martl
 

über das Roboterforum

Nutzungsbedingungen Impressum
Sitemap