Kraftregelung für einen UR10 Gelenkarmroboter
Autor: Daniel Gosedopp
Betreuer: Prof. Göbel
Einleitung
Aufgabenstellung
Vorgehensweise
Das Vorgehen erfolgt nach V-Modell. Die Phasen werden in diesem Wiki-Artikel als roter Faden verwendet.
Anforderungsdefinition
In der Anforderungsdefinition werden die Anforderungen an das System/die Aufgabenstellung festgehalten. Dabei sind lediglich die zu erfüllenden Aufgaben zu definieren, die Art der Umsetzung spielt zunächst keine Rolle. Alle Punkte sollen somit möglichst lösungsneutral beschrieben werden. Für die Kraftregelung mit einem UR10-Roboter werden folgende Anforderungen definiert und mit dem Auftraggeber (Prof. Göbel) abgestimmt:
ID | Typ (I = Info, A = Anforderung) | Kapitel | Inhalt | Ersteller | Datum | Kommentar Auftragnehmer | Status Auftraggeber | Kommentar Auftraggeber |
001 | I | 1 | Kommunikation | |||||
002 | A | Um Echtzeitfähigkeit zu gewährleisten, muss die RTDE Schnittstelle mit einer Übertragungsfrequenz von 125 Hz genutzt werden. | D. Gosedopp | 12.04.2023 | ||||
003 | A | Über RTDE müssen die Position des Roboters (Pose/Gelenkpositionen) und die Kraft am TCP empfangen werden. | D. Gosedopp | 12.04.2023 | ||||
004 | A | Über RTDE muss die Sollpositionen (Pose) in Register des UR Controllers geschrieben werden. | D. Gosedopp | 12.04.2023 | ||||
005 | A | Die RTDE Schnittstelle muss nach dem Protokoll im Dokument Real-Time Data Exchange (RTDE), das von Universal Robots zur Verfügung gestellt wird, umgesetzt werden. | D. Gosedopp | 12.04.2023 | ||||
006 | I | 2 | Datenverarbeitung | |||||
007 | A | Die geschätzte Kraft muss im Werkzeugkoordinatensystem vorhanden sein. | D. Gosedopp | 12.04.2023 | ||||
008 | A | Die geschätzte Kraft muss in einem Kalibrierungsschritt von einem möglichen Offset befreit werden. | D. Gosedopp | 12.04.2023 | ||||
009 | A | Die geschätzte Kraft muss mit einem Tiefpassfilter gefiltert werden, da das Signal nur eine angegebene Genauigkeit von +/- 10 N hat und sehr verrauscht ist. | D. Gosedopp | 12.04.2023 | ||||
010 | A | Es soll möglichst schnell auf eine Regeldifferenz reagiert und ein statischer Regelfehler vermieden werden. | D. Gosedopp | 12.04.2023 | ||||
011 | A | Der Regler hat als Eingangsgröße die Differenz aus Sollkraft und Istkraft in z-Richtung des Werkzeug-KOS und als Ausgangsgröße ein Weginkrement "dz" in z-Richtung des Werkzeug-KOS. | D. Gosedopp | 12.04.2023 | ||||
012 | A | Das Weginkrement "dz" muss auf die z-Koordinate der aktuellen Sollpose der Trajektorie addiert werden. | D. Gosedopp | 12.04.2023 | ||||
013 | A | Die Sollpose ist Stellgröße für den Roboter und wird in frei nutzbare Register des UR Controllers übertragen. | D. Gosedopp | 12.04.2023 | ||||
014 | I | 3 | Umsetzung/Software | |||||
015 | A | Die Datenverarbeitung erfolgt an einem externen PC (Client) in MATLAB. | D. Gosedopp | 12.04.2023 | ||||
016 | A | Die in MATLAB berechnete Sollpose wird von Polyscope aus den verwendeten Registern ausgelesen und vom UR Controller über die inverse Kinematik ggf. in Gelenkpositionen umgerechnet, da einige Bewegungsbefehle in Polyscope nicht mit der Pose arbeiten. | D. Gosedopp | 12.04.2023 | ||||
017 | A | Sollen z.B. in x-y-Richtung im Werkzeug-KOS mehrere Wegpunkte angefahren werden, wird im Vorfeld eine Trajektorie offline mit MATLAB generiert. | D. Gosedopp | 12.04.2023 | ||||
018 | A | Die Bewegungsbefehle werden in Polyscope geschrieben und in Dauerschleife mit der von MATLAB berechneten Sollpose aktualisiert. Dazu ist eine zeitliche Synchronisation zwischen Polyscope und MATLAB erforderlich. | D. Gosedopp | 12.04.2023 | ||||
019 | I | 4 | Rahmenbedingungen | |||||
020 | A | Das Projekt wird nachhaltig in SVN dokumentiert. | D. Gosedopp | 12.04.2023 | ||||
021 | A | Die Softwareentwicklung erfolgt nach dem V-Modell. | D. Gosedopp | 12.04.2023 | ||||
022 | A | Zum Projekt wird ein Wiki-Artikel und ein Werbeplakat angefertigt. | D. Gosedopp | 12.04.2023 |
Funktionaler Systementwurf
-
Abbildung 1: Funktionaler Systementwurf.