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
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.
Abbildung 1: Funktionaler Systementwurf.
Abbildung 2: Technischer Systementwurf.