Winkelkorrektur beim Absetzen (Palettierroboter)

    Hallo,

    für einen Palettierroboter möchte ich eine Art "Nachkorrigieren" von Setzpositionen realisieren.
    Heisst so viel wie: der Roboter bekommt seine Palettierpositionen von einem externen System (in idealer Hinsicht) fertig bereitgestellt.
    Nun soll man aber die Möglichkeit zum "Feinkorrigieren" von Winkeln bekommen in Folge eines leichten "Verzugs" des Greifer oder Ähnlichem. Sprich ich möchte auf die ideale Position noch allgemein ein Winkel von z.B. 0,5° für A,B,C "dazumachen".

    Da habe ich dann mittels geometrischem Operator etwas programmiert das folgendermaßen aussieht:

    PTP XSetzposition : Winkelkorrekturen

    Das funktioniert aber nicht so wie ich mir das vorgestellt hatte, da die Winkel a,b,c im Operator nicht den Winkeln a,b,c des Basesystems entsprechen (in dem ich als Bediener "denke")
    Es kommt hinzu: wenn sich Setzpositionen grundlegend in ihren Winkeln ändern, habe ich auch eine andere "Orientierung des Tools bezüglich zur Base" und die Winkelkorrekturen A,B,C (die man in Bezug zur Base erwartet) sind dann nochmals anders.

    D.h. ich wäre im Prinzip an einer "allgemeingültigen Orientierung des Tools in Bezug zur $Base in Abhängigkeit der anzufahrenden Setzposition" interessiert. Mir fällt es gerade sehr schwer eine solche Beziehung aus den $Tool Winkeln und den Winkeln der Fahrposition herzuleiten. Denke ich da zu kompliziert und sollte da einfacher rangehen ? Oder gibt es eine Kuka Systemvariable die mir die Orientierung des Tools in Bezug zur Base verrät ?

    Eine kleine Hilfestellung begrüsse ich sehr.

    Viele Grüsse,

    Robin

    Edited once, last by Robin / Robout (July 6, 2022 at 4:02 PM).

    • Schritt für Schritt zum Roboterprofi!

    Hallo Robin,

    ich bin mir nicht sicher ob ich dein Problem richtig verstanden habe:

    Ist deine Setzposition auch automatisch deine neue Base?

    Falls ja kannst du einfach eine Relativbewegung ausführen, die Winkelwerte beziehen sich Defaultmäßig auf deine verwendete Base.

    Code
    LIN_REL {A 5,B -2,C 3}

    Sofern deine Base irgendwo anders im Raum steht, könntest du dir den Vektor von deiner aktuellen Position zu deiner Setzposition ausrechnen.

    Code
    DECL FRAME Vektor

