Kraftregelung für einen UR10 Gelenkarmroboter

Autor: Daniel Gosedopp
Betreuer: Prof. Göbel

Einleitung

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.