22. Juli 2019, 20:41:24
Roboterforum.de - Die Industrieroboter- Anwender und Experten Community

[offen] Quarternion - Roboterposition plötzlich 180° verdreht


normal_post Autor Thema: [offen] Quarternion - Roboterposition plötzlich 180° verdreht  (Gelesen 1203 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

19. Juni 2018, 15:03:08
Gelesen 1203 mal
Offline

Potte1604


Hallo zusammen,
evtl. kann mich einer zu diesem Phänomen aufklären.. Ich habe einen Palettierroboter, der Bauteile in insgesamt 4 verschiedenen Richtungen ausgerichtet absetzen soll. Diese Positionen müssen senkrecht zum Werkobjekt angefahren werden (Z-Achse TCP entgegengesetzt parallel zu Z-Achse wobj). Es finden Verdrehungen um die Z-Achse um 0°, 180°, 90° bzw. 270° statt.
In Quarternion ausgedrückt:
Winkel (Drehung um Z-Achse des Werkobjekts)q1q2q3q4
0100
180°0010
90°0-0.7071070.7071070
270°0-0.707107-0.7071070

Diese Positionen liegen jeweils in verschiedenen Werkobjekten - jeweils für ein Werkobjekt ein Satz Positionen, da sich hier die Achskonfigurationen signifikant unterscheiden können.
Jetzt habe ich das Programm auf einen anderen Roboter kopiert, dabei haben sich die 90° und die 270°-Positionen um 180° um die Z-Achse gedreht. Jetzt habe ich dazu das Vorzeichen von q3 geändert und die Position war wieder in Ordnung.

Soweit so gut. Jetzt ereilte mich die Meldung, dass der Roboter ein Bauteil um 180° um Z gedreht eingesetzt habe und ich versuche jetzt herauszufinden, weshalb dem so ist.

Gibt es dazu eine Erklärung bzw. eine Möglichkeit der Abhilfe?
  • gefällt mir    Danke

Heute um 20:41:24
Antwort #1

Werbung

Gast

19. Juni 2018, 16:35:59
Antwort #1
Offline

Micky


Hallo,
hast Du eventuell in Deinem Programm  die Achskonfiguration mit "ConfL\Off" bzw. "ConfJ\Off" abgeschaltet?
Wenn ja, könnte hier der Fehler liegen!
Der Roboter versucht dann die Position auf dem kürzesten Weg anzufahren und achtet dabei nicht auf die Konfiguration der Achsen, so dass die 6. Achse die Position auch um 180 Grad gedreht erreichen kann.
Du solltest die Achskonfiguration nur dann ausschalten, wenn es unbedingt erforderlich ist und sie bei nächster Gelegeheit sofort wieder einschalten. Denn ansonsten kann der Fehler immer wieder auftreten.
Mfg
Micky
  • gefällt mir    Danke
Probleme kann man niemals mit derselben Denkweise lösen, durch die sie entstanden sind. (Albert Einstein)

19. Juni 2018, 17:03:04
Antwort #2
Offline

Potte1604


Hallo Micky,
mit ConfJ/L versuche ich so gut es geht sparsam umzugehen. In diesem Programm sind diese auch nicht benutzt. Genauso wenig verwende ich die Instruktion "SingArea"... Ich wünschte, es wäre anders, aber es ist leider nicht die Lösung. :? 

MfG

  • gefällt mir    Danke

21. Juni 2018, 20:41:06
Antwort #3
Offline

Konstantin


Hallo Potte 1604
Manchmal passiert es das ein Mitarbeiter ein Teil zur Prüfung nimmt und dies dann falsch zurücklegt. Wenn das möglich ist und das Teil rechts/links aufgenommen werden kann, dann würde ich nicht weiter suchen.
Gruß,
Konstantin
  • gefällt mir    Danke

22. Juni 2018, 09:40:29
Antwort #4
Offline

Programmiersklave


Ich hab' aus dem Bauch heraus immer einen Horror vor Orientierungen, bei denen man Vorzeichen ändern kann, ohne dass sich was an der Stellung ändert. [180°, 0°, 90°] ist dasselbe wie [-180°,0°,90°]. [0,-0.707107,-0.707107,0] ist dasselbe wie [0,0.707107,0.707107,0]; und [0,-0.707107,0.707107,0] entspricht  [0,0.707107,-0.707107,0]. Bin mathematisch nicht so fit, aber stelle mir dann immer "Totpunkte" vor, wie sie mein Grundschullehrer schon an seiner mitgebrachten Dampfmaschine eindrucksvoll demonstrierte. 

Und diese "Totpunkte" reichen ja auch in die Mathematik, Tangens von 90° und solche Sachen, als Programmierer kämpft man ja auch außerhalb der Roboterwelt mit sowas, wenn man Reaktionen auf Sensoren in Algorithmen pressen will. 

Dann habe ich mich schon oft genug mit dem Typ "num" des ABB rumgeärgert. Der ist nämlich (als atomare Komponente des Strukturtyps "Orient") ziemlich limitiert.  Die fragliche Zahl 0.707... ist ja gar nicht so rund, sondern es ist SQRT(2) / 2, ~ 0,70710678118654752440084436210485.............

Probier mal das Programm: 
MODULE te
    PERS orient inori:=[0,-0.707107,-0.707107,0];
    PERS num winkel{3}:=[-180,0,90];
    PERS orient outori:=[0,-0.707107,-0.707107,0];
    PROC ow()

        winkel{1}:=EulerZYX(\X,inori);
        winkel{2}:=EulerZYX(\y,inori);
        winkel{3}:=EulerZYX(\z,inori);
        stop;
        outori:=OrientZYX(winkel{3},winkel{2},winkel{1});
        !
    ENDPROC
ENDMODULE

und schau, was nachher in outori drinsteht...

Rapid kennt die Funktion NOrient(..), Ungenauigkeiten sind systembedingt.

Und dann gibt es ja heutzutage Multithreading und Branch-Prediction auf Prozessorebene. Was passiert, wenn sich mehrere Prozessoren gleichzeitig mit demselben Totpunkt beschäftigen? Ich habe keine konkrete Ahnung, aber ein schlechtes Bauchgefühl. In der Gleitkommadarstellung ist das Vorzeichen nur ein Bit.

Was ich mit all dem sagen will: wenn es mein Problem wäre, würde ich zuerst die Orientierungen künstlich verschlampen. Ein halbes Grad hier, ein halbes Grad dort, das könnte schon heilsam wirken. Der reinen Lehre zufolge ist das zwar eigentlich Quatsch, aber so'n Roboter ist auch nur'n Mensch....
Wenn es dann noch mal auftritt, weißt Du wenigstens, dass es daran nicht gelegen hat.

Grüße,
Michael
  • gefällt mir    Danke

Heute um 20:41:24
Antwort #5

Werbung

Gast

22. Juni 2018, 12:46:46
Antwort #5
Offline

Hermann


Bei einem einzigen Bauteil unter mehreren hundert oder gar tausend? --> Meldung ignorieren, bis sie nochmal kommt. Das war dann m.E. kein Programmierproblem.
180 Grad Verdrehung kann m.E. auch nichts mit den oben diskutierten Quaternionen / ConfL / ConJ usw.  zu tun haben. Da würde der Roboter versuchen um 360 Grad zu drehen, was dann meistens wegen Energieführung oder Endschalter nicht geht.
  • gefällt mir    Danke


Teile per facebook Teile per linkedin Teile per pinterest Teile per reddit Teile per twitter
 

über das Roboterforum

Nutzungsbedingungen Impressum Datenschutzerklärung

Sponsoren des Roboterforums

ROBTEC GmbH