Bahnwiederholgenauigkeit KR6 Agilus

Hallo,

Zitat von Twister

hat sich schon mal jemand mit der Bahnwiederholgenauigkeit eines Roboters beschäftigt?

Siehe meine Antwort hier
http://www.roboterforum.de/rob…8ha%29/msg53568/#msg53568

Im Verlaufe dieses Threads wurde ja auch geschrieben, dass Kuka die besonders genauen Roboter durch Aussortieren "produziert". Das deckt sich mit unseren Ergebnissen, dass Roboter bezüglich solcher Eigenschaften Individuen sind. Insbesondere gehen Eigenschaften der Mechanik, damit auch des Alters und des aktuellen Zustandes (inkl. Temperatur), genauso in die Bahngenauigkeit ein, wie Regelungsaspekte.

Grüße

Urmel

Hallo,

Zitat von Twister

BahnWIEDERHOLgenauigkeit haben

das ist mir schon klar, ich hab ja nicht geschrieben, dass wir die Bahnen nur einmal vermessen haben.

Zitat von Twister

ich die Geradenbewegung in viele kleine Geradenelemente aufteilen welche dann einzeln nachgebessert werden

Ja, bei Robotern, die C++ verwenden, kann man die interpolierte Bahn z.B. in einen std::vector tun. Die Bahn abfahren und dabei vermessen. Dann entsprechende Korrekturen auf den vector addieren und es noch mal probieren.

Zitat von Twister

Die Frage ist ob sich hiermit schon mal jemand beschäftigt hat.

Verschiedene Leute sind da unterwegs. Auch mit modifizierter Hardware z.B. einen Roboter mit 1,2 kHz IPO-Takt.

Grüße

Urmel

Hallo Twister,

Zitat von Twister

Kann man hierzu ein paar Worte sagen oder sind das interne Ergebnisse die man nicht weitergeben kann?

ich glaube man muss ein paar Worte dazu sagen.

Die Geschichte dieser Echtzeitbewegungen reicht schon eine Weile zurück und es gibt diverse Neuigkeiten auf dem Gebiet.

Die Alter-Moves bei Stäubli reichen wohl schon zurück in die Zeit der alten Puma-Roboter, also in die 70-80 Jahre. C++ Programmierung im Ipo-Takt gibt es bei Mitsubishi schon seit 1995. Kukas RSI ist da eher ein Spätzünder.

Insbesondere Mitsubishis Mxt war schon von Anfang an dazu gedacht, nicht nur die Roboterbewegung in Echtzeit zu regeln, sondern auch komplexe Bahnkurven im PC-Speicher zu halten und während der Bewegung per Netzwerk in die Robotersteuerung zu pumpen. Das sind meist eher komplexe Kurven und keine Gerade, aber z.B. in der Welt der Mikromontage wird so etwas schon lange zur Genauigkeitssteigerung eingesetzt. Man hat später eine Lösung ohne C++ nachgereicht, das sind die ominösen Mxt-Files, die hier in Threads im Mitsubishi Forum auftauchen.

Bei der Genauigkeit muss man nun aber unterscheiden, bei geregelten Bewegungen ist die schon sehr gut, manchmal besser als die angegebene (Positions-) Wiederholgenauigkeit des Roboters. Wenn man aber eine gegebene Kurve immer wieder ausführt, sind Angaben zur Wiederholenauigkeit viel komplizierter. Wie schon gesagt, spielt da natürlich auch die Temperatur und Alterungsprozesse eine Rolle.

Was auch noch eine Rolle spielt, das hast du ja schon angesprochen, sind Effekte der Servo-Regelung. Die liegen noch eine Ebene unter der Bahninterpolation. Abhängig vom Roboterhersteller gibt es da diverse Möglichkeiten an den Parametern zu schrauben, um Schwingungen und Hysterese-Effekte klein zu halten.

Manchen Leuten reicht das nicht. (Hier kann ich jetzt nicht mehr als Anwender berichten.) Es gibt verschiedene Ansätze den Roboter direkt bei den Motoren zu fassen, um die wirklich perfekte Bewegung zu erreichen:

• Man entfernt die Robotersoftware von der Steuerung und arbeitet auf dem nackten Betriebssystem (z.B. Stäubli LLI)


• Alternative Steuerungsaufbauten greifen direkt auf den Servobus zu (Motoman, Mitsubishi)


• Lösungen wie Stäubli uniVal drive stellen die Antriebe des Roboters per EtherCAT nach außen zur Verfügung

Soweit dieser kleine Rundumschlag. Was du willst geht, machen diverse Firmen auf unterschiedliche Weise. Der Grad der Perfektion wird im wesentlichen vom finanziellen Aufwand bestimmt.

Im Moment habe ich allerdings den Eindruck, du versuchst mit dem Agilus einen Mitsubishi nachzubauen. Ein RV-7F-D und eine Spraydose mit oranger Farbe ist da wohl günstiger.

Grüße

Urmel

Hallo Twister,

du willst also so 'ne Art Look-Up-Table basteln, um die Bahngenauigkeit in die Nähe der Bahnwiederholgenauigkeit (vielleicht sogar Wiederholgenauigkeit) zu steigern? Bin mir nicht sicher, ob das sooo einfach funktioniert, denn wie willst Du denn diese kleinen Offsets in y und z im Hunderstelbereich (1/2 bzw. 1/4 "Dicke" eines Blatts Papier) zuverlässig messen? Mein Laser Tracker kann das nicht Hast Du die Bahngenauigkeit deiner Geraden schon gemessen? Vielleicht ist die Genauigkeit ja gar nicht so schlecht. Außerdem musst Du ja dann auch noch Umgebungseffekte, wie die Temperaturausdehnung des Roboters (wenn er wärmer/kälter wird), Reibungseffekte, Getriebespiele usw. beachten.

Zitat von Twister

... von welchen Abweichungen sprechen wir denn bei der Bahnwiederholgenauigkeit? Liegen die um ein vielfaches höher wie die reine Wiederholgenauigkeit?

Nach meiner Erfahrung: Ja. Der Roboter wackelt bzw. schwingt etwas beim Fahren, diese etwas zufälligen dynamische Effekte fallen bei einer Messung bei stehendem Roboter (Positioniergenauigkeit/Wiederholgenauigkeit) weg. Während man die Wiederholgenauigkeit des Roboters eigentlich nicht beeinflussen kann, wäre das evtl. bei der Bahnwiederholgenauigkeit nicht ganz so.

Bye Puck

Hallo,

Zitat von puck

Hast Du die Bahngenauigkeit deiner Geraden schon gemessen? Vielleicht ist die Genauigkeit ja gar nicht so schlecht.

das wäre sowieso der erste Schritt.

Zitat von puck

denn wie willst Du denn diese kleinen Offsets in y und z im Hunderstelbereich (1/2 bzw. 1/4 "Dicke" eines Blatts Papier) zuverlässig messen?

Es gibt z.B. Platten in die ein hochpräzises Muster graviert ist. Da kann man mit einer Kamera entlangfahren ähnlich wie hier
HHN - Mitsubishi RV-6SL Roboter mit Kamera im TCP

Zitat von Twister

Eher an sowas:
Anstatt:
LIN {X 0,Y 0,Z 0,A 0,B 0,C 0}
LIN {X 100}

Nun so:
LIN {X 0,Y 0,Z 0,A 0,B 0,C 0} C_DIS
...

Alles anzeigen

Ich weiß nicht wie das bei Kuka ist, aber bei den meisten anderen Herstellern geht bei Programmen dieser Art die Performance mächtig in die Knie.

Wenn du eine Bahn einer bestimmten Länge hast und die mit einer bestimmten Geschwindigkeit fährst, kannst du dir mit dem Ipo-Takt des Roboters (12 ms bei Kuka ?) ausrechnen, wie lang ein Stück ist, das der Roboter quasi als elementaren Schritt fährt. Wenn die Länge deiner Minibewegungen davon abweicht, hat die Steuerung entweder jede Menge Rechnerei (-> Ungenauigkeiten) oder hält die vorgegebene Geschwindigkeit nicht ein (meist wird sie langsamer).

