Ansteuerung des UR3 Roboters mit Matlab und URSim mittels Realtime Schnittstelle

→ zurück zur Seite Praktikum Produktionstechnik

Autoren:
WS 2020/21: Jan Pinter und Rina Mucaj
WS 2021/22: Haris Adrovic, Maik Spinnrath und Franziska Troja

Betreuer: Prof. Dr. Mirek Göbel und Marc Ebmeyer

Einleitung

Abbildung 1: UR3 Roboter

In diesem Artikel wird die Ansteuerung des UR3 Roboters (siehe Abbildung 1) von Universal Robots mit Matlab und URSim mittels Realtime Schnittstelle beschrieben. Das Projekt fand im Rahmen des Praktikum Produktionstechnik im Wintersemester 20/21 statt. Die Aufgabe bestand darin, den UR3 Roboter so zu programmieren, dass er Legoteile aus einem Ablageort greift und diese auf eine Legoplatte platziert. Außerdem musste er durch wiederholsichere Bewegungen die Legoteile in verschiedenen Stellen platzieren. Zusätzlich wurde noch ein Magazin als Entnahmeort entwickelt, an dem der Roboter die Legosteine abnehmen kann.

Im Rahmen des Studiengangs Mechatronik findet im 7.Semester das Produktionstechnik-Praktikum statt. In diesem Praktikum können alle zuvor im Studium gelernten Inhalte noch einmal angewendet werden. Dazu werden in Kleingruppen verschiedene einzelne mechatronische Projekte semesterbegleitend bearbeitet. In diesem Artikel geht es um die Ansteuerung eines UR3-Roboters, der mit Hilfe von MATLAB und der eigenen Software URSim programmiert werden soll. Diese Aufgabe wurde in zwei Semestern (WS 2020/21 und WS 2021/22) von unterschiedlichen Studierenden bearbeitet.

Projektaufgabe

Der Roboter soll ein im Vorfeld festgelegtes Bild mit Klemmbausteine legen, dazu muss dieser auf die Steine aus einem Magazin entnehmen und auf einer Platte absetzen. An dem Roboter befindet sich ein Greifer als Endeffektor, der diese Steine greifen und an definierter Position absetzen muss. Da der Roboter kontinuierlich eine Schnittstelle in Echtzeit mit spezifischen Informationen über beispielsweise die Gelenkwinkel, -geschwindigkeiten und -beschleunigung schreibt, kann diese Realtime-Schnittstelle zur Unterstützung bei der Ansteuerung genutzt werden. Zusätzlich mussten auch noch die Greifbacken des Roboters an die Projektaufgabe angepasst werden, da die vorherigen nicht spezifisch an die Klemmbausteine zum Greifen und Absetzen geeignet waren. Ebenso wird ein größeres Magazin für die Anzahl an Steinen benötigt, da für das geplante „Bild“ insgesamt 26 Klemmbausteine von dem Magazin gefasst werden müssen. Dieses wurde dementsprechend auch noch neu designt.

Das V-Modell

Abbildung 2: Das V-Modell

Das V-Modell in Abbildung 2 ist eine konkrete Vorgehensweise zum Planen und Durchführen von Entwicklungsprojekten. Dieses Vorgehen wurde auch für dieses Projekt angewandt. Dadurch konnte eine konkrete Planung und gute Struktur des Projektes geschafft werden. Alle notwendigen Schritte zur Bewältigung eines erfolgreichen Projektes sind dort dargestellt. Für die Dokumentation wurde das Tortoise SVN genutzt, dort wurde ein gleichnamiger Ordner erstellt, der auch in die einzelnen Projektschritte noch einmal unterteilt wurde. Dort liegen alle Dateien, die während des Praktikums erstellt worden sind.

SVN-Ordner WS 2020/21
SVN-Ordner WS 2021/22

Anforderungsdefinition

In der Anforderungsliste bzw. dem Lastenheft für das Projekt „Ansteuerung des UR3 Roboters mit Matlab und URSim mittels Realtime Schnittstelle“ wurden die spezifischen Anforderungen, die an dieses Projekt gestellt worden sind, definiert.
Diese wurden unterteilt in:

• Funktion
  • Was ist die Aufgabe des Projekts?
  • Was soll das Ergebnis sein?
• Aufbau
  • Welchen Anforderungen werden an die Strukturierung der Station?
• Schnittstellen
  • Was für Schnittstellen zwischen dem Roboter und dem Computer genutzt?
  • Wofür werden die Schnittstellen genutzt?
• Software / Werkzeuge
  • Welche Programme werden benötigt?
  • Werden Toolboxen genutzt?
• Dokumentation
  • Wie wird die Dokumentation durchgeführt?
  • Wo wird dokumentiert?
• Optional
  • Was kann bei vorhandener Zeit noch bearbeitet/ergänzt werden?

Abbildung 3: Anforderungsliste

Die Anforderungsliste kann hier heruntergeladen werden: Datei:Anforderungsliste UR3MitLego.xlsx

Funktionaler Systementwurf

Mittels Software soll die Ansteuerung des UR3-Roboters geschehen. Dazu muss eine wiederholsichere Ausführung gewährleistet werden. Im Groben wird von dem Roboter immer ein Stein aufgenommen und an vorher festgelegter Position absetzen, dies wird in bestimmter Anzahl an Wiederholung durchgeführt.

Abbildung 3: Funktionaler Systementwurf

Originaldatei des Funktionalen Systementwurfs: Datei:Funktionaler Systementwurf UR3MitLego.xlsx

Technischer Systementwurf

In dem Technischen Systementwurf ist eine konkrete Verbindung zwischen den verschiedenen Komponenten dargestellt und wie diese miteinander kommunizieren können.

Abbildung 4: Technischer Systementwurf

