Ansteuerung des UR3 Roboters mit Matlab und URSim mittels Realtime Schnittstelle

→ zurück zur Seite Praktikum Produktionstechnik

Autor: Jan Pinter und Rina Mucaj
Betreuer: Prof. Dr. Mirek Göbel

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.

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 unser Projekt angewandt. Dadurch konnte eine konkrete Planung und gute Struktur des Projektes geschafft werden.

Abbildung 2: Das V-Modell

Anforderungsdefinition

In der Anforderungsliste in Abbildung 3 wurden die Anforderungen für das Projekt definiert.
Diese sind unterteilt in:

• Funktion
• Aufbau
• Software / Werkzeuge
• Dokumentation

Abbildung 3: Anforderungsliste

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

Funktionaler und technischer Systementwurf

Mithilfe vom funktionalen (schwarz) und technischen Systementwurf (orange) (siehe Abbildung 4) konnten wir genau das Verhalten des Roboters darstellen. Der UR3 Roboter muss nach einer erfolgreichen Ethernet-Verbindung mit der Matlabsteuerung erstmal zu einer Startposition fahren. Durch Anfahren der Sicherheitspositionen und Einstellung der Geschwindigkeit nimmt er die Legoteile aus dem Magazin ab und platziert diese auf die Legoplatte.

Abbildung 4: Funktionaler und technischer Systementwurf

Der Funktionale und technische Systementwurf kann hier heruntergeladen werden: Datei:Funktionaler und Technischer Systementwurf UR3.xlsx

Komponentenspezifikation

Bei der Komponentenspezifikation wird für jede Komponente die Aufgabe, das Verhalten, der innere Aufbau und Schnittstelle zu anderen Teilsystemen beschrieben. Die Komponentenspezifikation kann hier heruntergeladen werden: Datei:Komponentenspezifikation UR3.xlsx

CAD-Konstruktion des Magazins

Das Magazin in Abbildung 5 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 6). Damit dies gewährleistet werden kann, müssen in das gedruckte Magazin zwei zusammengebaute Legosteine wie in Abbildung 7 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 5: CAD-Zeichnung des Magazins

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

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

Das CAD Modell vom Magazin kann hier heruntergeladen werden: Datei:MagazinCAD.SLDPRT

Programmierung

Bei der Programmierung wurden die Bausteine für die Matlabsteuerung implementiert. Die unteren Abschnitte beziehen sich grundsätzlich auf die Programmierung als Schritt des V-Modells.

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

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

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. Die Transformationsmatrix ist in Abbildung 8 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,Z Koordinaten abgelesen werden.

Abbildung 8: Die Transformationsmatrix

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

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 9 aussehen (BytesInRange sind die zugehörigen Bytes aus der TCP Liste, die hier als feste Werte eingetragen sind):

Abbildung 9: 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 folgendem Link zu finden: Anleitung URSim
Ist die Verbindung mit der richtigen IP gewählt, lässt sich auch ein Befehl aus Matlab an die Virtuelle Maschine des URSim senden. In Abbildung 10 auf der rechten Seite ist das Matlab-Programm zu sehen. Der Befehl wird hier 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 10: 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 11) noch eine Anpassung vorgenommen werden:

Abbildung 11: 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 12). 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 12: 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 13: Möglicher Bewegungsablauf

In Abbildung 13 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 14: Lineare Bewegungen in Polyscope und Auslesen der Gelenkwinkel

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 14 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 15 umgewandelt werden. Diese können nun direkt im Hauptprogramm eingetragen werden.

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

• 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.

Literaturverzeichnis

→ zurück zur Seite Praktikum Produktionstechnik