Beiträge von fubini

Hallo,

max123: bezüglich Overrideverhalten kannst du mal hier nachschauen:

http://www.roboterforum.de/rob….0.html;msg33405#msg33405

SpeedFreak

Zitat

auch wenns jetz nicht so hierher gehört: was hat es mit diesen versionen 7 bzw. 8 auf sich?

Die V7.0 ist eine spezielle Version für die Denso Kleinroboter (andere Steuerungshardware). Im Funktionsumfang entspricht diese einer normalen V5.4, die noch keinen Spline bietet. Die V8.1 ist sozusagen der direkte Nachfolger zu V5.6 (ist auch im Funktionsumfang noch sehr ähnlich zur V5.6), der aber nur mit der neuen Steuerungshardware (KRC4) angeboten wird.

Da der Spline aktuell noch in der Entwicklung ist gibt es mit der V5.5 noch nur einen recht eingeschränkten Funktionsumfang. Ab der V5.6 ist es hier schon deutlich besser.

Gruß
Fubini

Hallo,

Das sollte mit $IPO_MODE=#TCP oder #BASE gehen.

Gruß
Fubini

Hallo,

der KUKA-Spline ist polynomial (5.Grades).

Gruß
Fubini

Hallo Prestorianer,

Zitat

Als ich das gehört hab, hab ich gedacht: WOW endlich kannste bei 30% T2 aufhören und das ding fährt dann bei 100% genau so.
Pustekuchen.
Der KRC4 verhällt sich wieder KRC2 bis 75% T2 relativ bahntreu.

Was hat das mit einer neuer Steuerung zu tun? Die Bahnplanung hat sich im Vergleich zur V5.x nicht geändert. Wenn du absolute Konturtreue willst, fahr besser Spline und den gibt es auch schon länger.

Gruß
Fubini

Hallo,

Die Variable $SERV_OFF_TM[n] (Reglersperrzeit) ist ab der V7 nicht mehr in der $machine.dat enthalten, sondern nach

C:\KRC\Roboter\Config\MotorServo\<DeinMotor>.xml

in das Tag <BrakeData CloseTime="50000"/> gewandert. Im Gegensatz zu früher steht hier die Zeit nicht mehr in Milli sondern in Nanosekunden (Wert 50000 = 50 ms).

Welcher Motor zu welcher Achse gehört findest du unter

C:\KRC\Roboter\Config\Axis\Ax.xml (x=1,...,n) im Tag
<AxisData MotorServoConfigFile="MotorServo/<DeinMotor>.xml"/>

Gruß
Fubini

Hallo,

Doku für eine V5.5 hab ich gerade keine zur Hand. Das sollte aber in der normalen "Bedien- und Programmieranleitung für Endanwender" unter dem Stichwort SPLINE enthalten sein, die mit jeder CD mitkommt.

Gruß
Fubini

Hallo Marcus,

das ist ein altes bekanntest Problem des LIN-LIN-Überschleifens, da die erreichbare Geschwindigkeit im Überschleifbogen durch die erreichbare Geschwindigkeit der beteiligten Einzelbewegungen beschränkt ist. Also kann man eigentlich nur probieren die Geschwindigkeiten $VEL und Beschleunigungen $ACC hochzuziehen um damit die Einzelsatzbewegungen schneller zu machen.

Als einzig wirkliche Alternative kann ich hier nur den Spline-Bewegungstyp SPL empfehlen, der hat die o.g. Probleme nicht mehr und ist für das was ihr machen wollt wohl besser geeignet. Den gibt es aber erst mit einer KRC V5.6 so richtig und mit einer KRC V5.5 nur eingeschränkt.

Gruß
Fubini

Hallo,

Zitat

lastdaten bei einem (wie oben beschrieben) vielleich 500g leichten tool... kann ich mir nicht vorstellen, falls das doch eine rolle spielt, wüsste ich gern, was ich da tun muss?

Bei der Absolutgenauigkeit muss auch immer die tatsächliche Last gesetzt werden, sonst kommt es zu den von dir beobachteten massiven Abweichungen. Default ist hier nämlich sonst maximale Last (in deinem Fall bei einem KR16 wohl ca. 16 kg). Nachdem in das absolutgenaue Modell u.a. auch die Durchbiegung der Roboterstruktur durch die Last eingeht, hat das sogar massiven Einfluß!! Um zu prüfen ob die Absolutgenauigkeit aktiv ist, kannst du dir entweder $ABS_ACCUR (TRUE=Absolutgenauigkeit aktiv) anschauen oder einfach mal die Last ändern, dann sollte sich der Roboter leicht bewegen um die "andere" Last zu kompensieren.

Gruß,
Fubini

Hallo Gregor,

Zitat

Ist es möglich das Weltkoordinatensystem irgendwo zu ändern?

Das Weltkoordinatensystem kann man nicht ändern. Man kann aber sagen wo bezüglich der Welt der Roboterfuß steht. Das findest du in $ROBROOT von R1/$machine.dat.

Gruß
Fubini

Hallo,

also um bei deinem Beispiel zu bleiben:

75 % programmierte Geschwindigkeit ($VEL_AXIS[AchsNr]=75) bedeutet, dass die jeweilige Achse nur maximal mit 75% ihrer maximal möglichen Geschwindigkeit verfährt. Angenommen also Achse 2 kann laut Maschinendaten mit 100°/s fahren dann fährt sie mit $VEL_AXIS[2] =75 also maximal mit 75 °/s. D.h. aber noch lange nicht das diese Geschwindigkeit auch realisiert wird (das hängt dann auch von der Bahn ab, d.h. kann der Roboter dynamisch das überhaupt fahren ohne kaputt zu gehen). Angenommen wir würden diese Geschwindigkeit auch tatsächlich fahren können, dann heisst das in Verbindung mit dem Override, dass Achse 2 bei 100% Override mit 75°/s fährt. Wäre dann z.B. der Override 25% erreicht die Achse 2 nur eine Geschwindigkeit von 75°/s * 0.25 = 18.25 °/s.

Wie bereits erwähnt nimmt dann aber die Beschleunigung quadratisch ab. Angenommen die Achse 2 hat ein Beschleunigungsvermögen von 1000°/s und die Beschleunigung $ACC_AXIS[2]=10 ist programmiert, dann bedeutet das, das bei 100% Override also eine Beschleunigung von 100°/s^2 realisiert wird (Fahrbarkeit wieder vorausgesetzt). Bei einer wiederum quadratischen Abnahme der Beschleunigung mit dem Override bedeutet das also bei 25% Override die Beschleunigung nimmt um sqrt(0.25) = 0.0625 ab. Man erreicht also eine Beschleunigung von 100°/s * 0.0625 = 6,25 °/s^2.

Soweit die Theorie. Allerdings gilt oben genanntes nur für den vereinfachten Fall, dass der Roboter ohne Dynamikmodell betrieben wird. Ist dass Dyanamikmodell aktiv ändert sich das Verhalten bei den Beschleunigungen. Da ein Roboter eigentlich nicht durch die Beschleunigung kaputt geht, sondern durch die Kräfte und Momente, die auf seine Achsen wirken programmiert man nämlich mit $ACC_AXIS[] nicht direkt die Achsbeschleunigung, sondern indirekt, das zum Beschleunigen zur Verfügung stehende Moment. Wie groß dieses Moment ist, hängt aber u.a. auch von der Stellung des Roboters ab. Außerdem werden alle Achsen noch synchronsiert, d.h. alle Achsen starten gelichzeitig und hören gleichzeitig auf sich zu bewegen. Damit bestimmt dann die "langsamste Achse" wie sich die anderen bewegen können. Es werden quasi alle Achsen von ihrem Profilverlauf (Beschleunigungen, Konstante Geschwindigkeit, Abbremsen) skaliert, so dass diese Bedingung erfüllt wird.

Gruß
Fubini

Hallo,

viele Leute sind der Meinung, dass der Override eine Geschwindigkeitskappung darstellt. Das stimmt aber so nicht: der Override ist eine Zeitskalierung, d.h. bei Override 50 % braucht der Roboter genau doppelt solange. Insbesondere bedingt das in einfachen Fällen wie einem Trapezprofil (3 Phasen: konstante Beschleunigung auf maximale Geschwindigkeit, konstante Geschwindigkeit und konstante Verzögerung auf Geschwindigkeitr Null) aber neben der Halbierung der Geschwindigkeit auch eine Viertelung der Beschleunigung. Das Folgt alles unmittelbar aus den Grundlagenformeln wie s = 1/2 a t^2.

Gruß
Fubini

Hallo,

dafür gibt es die Option LIN_REL {A -30} #TOOL.

Gruß
Fubini

Hallo $CYCFLAG,

ich habe jetzt deine Erläuterung noch nicht ganz verstanden.

Du hast so wie ich es verstehe aktuell einen über einen "Eingang X" aktivierbaren "Schutzraum" mit Geschwindigkeitsüberwachung im "geschützten Raum", der nicht an den "Grenzen stoppt". D.h. der Roboter wird beim reinfahren in den definierten Quader die Geschwindigkeit solange Überwachen wie du innerhalb des Quaders bleibst. Ist das soweit richtig?

Eventuell ist aber auch das Missverständnis, das der Roboter bei einem Schutzraum mit Haken bei "an Grenzen stoppen" nicht nur beim aktiven Überfahren der Grenzen einen Stop auslöst, sondern dieser Stop immer ansteht sobald er sich der Roboter außerhalb des von dir definierten Quaders befindet. Ausnahme bildet hiervon nur das Verfahren in der Betriebsart T1, da beim SafeRobot T1 implizit mit Freifahren gleichgesetzt wird. Damit stoppt er dann in T1 nur beim überfahren der Raumgrenze.

Gruß
Fubini

Hallo $CYCFLAG,

du musst den Haken wegnehmen, da du ja sonst nie in den "geschützten Raum" kommen könntest, da du ja immer beim Verlassen des erlaubten Raums durch einen Stopp angehalten würdest.

Gruß
Fubini