Der Technische Systementwurf kann hier heruntergeladen werden: Datei:Technischer Systementwurf UR3MitLego.pptx

Komponentenspezifikation

Bei der Komponentenspezifikation wird für jede Komponente die Aufgabe, das Verhalten, der innere Aufbau und Schnittstellen zu anderen Teilsystemen detailliert beschrieben und durch Skizzen oder Bilder unterstützt.

Die vollständige Komponentenspezifikation kann hier heruntergeladen werden: Datei:Komponentenspezifikation UR3 Lego WS 21 22.xlsx

Abbildung 5: Beispiel_Komponentenspezifikation

Roboter

Der Roboter ist ein UR3 von Universal Robots. Er verfügt über 6 rotierende Gelenke welche 6 Freiheitsgrade ermöglichen. Seine maximale Reichweite beträgt 500mm. Programmiert werden kann er entweder über das angeschlossene Terminal in der mitgelieferten Polyscope Software oder über einen angeschlossenen Computer. Zur weiteren Ansteuerung besitzt er sowohl 16 digitale als auch 2 analoge Ein- und Ausgänge.

Magazin

Die Komponente Magazin beinhaltet die Legosteine, welche der Roboter legen soll. Damit dieser die Steine wiederholsicher aufnehmen kann, muss die Position des auszunehmenden Steins bis auf eine minimale Toleranz immer gleich sein. Außerdem muss sich das Magazin dafür im Greifraum des Roboters befinden. Zusätzlich müssen die nachfolgenden Steine aus dem Magazin automatisch an die Entnahmestelle befördert werden.

Magazin V1

Das Magazin in Abbildung 6 wurde mit CAD konstruiert. Die Maße wurden an eine vorhandene Rutsche angepasst, sodass ein störungsfreier Rutschvorgang gewährleistet werden kann. Die Steine rutschen auch ohne verwendeten Druckluftanschluss an der Rutsche bis zur Endposition (siehe Abbildung 7). Damit dies gewährleistet werden kann, müssen in das gedruckte Magazin zwei zusammengebaute Legosteine wie in Abbildung 8 eingelegt werden, die für eine glatte Rutschfläche auch auf dem gedruckten Bauteil sorgen. Durch das Langloch als Befestigung kann die Position nahezu beliebig angepasst werden, sodass die optimale Rutschposition gefunden werden kann.

Abbildung 6: CAD-Zeichnung des Magazins

Abbildung 7: Zusammenbau vom 3D gedruckten Magazins und der Rutsche

Abbildung 8: Nutzung der Legosteine für glatte Oberfläche

Das CAD Modell vom Magazin kann hier heruntergeladen werden: Datei:MagazinCAD.SLDPRT
Die Originaldatei von der Abbildung 8 kann hier im SVN gefunden werden.

Magazin V2

Das Magazin in der Version 1 funktioniert gut, jedoch war die Kapazität zu gering, um größere Formationen zu legen. Daraufhin wurde mit dem vorhandenen Konzept eine größere Variante entwickelt. Diese besteht aus 4 Parallel verlaufenden Rutschen wodurch die Kapazität entsprechend vervierfacht wurde. Die Kapazität beträgt nun 32 Steine. Das Magazin verfügt nun über vier Entnahmestellen was in der Programmierung entsprechend angepasst werden muss.

Da die vorher benutzen Druckluftschienen sehr kostenintensiv sind, mussten andere Materialien verwendet werden. Diese Version besteht aus 3D gedruckten Teilen welche auf einer zugeschnittenen Holzplatte zusammengesteckt, geschraubt und geklebt wurden. Die 3D gedruckten Teile wurden vorher in der CAD Software SolidWorks konstruiert und in der hochschuleigenen Projektwerkstatt gefertigt.

Da auch andere Gruppen des Praktikums viele 3D Druck Teile benötigten waren die Wartezeiten teilweise lang. Dadurch verzögerten sich die Montage und Tests des Magazins. Die Tests ergaben, dass die Oberfläche der Holzplatte nicht glatt genug ist und so der letzte Stein einer Rutsche nicht vollständig in die Entnahmestelle rutscht. Alle vorherigen Steine einer Rutsche rutschen, wie geplant, in die Entnahmestellen. Somit reduziert sich die Kapazität auf 28 Steine.

Abbildung 9: CAD-Modell des Magazins V2

Abbildung 11: Foto des Magazins V2

Greifbacken

Die originalen Greifbacken sind zu sperrig, um auf der Legoplatte Steine aneinander zu legen. Außerdem sind sie nicht für die Aufnahme von Legosteinen optimiert. Deswegen wurden neue Greifbacken entwickelt. Diese wurden ebenfalls wie die Magazine zunächst in der CAD Software SolidWorks konstruiert und dann in der Projektwerkstatt 3D gedruckt.

Die Greifbacken sind nun kleiner und für die Form der Legosteine optimiert. Dadurch können die Steine auf der Legoplatte enger aneinandergelegt werden. Außerdem Verfügen sie über eine Zentriervorrichtung, welche die Noppen der Steine nutzt, um den Stein immer mittig im Greifer zu packen. So können kleine Toleranzen in der Entnahmestelle des Magazins ignoriert werden. Zusätzlich können die Steine mit der Zentriervorrichtung auch stärker auf die Platte gedrückt werden.

Abbildung 12: CAD-Modell des Greifers

Abbildung 13: Foto des Greifers

Steinpositionierung

Damit der Roboter Steine auf einer Platte absetzen kann, muss dieser die notwendigen Informationen über die unterschiedlichen Steine erhalten. Dies soll mit einer Excel-Datei realisiert werden, da hier sehr einfach die Positionierung der Steine geändert werden kann. Ein Vorteil einer Excel-Datei ist zudem, dass dort die Platte, auf der die Klemmbausteine positioniert werden sollen, imitiert werden kann. Denn diese kann mit den einzelnen Zellen die Noppen der Klemmbausteine darstellen. Da eine Excel-Datei aus sehr vielen Zeilen und Spalten bestehen kann, muss die Größe der Platte jeweils mit einer „0“ eingegrenzt werden.

