Beiträge von puck

  • Absolutgenaues Robotermodell bei KRC4 einschalten

    Zitat von hustrac


    dann wird die eds eigentlich nie getauscht und die pid file Daten bleiben immer beim Roboter.


    Genau das ist der Plan :zwink: Es sind übrigens noch weitere Daten auf dem Speicher gesichert, welche man zum Betrieb des Roboters unbedingt benötig, z.B.


      • Seriennummer des Roboters

      • Justageoffsets für EMD-Justage neuerer Robotertypen (MAM-File)

      • Daten für die Lastjustage (CAL-File)

      • Positioniergenaues Robotermodell bei absolutgenau vermessenen Robotern (PID-File)

      • Pfade für die Archivierung


    Alle diese Daten müssen nach einem Tausch des Speichers wiederhergestellt werden (z.B. aus einem früher gezogenen Archiv).


    Falls der EDS-Speicher gegen einen leeren getauscht wird, ploppt ein Dialog auf, der einem hilft die entsprechenden Daten wiederherzustellen. Relativ einfach geht das mit Hilfe eines alten Archivs. Hat man kein Archiv gezogen, muss man die Seriennummer neu vergeben (geht nur einmalig) und die weiteren Daten händisch übertragen (MAM-File, PID-File evtl. bei KUKA anfragen). Ein nicht ge-backup-tes aktuelles CAL-File wäre in diesem Fall verloren.


    Bye Puck

  • DH Parameter

    Zitat von pat


    Jetzt muss ich doch noch mal fragen. Also wenn ich mich einfach nur frei im Raum bewege, also kein programm angewählt ist und ich in x-richtung fahre, aber der Roboter sichtbar schräg, ist dann in der Justage oder in der machine.dat was falsch?


    Hej hej Pat,


    Was steht denn für ein Robotertyp auf dem Typenschild? Entspricht der Name der Bezeichnung in $machine.dat und $robcor.dat? Ist der Roboter absolutgenau?


    Bye René

  • Nullpunkt A6 setzen

    Hallo Benjamin,


    ich würde über den MAMES-Wert der Achse 6 in der $machine.dat die fehlerhafte Verdrehung des Werkzeugs ausgleichen.


    REAL $MAMES[12] ;VERSCHIEBUNG ZW. MECH. UND MATH. NULLPUNKT ACHSE[I] (I=1:A1,I=7:E1) [MM,GRAD]


    Bye René


    Edit: Upps zu spät gepostet, Ser-G war schneller :zwink:

  • Maschinendaten ungleich Robotertyp

    Hej, hej Ruf25,


    der Fehler "Maschinendaten ungleich Robotertyp"tritt auf, wenn $TRAFONAME[] (Der Robotertyp in den Maschinedaten auf dem Steuerschrank) nicht dem auf der RDW gesicherten Pendant $ROBTRAFO[] gleicht.


    Beim Umzug des Roboters scheint der ursprüngliche Steuerschrank nicht mitumgezogen zu sein, oder? Um den Fehler zu beseitigen musst man zuerst die korrekten Maschinedaten auf den "neuen" Steuerschrank kopieren. Anschließend noch das IR_SPEC-Verzeichnis -- evtl. mit dem PID-File und anderen Dateien -- vom alten Steuerschrank auf den neuen Steuerschrank kopieren.


    Nach einem Kaltstart wird evtl. eine Inkonsistenz zwischen RDW und Festplatte festgestellt und ein Auswahldialog popt auf. Jetzt "Festplatte" wählen.


    Alternativ geht das ganze auch folgend:



    Bye Puck

  • Auffälligkeit beim kartesischen Verfahren von Hand

    Zitat von ROBOter_Nils


    Der Kunde macht sich Sorgen, sein HA Roboter sei nicht in Ordnung.


    Keine Sorge, höchstwahrscheinlich ist alles in Ordnung!


    Zitat von ROBOter_Nils


    Verfahre ich im Weltkoordinatensystem den Roboter kartesich in der Z-Achse, bleiben die unter "Anzeige->Istposition->Kartesisch" angezeigten Koordinaten für X und Y nicht konstant. Hätte ich jedoch erwartet...


    Du verfährst dabei den Roboter absolutgenauen Roboter (Ist ja nen HA) im Handverfahren, stimmts?


    Die absolutgenauen Roboter sind beim Handverfahren etwas heimtückisch :evil1: Beim absolutgenauen Handverfahren wird die "Bahn" durch das Standard-Robotermodell (einfaches Starrkörpermodell) geplant, aber in Anzeige wird das absolutgenaue Robotermodell ausgewertet und angezeigt. Den Unterschied zwischen Standard-Robotermodell und absolutgenauen Robotermodell kannst du dann als Abweichungen in XYZ erkennen.


    Im Programmverfahren tritt der Effekt nicht auf! Wenn Du dort eine reine z-Bewegung kommandierst, dann bleiben x und y konstant. Denn beim Programmverfahren wird die Bahn durch das absolutgenaue Robotermodell geplant und auch in der Anzeige das absolutgenaue Robotermodell ausgewertet und angezeigt.


    Ziemlich kryptisch und versteckt findet man auch in der KUKA-Doku den entsprechenden Hinweis:


    Aktivierung des positioniergenauen Robotermodells prüfen
    Wenn ein positioniergenauer Roboter verwendet wird, muss überprüft werden,
    ob das positioniergenaue Robotermodell aktiviert ist.
    Bei positioniergenauen Robotern werden Positionsabweichungen aufgrund
    von Bauteiltoleranzen und elastischen Effekten der einzelnen Roboter kompensiert.
    Der positioniergenaue Roboter positioniert den programmierten TCP
    im gesamten kartesischen Arbeitsraum innerhalb der Toleranzgrenzen. Die
    Modellparameter des positioniergenauen Roboters werden an einem Messplatz
    ermittelt und dauerhaft am Roboter gespeichert (RDC).


    Bye Puck

  • Roll-Pitch-Yaw in Euler-Winkel umwandeln

    Zitat von sescholz


    Gibt es eine Formel mit der ich Roll-Pitch-Yaw Winkel in Euler Winkel umwandeln kann?


    Vielleicht ist die Umrechnung sogar ganz einfach :zwink:


    Die KUKA-ABC-Winkel sind nämlich auch Roll-Pitch-Yaw-Winkel, dabei gilt 1. Drehung Roll um die raumfeste x-Achse mit dem Winkel C, 2. Drehung Pitch um die raumfeste y-Achse mit dem Winkel B und schließlich 3. Drehung Yaw um die raumfeste z-Achse mit dem Winkel A. Die Erklärung warum das so ist, findet man in diesem etwas älteren Post von mir: http://www.roboterforum.de/rob…tionen/msg56517/#msg56517

  • Roll-Pitch-Yaw in Euler-Winkel umwandeln

    Zitat von sescholz

    Gibt es eine Formel mit der ich Roll-Pitch-Yaw Winkel in Euler Winkel umwandeln kann?


    Ja es gibt allgemeine Formeln (http://www.malcolmdshuster.com/Pub_2006a_J_eulerx_AIAA.pdf), aber der Standardweg ist eher aus den vorgegebenen Roll-Pitch-Yaw-Winkeln -- oder was auch immer als Parametrisierung gewählt wird -- eine Rotationsmatrix zu berechnen und anschließend aus dieser dann die KUKA-ABC-Winkel zu fischen.


    Anbei Formeln zur Berechnung der KUKA-ABC-Winkel aus einer Rotationsmatrix.


    Bye Puck

  • TCP vermessen

    Zitat von Programmiersklave


    ..., wie dieser glückselige Zustand Deinerseits nun letztendlich erreicht wurde...


    Also, ganz von vorne:


    [list type=decimal]

    • In der $machine.dat war ein Maschinedatum (von Werk ab) falsch, deshalb wurde von dem betroffenen KR5 ARC bei der Justage kein MAM-File (enthält Justage-Offsets zum Justagekerbengrund) verwendet, obwohl dies bei diesem Robotertyp notwendig ist.


    • Bei KR5 ARC gilt DECL INDIVIDUAL_MAMES $INDIVIDUAL_MAMES=#RDC



    • Nach dem das Maschinendatum auf den richtigen Wert gesetzt wurde, hat der Roboter auch bei der nächsten Justage gleich nach dem fehlenden MAM-File gejammert.

    • Das entsprechende MAM-File bzw. Justage-Offsets wurde dann bei KUKA angefragt und kurz später auch geliefert (das MAM-File hatte leider auch ab KUKA Werk gefehlt!).

    • Anschließend wurde das MAM-File auf die RDW importiert und Roboter nochmal justiert.

    • Der jetzt endlich korrekt justierte Roboter fährt genau ;)

    [/list]


    Der Roboter selbst ist einer der "ersten" KR5 ARCs von KUKA gewesen und damals ist anscheinend bei KUKA einiges durcheinander gegangen (SJX war wohl auch schon mal ein KR5-ARC-Opfer). Jetzt sind alle Fehler beseitigt und die Maschine scheint deutlich genauer zu fahren.


    Bye Puck

  • TCP vermessen

    Zitat von Bruce Banner


    Aber vielleicht schreibt hierzu Fubini noch was.


    Ha, ha, der sitzt mir gerade genau gegenüber und lacht :zwink:


    Zitat von Bruce Banner


    Was das Thema „DECL INDIVIDUAL_MAMES $INDIVIDUAL_MAMES=#NONE” oder in deinem Fall #RDC angeht, kann ich nichts dazu sagen


    Okay, dann musst Du akzeptieren, dass Deine MaDas aus irgeneinem Grund von Irgendwem verändert wurden und aktuell keine Standardmaschinendaten geladen sind. Falls Du irgendwo das zu Deiner Maschine passende MAM-File (<Serien-Nr.mam> im vielleicht IR-SPEC-Verzeichnis) findest, dann müsstes Du:
    [list type=decimal]

    • Das MAM-File ins IR_SPEC Verzeichnis kopieren.

    • In der $machinde.dat dann #RDC anstatt #NONE schreiben.

    • Das MAM-File via ".../Inbetriebnahme/Roboterdaten" als Experte am KCP auf die RDW importieren.

    • Roboter neu justieren.

    • Prüfen, ob der Roboter genauer verfährt.

    [/list]


    Falls Dein MAM-File unauffindbar ist, dann kann Dir -- mit etwas Glück -- noch jemand bei KUKA helfen, dazu müsstest Du beim KUKA Support Dein MAM-File anfragen.


    Bye Puck


    p.s.: Wenn Du einen "absolutgenauen" Roboter hast, dann musst Du ein Programm mit Umorientierungen schreiben, um zu testen, ob der Roboter genauer verfährt, auf keinen Fall im Handverfahren (http://www.robot-forum.com/rob…expect/msg50648/#msg50648)

  • TCP vermessen

    Okeydockey, dann stimmt irgendetwas nicht: In der $machine.dat für den KR 5 ARC steht bei mir



    Vielleicht hast Du doch nicht die richtigen Maschinendaten geladen, oder irgendjemand hat sie nachträglich verändert, also #RDC in #NONE geändert.


    Bye René


    p.s.: Wie groß war der angezeigte Fehler, als Du den TCP eingemessen hast?

  • Lastjustage erkennbar

    Mastery.log: Es gibt auch noch das Mastery.log, in welchem die verschiedenen Justageaktionen zeitlich mehr oder weniger gut dokumentiert sind.


    <Serienummer>.cal: In der CAL-Datei sind unter anderem die Offsets bei Lastjustage mit verschiedenen "Tools" gesichert, allerdings ohne zeitliche Zuordnung


    Bye Puck

  • Reihenfolge der Rotationen

    Um noch ein bisschen Verwirrung zu stiften:


    Die Eulerwinkel sind so ein bisschen heimtückisch, denn man kann sie verschieden interpretieren. Die KUKA-ABC-Winkel werden meist als Eulerwinkel in der Drehfolge Z-Y-X um mitrotierende Achsen in aktiver Darstellung verwendet (Google: "Euler Angles" oder "Tait-Bryan-Angles"). Mitrotierende Achsen man sich verdeutlichen, wenn man sich die gleich unten beschriebenen Drehungen des Flansches vorstellst. Flansch-Koordinatensystem und World-Koordinatensystem sollen dabei anfangs gleich ausgerichtet sein. Bei dieser Orientierung zeigt Z-Flansch nach oben und X nach "vorne", die Flanschfläche ist also parallel zum Boden ausgerichtet:
    [list type=decimal]

    • Drehung des Flansches um Z-Achse des Flansch-Koordinatensystems mit Winkel A

    • Drehung des Flansches um die Y'-Achse des jetzt einmal um Z mitrotierten Flansch-Koordinatensystems mit Winkel B

    • Drehung des Flansches um X''-Achse des jetzt einmal um Z und anschließend um Y' mitrotierten Flansch-Koordinatensystems mit Winkel C

    [/list]
    Die KUKA-ABC-Winkel kann man auch als Eulerwinkel in der Drehfolge X-Y-Z um raumfeste Achsen in aktiver Darstellung deuten (Google: "Fixed Angles"). Feste Achsen kann man sich vorstellen, wenn man die Drehungen des Flansches folgend aufbaut. Flansch-Koordinatensystem und World-Koordinatensystem sollen dabei anfangs wieder gleich ausgerichtet sein:
    [list type=decimal]
    • Drehung des Flansches um X-Achse des raumfesten, also nicht bewegten World-Koordinatensystems mit Winkel C

    • Drehung des Flansches um Y-Achse des raumfesten, also nicht bewegten World-Koordinatensystems mit Winkel B

    • Drehung des Flansches um Z-Achse des raumfesten, also nicht bewegten World-Koordinatensystems mit Winkel A

    [/list]
    Es ist etwas überraschend, dass bei beiden der oben beschriebenen Wege, am Schluss die selbe Flanschorientierung herauskommt, obwohl die beiden Wege tatsächlich unterschiedlich sind. Vielleicht hilft auch Google Books: Handbook of Robotics noch weiter.


    Bye Puck


    p.s.: In beiden Fällen liegt die Singularität der Eulerwinkel bei B = +/-90°, dort kann ein und dieselbe Orientierung mit unterschiedlichen Winkeln dargestellt werden, ist somit nicht mehr eindeutig. Bei B = +/-90° sind aber die Summe bzw. Differenz von A und C immer gleich.


    p.p.s: Die "Aktive Darstellung" bedeutet dabei, da sich der betrachtete Körper verdreht, z.B. sich der Roboter-Flansch tatsächlich bewegt. Bei der auch möglichen "passiven Darstellung" ändern sich die Blickwinkel auf den betrachteten Körper, ganz ähnlich wie bei einer Kamerafahrt im Film.

  • 4-Punkt-Toolvermessung - Mathematik dahinter

    Nur so ne Idee, wie man den TCP aus vier Spitze-auf-Spitze-Antastungen ein und desselben Punktes berechnen kann:


    R_1 * t + r_1 = p
    R_2 * t + r_2 = p
    R_3 * t + r_3 = p
    R_4 * t + r_4 = p


    Dabei ist R_1 die Flanschorientierung (Rotationsmatrix) beim ersten Spitze-auf-Spitze-Antasten. Die Flanschposition (Punkt mit x, y, z) ist r_1. Analog dann für die restlichen drei Antastungen r_2 und R_2 usw. Der gesuchte und konstante TCP-Vektor ist t und schließlich p der angetastete Punkt, ebenfalls konstant, da ja immer der selbe Punkt angetastet wird.


    Die vier Gleichungen kann man umformen, um den – eigentlich wenig interessanten – Punkt p herauszukürzen.


    R_1 * t + r_1 = R_2 * t + r_2
    R_1 * t + r_1 = R_3 * t + r_3
    R_1 * t + r_1 = R_4 * t + r_4


    Nochmal nen bisschen Umformen und als Matrix zusammenfassen ergibt dann


    [R_1 - R_2] [r_2 - r_1]
    [R_1 - R_3] [ t ]= [r_3 - r_1]
    [R_1 - R_4] [r_4 - r_1]


    9x3 3x1 9x1


    Jetzt hat man eine überbestimmte Matrixgleichung in der Form A x = b, die man mit den üblichen an Verdächtigen von Lösungsalgorithmen (Householder-Algorithmus) berechnen kann und zusätzlich auch noch eine Güte der Lösung angeben kann. Ein „echter“ Optimierungsalgorithmus ist nicht notwendig, aber die Lösung ist natürlich irgendein Best-Fit, weil das Gleichungssystem überbestimmt ist. Die Anstastrichtungen müssen sicher unterschiedlich sein und dürfen nicht in einer Ebene liegen.


    Bye Puck

  • 4-Punkt-Toolvermessung - Messpunkte

    Zitat von deimos1988


    ... jedoch nur mit 3 Nachkommastellen. Gibt es eine Möglichkeit, mehr Nachkommastellen anzeigen zu lassen?


    Hmm, mehr als zwei Nachkommastellen sind eigentlich sinnlos, denn genauer kann ein Roboter gar nicht nicht arbeiten ... wenn du mehr Nachkommastellen angibst, zeigen die nur noch "Mess-Schmoder" an ;) Bei der Toolvermessung musst du eher mit Fehlern deutlichen im Zehntel-Millimeter (wenn nicht noch mehr) rechnen.

  • Bahnwiederholgenauigkeit KR6 Agilus

    Zitat von Urmel

    Wie schon gesagt, da sind einige unterwegs ...


    Hihi, die Laser Tracker Hersteller (Leica, FARO, API, Nikon) und auch anderer 3D/6D-Meßsysteme würden sich freuen, wenn sie neben jeden genau positionierenden Roboter eines ihrer Meßsysteme stellen dürften. Aber sooo superdupper genau und schnell können Laser Tracker und Co. auch nicht messen, also nicht zuviel erwarten ;)


    Ich habe mal vor ein/zwei Jahren die "Pose-Wiederholgenauigkeit" eines Laser Trackers mit der Formel der ISO 9283 gemessen und dabei 18 µm = 0,018 mm als Ergebnis erhalten. Der Laser Tracker hatte dabei 30 mal hintereinander ein statisches, total unbewegliches Laser Tracker Meßziels gemessen. Die Umgebungsbedingungen waren dabei okay (keine Zugluft, keine Vibration, konstante Temp, keine Messung über Dehnfugen hinweg, LT kalibriert ...). Teure Messysteme sind also kein Allheilmittel und Industrieroboter sind auch keine hochgenauen CNC-Maschinen.


    Bye Puck, bekennender Fan von Laser Trackern

  • Bahnwiederholgenauigkeit KR6 Agilus

    Zitat von Twister


    Die "offizielle" Aussage zum Toleranzschlauch... wo bekommt man denn sowas her? So "offiziell" hab ich das noch nirgends gelesen.


    Manchmal gibt KUKA Bahnwiederholgenauigkeit in den Datenblättern an, manchmal nicht. Im Datenblatt vom KR30HA ist die z.B. brav Bahnwiederholgenauigkeit angegeben,

    http://www.kuka-robotics.com/g…_robots/kr30_ha/start.htm


    beim Agilus dagegen nicht ... komisch. Hilft alles nix, man muss wohl KUKA kontaktieren, um die Info zu erhalten,


    Zitat von drudge

    ..., die offizielle BahnWIEDERHOLgenauigkeit vom KR6 AGILUS ist ein Schlauch mit 0.2mm Radius.


    irgendwo muss drudge die Angabe ja bekommen haben.


    Bye Puck

  • Bahnwiederholgenauigkeit KR6 Agilus

    Zitat von Urmel


    Ich glaube Twister interessiert sich eher für die Genauigkeit seiner Laserbahn. Wenn ich dann daran denke, dass man vielleicht an einem warmen Freitagnachmittag Laserschneidet, dann die Anlage ausschaltet und dann an einem kalten Montagmorgen wieder anfängt ...


    Genau! Das macht das Ganze noch schwieriger, denn etwas über lange Zeit bzw. Temperaturunterschiede stabil zu halten ist schwierig. Deshalb auch die (gut versteckte) Anmerkung, dass die Bahnwiederholgenauigkeit nicht "Alles" ist und z.B. Temperatureinflüsse gerade nicht berücksichtigt. Allerdings stehen hochgenau Systeme meist in klimatisierten Räumen und einen stabilen Temperaturzustand kann man ja auch durch geschickte Programmierung und Aufwärmphasen erreichen.


    Zitat von Urmel


    Ansonsten bleiben nur sensorgeregelte Lösungen zu Laufzeit, ...


    Sensoren sind auch noch temperatur-, licht-, zugluft- und erschütterungsempfindlich :uglyhammer_2:


    Bye René

  • Bahnwiederholgenauigkeit KR6 Agilus

    Zitat von Urmel


    Wenn wir also mal von 0.2 mm bei 10 aufeinanderfolgenden Bahnen ausgehen, ist der Wunsch nach 0.05 mm, vermutlich über den laufenden Betrieb einer Anlage, in der Tat sportlich ...


    Hmm, "ja" und "nein", die Bahnwiederholgenauigkeit RT_p = 0,2 mm soll wohl so ein Worst-Case-Angabe sein, weil die dreifache Streuung eingerechnet wird, also so ne Art eine 3-Sigma-Umgebung (99,7% aller Fälle sind kleiner 0,2 mm). Mathematisch steht die Bahnwiederholgenauigkeit (eigentlich die ganze ISO 9283) aber eher auf wackligen Beinen, weil die Abweichungen sicher nicht normalverteilt sind und so typische Sigma-Umgebungen folglich nicht gelten (wahrscheinlich sogar besser als 99,7%).


    Schwierig wird es im Bereich von 0,05 mm über den typischen Arbeitsbereich eines Roboters überhaupt Positionen und Orientierungen zu messen.


    Lange Rede, kurzer Sinn: Die Bahnwiederholgenauigkeit von Robotern ist nicht so schlecht, wie es die Angabe der Bahnwiederholgenauigkeit nach ISO 9283 vermuten läßt.


    Zitat von Urmel


    ... Man denke nur an Temperaturänderungen ...


    Die sollen mit der Bahnwiederholgenauigkeit nicht erfasst werden, der Roboter soll laut Norm in einem statischen Temperaturzustand sein und eine Messung von nur 10 Zyklen, begrenzt die Zeit in der sich der Temperaturzustand ändern kann zusätzlich.


    Bye Puck