... LindePaul hat sich zum Ende letzten Jahres leider in seinen wohlverdienten Ruhestand verabschiedet.

Hallo,

deine Bewegung ist sicher nicht vollständig, d.h. bei der Startbewegung müssen alle Achswinkel zur Position immer eindeutig festgelegt sein. Bei kartesischen Positionen heißt das du brauchst x,y,z,a,b,c und den Status. Also z.B.

PTP {X 500,Y 123.6,Z 123.6, A 0, B 90, C 0, S 2}

Alternativ kannst du natürlich auch direkt eine Achsposition angeben:

PTP {A1 10,A2 20,A3 0, A4 -50, A5 -10, A6 0}

Gruß
Fubini

Hallo R2D2,

deine Beschreibung hört sich erstmal richtig an. Was ich allerdings nicht verstehe ist warum du die 3x3-Matrix zur Bestimmung der ABC-Winkel noch transponierst. Wie in

http://www.roboterforum.de/rob…hen_operator-t3303.0.html

bereits beschrieben bekommst du die Lage (X,Y,Z) und die ABC-Winkel zur homgenen Matrix A_ij, i=1,..4, j=1,...,4 über (vgl. MAT_TO_RPY in kue_weg.src)

X = A14
Y = A24
Z = A34

norm := sqrt( A11*A11 + A21*A21);

;Eulersingularität bei B=90°
if norm > 1E-5 then
sa = A21/norm;
ca = A11/norm;
A = atan2(sa, ca);
else
sa = 0.0;
ca = 1.0;
A = 0.0;
endif

B = atan2( -A21, ca*A11 + sa*A21 );
C = atan2( sa*A13 - ca*A23, -sa*A12 + ca*A22 );

atan2 ist dabei der Arkustangens mit zwei Argumenten, der entgegen dem normalen Arkustangens am Taschenrechner anhand der Vorzeichen der beiden Argumente auch eine Unterscheidung nach dem Quadranten in dem das Ergebnis liegen muss vornimmt.

Ich bin mir jetzt bei KRL nicht sicher aber ich glaube der ATAN2 braucht und liefert in C normalerweise Werte in Bogenmaß, so dass du eventuell deine Winkel noch nach Grad bzw- Bogenmass umrechnen musst.

Gruß
Fubini

Hallo R2D2,

das hast du richtig erkannt. Da es sich bei einer 3x3-Orientierungsmatrix immer um eine orthonormale Matrix handelt, ist das Transponieren identisch mit dem Invertieren der Matrix. Damit drehst du sozusagen die Beschreibung des Verhältnisses der Orientierung zweier Koordinatensysteme um.

Beispiel: In der Steurung beschreibt $POS_ACT immer die Lage und Orientierung von $TOOL bezüglich $BASE. Nimmt man nur den Orientierungsanteil (nach Umrechnung der ABC-Winkel in die entsprechende 3x3 Orientierungsmatrix) und wendet auf diesen INV_POS_MAT an erhält man also die Orientierung des $BASE-Systems bezüglich dem $TOOL-System.

Gruß
Fubini

Hallo Glöckler,

schau mal unter

http://www.roboterforum.de/rob…hen_operator-t3303.0.html.

In Ergänzung dazu kann man noch sagen, dass es auf jeder Steuerung unter C:KRC/UTIL ein kue_weg.src geben sollte, indem man die Funktion RPY_TO_MAT findet die in KRL die Umrechnung der ABC-Winkel in eine 3x3 Orientierungsmatrix vornimmt. An der kann man sich dann orientieren.

Gruß
Fubini

Hallo StefanW,

die Idee ist gut. Allerdings wird der Roboter trotzdem eventuell noch nicht volle Geschwindigkeit erreichen. Dass hängt aber nicht mit deiner Idee zusammen, sondern damit, dass die Steuerung in Echtzeit, d.h. in jedem Interpolationstakt von 12ms, eine Schätzung des maximalen Bremswegs vornehmen muss. Um den exakten aktuellen Bremsweg zu berechnen reicht die Zeit von 12ms allerdings nicht aus, so dass die Steuerung das nur approximativ machen kann. Im Wesentlichen sind dabei folgende Einschränkungen aktiv:

• Es wird kein exaktes physikalisches Modell für den Roboter verwendet, sondern nur ein etwas einfacheres das schneller durchgerechnet werden kann.


• Der aktuelle Zustand des Roboters wird in verschiedene Klassen unterteilt (für die Mathematiker unter uns: Äquivalenzklassen) und der Bremsweg dann für den Repräsentanten dieser Klasse bestimmt.

Dies führt in der Regel dazu, dass der Bremsweg von der Steuerung überschätzt wird. Dass muss aber auch so sein, da das ganze ja in sicherer Technik stattfinden muss, d.h. in keiner Situation darf der Bremsweg unterschätzt werden. Es findet also immer eine Worst-Case-Schätzung statt.

Ich bin aber trotzdem der Meinung, dass du durch deine vorgeschlagene Strategie das Maximum an Geschwindigkeit unter o.g. Randbedingungen herausholen kannst.

Gruß
Fubini