Universal Robots (UR) an der HSHL

UR3, CB-Serie

Der Roboter ist ein UR3 von Universal Robots. Er verfügt über sechs rotierende Gelenke welche sechs 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 in einer kompatiblen Entwicklungsumgebung. Zur weiteren Ansteuerung besitzt er sowohl 16 digitale als auch zwei analoge Ein- und Ausgänge. Außerdem ist ein RG2 Greifer der Firma OnRobot montiert. Bei diesem handelt es sich um einen elektrischen zwei Finger Greifer mit einer maximalen Greifkraft von 40 Newton.

Technische Daten zu dem Roboter können auf der Internetseite von Universal Robots angefordert werden.

Das Datenblatt des UR3-Roboters kann hier entnommen werden: Datei:Technische-Daten-UR-3.pdf.

UR10, CB-Serie

Ansteuerung der UR-Roboter

MATLAB

Siehe "interface-communication - remote-control-via-tcpip" von Universal Robots

Ansteuerungsmöglichkeiten
Ansteuerungart	Funktionen	Konflikte
Realtime/RTDE	Senden von URScript-Befehlen (z.B. Roboterbewegung) mit Hilfe der Peter Corke Toolbox Gleichzeitiges Auslesen der Realtime/RTDE-Schnittstelle (Erhalt vieler nützlicher Roboterdaten)	Senden von URCaps Befehlen (notwendig für Roboter-Werkzeuge) nicht möglich
Server-Client-Verbindung	Datenaustausch zwischen Polyscope und Matlab (oder anderem Gerät) möglich URCap und URScript-Befehle können im Polyscope geschrieben werden und durch Matlab angestoßen werden (über Variablenaustausch)	Server-Client-Verbindung erlaubt Kommunikation nur über einen unbelegten Port, Realtime und RTDE können also nur noch zum lesen verwendet werden Thread-Scheudling des Polyscope muss bei der Programmierung bedacht werden

Senden von URScript Befehlen Hilfe der Robotics Toolbox über RealtimeSchnittstelle

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

Der Port für die Kommunikation zum Roboter über Realtime ist 30003[1] ^[2]
Die IP-Adresse 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. Diese muss sich am Ende des Hauptprogramms oder mit demselben Namen im gleichen Pfad befinden.

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));

Kommunikation mit dem UR-Controller über das RTDE-Protokoll

Das Real-Time Data Exchange-Protokoll (kurz: RTDE-Protokoll) ermöglicht dem Nutzer die Synchronisation von externen Anwendungen mit dem UR-Controller über eine sog. Transmission Control Protocol/Internet Protocol (kurz: TCP/IP) Verbindung. Somit kann ein Klient-PC, der z.B. über ein Ethernet-Kabel mit dem UR-Controller verbunden ist, in Echtzeit den Roboter bewegen und Zustandsdaten vom Roboter empfangen. Im Dokument "Real_Time_Data_Exchange_(RTDE)_Guide.pdf" ^[3], das von Universal Robots zur Verfügung gestellt wird, ist das gesamte Protokoll beschrieben. Der Datenaustausch wird hierin als Synchronisation bezeichnet und beinhaltet folgende Daten:

Ausgänge (UR-Controller sendet an Klient-PC): Roboter-, Gelenk-, Werkzeug- und Sicherheitsstatus, analoge und digitale Ein-/Ausgänge (engl. inputs/outputs, kurz: I/O) und allgemeine Ausgangsregister
Eingänge (Klient-PC sendet an UR-Controller): Digitale und analoge Ausgänge, allgemeine Eingangsregister

Der Datenaustausch ist in zwei Phasen gegliedert - einen Setup-Prozess und eine Synchronisationsschleife. Im Setup-Prozess muss der Klient-PC die zu synchronisierenden Ein- und Ausgänge festlegen. Dazu muss jeweils eine Setup-Liste mit den Namen der Eingangsfelder und Ausgangsfelder als kommaseparierter String versendet werden. Die Feldnamen müssen dabei genau mit den im Dokument genannten übereinstimmen. Der UR-Controller antwortet nach jeweils erfolgreicher String-Übertragung mit einer Liste von Datentypen der jeweiligen Felder und der Anzahl der Elemente für jedes Feld. Diese Listen werden als Rezept bezeichnet, d.h. es gibt ein Eingangsrezept und ein Ausgangsrezept. Mögliche Felddatentypen, deren elementare Datentypen und die Größe in Bytes zeigt Tabelle 2.

