KUKA Roboter TCP-Koordinaten im Roboter einem Tool zuweisen bzw. umrechnen?

    Hallo Roboleutz,

    ich habe ein Problem mit der Kamera und einem KUKA-Roboter. Ich habe die Kamera-Basis relativ zum Roboter vermessen, was bedeutet, dass die Kamera und der Roboter das gleiche Ursprungskoordinatensystem verwenden. Die Korrektur der Basis funktioniert soweit gut.

    Der Roboter hat am Greifer ein Bauteil, das aus Aluminium besteht und biegsam ist. Dadurch ergibt sich ein Problem: Das Ende des Bauteils, welches eingeführt werden soll, ist jedes Mal anders ausgerichtet, und auch der Winkel zum Greifer ändert sich bei jedem Zyklus.

    Für unsere Anwendung reicht die Basiskorrektur allein nicht aus, da es Probleme bei Winkeländerungen gibt. Der TCP (Tool Center Point) stimmt nicht mit dem aktuellen Bauteil überein. Das bedeutet, dass ich jedes Mal sowohl den TCP als auch die Basis neu vermessen muss.

    Die Kamera kann die TCP-Koordinaten (X, Y, Z, A, B, C) relativ zu ihrem Ursprungskoordinatensystem messen und an den Roboter senden.

    Die beiden TCPs, die vermessen werden sollen, links und rechts am Greifer befinden. Sie sind jeweils fast 1 Meter von der Mitte des Roboterflansches entfernt – einmal links und einmal rechts.

    Das bedeutet, dass die gemessenen TCP-Koordinaten zunächst auf den Ursprung des Roboterflansches umgerechnet werden müssen. Wie könnte man das machen?

    Meine Frage ist:
    Wie kann ich diese TCP-Koordinaten im Roboter einem Tool zuweisen bzw. umrechnen? Da wir den gleichen Ursprung für die Basis im Roboter und in der Kamera definiert haben, sollte das theoretisch funktionieren.

    Ich komme hier nicht weiter. Hat jemand einen Tipp?

    Edited once, last by privet199 (November 28, 2024 at 8:34 AM).

    • Schritt für Schritt zum Roboterprofi!

    Vielleicht ist die Lösung auch zu simple gedacht aber schreib doch einfach jedes mal die entsprechenden Tool Daten um ?

    In die Config:
    DECL REAL TD_Kamera_X=0.0
    DECL REAL TD_Kamera_Y=0.0
    DECL REAL TD_Kamera_Z=0.0
    DECL REAL TD_Kamera_A=0.0
    DECL REAL TD_Kamera_B=0.0
    DECL REAL TD_Kamera_C=0.0

    ;Die Signale der Kamera einmal auswerten und jeweils beschreiben:
    TD_Kamera_X=giTD_Kamera_X
    TD_Kamera_Y=giTD_Kamera_Y
    TD_Kamera_Z=giTD_Kamera_Z
    TD_Kamera_A=giTD_Kamera_A
    TD_Kamera_B=giTD_Kamera_B
    TD_Kamera_C=giTD_Kamera_C

    ;Werkzeugdaten beschreiben:
    TOOL_DATA[1].X=TD_Kamera_X
    TOOL_DATA[1].Y=TD_Kamera_Y
    TOOL_DATA[1].Z=TD_Kamera_Z
    TOOL_DATA[1].A=TD_Kamera_A
    TOOL_DATA[1].B=TD_Kamera_B
    TOOL_DATA[1].C=TD_Kamera_C


    So habe ich zuerst gedacht und wollte es auch so umsetzen. Aber es wird nicht funktionieren, weil sich die beiden TCPs, die vermessen werden sollen, links und rechts am Greifer befinden. Sie sind jeweils fast 1 Meter von der Mitte des Roboterflansches entfernt – einmal links und einmal rechts.

    Das bedeutet, dass die gemessenen TCP-Koordinaten zunächst auf den Ursprung des Roboterflansches umgerechnet werden müssen. Wie könnte man das machen?

    Quote from privet199

    Das bedeutet, dass die gemessenen TCP-Koordinaten zunächst auf den Ursprung des Roboterflansches umgerechnet werden müssen. Wie könnte man das machen?

    Auch das geht, man muss dazu die Frames passend invertieren oder eben nicht und verknüpfen.

    Invertieren geht mit INV_POS() (Suchfunktion verwenden), verknüpfen mit ":".

    Und 'ne Menge Grübelei... ne Menge!

    Quote from Programmiersklave

    Auch das geht, man muss dazu die Frames passend invertieren oder eben nicht und verknüpfen.

    Invertieren geht mit INV_POS() (Suchfunktion verwenden), verknüpfen mit ":".

    Und 'ne Menge Grübelei... ne Menge!

    Vielen Dank, oh mächtiger Programmiersklave! 🙏 Ich werde mich gleich an das Studium der INV_POS-Funktion machen – klingt ja fast schon mystisch. 😄

    Mein aktuelles Problem habe ich aber pragmatisch gelöst: Ich habe das Tool mit der Spitze vermessen. Bis jetzt läuft die Korrektur mit der Kamera reibungslos, zumindest im kleinen Maßstab. Wir testen es gerade bei größeren Stückzahlen.

    Natürlich ist klar, dass die Kamera angeblich nur einen Fehler von 0,00001 mm liefert (ein Traum!). Aber der Roboter? Bei der Base-Vermessung kommen locker 1 mm dazu, plus nochmal 1 mm durch die Tool-Vermessung. Und dann gibt’s noch die Unterschiede beim Bauteil selbst... Das Ganze fühlt sich an, als würde ich mit einem Neandertaler-Messer gegen ein High-Precision-Gerät antreten. 🗿🔪

    Unsere Einkaufsexperten sehen das natürlich anders. Die denken: „Hey, die Kamera kostet 50 Teuronen, das muss reichen.“ Dass dazu aber auch ein entsprechend genau vermessener Roboter und Greifer gehören, ist für sie wohl... naja, Zukunftsmusik. 🎻

    Habe bei Greifervermessen 10mm Fehler gemessen :)

    So geht's auch, als pragmatische Lösung und vor allem als bessere Lösung, denn hier spielt ja dann noch nicht einmal eine Rolle, was der Roboter glaubt.

    Wird aber ein Problem wenn man nicht "wir" sagen kann, d. h. der Roboter nicht in der eigenen Firma steht und man eine lückenlose und idiotensichere Kalibrierkette einrichten muss. Sobald der Schlosser den Greifer wechselt, läuft einem das Problem hinterher.

    Hab' aktuell 'nen Kunden, der betreibt 25 Jahre alte Anlagen mit dem originalen Roboter und dem originalen Bildverarbeitungssystem, der letzte, der sich auskannte, ist seit Jahren in Rente. Da stellste ALLES in Frage....

    Quote from privet199

    Habe bei Greifervermessen 10mm Fehler gemessen :)

    Da stimmt was nicht. Wenn Du da einfach einen TCP mit der 4-Punktemethode vermessen hast und 10mm Fehler rausbekommst, dann mach das nochmal, und zwar so lange bis ein Fehler unter 1mm rauskommt! Wenn das absolut nicht machbar ist, dann ist der Roboter falsch justiert, oder die Maschinendaten stimmen nicht. Mit sowas kann man keine Vision-Anwendung realisieren.

    Quote from Hermann

    Da stimmt was nicht. Wenn Du da einfach einen TCP mit der 4-Punktemethode vermessen hast und 10mm Fehler rausbekommst, dann mach das nochmal, und zwar so lange bis ein Fehler unter 1mm rauskommt! Wenn das absolut nicht machbar ist, dann ist der Roboter falsch justiert, oder die Maschinendaten stimmen nicht. Mit sowas kann man keine Vision-Anwendung realisieren.


    Ich meinte, dass es Unterschiede beim Vergleich zwischen dem Greifer im CAD-Modell und dem Greifer in der Realität gibt. Der gemessene Messfehler an der Spitze beträgt etwa 1 mm.

    Quote from Programmiersklave

    Auch das geht, man muss dazu die Frames passend invertieren oder eben nicht und verknüpfen.

    Invertieren geht mit INV_POS() (Suchfunktion verwenden), verknüpfen mit ":".

    Und 'ne Menge Grübelei... ne Menge!

    Ich habe folgende Lösung entwickelt: Die Kamera positioniert den Roboter mithilfe der Korrekturen. Der Roboter justiert sich entsprechend. Ich übernehme die Kamerabasis als Tool, indem ich INV_POS() nutze, und werde dieses Tool als korrigierendes Tool einsetzen. Ich werde ausprobieren, ob das wie erwartet funktioniert.

    Hier ist mein Code:

    Code

    Code
    $base = base_Data[1]  