Aus diesem Grund gibt es da zwei andere Programmiermodelle:

Z.B. bei Stäubli gibt es Bewegungsbefehle, die genau einen Ipo-Takt lang sind, das sind alter() für kartesische und $syncMove() für Gelenkbewegungen.

Bei Mitsubishi kann man entweder einen Dateinamen als Parameter der Bewegung angeben, die Textdatei enthält in jeder Zeile eine Koordinate für einen Roboterschritt. Oder die Bewegung läuft als "externe Interpolation", das ist eine UDP-Verbindung zu einem externen C++ Programm, die im Robotertakt kommuniziert.

Beide Wege kann man sicher über RSI-XML irgendwie nachbauen. Aber einen Agilus kauft man, weil man einen kleinen Roboter wie einen großen programmieren will. Eine Stäubli- oder Mitsubishi-Simulation in KRL zu schreiben, klingt irgendwie wie "Android-Emulator für iPhone schreiben".

Grüße

Urmel

Hallo Twister,

Zitat

Fährt man aber einen kleinen Kreis (D<10mm) so ergibt dies mit einem Stift auf Papier schon ein sehr unrunden Kreis.

das Problem mit den kleinen Kreisen ist m.E. eher auf den Achsfilter $Filter zurückzuführen als auf die Reglerparameter (oder beobachtest du zu große Kreise?). Das Thema wurde hier schon mal ausführlich diskutiert:

http://www.roboterforum.de/rob…-hoherer-geschwindigkeit/

Der Achsfilter hat übrigens auch Auswirkungen auf die Genauigkeit von Geradenstücken, d.h. die LIN-Bahn hängt wie eine Wäscheleine leicht durch.

Zitat

Es gibt doch seit kurzem eine CNC-Option (G-Code) für KUKA, kann es sein dass hier die komplette Bahnplanung/Achsregelung anders/härter ist
oder wird nur einfach ein "G1 X100" durch ein "LIN {X 100}" getauscht?

Hier findet die Planung Regelung, ... nicht durch die KUKA-Steuerung statt, sondern es wird die CNC-Steuerung von ISG in die KUKA Steuerungsoberfläche integriert. Die ISG Steuerung nutzt dann Teile der Kuka-Steuerung (z.B. die Transformation) um seine eigene Bahnplanung durchzuführen und diese dann an die KUKA-Antriebstechnik zu kommandieren. Es findet also eine Art Mischbetrieb zwischen KUKA und ISG statt und so können von der ISG-Seite beliebige CNC Programme gefahren werden.

Gruß
Fubini

Hallo Twister,

Zitat

dann kann ich davon ausgehen dass der Roboter eine einzelne LIN-Bahn oder CIRC-Bahn egal ob KRL oder CNC räumlich gesehen gleich fährt?

Bei CNC-Betrieb wird ohne den Achsfilter gefahren, so dass sich die Bahnen unterscheiden.

Zitat

Der Durchmesserfehler der Kreise ist kein Problem

Der Filtereffekt ist aber gerade, dass jeder Kreis eher wie ein Ei aussieht. Im Spezialfall des Postings kommt no hinzu, dass die Kreisradien "extrem" klein sind, so dass hier das ganze zusätzlich etwas entartet, d.h. ein Kreis mit zu kleinem Radius entsteht. Falls du absolute konturtreue willst ohne störende Filtereffekte würde ich eh den Spline empfehlen.

Gruß
Fubini

Lieber Twister,

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

deine Idee

Nun so:
LIN {X 0,Y 0,Z 0,A 0,B 0,C 0} C_DIS
LIN {X 10, Y 0.01 , Z 0.01} C_DIS
LIN {X 20, Y -0.01, Z 0.03} C_DIS
LIN {X 30, Y 0.03 , Z 0.02} C_DIS
LIN {X 40, Y 0.02 , Z 0.04} C_DIS
LIN {X 50, Y 0.05 , Z 0.02} C_DIS
LIN {X 60, Y 0.02 , Z -0.05} C_DIS
LIN {X 70, Y -0.04, Z 0.01} C_DIS
LIN {X 80, Y 0.03 , Z 0.03} C_DIS
LIN {X 90, Y -0.01, Z -0.01} C_DIS
LIN {X 100, Y 0.0 , Z 0.0}