Tabelle 2: RTDE Felddatentypen und deren Bedeutung.
Felddatentyp	Elementarer Datentyp	Anzahl Bytes
BOOL	uint8 (0 = Falsch, alles andere = Wahr)	1
UINT8	uint8	1
UINT32	uint32	4
UINT64	uint64	8
INT32	int32	4
DOUBLE	double	8
VECTOR3D	3 $\:\cdot\:$ double	3 $\:\cdot\:$ 8 = 24
VECTOR6D	6 $\:\cdot\:$ double	6 $\:\cdot\:$ 8 = 48
VECTOR6INT32	6 $\:\cdot\:$ int32	6 $\:\cdot\:$ 4 = 24
VECTOR6UINT32	6 $\:\cdot\:$ uint32	6 $\:\cdot\:$ 4 = 24
STRING	ASCII char array	Anzahl Arrayelemente

Ist der Setup-Prozess abgeschlossen, kann die Synchronisationsschleife gestartet werden. Der UR-Controller sendet dem Klient-PC dann mit gewünschter Übertragungsfrequenz (UR10/CB3: max. $125\,\text{Hz}$ ) die Daten in der gleichen Reihenfolge, wie sie im Rezept festgelegt wird. Ebenso muss der Klient-PC die Eingänge aktualisieren. Eine Nachricht des RTDE-Protokolls hat immer die gleiche Struktur aus Nachrichtenkopf (engl. Header) und -rumpf (engl. Payload). Bei Nachrichten, die im Rahmen des Setup-Prozesses versendet werden, antwortet der UR-Controller, in der Synchronisationsschleife ist das hingegen nicht der Fall. Der Header der Nachricht hat folgenden Aufbau:

Aufbau des Headers einer RTDE-Nachricht.
Feldname	Datentyp
Nachrichtengröße	uint16
Nachrichtentyp	uint8

Mit Nachrichtengröße ist die Anzahl der Bytes der gesamten Nachricht gemeint. Außerdem werden acht verschiedene Nachrichtentypen unterschieden, für die jeweils ein bestimmter Dezimalwert an den UR-Controller gesendet werden muss:

Nachrichtentypen des RTDE-Protokolls.
Nachrichtentyp	Dezimalwert	Bemerkung
Protokollversion anfragen	86	Fragt beim UR-Controller die Nutzung der gewünschten RTDE-Protokollversion an. Möglich sind Version 1 und 2, die sich nur geringfügig unterscheiden. Es wird immer Version 2 genutzt, da diese die aktuellere ist.
UR-Control Version abfragen	118	Version der Software, die auf dem UR-Controller läuft.
Textnachricht senden	77	Der Klient-PC kann Textnachrichten an den UR-Controller senden, die in PolyScope unter dem Reiter \gf{Protokoll} eingelesen werden können.
Datenpaket senden oder empfangen	85	Daten der Rezepte aktualisieren.
Ausgangsrezept erstellen	79	-
Eingangsrezept erstellen	73	-
Übertragung starten	83	Synchronisationsschleife starten.
Übertragung pausieren	80	Synchronisationsschleife pausieren.

Der UR-Controller sollte im Setup-Prozess dann mit genau dem gleichen Nachrichtentyp antworten. In der Synchronisationsschleife werden Ausgänge vom UR-Controller mit der gewählten Übertragungsfrequenz versendet, es kann, aber muss nicht in jedem Zyklus der Nachrichtentyp mit Dezimalwert 85 ausgelesen werden. Eingänge werden ebenfalls mit Hilfe des Nachrichtentyps mit Dezimalwert 85 vom Klient-PC an den UR-Controller gesendet und in entsprechende Register geschrieben. Auch hier kann, aber muss nicht mit der gewählten Übertragungsfrequenz gesendet werden, da die Werte in den Registern des UR-Controllers erhalten bleiben. Fallen also in einem Zyklus oder mehreren Zyklen z.B. keine neuen Positionsdaten an, so werden weiterhin die Daten aus dem letzten Zyklus genutzt und der Roboter würde sich nicht bewegen. Wichtig ist lediglich, dass (Start-) Positionsdaten im ersten Übertragungszyklus einmalig in die Register geschrieben werden, mit denen der UR-Controller anfangs arbeiten kann. Geschieht dies nicht, wird eine Fehlermeldung ausgegeben.

