Kann ein KUKA Roboter eine Bewegung in Abhängigkeit von der Zeit nachfahren?

Kann ein KUKA Roboter eine Bewegung in Abhängigkeit von der Zeit nachfahren, wenn die Geschwindigkeits- und Beschleunigungslimits bei der Planung eingehalten wurden?

In unserem Unternehmen haben wir eine Software entwickelt mit deren Hilfe eine Roboterbewegung automatisch geplant und ein Programm für den jeweiligen Roboter erstellt werden kann. In Szenen wo Förderbänder mit kontinuierlicher (aber nicht notwendigerweise linearer) Bewegung vorkommen, werden alle Positionen samt Geschwindigkeiten der komplexen Roboterbewegung berechnet, die zu definierten Zeitpunkten angefahren werden müssen. Als Resultat haben wir somit eine Liste von „DeviceTimeStatuses“ ( Zeitpunkt, Achswinkel, Achsgeschwindigkeit).

Wenn der Roboter zu bald oder zu spät an einer Position wäre, würde er kollidieren. Uns fehlt jedoch ein wenig das Wissen, welche Mechanismen ein KUKA Roboter zur Verfügung stellt diese Bewegung auch exakt in der Zeit auszuführen.

Für uns wäre es somit wünschenswert, wenn es in einem KUKA Programm möglich wäre anzugeben zu welchen Zeitpunkten die jeweilige Achskonfiguration erreicht werden sollen. Kennt jemand einen Mechanismus der dies ermöglicht. Für jede Idee oder Anregung wären wir sehr dankbar.

Oder ist eine direkte Sollvorgabe für den Regler zu jedem Taktzeitpunkt möglich?

Besten Danke für die Rückmeldungen.
Die Antworten sind schon mal vielversprechend und mit ein wenig Dokumentenstudium unserseits lässt sich unsere Aufgabenstellung damit sicher umsetzen.

Zitat von Urmel

aus meiner Erfahrung mit Bewegungen mit ähnlichen Zeitanforderungen (aufgezeichnete menschliche Bewegung), würde ich sagen, dafür benötigst du einen eigenen Bahnplaner. Das ist ein Programm, meist in C++ geschrieben, das von einem externen Rechner aus die Robotersteuerung direkt in deren Interpolationstakt ansteuert.

Bei Kuka heißt diese Zusatzoption RSI-XML, dazu kann ich aber nicht mehr sagen, als man hier im Forum findet. Wir verwenden andere Roboter.

Bei dieser Möglichkeit wäre somit unsere eigene Software der Bahnplaner. Und über die RSI-XML Schnittstelle könnten wir die geplanten Achswinkel im Interpolationstakt direkt an die KUKA Steuerung übertragen. Wenn ich die Funktionsweise der RSI-XML Zusatzoption Richtig verstanden habe sollte es damit funktionieren. Falls uns noch jemand eine gute Dokumentation zu dieser RSI-XML Option empfehlen könnte wäre das hilfreich.

Zitat von Twister

Wäre es evtl. möglich deine externen Kinematiken (Förderbänder)
als zusätzliche KUKA-Achse zu betrieben?
Dann würde die Robotersteuerung alle Bewegungen mit rechnen.
Ähnlich einem Kipp-Schwenk-Tisch. (2 zusätzliche KUKA-Achsen)
Dann könntest dir die ganze externe Rechnerei sparen und könntest
in beliebigen Geschwindigkeiten das Programm "sauber" abfahren.

Alles anzeigen

Das wäre sicher die einfachste Methode, die wir uns auch bereits überlegt haben. Es gibt jedoch ein Problem, wo wir uns nicht sicher sind ob dadurch größere Probleme auftreten. Bei der Umrechnung von der Liste von „DeviceTimeStatuses“ ( Zeitpunkt, Achswinkel, Achsgeschwindigkeit) auf die Bewegungsbefehle ergibt sich leider eine kleine zeitliche Ungenauigkeit. Es kann somit sein das der Roboter einen Punkt auf der Bahn etwas früher oder auch später erreicht. In diesem Fall befindet sich das Förderband natürlich an einer etwas anderen Position. Somit muss der Roboter eine etwas andere Achskonfiguration einnehmen, um diesen Punkt zu erreichen. Diese ist dann aber nicht mehr hundertprozentig sicher kollisionsfrei. Ob dies wirklich ein Problem ist hängt natürlich von der zeitlichen Ungenauigkeit ab. Wir müssen aber erst testen wie groß diese wirklich ist.