$tool = $NULLFRAME  
Tool_Data[10] = INV_POS($POS_ACT)

    Freue mich auf Feedback und Anregungen!

    Quote from privet199

    Ich meinte, dass es Unterschiede beim Vergleich zwischen dem Greifer im CAD-Modell und dem Greifer in der Realität gibt. Der gemessene Messfehler an der Spitze beträgt etwa 1 mm.

    Da hat der Einkäufer gespart. Wenn du einen Roboter mit Absolutvermessung/Positioniergenau nimmst, dann hast du das Problem nicht. Ich glaube selbst bei den Roboter zwischen 90-300Kg bist du dann bei 0,6 mm.

    Für sämtliche korrekturen bietet sich bei KUKA immer der geometrische Operator an:

    Code
    $config.dat:
Signal X_verschiebung $in[100] to $in[115]
..
DECL Frame corr_frame
;der Roboter mach direkt nen Dezimalwert da draus

    danach in deinem jeweiligen Programm dir nen Korrektur Frame basteln:

    Code
    corr_frame = $nullframe
corr_frame.x = X_verschiebung

    dann etwas später die temporären Tooldaten modifizieren:

    Code
    $tool=tool_data[1]:corr_frame
SLIN zielpos

    wenn es ein geteachter Zielpunkt ist, solltest du den mit "temporären" Tooldaten anfahren:
    ;werkzeug 1 hast du vermessen (mit etwas mühe schafft man da 0,3 mm)

    Code
    tool_data[31] = tool_data[1] : corr_frame