Voraussetzung für das Einleiten des in den Grundlagen erklärten Setup-Prozesses ist eine bestehende TCP/IP-Verbindung zwischen Klient-PC und UR-Controller. Die Verbindung wird laut RTDE-Dokument über Port 30004 hergestellt. Die Umsetzung in MATLAB sieht nach Installation der "Instrument Control Toolbox" wie folgt aus:

function [RTDE] = connectRTDE(robotIP)
    
    % TCP/IP-Objekt erstellen
    RTDE = tcpip(robotIP,30004);
    
    % Verbindung öffnen
    try
        fopen(RTDE);
        disp('RTDE Schnittstelle erfolgreich geöffnet.');
    catch
    	% Bei Fehlschlag Meldung ausgeben
        error('Verbindung mit der RTDE Schnittstelle fehlgeschlagen. IP Adresse des Roboters überprüfen.');
    end

end

Anschließend können die in diesem SVN-Ordner abgelegten Funktionen genutzt werden. Diese müssen teils in einer bestimmten Reihenfolge aufgerufen werden. Zur Veranschaulichung wird der Programmablaufplan (kurz: PAP) in Abbildung 1 herangezogen. Hier ist zu beachten, dass die Funktionen innerhalb des PAPs keine Übergabeparameter haben. Dies ist in der Implementierung anders, die Parameter werden nur aus Platzgründen weggelassen. In der Implementierung sind alle Übergabeparameter und Rückgabewerte der jeweiligen Funktionen präzise beschrieben und können mit dem Befehl "help" im Command Window von MATLAB angezeigt werden. Außerdem werden teilweise innerhalb eines Blocks zwei Funktionen aufgerufen. Für diese Darstellungsweise wird sich entschieden, da die Reihenfolge der Funktionsaufrufe in diesen Blöcken keine Rolle spielt.

Abbildung 1: Programmablaufplan der Kommunikation.

Eingabewerte sind zunächst die Roboter-IP und der RTDE-Port 30004. Danach folgt der Aufbau der TCP/IP-Verbindung zwischen Klient-PC und UR-Controller mit der Funktion connectRTDE.m. Bei erfolgreichem Verbindungsaufbau muss als nächstes die Nutzung der Protokollversion 2 angefragt werden. Wird diese vom UR-Controller akzeptiert, können die Rezepte für Ein- und Ausgänge erstellt werden. Dafür benötigen die Funktionen setupInputs.m und setupOutputs.m einen Vektor aus Strings, die die entsprechenden Aus- und Eingänge enthalten. Wie bereits erwähnt, müssen die im RTDE-Dokument angegebenen Namen genau so verwendet werden. Ein Beispiel für die Vektoren zeigt folgender Codeschnipsel.

% Ausgänge
outputs = ['timestamp', 'actual_TCP_pose'];

% Eingänge
inputs = ['input_double_register_0'];

Wird daraus jeweils ein Rezept erstellt und die Synchronisation mit startTransmission.m gestartet, dann sendet der UR-Controller erst den Zeitstempel und dann die aktuelle Pose des Werkzeugmittelpunkts. Gleichzeitig muss vom Klient-PC mit MATLAB in das input_double_register_0 geschrieben werden. Zum Lesen der Ausgänge wird die Funktion getOutputData.m genutzt und zum Senden der Eingänge die Funktion setInputData.m. Die Synchronisation kann jederzeit durch pauseTransmission.m pausiert und dann wieder neu gestartet werden. Soll die Übertragung vollständig beendet werden, muss die Verbindung mit fclose(); geschlossen werden. Neben den im PAP vorkommenden Funktionen gibt es noch zwei Weitere, die zu jeder Zeit nach Aufruf der Funktion connectRTDE.m aufgerufen werden können. Dabei handelt es sich konkret um sendMessage.m zur Übermittlung einer Nachricht an den UR-Controller sowie um getControlVersion.m zum Abfragen der Softwareversion des UR-Controllers.

