Quarternion - Roboterposition plötzlich 180° verdreht

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

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

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

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.