Programmierung

Abbildung XY: PAP des Hauptprogramms

Bei der Programmierung des Roboters wurde zunächst ein Programmablaufplan (Abbildung XY) erstellt. Anhand dessen wurde dann im Folgenden die Programmierung des Roboters durchgeführt. Der Programmablaufplan besteht unter anderem aus vielen unterschiedlichen einzelnen Funktionen. So kann eine Übersichtlichkeit gewährleistet werden und beispielsweise das Anfahren einer Position mit dem Roboter als Funktion wiederverwendet werden.

Einbindung der Originaldatei fehlt noch

Ansteuerung des Roboters

Das Ansteuern des UR3 mit Matlab ist möglich, jedoch nicht einfach. Bereits nach 2 Stunden war es möglich, ohne Matlab mit der Programmierung des Polyscopes einen LEGO Stein wiederholt aufzunehmen und auf der Platte zu platzieren. Die Programmierung in Matlab erwies sich als schwierig, da viele Funktionen, die es im Polyscope gibt, nicht direkt in Matlab gibt. Die Verwendung der "Robotics Toolbox" von Peter Corke schafft zwar eine Lösungsmöglichkeit, jedoch muss man hier bereits genau wissen, wie die einzelnen Befehle anzuwenden sind, da es sonst zu Fehlern oder Abbrüchen des Programms kommt. Ebenso werden einige nützliche Polyscopebefehle nicht unterstützt. Abhilfe muss hier über andere Wege geschafft werden, wie über die Variablentabelle der Realtime TCP Verbindung. Sind alle Befehle bekannt und lassen sich alle Funktionen umsetzen, bietet die Programmierung über Matlab jedoch den Vorteil, weitere Funktionalitäten aus Matlab einzubeziehen, wie das Auslesen einer Excel Tabelle für die Steinkoordinaten. Eine Simulation der Bewegungen kann in Matlab auch erfolgen. Diese wäre jedoch auch ohne Matlab mit URSim möglich. Durch die Verwendung von Matlab erlernt man den Umgang mit Skripthandbüchern, die für die Anwendung von nicht selbst programmierten Befehlen nötig sind.

Herstellung der Verbindung und einfache Bewegungen mit Matlab

Um mit dem Roboter über eine Ethernet-Verbindung kommunizieren zu können, muss ein TCP Port geöffnet werden.

• Der Port für die Realtime Kommunikation zum Roboter ist 30003.
• Die IP des Roboters muss gegebenenfalls auf statisch festgelegt werden anstatt DHCP.

Für das Erzeugen einer Bewegung gibt es im Skripthandbuch von UR bestimmte Befehle. So ist eine Bewegung aller Achsen des Roboters auf bestimmte Zielwinkel „q“ mit der Funktion „movej(q, a, v, t=0, r=0)“ möglich. Die zu übergebenden Variablen sind hier ebenfalls beschrieben.

• q = Gelenkwinkel der einzelnen Achsen (Jeder Achse wird ein Winkel in Radiant zugeordnet. Jede Achse dreht sich beim Anfahren des neuen Bewegungsbefehls somit auf seinen vorgegebenen Wert. Bei dem UR3 gibt es 6 Achsen, somit auch 6 unterschiedliche q (q1, q2, q3, q4, q5, q6).)
• a = Beschleunigung der Achsen
• v = maximale Geschwindigkeit der Achsen

Dieser Befehl muss als String, also nicht als Variablen, an die Steuerung des Roboters übergeben werden. Dies kann in Matlab mit „num2str“ so umgesetzt werden:

function [commandString] = command2string(q,a,v,t,r)
    
    commandString = ['movej([' num2str(q(1)) ', ' num2str(q(2)) ', ' num2str(q(3)) ', ' num2str(q(4))...
                    ', ' num2str(q(5)) ', ' num2str(q(6)) '], ' num2str(a) ', ' num2str(v) ', ' num2str(t)...
                    ', ' num2str(r) ')'];
end

Hier kann die originale MATLAB-Funktion heruntergeladen werden: Datei:Command2string.m.

Anschließend muss dieser String über die Verbindung mit „fprintf“ gesendet werden.

Socket_conn = tcpip(Robot_IP,Port_NR);
fprintf(Socket_conn; command2string(q,a,v,t,r));

Koordinatensystem des Roboters und der Legoplatte

Abbildung XY: Skizze der Koordinatensysteme auf dem Tisch und Drehmatrix für neue Kooridnatensystem

Eine Eigenschaft des Roboters ist, dass dort eigene Koordinatensysteme festgelegt werden können. Die positive Richtung der drei Koordinatenachsen (x-, y- und z-Achse) können selbst gewählt werden. Dazu wird ein eigener Ursprung festgelegt und von dort aus dann die Richtung bestimmt.
Dadurch, dass bei dem UR3-Roboter für das Positionieren der Klemmbausteine ein Greifer befestigt ist, ist es sehr aufwendig und schwierig mit dem Greifer ein neues, geeignetes Koordinatensystem festzulegen. Denn durch den Greifer ist ein sehr langer Hebel gegeben, der es erschwert den Mittelpunkt des Endeffektors exakt im Lot für dem benötigten Ursprung zu setzen. Das würde nur mit einem sehr langen „Trial und Error“ zu einem zufriedenstellenden Ergebnis führen. Denn auch nur eine minimale Abweichung macht ein genaues Absetzen der Klemmbausteine an den definierten Positionen unmöglich.
In Abbildung XY ist eine Skizze des Aufbaus in dem Labor erkennbar, dort ist die Ausrichtung des Koordinatensystems „Ansicht“, welches eine Grundeinstellung des Roboters ist, eingezeichnet, mit einer Drehmatrix könnte in ein für das Projekt geeigneteres Koordinatensystem gedreht werden. Auf die Transformationsmatrix des Koordinatensystems „Ansicht“ kann zugegriffen werden. Diese besteht, wie in Abbildung XY (Die Transformationsmatrix), erkennbar aus der Drehmatrix und dem Verschiebevektor. Der Verschiebevektor kann sowohl ausgelesen als auch neu beschrieben werden. Hingegen kann die Drehmatrix nur gelesen werden und nicht überschrieben werden. Denn die Abspeicherung für der Informationen des Roboters erfolgt in einem SE3, welche bestimmte Möglichkeiten aber auch Einschränkungen mit sich bringt.