Um die Eingänge mit PolyScope auszulesen, muss folgendes Programm geschrieben werden:

 Programm
   VorStart
     pSoll=p[0.666, -0.16395, 0.85496, 1.6317, -3.9392, 1.6317]
     qSoll=get_inverse_kin(p[pSoll[0], pSoll[1], pSoll[2], pSoll[3], pSoll[4], pSoll[5]], get_actual_joint_positions())
     movej(qSoll)
     write_output_integer_register(0,0)
     Meldung
     sync()
   Roboterprogramm
     write_output_integer_register(0,1)
     sync()
     Schleife
       servoj(qSoll,0, 0, 0.008,0.05,500)
   Thread_1
     Schleife
       pSoll[0] = read_input_float_register(0)
       pSoll[1] = read_input_float_register(1)
       pSoll[2] = read_input_float_register(2)
       pSoll[3] = read_input_float_register(3)
       pSoll[4] = read_input_float_register(4)
       pSoll[5] = read_input_float_register(5)
       qSoll=get_inverse_kin(p[pSoll[0], pSoll[1], pSoll[2], pSoll[3], pSoll[4], pSoll[5]], get_actual_joint_positions())
       sync()

Hier wird der TCP zuerst mit movej an eine für die Kraftmessung vorgesehene Sollpose pSoll gefahren, die zuvor mit der inversen Kinematik des Roboters in Gelenkpositionen umgerechnet werden muss (qSoll). Zusätzlich wird ein uint8-Register mit dem Wert 0 beschrieben. Danach wird eine Meldung angezeigt, die den Nutzer auffordert, das MATLAB-Skript zu starten. Wird das gemacht, muss die Meldung mit einem Klick auf "Weiter" geschlossen werden. Das Programm springt dann in den Hauptteil. Hier wird zunächst das uint8-Register auf 1 gesetzt, was MATLAB indiziert, dass Werte übertragen werden können. In der Schleife erfolgt das Anfahren der von MATLAB gesendeten Pose mit dem URScript-Befehl servoj. Die Pose wird parallel zum Hauptprogramm in dem Thread_1 aus den Registern des UR-Controllers ausgelesen und mit der inversen Kinematik des UR10 in Gelenkpositionen umgerechnet. Diese können dann zusammen mit der Zykluszeit von $\Delta t=0{,}008\,\text{s}$ und zwei Parametern lookahead_time und gain, die die Trajektorie glätten, an servoj übergeben werden. Für die lookahead_time und den gain gibt es keine Einstellregeln. Ein Beispiel ^[4] von Universal Robots nutzt die Werte $0{,}05$ und $500$ . Damit können in Tests die gewünschten Trajektorien ruckelfrei abgefahren werden. Die beiden übergebenen Nullen sind für die Geschwindigkeit und Beschleunigung der Bewegung, welche laut Universal Robots aber noch keinen Nutzen haben, also vom Befehl ignoriert werden.

Austauschen von Daten über Server-Client Verbindung

Eine Server-Client Verbindung erlaubt es, dass zwei Geräten untereinander Daten austauschen und diese verarbeiten können. Im Gegensatz zur Nutzung der Realtime-Schnittstelle ist es hier also möglich, aus MATLAB Daten zu senden und diese im Polyscope Skript zu verwenden. Wird der UR3 über die Realtime-Schnittstelle betrieben, können nur Befehle gesendet werden, die unabhängig von einem Polyscope Skript verarbeitet werden.

Um die Server-Client Verbindung aufzubauen ist es notwendig die Rollen „Server“ (in dem Fall MATLAB) und „Client“ (hier das Polyscope) zu vergeben. Dies wird in MATLAB in dem Code eingebunden und vom Polyscope automatisch erkannt. Des Weiteren ist es unbedingt notwendig einen freien, also nicht belegten, Port zur Kommunikation zu wählen, da sich auf einem belegten Port keine neue Verbindung öffnen lässt (Portliste ^[5]) und die (Windows-)Firewall in ihren Werkseinstellungen zu nutzen. Stärkere Firewalls können die Server-Client Verbindung gegebenenfalls unterbinden.