slin xteach with .... [31]

    Edited once, last by Sebastian T (December 3, 2024 at 1:45 PM).

    Quote from Sebastian T

    Da hat der Einkäufer gespart. Wenn du einen Roboter mit Absolutvermessung/Positioniergenau nimmst, dann hast du das Problem nicht. Ich glaube selbst bei den Roboter zwischen 90-300Kg bist du dann bei 0,6 mm.

    Für sämtliche korrekturen bietet sich bei KUKA immer der geometrische Operator an:

    Code
    $config.dat:
Signal X_verschiebung $in[100] to $in[115]
..
DECL Fram corr_frame
;der Roboter mach direkt nen Dezimalwert da draus

    danach in deinem jeweiligen Programm dir nen Korrektur Frame basteln:

    Code
    corr_frame = $nullframe
corr_frame.x = X_verschiebung

    dann etwas später die temporären Tooldaten modifizieren:

    Code
    $tool=tool_data[1]:corr_frame
SLIN zielpos

    wenn es ein geteachter Zielpunkt ist, solltest du den mit "temporären" Tooldaten anfahren:
    ;werkzeug 1 hast du vermessen (mit etwas mühe schafft man da 0,3 mm)

    Code
    tool_data[31] = tool_data[1] : corr_frame
slin xteach with .... [31]


    Sebastian T, vielen Dank für deinen hilfreichen Tipp!

    Im ersten Schritt habe ich das Tool mithilfe der Kamera ausgerichtet und für das Schweißen positioniert. Dabei war eine Genauigkeit von etwa 0,2 mm erforderlich, die ich durch einen Teach-Punkt-Versatz erreicht habe.

    Der Roboter soll danach auch andere Aufgaben, wie das Einführen von Bauteilen, präzise, aber ohne Kamera ausführen. Daher plane ich, wie von dir vorgeschlagen, die Toolkorrektur im ersten Schritt anzuwenden. Mit dem korrigierten Tool werde ich die weiteren Aufgaben lösen.


    Hoffentlich klappt es!