Zitat von Berrad

ab Softwarestand 8.2 (KrcNexxt) kann eine Splinebewegung mit Zeitvorgabe
programmiert werden. Ich habe es aber noch nicht probiert.

Diese Möglichkeit hört sich für uns sehr interessant an. Leider konnten wir auf die schnelle keine weiteren Informationen darüber finden. Sollte jemand eine Dokumentation oder weitere Informationen hierfür zur Verfügung habe wäre das sehr hilfreich.

Zitat von Urmel

sowas macht doch keiner ohne Detailwissen über die verwendeten Roboter.

Die Software lässt sich so gut wie auf jeden Roboter anpassen, egal ob KUKA, ABB oder irgend ein anderer Typ. Das Detailwissen über die Kinematik des Roboters ist natürlich immer vorhanden.
Wir habe damit einige Projekte umgesetzt wo z.B. online Bearbeitungspunkte am Werkstück ermittelt werden und das Roboterprogramm von unserer Software innerhalb weniger Sekunden automatisch und kollisionsfrei geplant wurde.
Die Situation wo sich das Werkstück auf einen Förderband bewegt ist nun der nächste Schritt den wir gehen wollen.

Ich werde mal versuchen die Aufgabenstellung etwas genauer zu beschreiben damit es besser verständlich ist. Ich hoffe es gelingt mir, da ich nicht jedes Detail der Aufgabe ausplaudern darf. Die Beschreibung wird aber leider etwas länger werden.

Auf dem Werkstück werden Online verschiedene Bearbeitungs-Punkte bestimmt die von Roboter angefahren werden müssen. Das geschieht z.B. über ein Sensorsystem. Die Anzahl und Position der Punkte ist jedes mal unterschiedlich. Beim Werkstück handelt es sich um ein dreidimensionales komplex geformtes Objekt. Die an zufahrenden Punkte liegen teilweise an schwer zu erreichenden Positionen.

Unsere Planungssoftware hat nun als Ausgangspunkt ein komplettes Modell der Szene. Die Szene beinhaltet ein Modell des Roboters, des Werkstückes, des Tools und jeweils ein Modell aller Hindernisse (Boden, Wände, …). Mit Hilfe dieser Informationen wird nun eine Roboterbewegung berechnet die alle Bearbeitungs-Punkte kollisionsfrei anfährt.
Als Ergebnis dieser Planung erhalten wir eine Liste mit Einträgen die wir „DeviceTimeStatuses“ (Zeitpunkt, Achswinkel, Achsgeschwindigkeit) nennen. Diese Liste beschreibt die erforderliche Roboterbahn. In der Liste befinden sich natürlich für jeden Bearbeitungs-Punkt ein zusätzlicher Eintrag der angibt das hier die Bearbeitung durchgeführt werde soll.

Zu allerletzt wird diese Liste mit einer Komponente unserer Software abgearbeitet, die das eigentliche Roboterprogramm generiert. Hier existiert natürlich für jeden Robotertypen eine eigene speziell angepasste Software-Komponente die das nötige Detailwissen beinhaltet wie ein Bewegungsbefehl bei KUKA, ABB, … auszusehen hat. Auch die Bearbeitungsbefehle werden hier auf die jeweilige Roboterprogrammiersprache umgesetzt (z.B. Aufruf eines Unterprogramms, Setzten eines Digitalen Ausgangs, ...).

Das damit erzeugte Programm kann nun vom Roboter geladen und eventuell als Unterprogramm in die Ablauflogik der kompletten Anlage aufgenommen werden.