Der Vorteil dieser Verbindungsart besteht darin, dass Skriptbefehle, die über den Port der Realtime-Schnittstelle nicht gesendet werden können, hier im Polyscope-Skript eingebettet werden. Dort wird laufend eine Variable abgefragt, die je nach Wert einen bestimmten Programmteil anstößt und ausführt. Diese Variable kann nun durch MATLAB-Code beliebig oft und in veränderter Weise aufgerufen werden, um bestimmte Funktionen auszuführen. Dadurch können alle notwendigen Funktionen über eine Socket-Connection implementiert werden. Dies ist notwendig, da das Polyscope lediglich über einen Socket gleichzeitig Befehle empfangen, aber über mehrere Daten senden kann. Also muss der Datenaustausch über die Server-Client Verbindung stattfinden, während das reine Auslesen der Realtime-Schnittstelle noch möglich bleibt. Das Senden von Bewegungsbefehlen über diese Art und Weise fällt dann jedoch weg.

UR3

Um eine Server-Client Verbindung aufzubauen, muss zuerst gegeben sein, dass sich beide Geräte im selben IP-Adressbereich finden und per Ethernet-Kabel verbunden sind. Eventuell müssen die IP-Adressen aufeinander abgestimmt werden. Als unbelegter Port wird hier Port_NR = 33 gewählt und als Robot_IP wird, die des Roboters vergeben (es funktioniert sowohl mit dem richtigen Roboter als auch mit der Virtuellen Maschine).

Durch den folgenden Code wird eine Server-Client Verbindung aufgebaut:

 Socket_conn = tcpip(Robot_IP,Port_NR,'NetworkRole','server');

try
    fprintf(1, 'Aufbau der Verbindung mit dem UR3....');
    fopen(Socket_conn); % Verbindung herstellen
catch
    error('Verbindung zum  UR3 nicht herstellbar');
end

fprintf(1, 'Verbindung mit UR3 hergestellt.\n');
pause(2); % warten

Der Befehl Socket_conn = tcpip(Robot_IP,Port_NR,'NetworkRole','server'); gibt MATLAB die Information, sich als Server an das Polyscope zu richten.

Im Polyscope-Skript lautet der notwendige Befehl socket_open(„IPADRESSE“,PORTNUMMER), in dem als IP-Adresse die des Rechners (auf richtigen Ethernet Port achten) und dieselbe Portnummer wie im MATLAB-Code eingetragen werden. Nun sollte die Meldung „Verbindung mit UR3 hergestellt“ im Command Window von MATLAB erscheinen. Es können nun Daten ausgetauscht werden. Der vollständige Polyscope-Code wird im Abschnitt 8.7 Programmierung des Polyscope [2] genauer erläutert.

Simulationssoftware

Um in der Virtuellen Maschine eine Server-Client Verbindung aufbauen zu können sind ebenfalls die beiden Grundbedingungen (passende IP-Adressen und unbelegter Port) zu erfüllen. Der MATLAB-Code bleibt, bis auf eine angepasste IP-Adresse, vollständig erhalten.

Der im Polyscope verwendete Befehl socket_open(„IPADRESSE“,PORTNUMMER) erhält hier, statt der IP-Adresse des Computers, die IP-Adresse des Ethernet-Adapters der VirtualBox. Diese sind über den Windows-cmd Befehl ipconfig zu finden und lautet 10.0.2.1, wenn die VirtualBox nach den Anleitungen der Hochschule ^[6] eingerichtet wurde. Die Virtuelle Maschine über das Windows-cmd Fenster mit dem Windows-cmd Befehl ping 10.0.2.2 anzupingen (IP-Adresse des virtuellen UR3 prüfen), hilft gelegentlich die Verbindung aufzubauen. Dies kann wiederholt durchgeführt werden, falls die Verbindung nach einer gewissen Zeit nicht mehr hergestellt werden kann.