Vektor = INV_POS($Pos_Act_Mes):Setzpos

    Dieser Vektor enthält die Delta-Winkel der Istposition zu deiner Setzposition.

    Wenn du anschließend deine Istposition mit den Delta-Winkeln verrechnest stehst du wieder korrekt ausgerichtet im Raum.

    Falls das deine Frage nicht beantwortet hat, versuch es bitte nochmal zu erläutern,

    Hallo Tobbyash,

    Also die Base bleibt im Prinzip die ganze Zeit an der Kante der Palette...
    Kann das Problem gerne noch etwas näher schildern...
    Also ich bekomme die Setzpositionen in Form von x,y,z,a,b,c von dem externen System... (Frame)
    Welches ich dann mittels PTP Fahrbefehl anfahre. Ist auch alles gut soweit...
    Das merkwürdige passiert dann wenn ich zum Beispiel hingehe und die Winkel leicht korrigieren möchte...
    Also statt z.B. Setzpos1 = {x 100 , y 100 ,z 250 , a 0, b 90, c 0)

    das Frame Setzpos1_korr = = {x 100 , y 100 ,z 250 , a 2, b 90, c 0)

    anfahre.. mit der Intention den Greifer leicht um +2° in a Winkelrichtung (gemäß Base) zu korrigieren.

    Tut es eben nicht... woraufhin ich hingegangen bin und das per geometrischem Operator hinkriegen wollte. Nämlich:

    PTP Setzpos1 : {x 0, y 0, z 0, a 2, b 0, c 0}

    Da ist aber auch eine Varianz drin in Abhängigkeit von den a,b,c Winkeln der Setzpos1, beziehungsweise eben von der Stellung des Tools in Bezug zur Base. Also wenn ich z.b. wüsste dass die x-Koordinate des Tools in z-Richtung der Base schaut, dann könnte ich hingehen und den Korrekturwert um den Winkel a der Base im Operator an die Stelle c schreiben, sprich:

    PTP Setzpos1 : {x 0, y 0, z 0, a 0, b 0, c 2}

    Nach meinem jetzigen Verständnis dreht der geometrische Operator das Tool nicht um die Base sondern um das eigene $Tool System wenn ich das so pauschal sagen kann ? Bräuchte aber die Drehung um die Base :/
    Ist eine Anwendung bei der sich die Winkel oft ändern beim Setzen.

    Danke für den Hinweis zu dem Relativbefehl (da müsste ich dann ja die Tool Orientierung konstant halten, was ich eventuell vermeiden wollte)
    Das mit der Vektorabfrage kann ich eventuell an anderer Stelle gebrauchen(!?)


    Gruss,

    Robin

    Hallo Fubini,

    nach der Beschreibung von KUKA würde ich dann aber bei den Translationen in Setzpos1 (x,y,z) dann auch die Achsen x,y,z rotieren. Ich will aber das Tool in der Setzpositionen um die a,b,c gemäß der Grundbase Orientierung drehen, oder ?

    Gruss,

    Robin

    Dann schau dir mal $rot_sys und $trans_sys an.

    Post

    RE: Relativ zu BASE (ich verzweifele)

    Ipo_mode definiert ob ihr ein feststehedes Werkzeug habt. Also ob der Roboter das Bauteil oder das Werkzeug hält. Letzten Endes funktioniert das technisch so, das Tool und Base die Rollen vertauschen und der pos_act invertiert wird.

    Was passiert eigentlich bei lin_rel mit Tool ist das korrekt?



    […]

    Was für einen Wert hat $ROTSYS (eventuell auch $rot_sys erinner mich nicht genau) Darüber kann man einstellen ob xyz bzgl. Base und ABC bzgl Tool verfährt oder umgekehrt. Man kann also wählen und…
    fubini
    November 16, 2021 at 7:27 PM

    Fubini

    Hallo,

    komme wschl. erst nächste Woche wieder ans System (steht beim Kunden) werde dann ein paar Sachen ausprobieren.

    $ROTSYS - "Rotationsbezugssystem bei Relativsätzen im Vorlauf"
    Hört sich sehr vielversprechend an... wäre das idealerweise dann:

    $ROTSYS = #BASE

    damit der Geometrische Operator (siehe mein Beispiel oben) dann um die Base Winkel dreht ?

    und die Einstellung

    $ROTSYS = #TOOL

    so wie ich das momentan als Drehung um das Tool-Koordinatensystem beobachte ?

    Oder bezieht sich $ROTSYS leider nur auf Befehle wie LIN_REL oder sonstiges...? Wäre jedenfalls ein Traum wenn ich damit den geometrischen Operator wahlweise auf $Base / $Tool beziehen kann.

    Gruss,

    Robin

  • Robin / Robout July 6, 2022 at 3:59 PM

    Changed the title of the thread from “Abfragen wie das Tool in Bezug zur Base orientiert ist (dynamisch)” to “Winkelkorrektur beim Absetzen (Palettierroboter)”.

    Und wie das Tool in Bezug zur Base orientiert ist kannst Du doch an der Teachposition selbst erkennen. Die Teachposition bezieht sich ja auf die Base.

    Anbei ein Beispiel aus einem Palettierprgramm bei dem der Ursprung der Base gleichzeitig Platz 1 der Palette ist.

    Pos 1,2 und 6 sind um 179° in A verdreht zur Base.

    ;Greifpositionen

    DECL POS Mag_2_GP[80]

    Mag_2_GP[1]={X 0.0,Y 0.0,Z -7.93154764,A 179.193024,B 0.0,C 0.0,S 2,T 10}

    Mag_2_GP[2]={X 60.0000,Y 0.0,Z -7.95628166,A 179.193024,B 0.0,C 0.0,S 2,T 10}

    Mag_2_GP[3]={X 120.000,Y 0.0,Z -7.98100,A 0.193028510,B 0.0,C 0.0,S 2,T 10}

    Mag_2_GP[4]={X 180.000,Y 0.0,Z -8.00573444,A 0.193028510,B 0.0,C 0.0,S 2,T 10}

    Mag_2_GP[5]={X 240.000,Y 0.0,Z -8.03046799,A 0.193028510,B 0.0,C 0.0,S 2,T 10}

    Mag_2_GP[6]={X 0.0,Y 60.0000,Z -7.92012262,A 179.193024,B 0.0,C 0.0,S 2,T 10}

    LIn_rel ist ja schön und gut, aber da muss der Roboter schon auf der Position stehen. Wenn man jetzt die Anfahrposition VOR dem Zielpunkt anpassen will, dann steht man da im kurzen Hemd. ;)

    Da muss man selber rechnen. sowas wie (halber Pseudocode)

    Geht schon, muss man ihm eben die Hand brechen. 😁

    Dachte ich auch erst, aber die werden schon wissen was sie da für einen Roboter haben. Manche sagen halt zu einem Standard Roboter 'Palettierroboter' weil er igend was palletiert, und nicht weil es die besondere Roboter Bauart ist.

    Quote from Der_Robonaut

    Wie Fubini schon gesagt hat: Dann dreh um.

    Drehung um Toolkoordinatensystem:

    PTP Setzpos:{x 0, y 0, z 0, a 2, b 0, c 0}

    Drehung um Basekoordinatensystem:

    PTP {x 0, y 0, z 0, a 2, b 0, c 0}:Setzpos

    Das probier ich mal wenn ich wieder dran bin, ich befürchte aber da wird die x,y,z Translationen der Setzpos dann aber in die um a = 2° gedrehten Koordinatenachsen zeigen... Zumindest wenn man der KUKA Abbildung des geom. Operators glaubt.

    Natürlich habe ich schon probiert hier kleine Winkeloffsets auf A,B,C draufzurechnen, aber das ist ja mein Problem. Geht nicht.
    Manchmal dreht er statt um a um c und das auch stark abhängig von der Winkelorientierung.

    Ich fahre eben auch auf FRAME und nicht auf E6POS

    Bei den E6POS würde sich ja der Turn ändern je nachdem ob da bei A mal 90° oder zum Beispiel -90° und das ist bei dieser Palettieranwendung eben sehr flexibel

    Beim Anfahren meiner Setzpos bin ich natürlich mal hingeganen und hab mir den $Pos_Act Frame mal abgegriffen wenn der Rob die Posi erreicht. Und da gilt eben Setzpos != M_Pos_Act

    Quote from Hermann

    LIn_rel ist ja schön und gut, aber da muss der Roboter schon auf der Position stehen. Wenn man jetzt die Anfahrposition VOR dem Zielpunkt anpassen will, dann steht man da im kurzen Hemd. ;)

    Da muss man selber rechnen. sowas wie (halber Pseudocode)

    Hallo Herrmann,

    ja ist ein 6-Achsroboter aber geht um eine Palettieranwendung. Das werde ich mal testen indem ich "kurz" die Translationen "wegblende".

    Hallo Robin,

    da würde ich meinen Vorschlag nochmal aufgreifen:

    Quote

    Sofern deine Base irgendwo anders im Raum steht, könntest du dir den Vektor von deiner aktuellen Position zu deiner Setzposition ausrechnen.

    Code

    Code
    DECL FRAME Vektor

