Bahnplanung auslesen

Versuche es mit $AXIS_ACT. Es gibt die aktuelle achsspezifische Sollposition des Roboters.

Während die Bewegung noch im Vorlauf ist kannst du das nicht irgendwie abfragen. Die Bewegung ist ja da gerade erst in der Planung. Du kommst maximal an Daten wie den Zielpunkt der Bewegung. Am einfachsten geht das über den pro_ip und der darin enthaltenen Satznummer des Vorlaufs wie es auch schon der Support mitgeteilt hat.

Fubini

Zitat von TomTomToGo

will wissen wie der Roboter (Achspositionen) das Programm verfährt. Das ganze möglichst während das Programm gefahren wird im Vorlauf

Hab da auch keine Lösung, aber bei solchen Fragen frage ich mich immer wieder: wozu braucht man das?

Ptp sind Geraden im Achsraum, d.h. du kannst es selbst ausrechnen. Außerdem sind die Achsen dabei gemeinsam parametrisiert, d.h. wenn Achse 1 10% ihres Gesamtwegs gemacht hat haben auch alle anderen Achsen genau 10 % ihres Wegs hinter sich.

Bei Lin/circ musst du dir die kartesische Sollgeometrie über Inverse selbst in kleine Teile zerlegen.

Aber das ist alles aufwendig und komplex zu programmieren. Warum besorgt ihr euch kein offline simulationstool? Oder verriegelt Arbeitsräume gegeneinander?

Fubini hat schon das meiste dazu gesagt.

So wie ich das jetzt verstehe wollt Ihr in Echtzeit auf einem Roboter evtl. Kollisionen mit anderen Robotern (mehr als nur ein anderer?) verhindern.

Nur mal ein paar Gedanken dazu:

- Welche Geometrie soll da kontrolliert werden? Die komplette Roboterkinematik mit Greifer/Werkzeug, (zumindest alles ab Achse 4, was m.M. das einzige Sinnvolle wäre)? Oder nur der Greifer/Werkzeug? Oder etwa nur der TCP?

Wenn da zumindest Teile der Geometrie (Greifer, Achse 4,5,6) betrachtet werden sollen, da ist dermassen viel komplizierte Mathematik nötig: wie langsam schleichen denn die Roboter da in der Gegend rum? Das dürfte nicht in Echtzeit zu schaffen sein.

- Es müsste dann doch auch noch die Position des anderen Roboters bekannt sein, also müsste die noch von einem Roboter auf den anderen übertragen werden, natürlich ebenfalls die Vorlaufposition, kostet auch Zeit, die von den Berechnungen abgeht. Dann müsste auch noch die Geomtrie des anderen Roboters dazu berechnet werden.

Kann mir beim besten Willen nicht vorstellen wie das online in Echtzeit gehen sollte.

Wenn es nicht in Echtzeit geschehen soll, sondern "irgendwie" offline oder nachträglich, dann macht die Forderung nach "vorlaufend" m.M. keinen Sinn.

Wir haben mal eine Echtzeit-Kollisionsüberwachung geschrieben. Mit genug potenter Hardware (dicke GPU) geht da schon was.

Kommt aber, wie Hermann bereits gesagt hat, auf die zu überwachenden Geometrien an.

In unserem Fall war es zum Beispiel nur ein Roboter, welcher selbst nicht betrachtet wurde, mit relativ komplexem Greifer gegen eine Zelle mit ein paar Störkonturen. Die Überwachung lief nur auf einer externen CPU, war aber extrem optimiert und hat ca. 12ms für eine Position gebraucht.

Die Entwicklung hat aber bestimmt ein Mann-Jahr gedauert.

Ich würde mir erstmal anschauen, ob man das nicht einfacher lösen kann.

Hmm,

wenn du die Roboter in einem Roboteam hast kannst du sie in den Simulationsmodus stellen und ihre Bahnen ablaufen lassen.

In der SPS.SUB kannst du dir die aktuellen Achspositionen ausgeben lassen.

Mit den Daten kannst du dir dann gegenüberstellen wann welcher Roboter welche Achspositionen hat.

Mit Hilfe der DH Parameter kannst du dir dann die Punkte der Achsübergänge im Raum ermitteln und die Abstände zueinander.

Das wäre ein Weg um sich zumindest die Kettenpunkte voneinander abzutrennen.

Aber wirklich in Laufzeit sich die Roboter gegenseitig abzufragen und das dann auch noch im Vorlauf?

Abgesehen davon, dass ich nicht wüsste, dass Kuka die Position ausgibt, die er in x Sekunden hat, gibt Kuka sicherlich nicht die Bahnplanung raus die sie verwenden. Und dann musst du das ganze noch berechnen lassen. Ein normaler PC wird damit sicherlich überfordert sein. Und das wenn er 2 gegen rechnen muss. Um das abzukürzen müsstest du dir die einzelnen Glieder in Punkte aufteilen, die du alle über die DH Parameter bestimmst und dann definierte Kugeln darüber legen. Dann kannst du es vllt rechnen, sitzt aber auch lange an der Programmierung.

LG

Moin TomTom,

vielleicht hilft dir das weiter - KUKA.FastSendDriver - ich weiss allerdings nicht obs das für deine SW-Version gibt.