Wie bereits erwähnt funktioniert dieses Prinzip einwandfrei wenn Roboter und Werkstück statisch sind. Bewegt sich jedoch einer der beiden (in unserem Fall ist es das Werkstück das sich auf einem Förderband befindet) berücksichtigt unsere Bahnplanungssoftware diese Bewegung, um auch in diesen Fall eine kollisionsfreie Roboterbewegung zu ermitteln. Als Ergebnis erhalten wir wieder die selbe Liste von Bahn-Punkten wie im statischen Fall nur das die Bewegung des Förderbandes berücksichtigt wird. Ziel ist es jetzt daraus ein Programm für einen KUKA Roboter zu generieren, wo sich das Werkstück auf dem Förderband befindet.

Das einfachste meiner Meinung nach wäre es wenn die Robotersteuerung die Kontrolle über das Förderband übernehmen könnte. Dann würde der Roboter an jeder vorgegebenen Position des Förderbandes die geplante Achskonfiguration einnehmen und könnte somit die Bewegungsbahn gesichert kollisionsfrei abfahren. Leider wird es aber nicht möglich sein das die Robotersteuerung die Kontrolle über das Förderband übernimmt. Darum suchen wir jetzt einen Ausweg wie sich diese Aufgabe trotzdem realisieren lässt.

Wenn wir dafür die Conveyor-Tech Funktionalität verwende könnte die Bewegungsbahn nach meinem Wissen an die tatsächliche Position des Förderbandes angepasst werden. Treten dabei aber kleine Geschwindigkeitsfehler beim Förderband auf (wie z.B. von Sebbi beschrieben das sich die mechanischen Verhältnisse des Bandes ändern) erreicht der Roboter einen Bearbeitungs-Punkt zu einem Zeitpunkt an den sich das Förderband an einer geringfügig anderen Stelle befindet als zuvor geplant. Dadurch muss der Roboter eine andere Achskonfiguration einnehmen. Je nachdem in welcher Stellung der Roboter sich gerade befindet kann eine kleine Änderung des TCPs eine große Änderung der Achskonfiguration verursachen. Dadurch ergibt sich das Problem das eine Kollision auftreten kann weil sich sozusagen der Ellbogen des Roboterarms an einer ganz anderen Stelle befindet. Dies kann durch die Planungssoftware zuvor natürlich nicht abgefangen werden. Alles vorausgesetzt natürlich das wir die Möglichkeiten der Conveyor-Tech Funktionalität richtig interpretiert haben.

Unser Gedanke diese Situation zu umgehen wäre nun folgender. Wir nutzen eine zeitliche Steuerung des Roboters.
Die zeitliche Steuerung würden wir deshalb vorziehen, da es uns natürlich nicht möglich ist die komplette Steuerung des Roboters nach zu implementieren um das komplette dynamische Verhalten des Roboters zu simulieren. Wenn wir also für die Bewegung die Geschwindigkeiten der Achsen vorgeben, würde sich ein kleiner zeitlicher Fehler ergeben der sich bei jeden Punkt aufsummieren würde. Bei einer zeitlichen Steuerung würden wir den Roboter auf unsere geplante Bewegung zwingen.
Natürlich haben wir auch mit diesem Verfahren ein Problem wenn sich das Förderband mit unterschiedlicher Geschwindigkeit bewegt. Diese sind aber unserer Meinung nach leichter zu beherrschen bzw. hat der Bearbeitungsprozess keine besonders hohen Genauigkeitsanforderungen. Ist jetzt z.B. das Förderband nur mit halber Geschwindigkeit unterwegs könnten wir diese vor der Abarbeitung der Roboterbahn messen und die Zeiten mit einem Skalierungsfaktor belegen. Alle weiteren hoffentlich kleinen Ungenauigkeiten könnten dadurch berücksichtigt werden das wir einfach das Kollisionsmodell des Roboters und des Tools um den maximal zu erwartenden Abweichungswert vergrößern.
Sollte das Förderband während der Bewegung des Roboters stehen bleiben oder sich die Geschwindigkeit wären dessen verändern, könnten wir das natürlich nicht berücksichtigen und müssten Roboter und Förderband zur Sicherheit wahrscheinlich stoppen.

Aus der hier beschriebenen Aufgabenstellung ergibt sich somit unsere ursprüngliche Fragestellung.