Realtime-Schnittstelle des Roboters

Wie schon bei den Komponentenspezifikationen erwähnt, werden von dem Roboter kontinuierlich Daten über einen Port geschrieben. Da über diesen Port kontinuierlich geschrieben wird, muss die Anzahl der maximalen Ausleselänge in MATLAB beschränkt werden. Ab dem 1060. Byte wiederholt sich das große Datenpaket, weshalb es auf diese Größe begrenzt wird. Dies kann mit dem Befehl "Socket_conn.InputBufferSize = 1060" maximiert werden. Je nach Version des Polyscope-Programms auf dem Roboter werden unterschiedlich viele Werte übertragen. Die Zuordnung kann über eine von Universal Robots bereitgestellte Liste erfolgen. Diese enthält nützliche Daten zur Ansteuerung des Roboters, beispielsweise die Achswinkel, -geschwindigkeiten und Motorlast. Deren Interpretation erfolgt anhand einer von UR (Universal Robots) breitgestellten Liste. Das Schreiben der Informationen über den Roboter geschieht in Echtzeit mit 125Hz, wodurch dies praktisch für die Programmierung der Ansteuerung des Roboters genutzt werden kann. Diese Informationen müssen noch strukturiert werden, da nur mit dem Auslesen der Schnittstelle die Daten einem nicht sinnvoll für die weitere Nutzung zur Verfügung stehen. Hierbei hilft ebenfalls die Liste von UR. In diesem Projekt wird die Realtime-Schnittstelle nur zum Lesen genutzt, es erfolgt keine Befehlsübergabe über diese Schnittstelle.

function realtime = realtime_schnittstelle(Robot_IP, Port_NR)
    Socket_conn = tcpip(Robot_IP,Port_NR);
    Socket_conn.InputBufferSize = 1060; 


    % Auslesen der Schnittstelle
    fclose(Socket_conn);                %ggf. bestehende Verbindung trennen
    fopen(Socket_conn);                 %Verbindung zur Schnittstelle starten
    flushinput(Socket_conn);
    realtime = fread(Socket_conn); 
    fclose(Socket_conn);                %Verbindung zur Schnittstelle schließen
end

Bewegungsarten

Unterschied Lineare und Joint Bewegung

Der Roboter kann die Zielposition entweder durch direkte Drehung der Achsen anfahren oder seine resultierende Bewegung vorher berechnen und für den Greifer eine lineare, gradlinige Bewegung erzeugen. Mit der linearen Bewegung lässt sich besser die Bewegung des Roboters abschätzen, da er sich im Joint Modus auch bei kleinen Bewegungen um seine eigene Achse drehen kann. Damit es hierbei zu keinen unerwarteten Problemen, wie das Verfahren durch Hindernisse, bei einem Programmstart kommt, fahren wir den Roboter zunächst in eine Ausgangsposition, in welcher er senkrecht nach oben zeigt. Analog zu „movej“ gibt es hierzu den Befehl „movel“.

Zielangaben

Die Zielkoordinaten einer Bewegung können entweder als direkte Winkel der Achsen (q1, q2, q3, q4, q5, q6) oder als Transformationsmatrix T angegeben werden. Die Umrechnung erfolgt über ikine und fkine und erfordert ein aktives Robotermodell, das mit dem Befehl „mdl_ur3;“ aktiviert wird. Dieser Befehl wird einmal zu Beginn des MATLAB-Programms aufgerufen und ausgeführt. Die Transformationsmatrix ist in Abbildung 14 dargestellt. Aus ihr lassen sich die Drehmatrix und der Verschiebevektor erkennen. Die Drehmatrix gibt an, wie der Tool-Center-Point gedreht ist. Der Verschiebevektor gibt die kartesischen Koordinaten von diesem im Raum an. Diese können als x-, y- und z-Koordinaten abgelesen werden.

Abbildung 14: Die Transformationsmatrix

Die Originaldatei von der Abbildung 14 kann hier im SVN gefunden werden.

Ikine-Befehl

Mit "ikine" lassen sich aus einer Transformationsmatrix T neue Zielwinkel q bestimmen. Dies ist der Befehl für die Inverse Kinematik. Er berechnet aus den Zielkoordinaten die einzelnen Gelenkwinkel q des Roboters so, dass der Tool-Center-Point des Roboters sich anschließend an der gewünschten kartesischen Koordinate befindet. Hierzu werden jedoch noch Startwinkel für die Berechnung benötigt. Es empfiehlt sich, für den Startwinkel die aktuellen Winkel der Gelenke zu nutzen. Sollte die Berechnung mittels Matlab nicht funktionieren, müssen andere Startwinkel gewählt werden oder geprüft werden, ob das Ziel im erreichbaren Roboterbereich liegt.
Der Code für ikine sieht so aus:

q = ur3.ikine(T,'q0',q_Startwinkel);

Fkine-Befehl

