Quelltext der Seite Ansteuerung des UR3 Roboters mit Matlab und URSim mittels Realtime Schnittstelle


→ zurück zur Seite [[Praktikum Produktionstechnik]]

'''Autoren:''' <br>
WS 2020/21: [[Benutzer:Jan Pinter|Jan Pinter]] und [[Benutzer:Rina Mucaj|Rina Mucaj]] <br>
WS 2021/22: [[Benutzer:Haris androvic| Haris Adrovic]], [[Benutzer: Maik Spinnrath| Maik Spinnrath]] und [[Benutzer: Franziska Troja| Franziska Troja]] <br> <br>
'''Betreuer:''' [[Benutzer:Mirekgoebel|Prof. Dr. Mirek Göbel]] und [[Benutzer:Marc Ebmeyer| Marc Ebmeyer]]
[[Datei:Bild GPE.PNG|500px|thumb|right|Abbildung 1:  Projektaufbau]]
== '''Einleitung''' ==
[[Datei:UR3Roboter.jpg|300px|thumb|rechts|Abbildung 2: UR3 Roboter]]
Im Rahmen des Studiengangs Mechatronik findet im 7.Semester das [[Praktikum Produktionstechnik]] 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 (siehe Abbildung 2) von [[Universal Robots]] <ref> [[Universal_Robots| Universal Robots]] </ref>, welcher von der HSHL zur Verfügung gestellt wird. Dieser soll mit Hilfe von MATLAB und der eigenen Software URSim programmiert werden. Diese Aufgabe wurde in zwei Semestern (WS 2020/21 und WS 2021/22) von Studierenden bearbeitet. 
<br clear=all>