Ist seit der KSS Version 5.5 im normalen KRL möglich ohne dass die Steuerung in die Knie geht (sofern du nich 1000de Punkte mit minimalstem Abstand aufführst). Das Zauberwort dazu lautet SPLINE (wie fubini schon antönt). Das musst du spezielle (SPLINE-)Bewegungsbefehlsblöcke verwenden, also nicht mehr normale LIN, CIRC oder PTP.
Ich denke KUKA.CNC könnte auch funktionieren. (Habe ich selber noch nie ausprobiert und musst du einfach zusätzlich kaufen )

Sehr wichtig für eine saubere Bewegung ist natürlich immer: exakte Lastdaten (auch für die Zusatzlasten ).

greetz Drudge

Hallo,

Zitat von drudge

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

mich würde mal interessieren, wie die offizielle Definition dieser Wiederholgenauigkeit lautet ? Die Toleranz bei n direkt hintereinander ausgeführten Bewegungen ?

Zitat von drudge

sofern du nich 1000de Punkte mit minimalstem Abstand aufführst).

Bei Strecken von 0.01 mm und einer Bahnlänge von 100 mm (s.o.) kommt man aber in diesen Bereich. Wenn man die Bahngenauigkeit in Richtung 0.05 drücken will, muss man das auch.

Grüße

Urmel

Zitat von Urmel

mich würde mal interessieren, wie die offizielle Definition dieser Wiederholgenauigkeit lautet ?

Die offizielle Definition der Bahnwiederholgenauigkeit ist in der DIN ISO 9283, Leistungskenngrößen und zugehörige Prüfmethoden festgelegt. Die Definitionen sind dabei etwas willkürlich, aber Norm ist Norm:

Bahnwiederholgenauigkeit: Eine durch den "Iso-Würfel" festgelegte Prüfbahn wird 10 mal nacheinander abgefahren. Anschließend wird aus den 10 gemessenen Bahnen eine "Schwerelinie" berechnet und die radialen Abweichungen der gemessenen Bahnen zur Schwerelinie ermittelt. Die Bahnwiederholgenauigkeit RT_p ist dann das Maximum aus allen berechneten Abweichungen an den Abtaststellen plus 3 mal die zugehörige Streuung an den Abtaststellen.

Im Gegensatz zur ISO 9283 gibt es noch eine us-amerikanische Norm R15.052-1992 Path-Related and Dynamic Performance Characteristics, Evaluation. Die Definitionen der Bahnwiederholgenauigkeiten der beiden Normen unterscheiden sich deutlich und deshalb ergeben sich auch andere Zahlenwerte.

Bye Puck

Dank für deine Mühe Puck.

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. Man denke nur an Temperaturänderungen ...

Eine aus optimalen Minischritten zusammengesetzte Bahn kann da sicher etwas Verbesserung bringen, aber das ist nur eine statische Lösung. CNC-Systeme arbeiten da sicher mit ausgefuchsteren Verfahren, genau wie die Leute, die die oben erwähnten Low-Level Roboterlösungen verwenden.

Ansonsten bleiben nur sensorgeregelte Lösungen zu Laufzeit, das ist aber sicher nichts für CNC oder Laserschneiden, hat aber ganz allgemein den Vorteil, Abweichungen bei Roboter und Umgebung automatisch kompensieren zu können.

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

Zitat von puck

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

Das sagen mir meine Messungen auch.

Zitat von puck

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.

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 ...

Das sind mir adaptive Systeme lieber, als irgend etwas "absolut" genaues. Wobei mir im konkreten Anwendungsfall aber auch nicht klar ist, wie man das machen könnte. Was ich aber sagen kann, dass z.B. kamerageregelte Echtzeitbewegungen so genau sein können.

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

Bye René