Mit "fkine" lässt sich aus einem q (Zielwinkel) eine Transformationsmatrix T errechnen. Dies kann folgend umgesetzt werden:

T = ur3.fkine(q_neu);

Quellcode

Der gesamte Quellcode befindet sich im SVN. Ein externer Nutzer oder bei fehlerhafter Verbindung kann auf diesen Pastebin zurückgegriffen werden: Verknüpfung zu PasteBin
Die Funktionalität der Funktionen beginnend mit „test“ oder auskommentierter Code ist nicht gewährleistet, und muss vor Verwendung geprüft werden.

Nutzung verschiedener nutzerdefinierten Funktionen

In dem Hauptprogramm, der den UR3-Roboter ansteuert, werden auf unterschiedliche nutzerdefinierte Funktionen zugegriffen. Diese Funktionen ermöglichen eine übersichtliche Arbeitsweise und können ebenfalls bei nachfolgenden Projekten einfacher wiederverwendet werden.

Berechnung der Steinkoordinaten

Für die Bestimmung der Steinkoordinaten wird die zuvor generierte Excel-Datei benötigt, da ausgehend von dieser die Mittelpunktkoordinaten und Ausrichtung berechnet wird. Ebenso muss abhängig von der Ausrichtung der x- und y-Achse darauf geachtet werden, ob sich die Koordinatenpunkte ggf. im negativen Bereich der Koordinatenachse befindet.

Auslesen der Realtime-Schnittstelle

Für die Auswertung der Roboterbewegung wird die Realtime-Schnittstelle, die kontinuierlich von dem Roboter unter anderem über den Port 30003 beschrieben wird, genutzt. Wie schon bei den Komponentenspezifikationen erwähnt, werden von dem Roboter kontinuierlich Daten über einen Port geschrieben. Da über diesen Port kontinuierlich geschrieben wird, muss die Anzahl der maximalen Ausleselänge in MATLAB beschränkt werden. Ab dem 1060. Byte wiederholt sich das große Datenpaket, weshalb es auf diese Größe begrenzt wird. Dies kann mit dem Befehl "Socket_conn.InputBufferSize = 1060" maximiert werden. Je nach Version des Polyscope-Programms auf dem Roboter werden unterschiedlich viele Werte übertragen. Die Zuordnung kann über eine von Universal Robots bereitgestellte Liste erfolgen. Diese enthält nützliche Daten zur Ansteuerung des Roboters, beispielsweise die Achswinkel, -geschwindigkeiten und Motorlast. Deren Interpretation erfolgt anhand einer von UR (Universal Robots) breitgestellten Liste. Das Schreiben der Informationen über den Roboter geschieht in Echtzeit mit 125Hz, wodurch dies praktisch für die Programmierung der Ansteuerung des Roboters genutzt werden kann. Diese Informationen müssen noch strukturiert werden, da nur mit dem Auslesen der Schnittstelle die Daten einem nicht sinnvoll für die weitere Nutzung zur Verfügung stehen. Hierbei hilft ebenfalls die Liste von UR. In diesem Projekt wird die Realtime-Schnittstelle nur zum Lesen genutzt, es erfolgt keine Befehlsübergabe über diese Schnittstelle.

function realtime = realtime_schnittstelle(Robot_IP, Port_NR)
    Socket_conn = tcpip(Robot_IP,Port_NR);
    Socket_conn.InputBufferSize = 1060; 


    % Auslesen der Schnittstelle
    fclose(Socket_conn);                %ggf. bestehende Verbindung trennen
    fopen(Socket_conn);                 %Verbindung zur Schnittstelle starten
    flushinput(Socket_conn);
    realtime = fread(Socket_conn);      %Verbindung zur Schnittstelle schließen
end

Die Originaldatei kann hier heruntergeladen werden: Datei:Realtime schnittstelle.m

Strukturierung ausgewählter Daten der Realtime-Schnittstelle

Für die Übersichtlichkeit, an welchem Byte welche Information geschrieben wird, wurde eine Excel-Datei erstellt. Diese Bytes müssen anschließend in einen double-Wert umgewandelt werden. Es muss dabei darauf geachtet werden, dass die Bytenummer von links nach rechts sinkt. Dies kann mit dem folgenden Code erfolgen:

 
 „typecast(uint8([Byte8, Byte7, Byte6, Byte5, Byte4, Byte3, Byte2, Byte1]),'double')“ 

Die Zuordnung der Bytes kann dieser Excel-Liste entnommen werden: Datei:RealtimeDaten Bedeutung.xlsx

Da die Gelenkgeschwindigkeiten zunächst für die Auswertung der Bewegung des Roboters genutzt werden, werden diese in für eine einfache Handhabung in einem Struct abgespeichert. Anhand der zuvor verlinkten Excel-Datei ist erkennbar, dass diese Informationen in den Bytes 301 bis 348 steht. So wird in der Variable realtime alle aktuell benötigten Variablen übersichtlich hinterlegt. Dies geschieht ebenfalls über eine Funktion, die innerhalb der Funktion auch noch einmal auf die Funktion zum Auslesen der Realime-Schnittstelle zugreift.

function realtime = struktur_realtime(Robot_IP, Port_NR)
    daten_realtime = realtime_schnittstelle(Robot_IP, Port_NR);
    A = daten_realtime;      %fuer Uebersichtlichkeit Daten der Realtime-Schnittstelle kuerzer abgespeichert
       
    
    % Struktur fuer Geschwindigkeiten der Gelenke
    v_g(6)= zeros;    
    v_g(1)= typecast(uint8 ([A(308), A(307), A(306) ,A(305), A(304), A(303), A(302), A(301)]),'double');
    v_g(2)= typecast(uint8 ([A(316), A(315), A(314) ,A(313), A(312), A(311), A(310), A(309)]),'double');
    v_g(3)= typecast(uint8 ([A(324), A(323), A(322) ,A(321), A(320), A(319), A(318), A(317)]),'double');
    v_g(4)= typecast(uint8 ([A(332), A(331), A(330) ,A(329), A(328), A(327), A(326), A(325)]),'double');
    v_g(5)= typecast(uint8 ([A(340), A(339), A(338) ,A(337), A(336), A(335), A(334), A(333)]),'double');
    v_g(6)= typecast(uint8 ([A(348), A(347), A(346) ,A(345), A(344), A(343), A(342), A(341)]),'double');
    
    
    realtime.v = v_g;                       % Info ueber Gelenkgeschwindigkeiten