=== 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 wiederholsicher diese Steine greifen und an definierter Position absetzen muss. Die Steine können aus einem Magazin entnommen werden. 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 ===
[[Datei:Vmodell.JPG|400px|thumb|right|Abbildung 3: Das V-Modell <ref name="[Quelle Das V-Model]"> Quelle  Das V-Modell: Produktionstechnik Praktikum, Prof. Dr. Göbel'' </ref> ]]
Das V-Modell in Abbildung 3 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 [https://tortoisesvn.net/downloads.de.html 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.


[https://migsvn.hshl.de:65489/usvn/svn/UniversalRobots/Mitarbeiter/2020_Mucaj_Pinter/ SVN-Ordner WS 2020/21]  <br>
[https://migsvn.hshl.de:65489/usvn/svn/UniversalRobots/Mitarbeiter/2021_Spinnrath_Troja/ SVN-Ordner WS 2021/22]



<br clear=all>

== '''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. <br>
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?

[[Datei:Aliste.JPG|500px|thumb|left|Abbildung 4: Anforderungsliste]] 
<br clear=all>

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 abgesetzt, dies wird wiederholt durchgeführt.

[[Datei:Funktionaler Systementwurf UR3MitLego.PNG|500px|thumb|left|Abbildung 5: Funktionaler Systementwurf]]
<br clear=all>

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

== '''Technischer Systementwurf''' ==
In dem Technischen Systementwurf wird die Projektaufgabe genauer spezifiziert. Es wird die konkrete Verbindung zwischen den verschiedenen Komponenten dargestellt und wie diese miteinander kommunizieren können. 


[[Datei:Technischer Systementwurf UR3MitLego.PNG|600px|thumb|left|Abbildung 6: Technischer Systementwurf]]
<br clear=all>

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

== '''Komponentenspezifikation''' ==
Aus dem Technischen Systementwurf lassen sich mehrere Komponenten ableiten. In der Komponentenspezifikation werden die genauen Anforderungen der Komponenten definiert. Hier wird für jede die Aufgabe, das Verhalten, der innere Aufbau und Schnittstellen zu anderen Teilsystemen detailliert beschrieben und durch Skizzen oder Bilder unterstützt. In Abbildung 7 ist ein Auszug aus dieser am Beispiel der Komponente Greifbacken zu sehen.

Die zu betrachtenden Komponenten sind:

* MATLAB-Programm
* Realtime-Schnittstelle
* Roboter
* Magazin 
* Greifbacken
* Steinpositionen

Die vollständige Komponentenspezifikation kann hier entnommen werden: [[Datei:Komponentenspezifikation UR3 Lego WS 21 22.xlsx]]
[[Datei:Komponentenspezifikation Bsp UR3 Lego WS 21 22.jpg |900px|thumb|left|Abbildung 7: Beispiel Komponentenspezifikation (Greifbacken)]]
<br clear=all>

=='''Komponentenumsetzung: Magazin, Greifbacken, Steinpositionen'''==

=== Magazin ===
Die Komponente Magazin beinhaltet die Klemmbausteine, 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 9 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 10). Damit dies gewährleistet werden kann, müssen in das gedruckte Magazin zwei zusammengebaute Klemmbausteine wie in Abbildung 11 eingelegt werden, die für eine glatte Rutschfläche auch auf dem gedruckten Bauteil sorgen. Durch das Lang loch als Befestigung kann die Position nahezu beliebig angepasst werden, sodass die optimale Rutschposition gefunden werden kann.
{| class="wikitable"
 |[[Datei:Magazin.jpg|240px|thumb|centre|Abbildung 9: CAD-Zeichnung des Magazins]]
 |[[Datei:RutscheUR3.JPG|265px|thumb|centre|Abbildung 10: Zusammenbau vom 3D gedruckten Magazins und der Rutsche <ref> Foto: Marc Ebmeyer </ref>]]
 |[[Datei:Legosteine.JPG|240px|thumb|centre|Abbildung 11: Nutzung der Klemmbausteine für glatte Oberfläche <ref> Foto: Marc Ebmeyer </ref>]]
|}

<br clear=all>
Das CAD Modell vom Magazin kann hier heruntergeladen werden: [[Datei: MagazinCAD.SLDPRT]]<br>
Die Originaldatei von der Abbildung 11 kann [https://migsvn.hshl.de:65489/usvn/svn/UniversalRobots/Mitarbeiter/2020_Mucaj_Pinter/Bilder hier]<ref>[https://migsvn.hshl.de:65489/usvn/svn/UniversalRobots/Mitarbeiter/2020_Mucaj_Pinter/Bilder ''Originale Bilder'']</ref> 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 vier 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 musste.

Da die vorher benutzen Druckluftschienen sehr kostenintensiv sind, wurden andere Materialien verwendet. 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 dafür teilweise lang. Dadurch verzögerten sich die Montage und der Komponententest 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.
{| class="wikitable"
 |[[Datei:Magazin CAD WS21 22.PNG|500px|thumb|centre|Abbildung 12: CAD-Modell des Magazins V2]]
<!-- |[[Datei:Magazin Rendering WS21 22.jpg|380px|thumb|centre|Abbildung 10: Rendering des Magazins V2]] -->
 |[[Datei:Magazin Foto WS21 22.jpg|280px|thumb|centre|Abbildung 13: Foto des Magazins V2]]
|}


Die CAD-Dateien zum 3D-Drucken als Download:
{| class="mw-datatable"
! style="font-weight: bold;" | Bauteil
! style="font-weight: bold;" | Anzahl
! style="font-weight: bold;" | Originaldatei
|-
| Platte groß (aus Holz zugeschnitten)
| 1
| [[Datei:Holzplatte.SLDPRT]]
|-
| Platte kurz (aus Holz zugeschnitten)
| 1
| [[Datei:Holzplatte kurz.SLDPRT]]
|-
| Abstandshalter der Schienen
| 1
| [[Datei:Abstandshalter.SLDPRT]]
|-
| Adapterstütze Magazin links
| 1
| [[Datei:Adapter Stütze Magazin.SLDPRT]]
|-
| Adapterstütze Magazin rechts
| 1
| [[Datei:Adapter Stütze Magazin gespiegelt.SLDPRT]]
|-
| Entnahme-Kamm
| 1
| [[Datei:Entnahme Kamm.SLDPRT]]
|-
| Schienen
| 5
| [[Datei:Schienen Magazin.SLDPRT]]
|-
| Winkel zur Verbindung der beiden Holzplatten   
| 2
| [[Datei:Winkel.SLDPRT]]
|-
| Magazin vollständig (Hilfsbauteile vorhanden)    
| 1
| [[Datei:Magazin komplett.SLDASM]]
|}

=== Greifbacken ===
Die originalen Greifbacken sind zu sperrig, um auf der Noppenplatte Steine aneinander zu legen. Außerdem sind sie nicht für die Aufnahme von Klemmbausteinen 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 ersten gedruckten Greifbacken wurden aus PLA gedruckt und hatten das Problem, dass die Steine manchmal aus dem Greifer rutschten. Daraufhin wurde eine zweite Version aus TPU gedruckt, bei dieser tritt das Problem nicht mehr auf und bieten zusätzlich mehr Flexibilität beim Setzen der Steine.

Die Greifbacken sind nun kleiner und für die Form der Klemmbausteine optimiert. Dadurch können die Steine auf der Noppenplatte 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. 
{| class="wikitable"
 |[[ Datei:Greifer CAD WS21 22.jpg|255px|thumb|centre|Abbildung 14: CAD-Modell des Greifers]]
 |[[ Datei:Greifer Foto WS21 22.jpg|350px|thumb|centre|Abbildung 15: Foto des Greifers]]
 |[[ Datei:Seitenansicht Greifbacken.jpeg|250px|thumb|centre|Abbildung 16: Greifbacken für den Greifer]]
|}

Die CAD-Datei zum Nachdrucken kann hier heruntergeladen werden: [[Datei:Greifbacken HSHL.SLDPRT]].

=== Steinpositionierung mit Excel-Datei ===
[[Datei:Position Steinkoordinaten.PNG|350px|thumb|right| Abbildung 17: Excel-Datei mit Steinpositionen]]
Damit der Roboter Steine auf einer Platte absetzen kann, muss dieser die notwendigen Informationen über die unterschiedlichen Steine erhalten. Dies wird mit einer Excel-Datei realisiert, da hier sehr einfach die Positionierung der Steine geändert und jeder einzelne Stein visuell positioniert werden kann. Ein Vorteil einer Excel-Datei ist zudem, dass dort die Platte, auf der die Klemmbausteine abgesetzt 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. In Abbildung 17 ist das Beispielbild, welches mit dem Roboter gesetzt werden soll, erkennbar. <br> <br>

Die Excel-Datei mit Steinkoordinaten herunterladen: [[Datei:Legosteine Positionierung.xlsx]]
<br clear=all>

== '''Ansteuerung des Roboters''' ==
Die Ansteuerung des UR3-Roboters ist sowohl mit Hilfe der eigenen Polyscope-Software als auch mit MATLAB realisierbar. 

In einem Polyscope-Programm können dem Roboter mehrere Positionen angegeben werden, die dieser in der vorgegebenen Reihenfolge nacheinander wiederholt abfährt. Die festgelegten Positionen werden von dem Roboter mit einer sehr hohen Genauigkeit angefahren. Über das Polyscope ist auch eine Ansteuerung des Greifers sehr einfach durchführbar, da dies über eine Einbindung der dazu notwendigen Befehle innerhalb der Software realisiert werden kann. So war es vergleichsweise schnell machbar, dass ein Klemmbaustein gegriffen und an vorgegebener Position abgesetzt wird.

Das Ansteuern des UR3-Roboters ist ebenso mit MATLAB möglich. Die Programmierung in MATLAB erwies sich als schwierig, da einige nützliche Eigenschaften, die im Polyscope verfügbar sind, nicht direkt in MATLAB gibt. So führt das MATLAB-Programm schon den nächsten Schritt aus, obwohl der Roboter seine vorherige Bewegung noch nicht vollständig zu Ende geführt hat. Zudem kann man dem Roboter nicht direkt die einzelnen Positionspunkte übergeben, sondern muss diese zunächst umrechnen bzw. verarbeiten lassen. Die Verwendung der [http://petercorke.com/wordpress/toolboxes/robotics-toolbox "Robotics Toolbox" von Peter Corke] <ref> [http://petercorke.com/wordpress/toolboxes/robotics-toolbox "Robotics Toolbox" von Peter Corke]</ref> kann hier Abhilfe schaffen, jedoch muss bekannt sein, wie die einzelnen Befehle anzuwenden sind. Ebenso werden einige nützliche Polyscope-Befehle nicht unterstützt. Hier kann aber beispielsweise die Verwendung der Realtime-Schnittstelle des Roboters unterstützen, da diese nahezu Echtzeitdaten des Roboters zur Verfügung stellt, wie z.B. die einzelnen Gelenkgeschwindigkeiten.
Die Programmierung mit MATLAB bietet jedoch den Vorteil, dass weitere Funktionalitäten aus MATLAB genutzt werden können, wie das Auslesen einer Excel-Tabelle für die Steinkoordinaten. Eine Simulation der Bewegungen kann in MATLAB auch erfolgen. Dies kann jedoch auch ohne MATLAB mit [https://wiki.hshl.de/wiki/index.php/Universal_Robots#Simulation_der_UR-Roboter_mittels_.22Offline-Simulation.22 URSim] (eigenständige Simulationssoftware) erfolgen.

Eine Kombination der beiden Programmierungsarten bietet die Verwendung einer Server-Client-Verbindung. Hier kann sowohl die Programmierung in MATLAB als auch in Polyscope verwendet werden. Dies ist zudem notwendig, da bis zu dem aktuellen Zeitpunkt noch keine Möglichkeit für die Ansteuerung des Greifers über MATLAB gefunden worden ist. Auch mit Rücksprache des Supports von Universal Robots konnte keine Lösung für die Ansteuerung über MATLAB gefunden werden.
	
'''[https://wiki.hshl.de/wiki/index.php/Universal_Robots#Matlab| Dieser Artikel] zeigt, wie über Matlab mit Hilfe der Robotics Toolbox ein UR-Roboter angesteuert werden kann.'''

=== Bewegungsbefehle ===
* '''Polyscope: 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“.

* '''Nutzung der Peter Corke-Toolbox'''
::* '''Zielangaben'''
Die Zielkoordinaten einer Bewegung können über unterschiedliche an den Roboter übergeben werden. Beispielsweise kann dies 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 18 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.
[[Datei:Drehmatrix.jpg|400px|thumb|left|Abbildung 18: Die Transformationsmatrix <ref> Original ohne Anmerkung: Montage- und Handhabungstechnik, Prof.Dr.Göbel, FolienID: 210.0 </ref>]]
<br clear=all>

Die Originaldatei von der Abbildung 18 kann [https://migsvn.hshl.de:65489/usvn/svn/UniversalRobots/Mitarbeiter/2020_Mucaj_Pinter/Bilder hier] im SVN gefunden werden.

::*'''Ikine-Befehl''' 
Mit <code>ikine</code> 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. <br>
Der Code für <code>ikine</code> sieht so aus:

<code>
q = ur3.ikine(T,'q0',q_Startwinkel);
</code>

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

<code>
T = ur3.fkine(q_neu);
</code>

=== Koordinatensystem des Roboters und der Noppenplatte ===
Der Roboter verfügt über insgesamt drei vordefinierte Koordinatensysteme, in denen dieser bewegt werden kann: Fuß, Basis und Werkzeug. 
Ebenso können für den Roboter eigene Koordinatensysteme festgelegt werden. Dabei kann die positive Richtung der drei Koordinatenachsen (x-, y- und z-Achse) selbst gewählt werden. Hierzu wird ein eigener Ursprung festgelegt und von dort aus dann die Richtung bestimmt.<br>
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. <br>
Deswegen muss hier wahrscheinlich am einfachsten mit einer Drehmatrix von dem Koordinatensystem der Noppenplatte in das "Ansicht"-Koordinatensystem realisiert werden würden.

=== Realtime-Schnittstelle des Roboters ===
Wie schon bei den Komponentenspezifikationen erwähnt, schreibt der Roboter kontinuierlich Daten über einen Port. Da dies kontinuierlich geschieht, muss die Anzahl der maximalen Ausleselänge in MATLAB beschränkt werden. Nach 1060 Bytes fängt die Übertragung wieder mit dem ersten Byte an, weshalb die Ausleselänge auf diese Größe begrenzt wird. Dies kann mit dem Befehl "Socket_conn.InputBufferSize = 1060" eingestellt werden. Je nach Version des Polyscope-Programms auf dem Roboter werden unterschiedlich viele Werte übertragen. Diese Bytes müssen zunächst zusammengefasst und einzelnen Werten zugeordnet werden. Die Zuordnung kann über eine von Universal Robots bereitgestellte [https://www.universal-robots.com/articles/ur/remote-control-via-tcpip/ Liste] erfolgen. Diese Werte enthalten Daten über den Zustand des Roboters, beispielsweise die aktuellen Achswinkel, -geschwindigkeiten und Motorlast. Das Schreiben der Informationen geschieht mit 125Hz in Echtzeit, welche zur Überwachung des Roboters genutzt werden können. Die Werte der Gelenkgeschwindigkeiten werden nach einem Bewegungsbefehl immer wieder ausgelesen und abgeglichen. Wenn alle null sind, ist der Roboter mit der Bewegung fertig und der nächste Befehl kann gesendet werden.

== '''Greiferansteuerung''' ==

Der im Praktikum verwendete [https://onrobot.com/de/produkte/greifer-rg2 OnRobot RG2 Gripper] ist über ein 8 Pin M8 Kabel mit dem Werkzeugausgang des UR3 verbunden und bietet verschiedene Möglichkeiten angesteuert zu werden. 


[[Datei:Greiferansteuerung RG2 Foto.PNG|500px|thumb|left|Abbildung 19: Möglichkeiten der Greiferansteuerung]] 

UR stellt die Funktion bereit auf ihren Robotern aufgebaute Hardware direkt über die Spannungsversorgung am Werkzeugausgang zu steuern. Dies ist leider seitens OnRobot nicht vorgesehen und fällt deshalb als Option weg. Somit beschränkt sich die Möglichkeit den Greifer vom Roboter aus anzusteuern darauf URCaps Befehle auszuführen, die zur Ansteuerung des Greifers vorgesehen sind.

Die zuvor im Mittelpunkt der Betrachtung gestandene Realtime-Schnittstelle ist wie bereits im Abschnitt Server-Client vs. Realtime-Schnittstell beschrieben nicht in der Lage ein Polyscope-Skript anzustoßen und Daten auszutauschen. Somit müssten die URCap Befehle zusammen mit den Bewegungsbefehlen von MATLAB aus über die Realtime-Schnittstell an das Polyscope gesendet werden. Über diese ist das Polyscope jedoch '''nicht''' in der Lage URCap-Befehle zu empfangen. Somit müssen diese unbedingt aus einem Polyscope Skript an den Greifer gesendet werden. Dadurch fällt die Realtime-Schnittstell als Hauptkommunikationsweg aus. 

Als funktionierende Lösung hat sich die Server-Client-Verbindung herausgestellt, da über diese MATLAB in der Lage ist Polyscope-Funktionen anzustoßen, die anschließend URCap-Befehle ausführen. Ebenfalls können so von MATLAB Zielkoordinaten an das Polyscope übergeben werden, um die Bewegung des UR3 zu gewährleisten. Damit ist das Herstellen einer Server-Client-Verbindung nach aktuellem Stand die einzig lauffähige Methode Greifer und UR3 zu steuern.

Originaldatei für die Darstellung der Möglichkeiten zur Greiferansteuerung: [https://wiki.hshl.de/wiki/index.php/Datei:Greiferansteuerung.pptx hier] 
<br clear=all>

== '''Programmierung und Quellcode''' ==
Der gesamte Quellcode befindet sich im SVN.

Ein externer Nutzer kann auf alle Dateien aus dem WS20/21 in diesem Pastebin zurückgreifen: [https://pastebin.com/Qs8suzqq Verknüpfung zu PasteBin] <br>
Die Funktionalität der Funktionen beginnend mit „test“ oder auskommentierter Code ist nicht gewährleistet, und muss vor Verwendung geprüft werden.

Alle Dateien aus dem WS21/22 stehen in diesem [https://wiki.hshl.de/wiki/index.php/Datei:Alle_wichtigen_Programme_UR3_WS2021_2022.zip Ordner] zum Herunterladen zur Verfügung.

=== Hauptprogramm zur Ansteuerung des UR3-Roboters ===
[[Datei:Hauptprogramm PAP UR3mitLego.PNG|250px|thumb|right|Abbildung 20: PAP des Hauptprogramms]]
In dem Hauptprogramm, das den UR3-Roboter ansteuert, werden auf unterschiedliche nutzerdefinierte Funktionen zugegriffen. Zunächst wird die Verbindung zu dem Roboter aufgebaut. Die Programmierung des Roboters erfolgt mit MATLAB und einer Server-Client-Verbindung. Die Server-Client-Verbindung wird zur Ansteuerung des Greifers an dem Roboter benötigt. Diese Funktionen ermöglichen eine übersichtliche Arbeitsweise und können ebenfalls bei nachfolgenden Projekten einfacher wiederverwendet werden. Im Folgenden wird näher auf die einzelnen Funktionen eingegangen.

Programmablaufplan des Hauptprogramms und für die einzelnen Funktionen:[[Datei:PAP UR3 mit Lego.zip]]

Die Originalprogramme für MATALB sind alle [https://wiki.hshl.de/wiki/index.php/Datei:Test_Hauptprogramm_20220113.zip hier] zum Herunterladen zu finden.
<br clear=all>

=== Funktionen zum Verfahren des Roboters ===

MATLAB ist nun nach dem Aufbauen der Server-Client Verbindung in der Lage mit dem Befehl  ''fprintf(Socket_conn,'(8)')''  Daten an das Polyscope zu senden (hier z.B. den Wert = 8). Dieser wird im Polyscope über die bestehende Socket-Connection ausgelesen und in einer Variablen (in dem Fall „task“) abgespeichert, welche durch laufende If-Abfragen bestimmt, welcher Befehl als Nächstes durch das Polyscope ausgeführt wird. So kann das Polyscope bei Eingabe der Variable „8“ z.B. ein Unterprogramm zur Greiferbewegung anstoßen. Die schlussendliche Greiferbewegung wird im Polyscope programmiert. Das Senden von Daten an das Polyscope wird in Matlab in einzelnen Funktionen umgesetzt. So sendet die Funktion readrobotpose.m mit dem Befehl ''fprintf(Socket_conn,'(2)');'' den Wert 2, welcher im Polyscope das Unterprogramm ''Postition_auslesen'' anstößt. Genauso verhält es sich mit der Funktion moverobot.m, readrobotMsg.m (Funktion, die Übertragung der moverobot.m-Variablen an Polyscope prüft)  und allen folgenden Funktionen (z.B. zur Greiferansteuerung, diese könnte auch in einer .m-Datei eingebunden werden).

Bewegungsbefehle werden seitens MATLAB ähnlich versendet. Durch das Aufrufen der Funktion ''moverobot(Socket_conn,Translation,Orientation);'' (Translation und Orientation enthalten die x, y, z, rx,ry und rz Koordinaten, diese können bei Bedarf auch in einer einzigen Variable übergeben werden) führt moverobot.m den Befehl ''fprintf(Socket_conn,'(1)')'' aus, sodass das Polyscope in seinen ''move_robot'' Programmteil springt. Das Polyscope ließt nun erneut die Verbindung aus und speichert die jetzt übergebenen Roboterkoordinaten nicht mehr in der Variable „task“ ab, sondern in einer einer neuen („Move_To_Pos“). 
Die Zielkoordinaten werden matlabseitig als String abgespeichert. 
<br clear=all>

Ausschnitt aus moverobot.m:

<pre>
fprintf(Socket_conn,'(1)'); % task = 1 : moving task
pause(0.01);% 
fprintf(Socket_conn,P_char); % „Socket_conn“ ist im Gesamtcode mit „t“ abgekürzt, hier nur zur Veranschaulichung
                             % P_char enthält die x, y, z, rx,ry und rz Koordinaten
</pre>


Dieser modulare Aufbau des Hauptprogramms ermöglicht es den UR3 bei bekannten Koordinaten der Anfahrpunkte eine beliebige Reihenfolge von Aktionen ausführen zu lassen.

Die Programme (MATLAB und Polyscope) die der Erarbeitung unserer Gruppe zugrunde lagen finden sich  [https://de.mathworks.com/matlabcentral/fileexchange/50655-ur5-control-using-matlab hier ]<ref>[https://de.mathworks.com/matlabcentral/fileexchange/50655-ur5-control-using-matlab Polyscope und MATLAB-Programm]</ref>.

=== Berechnung der Steinkoordinaten ===
[[Datei:Abstand Noppen.PNG|150px|thumb|right|Abbildung 21: Abstand zwischen Noppen]] [[Datei:Matrix Steinkoordinaten.PNG|150px|thumb|right|Abbildung 22: Matrix der Steinkoordinaten]]
Für die Positionierung der Klemmbausteine, die der UR3-Roboter auf einer Platte absetzen soll, wird die Excel-Datei, in der die Steine positioniert sind, benötigt. Diese Datei wird mithilfe einer MATLAB-Funktion eingelesen und ausgewertet. Das Ergebnis der Funktion ist eine Matrix, die so viele Zeilen wie Anzahl an Steinen und fünf Spalten hat. Es ist nicht vorgegeben, wie viele Steine in der Datei enthalten sind, dies wird von der Funktion selbst ermittelt. Abhängig von der Steinnummer, die jedem Stein in der Excel-Datei zugeordnet worden ist, wird die entsprechende Zeile gefüllt. <br>
Von dem jeweiligen Stein wird die Koordinate des Mittelpunktes abgespeichert. In die ersten drei Spalten werden die Koordinatenpunkte x, y und z des jeweiligen Steins an der zugehörigen Steinnummer geschrieben. Für das Anfahren der Noppen muss ein Umrechnungsfaktor ermittelt werden, da in der Excel-Liste mit einem Abstand von 1 gerechnet wurde. Der reale Abstand zwischen den Zwischenräumen ist ca. 8mm (siehe Abbildung 21). Es muss ggf. die y-Koordinate negativ gesetzt werden. Dies ist abhängig von dem Koordinatensystem, in dem sich der Roboter bewegt, und ist sehr einfach in dem Programmcode realisierbar. Die vierte Spalte enthält dann die Ausrichtung des Steins, ist der Stein horizontal („0“) oder vertikal („1“) angeordnet. Die Funktion überprüft abhängig von der ersten „Noppe“, die sie in der Excel-Datei findet, wie die Orientierung der Steine ist. Da die Orientierung des letzten Gelenks <code> .Rx</code>, <code> .Ry</code> und <code>.Rz</code> relativ von der Ausrichtung sind, kann hierüber nur sehr eingeschränkt  die Orientierung des Greifers angegeben werden, dies ist aktuell in dem Programmcode noch nicht implementiert. Da unser Magazin vier Schienen enthält, die mit verschiedenfarbigen Steinen gefüllt ist und das Bild auf der Platte eine bestimmte Anordnung der Farben enthält, steht in der fünften Spalte die Magazinnummer.

Der Rückgabewert der Funktion ist eine Matrix (26x5) mit den Mittelpunktkoordinaten der Steine, Ausrichtung und Magazinnummer (siehe Abbildung 22) und zusätzlich wird noch die Anzahl der Steine in der Excel-Datei zurückgegeben.


<div style="width:1200px; height:270px; overflow:auto; border: 2px solid #088">
<pre>
function [position,Anzahl_Steine] = steinkoordinaten()
    steine = xlsread('Legosteine Positionierung.xlsx');    %Einlesen der Excel-Datei mit den Positionen der Steine und "Legoplatte"
    steinnummer = 0;                                            %Laufvariable fuer die Steine iniitiert
    [i,j] = size(steine);                                       %Groesse der "Legoplatte" auslesen
    steine_gefunden = true;                                     %Boolsche Variable fuer Abbruchbedingung

    while steine_gefunden == true                               %Wiederholen, solange Steine auf "Legoplatte" gefunden werden
        steinnummer = steinnummer + 1;                          %Steine nacheinander in der Matrix "steine" suchen
        for m = 1:i                                             %Zeilen durchgehen 
            for n = 1:j                                         %Spalten durchgehen 
               if steine(m,n) == steinnummer                    %Steinnummer an Position in Array Ueberpruefen, ob die sich dort befindet

                   % Stein liegt horizontal
                   if steine(m,n+2) == steinnummer              %Ueberpruefen, ob Stein horizontal liegt                  
                       %Mittelpunkt der Koordinate des Steins berechnen 
                       %-> fuer Weitergabe an Roboter zum Absetzen des Steins 
                       x = n + 1.5 - 2.5;                             
                       y = m + 0.5 - 2.5;                             
                       ausrichtung = 0; % Stein liegt horizontal, wenn ausrichtung = 0 

                       %Abspeicherung der Koordinaten und Ausrichtung des Stein
                       position(steinnummer,1) = x;
                       position(steinnummer,2) = -y;
                       position(steinnummer,3) = 0;
                       position(steinnummer,4) = ausrichtung;

                   % Stein liegt vertikal 
                   else                                         %Gegenereignis -> Stein muss vertikal liegen                
                       %Mittelpunkt der Koordinate des Steins berechnen 
                       %-> fuer Weitergabe an Roboter zum Absetzen des Steins 
                       x = n + 0.5 - 2.5;                             
                       y = m + 1.5 - 2.5;                             
                       ausrichtung = 1; % Stein liegt vertikal, wenn ausrichtung = 1

                       %Abspeicherung der Koordinaten und Ausrichtung des Stein
                       position(steinnummer,1) = x;
                       position(steinnummer,2) = -y;
                       position(steinnummer,3) = 0;
                       position(steinnummer,4) = ausrichtung;
                   end

                   break;
               end

               if steine(m,n) == steinnummer % for-Schleife fuer n abbrechen, wenn erste Koordinate der Steinnummer gefunden wurde
                   break
               end
            end

             if steine(m,n) == steinnummer % for-Schleife fuer m abbrechen, wenn erste Koordinate der Steinnummer gefunden wurde
                   break
             end
        end

        %am Ende der "Legoplatte" angekommen
        if m == i && n == j                                 
            Anzahl_Steine = steinnummer - 1;                 %Ausgabe der Anzahl der gefundenen Steine
            steine_gefunden = false;                        %Abbruchbedingung fuer while-Schleife
        end
    end

    %Ergaenzung der Matrix fuer Zuordnung der Magazine zu Legosteinnummerentnahme
    for i = 1:Anzahl_Steine
        %Magazin 1/rot
        if i >= 1 && i <= 4
            position(i,5) = 1;
        end

        %Magazin 2/gelb
        if i >= 5 && i <= 8
            position(i,5) = 2;
        end

        %Magazin 3/schwarz
        if i >= 9 && i <= 15
            position(i,5) = 3;
        end

        %Magazin 4/blau
        if i >= 16 && i <= 21
            position(i,5) = 4; 
        end
        
        %die übrigen schwarzen Steine müssen auf die anderen Magazine verteilt werden
        if i >= 22 
            position(i,5) = 1;
         if i >= 22 && i <= 24
            position(i,5) = 1;
        else 
            position(i,5) = 2;
        end
    end  
end
</pre>
</div>
<br clear=all>

=== Auslesen der Realtime-Schnittstelle ===
Für die Auswertung der Roboterbewegung wird die Realtime-Schnittstelle, die kontinuierlich von dem Roboter unter anderem über den [https://www.universal-robots.com/articles/ur/remote-control-via-tcpip/ 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 [https://www.universal-robots.com/articles/ur/remote-control-via-tcpip/ 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 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.

<pre>
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
</pre>

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:
<pre> 
„typecast(uint8([Byte8, Byte7, Byte6, Byte5, Byte4, Byte3, Byte2, Byte1]),'double')“ 
</pre>

Die Zuordnung der Bytes kann dieser Excel-Liste entnommen  werden: [[Datei:RealtimeDaten Bedeutung.xlsx]]<br><br>

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. Dies ermöglicht es, dass mit dem Punktoperator auf die einzelnen Variablen zugegriffen werden kann. Anhand der zuvor verlinkten Excel-Datei ist erkennbar, dass diese Informationen in den Bytes 301 bis 348 stehen. So wird in der Variable <code>realtime</code> 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.

<pre>
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
</pre>
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.

<pre>
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
</pre>

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

=== Berechnung der neuen Positionen für den Roboter ===
[[Datei:Startposition.PNG|300px|thumb|right| Abbildung 23: Definition der Startposition]]
Die Berechnung muss auf Basis der Excel-Datei für die Steinpositionen erfolgen. Diese ist die Grundlage für die neuen Positionen für den Roboter. In den ersten drei Spalten stehen die Koordinatenpunkte für die Positionen der Steinnummern auf der Noppenplatte und in der vierten Spalte ist die Ausrichtung der Steine, ob horizontal oder vertikal, definiert. Die Nummer "0" steht dabei für die horizontale Ausrichtung und die "1" für die vertikale Ausrichtung. 

Zunächst muss eine Startposition für den Roboter definiert werden. Diese wird als "Kalibrierung" des Roboters benötigt. Die Startposition sollte am „Ursprung“ der Noppenplatte, die in der Berechnung der Funktion Steinkoordinaten gewählt wurde, wie in Abbildung 23 erkennbar,  liegen. Da auch ausgehend von dieser Startposition die Koordinatenpunkte aus der Excel-Datei berechnet werden. Die Basis für die Berechnung der neuen x-, y- und z-Koordinate, die das Ergebnis der Berechnung sein müssen, ist ebenfalls die Startposition. Nach aktuellem Stand kann aufgrund der Verwendung der Server-Client Verbindung nicht, wie vorher geplant, die Übergabe von Gelenkwinkeln an den Roboter erfolgen. Mit der Recherche zu der Server-Client Verbindung wurde unter anderem eine Funktion gefunden, die als Eingabeparameter nur die neuen x-, y- und z-Koordinaten und die Rotation, also <code>.Rx</code>, <code>.Ry</code> und <code>.Rz</code>, erhält. Die neuen Koordinatenpunkte werden abhängig von der gewählten Startposition angefahren. Da die Noppenplatte bzw. das Bild nicht dieselbe Ausrichtung des Koordinatensystems wie das "Ansicht"-Koordinatensystem des Roboters hat, müssen die Koordinatenpunkte umgerechnet werden. 

Eine weitere Herausforderung ist, dass die Angabe der Rotation für <code>.Rx</code>, <code>.Ry</code> und <code>.Rz</code> des Gelenks nicht festdefiniert vorgegeben werden kann. Hierfür muss noch eine Lösung gefunden werden. 
<br clear=all>

=== URSim Simulationssoftware ===
Eine Anleitung zur Installation der Simulationssoftware URSim befindet sich unter dem folgenden Link [[Universal_Robots#Simulation_der_UR-Roboter_mittels_.22Offline-Simulation.22|Anleitung URSim]] <ref> [[Universal Robots|Anleitung URSim]] </ref>. Kleine Programmabschnitte können hiermit programmiert und überprüft werden. Diese können somit vorab auf ihre Funktionsfähigkeit getestet werden. Wie die Einstellungen für die Simulation des UR3-Roboters mittels der "Virtuellen Maschine" durchgeführt werden kann, kann in dem Artikel [[Universal_Robots]] nachgelesen werden. Die "Virtuelle Maschine" simuliert das Polyscope und damit die Eigenschaften und Bewegungen eines realen Roboters inklusive der Ausgabe der Realtime-Schnittstelle. Dadurch kann die Interaktion mit dem Roboter realitätsnah auch ohne den Roboter getestet werden. <br>
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 24 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.
[[Datei:URSim.jpg|500px|thumb|left|Abbildung 24: Ansteuerung des Roboters mit URSim]]
<br clear=all>
Herunterladen der Testdatei: [[Datei:Test simulation.m]].

=== Programmierung des Polyscopes ===


Das Polyscope ist die Bedienschnittstelle des UR3, welches mit der Programmiersprache URScript programmiert werden kann. Die hier programmierten Skripte können Befehle einzeln oder in einer kontinuierlichen Folge ausführen. 
Einteilen lassen sich die Skripte in eine Initialisierungssequenz (▼), das Hauptprogramm (▼), Unterprogramme (P) und Threads (▼). Das Polyscope kann nur einen Programmteil auf einmal ausführen, die Taktung liegt bei 500Hz. Somit müssen Programmabschnitte innerhalb von 0,002s verarbeitet sein. Nach dem Ausführen eines Threads/Unterprogramms werden die folgenden Threads mithilfe des [https://www.wirtschaftsinformatik-muenchen.de/wp-content/uploads/Peter%20Mandl/Lehrveranstaltungen/SoSe%2015/Wirtschaftsinformatik/06_CPU_Scheduling_-_Grundkonzepte.pdf Round Robin Verfahrens][https://s3-eu-west-1.amazonaws.com/ur-support-site/18679/scriptmanual_en.pdf (siehe URScript-Hanbuch)] <ref> [https://s3-eu-west-1.amazonaws.com/ur-support-site/18679/scriptmanual_en.pdf]</ref>sortiert. Besteht eine Server-Client Verbindung zwischen dem Polyscope und einem anderen Gerät, ist es nur möglich über '''eine''' Socket-Connection Befehle an das Polyscope zu senden, da sonst das laufende Polyscopeprogramm abbricht, somit können andere Ports des Polyscope nur noch ausgelesen werden, das Senden von Daten an das Polyscope muss vollständig über einen einzigen Port stattfinden. 
Es bietet sich an das Hauptprogramm, welches seine Befehle benutzerunabhängig zyklisch ausführt, zur Organisation der Unterprogramme zu verwenden. Ein Thread wird, ebenso wie das Hauptprogramm, benutzerunabhängig zyklisch ausgeführt und wird hier verwendet, um die Roboterbewegung auszulösen. Unterprogramme werden nur durch das Hauptprogramm oder Threads angestoßen und können dann bestimmte Befehle ausführen. Weitere Hinweise sollten unbedingt aus dem [https://s3-eu-west-1.amazonaws.com/ur-support-site/77327/scriptManual_e-Series_5.9.4.pdf Benutzerhandbuch] <ref>[https://s3-eu-west-1.amazonaws.com/ur-support-site/77327/scriptManual_e-Series_5.9.4.pdf The URScript Programming Language] </ref>zur URScript-Sprache entnommen werden. 


<div style="width:1500px; height:350px; overflow:auto; border: 2px solid #088">
<pre>
   ▼ BeforeStart                                    %% Initialisierungssequenz
     receive_data≔[6,0,0,0,0,0,0]                  %% Leeres Array zum Abspeichern der x,y,z,rx,ry,rz-Koordinaten, Startwert 6 zur Überprüfung der Vollständigkeit der Daten
     Move_To_Pos≔p[0,0,0,0,0,0]                    %% Leeres Array zum Übergeben der x,y,z,rx,ry,rz-Koordinaten an die Bewegungsfunktion im Thread 1
     'Call '
     socket_open("10.0.2.1",33)                     %% Funktion zum Öffnen der Socket-Connection, siehe hier IP-Adresse des virtuellen Ethernetadapters und unbelegten Port 33
     task≔[0,0]                                    %% Variable zur Aufgabenzuweisung 

  ▼ Robot Program                                   %% Hauptprogramm
     'Wait: 0.1'
     task=socket_read_ascii_float(1)                %% Auslesen des Dateneingangs, abspeichern in der Variable task
     If task[1]≟2                                   %% If-Abfrage, je nach Wert der Variable task wird ein bestimmtes Unterprogramm ausgeführt
       Call Position_auslesen
       task≔[0,0]
     ElseIf task[1]≟1
       Call move_robot
     ElseIf task[1]≟3
       Call greifer_auf
     ElseIf task[1]≟4
       Call greifer_zu
     Wait: 0.01

   P  greifer_auf                                      %% Unterprogramm Greifer auf 
     'RG2(40,40,0.0, True , False , False )'           %%URCaps-Code zur Greiferansteuerung 

   P  greifer_zu                                       %% Unterprogramm Greifer zu
     'RG2(12.3,40,0.0, True , False , False )'         %%URCaps-Code zur Greiferansteuerung 

   ▼ Thread_1                                          %% Thread wird ohne Benutzeraufruf ausgeführt, Scheudling anhand von Round Robin Verfahren
     If Move_To_Pos≠p[0,0,0,0,0,0]                     %% Wenn Move_To_Pos nicht leer ist,
       movel(Move_To_Pos,a=0.2,v=0.2,r=0)              %% Führe Bewegungsbefehl aus

   P move_robot                                        %%Unterprogramm zur Einstellung neuer Zielkoordinaten
     receive_data=socket_read_ascii_float(6)           %% Auslesen des Dateneingangs, abspeichern in der Variable receive_data
     If receive_data[0]≠6                              %% Wenn Datenlänge nicht korrekt
       socket_send_string("0")                         %% Sende Meldung über Socket-Conn an Matlab, Matalb bricht dann laufenden Befehl ab 
     Else                                              %% Wenn Datenlänge korrekt
       socket_send_string("1")                         %% Sende Meldung über Socket-Conn an Matlab, Matalb führt dann laufenden Befehl weiter aus
       pointer≔0                                      %% Variable Pointer wird initialisiert und der Wert 0 zugewiesen
       Loop pointer<receive_data[0]                    %% Solange pointer kleiner ist als 6
         Move_To_Pos[pointer]=receive_data[pointer+1]  %% Speichere Wert der Variable receive_data an der Stelle pointer +1 in Variable Move_To_Pos an der Stelle pointer 
                                                       %%(da receive_data[0] = 6 sein muss)
         pointer≔pointer+1                            %% Inkrementieren der Laufvariable pointer
       task≔[0,0]                                     %% Wenn Loop-Bedingung nicht mehr erfüllt, setzte Zuweisungsvariable task gleich Null

  P Position_auslesen
     pose_1=get_actual_tcp_pose()                     %% get_actual_tcp_pose() übergibt die aktuellen x,y,z,rx,ry,rz-Koordinaten des Tool-Center-Points, wird in pose_1 gespeichert
     socket_send_string(pose_1)                       %% pose_1 wird über Socket-Connection an Matlab gesandt

</pre>
</div>
Ordner mit der Datei dazu [[Datei:Greifer 20220113.zip]]
<br clear=all>

:* '''BeforeStart'''

Die Initialisierungssequenz wird verwendet, um globale Variablen vor Programmstart anzulegen, dieses Vorgehen wird seitens UR empfohlen.
task = Organisationsvariable
receive_data = Array zum Abspeichern der von MATLAB übergebenen Bewegungs-/ Neigungskoordinaten
Move_To_Pos = Array in dem die Bewegungs-/ Neigungskoordinaten an den Bewegungsbefehl der Roboters übergeben werden
socket_open(„IPADRESSE“, PORTNUMMER) = Funktion um die Server-Client Verbindung aufzubauen, diese kann ggf. auch in einer Loop ausgeführt werden, falls die Verbindung nicht direkt zu Stande kommt. Hiernach ist eine Socket-Connection zwischen Polyscope und MATLAB aufgebaut

:* '''Robot Program'''

Wird das Hauptprogramm des Roboters ausgeführt, liest es zu Beginn den Dateneingang über die bestehende Socket-Connection aus und speichert ihn in der Variablen „task“ ab. Das Verwenden des Befehls socket_read_ascii_float(1) ist hierbei zu empfehlen. Nun entscheidet das Programm anhand einer If-Abfrage welche der Unterfunktionen ausgeführt wird.

:* '''move_robot'''

Im Unterprogramm move_robot wird wie bei der Variable task der Eingang der Socket-Verbindung ausgelesen, hier jedoch mit sechs Zeichen, welche die x, y, z, rx,ry und rz Koordinaten enthalten müssen, die von MATLAB gesendet werden.  Dies funktioniert, weil MATLAB zuerst über die Socket-Verbindung den Wert „1“ sendet und das Polyscope damit in den Programmteil move_robot springt, wo die nächste Eingabe der Socket-Verbindung zuerst auf ihre Länge geprüft und dann in der Variable receive_data abgespeichert wird.

:* '''Position_auslesen'''

Dieses Unterprogramm ist für den Anwendungsfall nicht notwendig, wird aber übergeben, falls die Verwendung in Betracht gezogen werden soll.

:* '''Thread_1'''

Sobald der Thread_1 an der Reihenfolge ist, wird die Variable Mov_To_Pos in den movel() Befehl eingefügt und der Roboter verfährt.

:* '''Greifer'''

Unterprogramm, welches bei Anstoß aus dem Hauptprogramm den URCap Befehl zur Greiferansteuerung ausführt. Hier ist exemplarisch nur ein Unterprogramm zur Greiferansteuerung eingefügt, es wird jedoch eins zum Öffnen und eins zum Schließen des Greifers benötigt.
<br/>
<br/>
Hier findet sich eine Anleitung, wie ein Polyscope-Programm in die Virtuelle Maschine geladen werden kann, um dies im Vorhinein schon einmal zu testen: [[Datei:Einbinden von Polyscope in Virtuelle Maschine.zip]]

== '''Ausblick''' ==

=== Optimierung des Magazins ===

Da sich der vollständige Aufbau des Magazins V2 aufgrund der fehlenden 3D Druck Teile verzögerte, konnte der Komponententest ebenfalls erst am Ende der Projektzeit durchgeführt werden. Dadurch konnte das beschriebene Problem, welches dieser aufzeigte, nicht mehr ausgebessert werden. 

Ansätze zu Lösung sind:

-	Flacheren Winkel zwischen den beiden Holzplatten – neu drucken einiger Teile notwendig

-	Den Reibungswiderstand der Holzplatten reduzieren, beispielsweise durch Aufkleben von Teflon Band

===  Genaue Berechnung der Steinpositionen für Roboter ===
[[Datei:Skizze Aufbau Tisch.jpg|350px|thumb|right| Abbildung 25: Skizze der Koordinatensysteme auf dem Tisch und Drehmatrix für neues Koordinatensystem]]
Der Abstand zwischen den Punkten der Steine muss noch mit einem Faktor berechnet werden, denn aktuell wird mit der Anzahl und nicht mit einem konkreten Wert gerechnet. Der Abstand zwischen den Noppen beträgt „1“, aber für das Anfahren mit der Funktion ist der Abstand in mm notwendig. Dieser beträgt 8mm. 
Aktuell werden aus der Excel-Datei die Mittelpunktkoordinaten der Steine berechnet. Die Überlegung besteht darin, dass mit der Drehmatrix die Punktkoordinaten der Steinnummern in das Koordinatensystem „Ansicht“ umgerechnet. Abhängig von der Startposition müssen dann die neuen Anfahrpositionen ermittelt werden. Dazu muss die Berücksichtigung mit dem Faktor enthalten sein.
Die Drehmatrix wurde schon aufgestellt, aber noch nicht auf ihre Funktionsweise getestet. Dies müsste im Folgenden noch durchgeführt werden. Die mögliche Funktion ist nachfolgend dargestellt.
In Abbildung 25 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 kann von einem geeigneteren Koordinatensystem von der Noppenplatte in das Koordinatensystem „Ansicht" gedreht werden. Auf die Transformationsmatrix des Koordinatensystems „Ansicht“ kann zugegriffen werden. Diese besteht, wie in Abbildung 18, 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. Durch den SE3 wird eine Darstellung einer 3D-Starrkörperbewegung genutzt, hierdurch können dreidimensionale Bewegungen einfach dargestellt werden. Eine ausführliche Beschreibung eines SE3 und Funktionsweise sind [https://wiki.hshl.de/wiki/index.php/Datei:MATLAB_SE3.pdf hier] zu finden.
<br clear=all>
<pre>
function koord = umrechnung_koord(pos)
    % Drehmatrix von Noppen- in Ansicht-Koordinatensystem
    drehmatrix = [0    -1     0;
                  1     0     0;
                  0     0     1];
              
    % Berechnung Koordinaten in Ansicht-Koordinatensystem
    vektor = [pos(1); pos(2); pos(3)];
    
    koord = drehmatrix * vektor;
    koord = transpose(koord);
end
</pre>
Funktion als Originaldatei: [[Datei:Umrechnung koord.m]]

Das Ergebnis ist ein Array, welches direkt an die Funktion ''moverobot.m'' als Translationswerte übergeben werden kann.

=== Vollständiger Bewegungsablauf ===
[[Datei:Bewegung.jpg|400px|thumb|left|Abbildung 26: Möglicher Bewegungsablauf]] 
Aktuell können die Positionen über dem Magazin angefahren werden. Der vollständige Bewegungsablauf ist nur grob in dem Hauptprogramm beschrieben.

Aktuell ist das MATLAB-Programm in der Lage so mit dem Polyscope zu interagieren, dass die Roboter- und Greiferbewegung gewährleistet ist. Es stellte sich jedoch heraus, dass diese beiden in Kombination zu unerwarteten Bewegungen führten. Werden UR3 und Greifer in größerem zeitlichem Abstand verfahren verschwindet das Problem wieder und beide handeln strikt nach Anweisung. Dies lässt die Schlussfolgerung zu, dass die Daten, die dem Polyscope übergeben werden, nicht immer an ihrem Zielort ankommen. So könnten Inhalte, die für die Polyscope-Variable „task“ bestimmt waren, fälschlicherweise in andere Programmteile eingebunden werden. Dies führt dann zu unvorhergesehenem Verfahren von UR3 und RG2. Der Grund hierfür liegt nach aktuellem Kenntnisstand wahrscheinlich im Threadscheduling des Polyscope, als auch in den Pausenzeiten der Matlab- und Polyscopecodes. Ersteres sollte eingehend studiert werden, um dann eventuelle Änderungen an den Programmen vorzunehmen, letzteres könnte durch Trial and Error zu einer Lösung führen. Jedoch werden auch hierfür Kenntnisse über das vom Polyscope verwendete Round Robin Verfahren dringend empfohlen. Ebenfalls können häufigere Abfragen der Datenübertragung stattfinden und eine Lösung bieten (vgl. moverobotMsg.m), wenn sie in MATLAB und Polyscope zweckgerichtet eingesetzt werden.
<br clear=all>

=== Greifer je nach Anforderung Drehen ===
Wie vorher schon beschrieben, muss die Rotation des Greifers in Abhängigkeit von der Ausrichtung des abzusetzenden Steins (horizontal oder vertikal) bestimmt werden. Dies ist aber leider nicht so einfach möglich, wie zu Anfang gedacht wurde, da die Rotation des Werkzeugs über die Werte <code>.Rx</code>, <code>.Ry</code> und <code>.Rz</code> dem Roboter übergeben werden kann. Aber nach den ersten Versuchen ist dies nicht bei den vertikalen und horizontalen Ausrichtung nicht identisch.

Für die Umsetzung kann diese [https://dof.robotiq.com/discussion/695/help-for-understanding-rx-ry-rz-position-in-universal-robot Internetseite] <ref>[https://dof.robotiq.com/discussion/695/help-for-understanding-rx-ry-rz-position-in-universal-robot Help for Understanding Rx, Ry, Ry position]</ref> hilfreich sind.

== '''Zusammenfassung''' ==
[[Datei:V-Modell Stand UR3.PNG|350px|thumb|right| Abbildung 27: Aktueller Stand im V-Modell]]
Die Verbindung zwischen MATLAB und dem UR3-Roboter kann aufgebaut werden und für den Datenaustausch genutzt werden. Die Realtime-Schnittstelle, die von dem Roboter nahezu mit Echtzeit beschrieben wird, kann zur Überprüfung der Roboterbewegung genutzt werden. So kann sichergestellt werden, dass der Roboter die nächste Ausführung erst nach Stillstand der Gelenke ausführt.

Eine Lösung zur Ansteuerung des Greifers konnte mit der Umsetzung der Server-Client Verbindung realisiert werden. Dies ermöglicht, dass Programmabschnitte, die im Polyscope geschrieben wurden, genutzt werden können. Die Greiferansteuerung über das Polyscope ist einfacher zu realisieren, da dort vorgefertigte Funktionsabschnitte programmiert werden, die bei Bedarf aufgerufen werden können. 

Für die Positionierung der Steine konnte eine Excel-Datei mit der Darstellung der Noppenplatte und dem Setzen der Steine eingebunden werden. Dort werden die Positionskoordinaten, Ausrichtung und Magazinnummer in einer Matrix abgespeichert und können im Weiteren verwendet werden. Die Umrechnung in die passende Größe der Noppenplatte und Umwandlung in das "Ansicht"-Koordinatensystem ist noch nicht implementiert.

Zusammen mit der Server-Client Verbindung, der Nutzung der Realtime-Schnittstelle des Roboters und dem Einlesen der Excel-Datei für die Steinkoordinaten sind nun alle Grundlagen gegeben, sodass ein vollständiger Bewegungsablauf mit dem UR3 geschaffen werden kann. Die finalen Anforderungen für das Absetzen der Klemmbausteine auf der Noppenplatte, sowie die Problematik, der sich beeinflussenden Greifer- und Roboterbewegungen müssen noch gelöst werden. Ebenso kann durch eine weitere Optimierung des Magazins ermöglicht werden, dass der letzte Stein automatisch auf die Entnahmestelle rutschen kann.


Die zuvor genannten und eingebundenen Dateien sind noch einmal zum Herunterladen [https://wiki.hshl.de/wiki/index.php/Datei:Alle_wichtigen_Programme_UR3_WS2021_2022.zip hier] zu finden.

== '''Literaturverzeichnis''' ==
<references />

----
→ zurück zur Seite [[Praktikum Produktionstechnik]]