Vektor = INV_POS($Pos_Act_Mes):Setzpos

    Dieser Vektor enthält die Delta-Winkel der Istposition zu deiner Setzposition.

    Wenn du anschließend deine Istposition mit den Delta-Winkeln verrechnest stehst du wieder korrekt ausgerichtet im Raum.

    Ich würde mir die Setzpos als neue Base rausschreiben und den Vektor dann als Bewegungspunkt darunter einspeichern. Das ergibt die aktuelle Roboterposition in Bezug auf die Base. Diese kannst du dann beliebig manipulieren, bezogen auf dein Tool oder die Base (=Setzpos).

    Quote from Robin / Robout

    Natürlich habe ich schon probiert hier kleine Winkeloffsets auf A,B,C draufzurechnen, aber das ist ja mein Problem. Geht nicht.
    Manchmal dreht er statt um a um c und das auch stark abhängig von der Winkelorientierung.

    Ich fahre eben auch auf FRAME und nicht auf E6POS

    Bei den E6POS würde sich ja der Turn ändern je nachdem ob da bei A mal 90° oder zum Beispiel -90° und das ist bei dieser Palettieranwendung eben sehr flexibel

    Beim Anfahren meiner Setzpos bin ich natürlich mal hingeganen und hab mir den $Pos_Act Frame mal abgegriffen wenn der Rob die Posi erreicht. Und da gilt eben Setzpos != M_Pos_Act

    Nochmal zum Verständniss:

    Du willst dass die Winkelkorrektur eine Drehung um den TCP bewirkt, allerdings ist die Orientirung des Werkzeugs nicht konstant.

    Das heißt Winkelkorrektur Werkzeug weg vom Roboter kippen wäre bei Pos 1 z.B. c- und bei Pos 3 b+.

    Stimmt das soweit?

    Wieviel Positionen und verschiedene Orientierungen hast Du denn ca. ?

    Quote from Tobyasch

    Hallo Robin,

    da würde ich meinen Vorschlag nochmal aufgreifen:

    Ich würde mir die Setzpos als neue Base rausschreiben und den Vektor dann als Bewegungspunkt darunter einspeichern. Das ergibt die aktuelle Roboterposition in Bezug auf die Base. Diese kannst du dann beliebig manipulieren, bezogen auf dein Tool oder die Base (=Setzpos).

    Die Setzpos wäre ja sogar schon ein Frame.

    Auf das wollte ich eigentlich auch hinaus.

    Einfach auf die POS/E6POS/FRAME die Winkelkorrektur dazurechnen funktioniert nicht.

    Dann drehst du um die Base.

    Anhand der A,B,C Koordinaten der Setzpos musst Du entscheiden in welche Richtung des Tool Koordinatensystems du kippen willst.