Um geschriebenen Polyscope-Code in der Virtuellen Maschine einzubinden hat es sich als nützlich erwiesen diesen auf einem USB-Stick abzulegen, welcher dann von der Virtuellen Maschine ausgelesen werden kann.

ROS

In diesem Artikel ist die Inbetriebnahme der beiden UR-10 Arme mit Hilfe von ROS beschrieben.

Simulation der UR-Roboter mittels "Offline-Simulation"

Die Software, die auf den Rechnern des Roboters läuft (auf dem Handbediengerät) kann auf jedem beliebigen PC als so genannte "virtuelle Maschine" installiert werden.

Installation

Eine auführliche Anleitung erhalten Sie, wenn Sie im Download-Bereich der UR-Internetseite auswählen:

CB-Series
Software
Offline Simulator
Betriebssystem auswählen, wo die Roboter-Offline-Software laufen soll. Im häufigsten Fall liegt auf Ihrem PC ein Windows-Betriebssystem vor. Installieren Sie sich in diesem Fall die Software VirtualBox und folgenden der Anleitung von UR!

Ergänzung Prof. Göbel 11.5.22: Da dafür nun ein Login erforderlich ist, verwenden wir einheitlich die virtuelle Maschine Nr. URSim_VIRTUAL-3.14.3.1031232. Die Installationsschritte sind hier dargelegt:

VirtualBox installieren [zuletzt getestet: v6.1]
Maschine/neu
Namen beliebig vergeben
Ordner beliebig wählen
Typ: Linux
Version: Ubuntu 32bit
Speichergröße: 768MB
"Vorhandene Festplatte verwenden" auswählen und den entpackten Ordner der virtuellen Maschine verwenden (siehe Download von Prof. Göbel)
Erzeugen!

Diese Art der Offline-Simulation der UR-Roboter wird selbst vom Support von UR verwendet, um alle Roboter in allen Software-Versionen testen und Fragen dazu beantworten zu können!

Einrichtung der Netzwerkverbindung von Host-Rechner und virtuellem PC

Einstellungen

Der Rechner, auf dem die virtuelle Maschine installiert ist, nennt sich "host". Um von diesem "host" aus eine Netzwerkverbindung zum virtuellen Rechner herstellen zu können, wurde dieses Vorgehen erfolgreich getestest:

Einrichtung einer Netzwerkverbindung in den Einstellungen von VirtualBox:
1. Werkzeuge/Netzwerk/Erzeugen
2. Werkzeuge/Netzwerk/Eigenschaften: Netzwerkadresse einstellen.
  Netzwerkadresse einstellen
3. Werkzeuge/Netzwerk/Eigenschaften/DHCP-Server Adresse für DHCP-Server einstellen.
  DHCP-Server einstellen
In den Einstellungen für die virtuelle Maschine muss noch der richtige Netzwerkadapter und der richtige Modus eingestellt werden:
Netzwerkadapter und Modus einstellen

Getestet wird das Ganze, in dem auf dem "host" in einem Kommandofenster (Suchen nach "cmd") der Befehl "ping 10.0.2.15" ausgeführt wird.

Fehlersuche

Sollte es bei dieser Netzwerkverbindung [In Virtual Box "VirtualBox Host-Only Ethernet-Adapter"] beim Start der virtuellen Maschine zu Fehlermeldungen kommen, so kann ein Deaktivieren und anschließenden Aktivieren des Netzwerkadapter [in Windows: Einstellunge/Netzwerk/Adaptereinstellungen] helfen.

Literatur

↑ Eigenes Foto
↑ TCP Ports
↑ Real_Time_Data_Exchange_(RTDE)_Guide.pdf
↑ ServoJ command
↑ [3])
↑ Wiki-Artikel: Universal Robots

[1] Eigenes Foto

[2] TCP Ports

[3] Real_Time_Data_Exchange_(RTDE)_Guide.pdf

[4] ServoJ command

[5] [3])

[6] Wiki-Artikel: Universal Robots

[1]

[2]

[3]

[4]

[5]

[6]

Universal Robots

Inhaltsverzeichnis