end

Die originale MATLAB-Funktion kann hier heruntergeladen werden: Datei:Struktur realtime.m

Überprüfung der Roboterbewegung

Die vorher beschriebene Funktion, in der die Daten für die Gelenkgeschwindigkeiten strukturiert werden, kann für die Überprüfung der Roboterbewegung genutzt werden. Hier werden so lange die Daten der Realtime-Schnittstelle abgerufen und abgeglichen, bis alle sechs Gelenke des Roboters stehen, also die Geschwindigkeit null ist. Diese Funktion wird nach allen Bewegungen, die der Roboter anfahren soll, aufgerufen, so dass sichergegangen wird, dass der Roboter seine Bewegungen korrekt ausführt.

function Roboter_steht(Robot_IP, Port_NR)
    realtime = struktur_realtime(Robot_IP, Port_NR);
    
    while realtime.v ~= 0 
        realtime = struktur_realtime(Robot_IP, Port_NR);
        pause(1); 
    end
end

Die originale MATLAB-Datei kann hier heruntergeladen werden: Datei:Roboter steht.m

Aufbau mit Funktionen für Übersicht

Der von unserer Gruppe generierte Matlab Code ist in Funktionen gegliedert, um eine übersichtliche Programmierung zu gewährleisten und einzelne Programmteile erneut verwenden zu können. Somit lässt sich übersichtlich eine Verbindung zum Roboter aufbauen, einige Sicherheitspositionen anfahren und gezielt bestimmte Koordinaten in wenigen Zeilen anfahren:

 %% Ausführen der Bewegungen/Aufruf der Funktionen
 connectRobot();
 normaleGeschwindigkeit();
 ResetUR3_startPositionUp();
 %startPositionWithTurn();                
 Startposition_MoveJ();
 if(StopOnCalibrationPosition) return; end
 langsameGeschwindigkeit();
 moveTo_XYZ(0,-0.3,0.3);
 moveTo_XYZ(-0.3,-0.3,0.3);
 testPlateCoordinate();

Globale Variablen und Bedeutung

Für das Programm wurden mehrere Globale Variablen angelegt. Diese dienen dazu, das Programm zu konfigurieren und das Programmverhalten schnell ändern zu können. So kann man beispielsweise schnell die maximalen Geschwindigkeiten für eine schnelle oder langsame Fahrt anpassen, ohne tief in den Code einsteigen zu müssen.

• UR3_connected; Boolean
  • True – Roboter ist angeschlossen und soll Bewegungen ausführen
  • False – Roboter ist nicht angeschlossen oder soll keine Bewegung ausführen → Simulationsdurchlauf nur in Matlab
• UR3_plot
  • True – Matlab erstellt eine Simulation der Bewegung
  • False – Simulation wird übersprungen, schnellerer Durchlauf
• pausetimeOnMovement
  • True – Voreingestellte Pausenzeiten werden nach einer Bewegung berücksichtigt
  • False – Pausenzeiten werden ignoriert. Programmdurchlauf über Breakpoints.
• StopOnCalibrationPosition
  • True – Matlab beendet das Programm auf der Ausgangsposition mit „richtiger“ Drehung des Greifers. Manuelles Auslesen einzelner Zielkoordinaten ab hier möglich.
  • False – Programm wird vollständig durchlaufen
• SicherheitsabstandUeberEndposition
  • Sicherheitsabstand zum Anfahren des Magazins oder Steinkoordinate in Meter
• brickUpperLeft
  • Obere, linke Ecke der Legoplatte als „q“ (Auslesen bei gegriffenem Stein und manuellem Anfahren)
• brickLowerRight
  • Untere, rechte Ecke der Legoplatte als „q“ (Auslesen bei gegriffenem Stein und manuellem Anfahren)
• magazinPosition
  • Position eines Steins im Magazin als „q“ (Auslesen bei gegriffenem Stein und manuellem Anfahren)
• normaleGeschwindigkeit
  • Prozentuale Geschwindigkeit für „schnelle“ Bewegungen, Wert 0-1.
• langsameGeschwindigkeit
  • Prozentuale Geschwindigkeit für „langsame“ Bewegungen, Wert 0-1.
• ParameterGeschwindigkeitMax_mm
  • Anpassungsparameter der Geschwindigkeit bei linearer Bewegung, Standardwert: 1
• ParameterGeschwindigkeitMax_mm_accel
  • Anpassungsparameter der Beschleunigung bei linearer Bewegung, Standardwert: 1

runQ(time,movement)

Mit dem Befehl "runQ" wird der Bewegungsprozess nach der Berechnung des neuen Ziels eingeleitet. Hierzu muss das Ziel vorher als Transformationsmatrix „T_neu“ (ggf. muss die 4x4 Matrix mit SE3 umgewandelt werden) oder als Zielwinkel „q“ definiert werden.
Bei Aufruf von „runQ“ muss nun noch eine zu erwartende Zeit als „time“ eingetragen werden, um dem Roboter Zeit zu lassen, die Bewegung vor einem neuen Befehl auszuführen. Die Zeit wird hierbei auf 100% Robotergeschwindigkeit angegeben und wird automatisch auf kleinere Geschwindigkeiten umgerechnet.
Zudem muss definiert werden, ob es sich um eine joint oder eine lineare Bewegung handeln soll. Dies geschieht mit einem „L“ oder „J“ in der Variable „movement“.

moveTo_XYZ(x,y,z)

Ist eine Zielkoordinate kartesisch zum Roboterfuß bekannt, kann die Funktion „moveTo_XYZ“ genutzt werden. Diese Funktion fährt linear zur Zielkoordinate. Der Greifer wird hierbei jedoch nicht gedreht. Er bleibt hierbei immer „gerade“ (Drehmatrix), wie er in der Transformationsmatrix in der Funktion definiert ist (siehe auch Abbildung 8). In der vierten Spalte können die Zielkoordinaten eingetragen werden (Verschiebevektor). Soll sich der Roboter anders gedreht bewegen, kann die Drehmatrix der Transformationsmatrix angepasst werden. Hierzu muss der Roboter manuell in die gewünschte Richtung gedreht werden und über „fkine“ die Transformationsmatrix in Matlab ausgelesen werden.

testPlateCoordinate()

Das Anfahren über einen Sicherheitsabstand kann in der Funktion „testPlateCoordinate()“ erreicht werden. Hierzu wird zunächst ein Sicherheitsabstand auf die Z Koordinate addiert und schnell angefahren. Anschließend lässt sich das Ziel mit „movel“ langsam anfahren, sodass der Roboter nur noch langsam vertikal nach unten fährt. Analog lässt sich so das Entfernen von einer Sicherheitsposition in umgekehrter Reihenfolge erzeugen.

TCP Realtime Variablen

Der UR Roboter schreibt viele Variablen über den Port 30003. Diese können mit „fread(TCP_Verbindung)“ als Array ausgelesen werden. Da es sehr viele Bytes sind, muss die maximale Ausleselänge in Matlab mit dem Befehl „TCP_Verbindung.InputBufferSize = 1080“ erhöht werden. Es empfiehlt sich, vorher alle Werte der Schnittstelle zu reinigen mit „flushinput(TCP_Verbindung)“, damit nicht mitten in der Übertragung mit „fread“ abgegriffen wird. Je nach Version des Polyscope-Programms auf dem Roboter, werden unterschiedlich viele Werte übertragen. Die Zuordnung kann über eine von UR bereitgestellte Liste erfolgen. So können beispielsweise die aktuelle Position, die Zielposition oder die Bewegungsgeschwindigkeit ausgelesen werden. Eine übersichtlichere Liste zur aktuellen Version des Roboters wurde im SVN abgelegt und beschreibt die Byte-Nummer sowie die Deutung der Werte. Diese Bytes müssen anschließend in einen double-Wert umgewandelt werden. Dies kann mit dem Code erfolgen:

 
 „typecast(uint8([Byte1, Byte2, Byte3, Byte4, Byte5, Byte6, Byte7, Byte8]),'double')“ 

Für das Auslesen eines Gelenkwinkels (in Grad) könnte dies so wie in Abbildung 15 aussehen (BytesInRange sind die zugehörigen Bytes aus der TCP Liste, die hier als feste Werte eingetragen sind):

Abbildung 15: Auslesen eines Gelenkwinkels aus der TCP Liste

Die TCP Liste von UR für alle Versionen kann unter folgendem Link unten auf der Seite als Excel-Datei gefunden werden: TCP Liste

URSim Simulationssoftware

Eine Anleitung zur Installation der Simulationssoftware URSim befindet sich unter dem folgenden Link: Anleitung URSim Diese Simulationssoftware ist sehr hilfreich, um Programmabschnitte vorher an der Funktionsfähigkeit zu testen. Kleine Programmabschnitte können hiermit programmiert und überprüft werden.
Ist die Verbindung mit der richtigen IP-Adresse gewählt, lässt sich auch ein Befehl aus MATLAB an die Virtuelle Maschine des URSim´s senden. In Abbildung XY auf der rechten Seite ist das MATLAB-Programm zu sehen. Der Befehl wird ausgeführt und die Bewegung des Roboters wird simuliert. Die Simulation ist auf dem Bild oben rechts zu erkennen. Auch hierbei ist es möglich, die TCP Realtime Variablen mit MATLAB auszulesen. Unten rechts auf dem Bild wird die Bewegung zusätzlich in der virtuellen Maschine simuliert.

Abbildung XY: Ansteuerung des Roboters mit URSim

Ausblick

Wann ist eine Roboterbewegung fertig?

Derzeit weiß das Matlab Programm noch nicht, ob der Roboter eine Bewegung abgeschlossen hat. Beim Senden eines neuen Bewegungsbefehls, stoppt der Roboter abrupt und führt dann sofort die neue Bewegung aus. So kann es zu ungewollten Bewegungsbahnen kommen, die ggf. in Hindernisse fahren oder ein Sicherheitsrisiko darstellen.
Daher muss geprüft werden, wann eine Bewegung vollständig abgeschlossen ist. Derzeit wird dies über eine Wartezeit zwischen den einzelnen Bewegungen realisiert. Dies führt zu Wartezeiten und muss ggf. für jede Bewegung angepasst werden. Die Befehle des Polyscopes wie „is_steady()“ funktionieren nicht über die Verbindung des Realtime Port 30003.
Daher muss entweder mit den Variablen der TCP Verbindung gearbeitet werden oder in Matlab die Zeit der Bewegung errechnet werden. Mit der Variablentabelle der TCP Realtime Verbindung könnte die aktuelle Geschwindigkeit oder Position abgefragt werden und bei Unterschreiten eines bestimmten Grenzwertes gilt die Bewegung als abgeschlossen. (In der Realität schwankt der Roboter immer etwas, daher wird nie exakt der Wert aller Achsen erreicht.)

Greifer ansteuern

Die Ansteuerung des Greifers funktioniert im Polyscope mit dem Befehl: RG2(10,40,0.0,True,False,False)
Dieser wird nicht ausgeführt, wenn er als Skriptbefehl gesendet wird. In Absprache mit dem UR Support ist dies nicht möglich. Hierfür könnte jedoch ein anderer Skriptbefehl genutzt werden: set_tool_digital_out(0,True) bzw. set_tool_digital_out(1,True)
Hierzu muss jedoch im Polyscope (siehe Abbildung 17) noch eine Anpassung vorgenommen werden:

Abbildung 17: Werkzeugausgang durch Benutzer

Sollte dieser Befehl nicht funktionieren, muss ggf. das „UR Caps“ Programm des Greifers im Polyscope deinstalliert werden, da es sich Exklusivrechte für diesen Skriptbefehl einräumen kann.

Greifer je nach Anforderung Drehen

Der Greifer muss sich mit „moveTo_XYZ“ auch drehen können, um auch ein gedrehtes Magazin nutzen zu können oder Steine horizontal oder vertikal drehen zu können vor der Ablage auf der LEGO Platte. Die Drehung könnte jeweils auf einer Sicherheitsposition überprüft werden und bei Bedarf gedreht werden. So ließe sich moveTo_XYZ auch weiter nutzen.

Kompletten Bewegungsablauf für das Platzieren eines Steines erstellen

• Excel auslesen für Steinkoordinaten

Geplant war, eine Excel-Liste auszulesen, in welcher die Steinkoordinaten anschaulich eingetragen werden. Die Verwendung von „MergedCells“ ist in Matlab nicht möglich oder liefert nur „NaN“ Werte. Daher müsste ein Stein in jedem Feld eine Zahl besitzen (siehe Abbildung 18). Die Zahl stünde für die Reihenfolge des Platzierens. Die Spalten und Zeilenbreite von Excel ist gleich, sodass die Legoplatte quadratisch abgebildet wird.

Abbildung 18: Excel-Liste für die Steinkoordinaten

Diese Excel-Liste soll mit Matlab ausgelesen werden. Damit das Array nicht automatisch in Matlab gekürzt wird, kann man in die äußeren Ecken eine „0“ setzen, damit ein Wert vorliegt. Das ausgelesene Array muss weiterbearbeitet werden, sodass die Steine am Ende nur durch ihre Platzierreihenfolge, ihren Mittelpunkt und ihre Drehung (horizontal oder vertikal) definiert sind. Diese können anschließend in einer Schleife im Hauptprogramm abgearbeitet werden.

• Steinplatzierungsfunktion und Entnahmefunktion erstellen

Ein aufgenommener Stein muss von der Ausgangssicherheitsposition auf die Legoplatte platziert werden und anschließend zurück zur Sicherheitsposition fahren. Hierzu muss die Zielkoordinate aus der von Excel errechneten Steinkoordinate ausgewertet werden und über einen Sicherheitsabstand angefahren werden (vgl. testPlateCoordinate() ). Die Entnahme der Steine aus dem Magazin wird analog zu Steinplatzierungsfunktion erstellt.

Abbildung 19: Möglicher Bewegungsablauf

In Abbildung 19 ist ein möglicher Bewegungsablauf dargestellt. Die Reihenfolge der Bewegungsschritte ist wie folgt:
(Position 2 und 5 sind jeweils senkrecht 10cm über 3 bzw. 6; Startposition ist immer Position 1)

• Stein aus Magazin nehmen - 1; 2; langsam; 3; Greifer schließen; 2; schnell; 1;
• Stein auf Platte platzieren - 1; 4; 5; langsam; 6; Greifer öffnen; 5; schnell; 4; 1.

Abbildung 20: Lineare Bewegungen in Polyscope und Auslesen der Gelenkwinkel

Die Originaldatei von der Abbildung 20 kann hier im SVN gefunden werden.

Zum Auslesen der kartesischen Koordinaten muss der Roboter in seine Startposition 1 gefahren werden, sodass der Greifer passend zur Platte ausgerichtet ist (zB mit dem Einstellparameter „StopOnCalibrationPosition“). Nun muss er manuell über die in Abbildung 20 gezeigten Schaltflächen verfahren werden, bis die nächste Zielposition erreicht ist.
Die abgebildeten Gelenkwinkel können in Matlab zu den gewünschten Koordinaten für die Funktion moveTo_XYZ() wie in Abbildung 21 umgewandelt werden. Diese können nun direkt im Hauptprogramm eingetragen werden.

Abbildung 21: Umwandeln der aktuellen Position in karthesischen Koordinaten in Matlab

Die Originaldatei von der Abbildung 21 kann hier im SVN gefunden werden.

• Mehrere Schichthöhen der Steine

Die Legosteine könnten auch übereinandergestapelt werden, nachdem eine Ebene vollständig abgearbeitet wurde. Hierzu können analog zu ersten Excel Tabelle weitere angelegt werden, die die nächsthöhere abdecken.

Zusammenfassung

Eine Verbindung zwischen Roboter und Matlab ist aufgebaut und kann für den Datenaustausch verwendet werden. Bewegungen lassen sich sowohl linear als auch im joint Modus umsetzen und können einfach durch die Angabe der Zielkoordinaten mit moveTo_XYZ() erreicht werden. Die aufgetretenen Probleme wurden teilweise schon gelöst. Zu nicht gelösten Aufgaben und Problemen wurden Ansätze und Lösungsstrategien im Wiki festgehalten. Zur Erweiterung der Funktionalität in Matlab können Daten über die TCP Schnittstelle des Roboters abgefragt werden.

Alle Originaldateien können hier im SVN gefunden werden.

Literaturverzeichnis

→ zurück zur Seite Praktikum Produktionstechnik