Zusammenfassung

Gegenstand dieser Arbeit ist der Entwurf eines Kommunikationsmodells für eine PC-basierte Robotersteuerung und deren Implementierung. Ausgehend von den Grundlagen der Kommunikation werden verschiedene

Entwurfsalternativen erläutert. Die gewählte Alternative besteht in der Implementierung eines Object-Servers, der das Management der gesamten Steuerungskommunikation übernimmt. Als Schnittstelle zum Benutzer wird ein TCP/IP-Interface zur Verfügung gestellt, so dass die Robotersteuerung von beliebigen Computern in einem angeschlossenen Netzwerk in Betrieb genommen werden kann. Die nähere Betrachtung der durch den Object-Server und das TCP/IP-Interface disponiblen Funktionen bildet einen wesentlichen Teil dieser Arbeit. Im letzten Teil der Arbeit werden dann die Modifikationen erläutert, die ausgehend von der vorhandenen Robotersteuerung vorgenommen werden mussten, um das gewählte Kommunikationskonzept zu realisieren. Die Beleuchtung einiger praktischer Aspekte der Benutzung des Roboters schließt die Arbeit ab.

i

Abstract

Objective of this thesis is a communication-model for a PC-based robot control system as well as its realisation.

Based on available communication-alternatives different implementation possibilities will be explained. The resulting Object-Server, which controls and manages the complete communication will be explained in more detail a fterwards. An available usercommunication-interface uses the TCP/IP-protocols to support connections to the „world“. Therefore the robot control system can be used by arbitrary computers in a common network. Finally some modifications of the previously e xisting robot control system will be explained and some technical aspects of using the robot will be stated.

ii

Erklärung

Hiermit erkläre ich, dass die vorliegende Arbeit selbständig, nur unter Verwendung der aufgeführten Hilfsmittel, von mir erstellt wurde.

Braunschweig, den 23.03.2001

iii

Danksagung

Auf diesem Wege möchte ich mich bei allen, die mir das Vollenden dieser Arbeit und damit auch den Abschluss meines intensiven Informatik-Studiums an der Technischen Universität Braunschweig ermöglicht haben, bedanken. Namentlich seien hier, stellvertretend für alle anderen, die besonders an der Schlussphase beteiligten Bernd Finkemeyer, Jörg Hanna und Prof. Dr. F. M. Wahl erwähnt. Neben den am fachlichen Gelingen Beteiligten gilt mein besonderer Dank meinen Eltern, d ie mich geduldig bis zur Beendigung dieser Arbeit mit allerlei Nahrungs- und Genussmitteln versorgt haben und meinen beiden Frauen für ihre finanzielle Unterstützung und dafür, dass ich doch nicht immer spielen musste.

iv

Abbildungsverzeichnis   

Abbildung  1.1 Roboter in Ausgangsstellung  

Abbildung  1.2 Arbeitszelle  

Abbildung  1.3 Steuerungsschrank von MAX  

Abbildung  2.1 Zyklische Blockade  

Abbildung  2.2 TCP/IP-Protokoll-Schichten  

Abbildung  2.3 Drei-Wege-Handshaking- Verfahren  

Abbildung  2.4 IPv4-Header-Aufbau  

Abbildung  2.5 Prozess-Zustands-Übergänge unter QNX  

Abbildung  2.6 Datendurchsatz in Abhängigkeit von der Nachrichtenlänge  

Abbildung  3.1 Architektur der Robotersteuerung  

Abbildung  3.2 Blockade von Regler und Object-Server  

Abbildung  3.3 Nachrichten-Scheduling und Anfragenbearbeitung  

Abbildung  3.4 Object-Server-Initialisierungsdatei  

Abbildung  3.5 Header-Datei der Klasse Message  

Abbildung  3.6 Reihenfolgeerhaltung beim Scheduling  

Abbildung  3.7 Header-Datei der Klasse InitFileEntry  

Abbildung  3.8 Beispiel einer Konfigurationsdatei  

Abbildung  3.9 Datenstruktur der Nachrichtenliste  

Abbildung  3.10 Schematischer Aufbau des TCP/IP-Interface  

Abbildung  3.11 Klassenhierarchie des TCP/IP-Interface  

Abbildung  4.1 Schematischer Aufbau des Treiber-Quell-Programms  

Abbildung  4.2 Benutzeroberfläche nach Initialisierung  

Abbildung  4.3 Benutzeroberfläche nach Empfang der Nachrichtenliste  

Abbildung  4.4 Benutzeroberfläche des interaktiven Bewegungsdialogs  

Abbildung  4.5 Benutzeroberfläche des Mühlespiels  

Abbildung  4.6 Robotergrundposition für das Mühlespiel  

Abbildung  4.7 Datendurchsatz in Abhängigkeit vom Regeltakt  

Abbildung  4.8 Datendurchsatz auf unterschiedlichen Computer-Systemen  

Abbildung  7.1 Vorreferenzierstellung des Basisge lenks (Detail)  

Abbildung  7.2 Vorreferenzierstellung des Ellenbogengelenks (Detail)  

Abbildung  7.3 Vorreferenzierstellung des Schulterge lenks (Detail)  

Abbildung  7.4 Vorreferenzierstelung des Ellenbogen- und Schultergelenks  

v

1  Einleitung  1

1.1  Hardware / Betriebssystem  2

2  Grundlagen  4

2.1  Client-Server Kommunikation  4

2.1.1  Blockade/Verklemmung  6

2.2  TCP/IP  7

2.3  QNX-Inter-Prozess-Kommunikation  10

3  Architektur der Robotersteuerung  13

3.1  Object-Server  13

3.1.1  Nachrichten-Scheduling  18

3.1.1.1  Motivation  18

3.1.2  Anfragenbearbeitung  21

3.1.2.1  Motivation  21

3.1.3  Limitierung der Nachrichtenbenutzung  22

3.1.3.1  Motivation  22

3.1.4  Nachrichtenformat  23

3.1.5  Konfigurationsdatei  26

3.1.6  Object-Server Nachrichten  27

3.1.7  Klassenhierarchie  30

3.1.7.1  Die Klasse Message  31

3.1.7.2  Die Klasse connection  37

3.1.7.3  Die Klasse Scheduler  39

3.1.7.4  Die Klasse Requests  42

3.1.7.5  Die Klasse Table  43

3.1.7.6  Die Klasse ActionPool  45

3.1.7.7  Die Klasse InitFileEntry  46

3.2  Datenstrukturen  50

3.3  TCP/IP Interface  54

4  Anwendungen  56

4.1  Modifikation der vorhandenen Steuerung  57

4.1.1  Treiberanpassung  57

4.1.2  Regleranpassung  62

4.2  Eine Benutzeroberfläche  64

4.3  Leistung des Object-Server  72

vi

5  Ausblick  74

6  Literatur  75

7  Anhang  76

7.1  Technische Daten Roboter  76

7.1.1  Referenzierung  76

7.1.2  Kalibrierung  80

7.2  Probleme  80

7.3  Zero  81

7.4  Nachrichtenliste  82

7.4.1  Object-Server  82

7.4.2  Regler  82

7.4.3  Treiber  85

7.5  Programmerzeugung  87

vii

1 Einleitung

Die vorliegende Arbeit entstand im Rahmen meines Informatikstudiums an der Technischen Universität Braunschweig. Gegenstand dieser Arbeit ist eine Robotersteuerung für die am Institut für Robotik und Prozessinformatik (iRP) vorhandenen manutec r2 Roboter. Diese wurden zuvor mit einer im Laufe mehrerer wissenschaftlicher Arbeiten am Institut entwickelten, offenen transputerbasierten Robotersteuerung gesteuert. Das offene Konzept dieser Steuerung ermöglichte eine einfache Untersuchung neuer Regel- und Programmierkonzepte. Da, u.a. bedingt durch den hohen Preis von Transputern und die immer größer werdende Leistungsfähigkeit von Standard PCs, die Forschung auf dem Gebiet der Transputer eingestellt wurde, hat man auch am iRP die Weiterentwicklung der tranputerbasierten Steuerung zugunsten der Neuentwicklung einer auf einem Standard PC basierenden, offenen Steuerung aufgegeben. Nachdem sich Windows NT als Betriebssystem für diese harte Echtzeitaufgabe als ungeeignet erwiesen hat, wurde als Plattform für diese Aufgabe das Echtzeitbetriebssystem (engl. Real Time Operating System RTOS) QNX gewählt.

Auch die neue Steuerung soll offen für Untersuchungen verschiedener Regel- und Programmierkonzepte sein und wurde konzeptionell besonders im Hinblick auf universelle Einsetzbarkeit, Skalierbarkeit und preiswerte Realisierung optimiert. Die Grundlagen für die Umsetzung dieses Konzeptes wurden mit den Arbeiten von André Schröder (Anpaßbaugruppe → [2]) und Jörg Hanna (Regler und Treiber → [3]) geschaffen. Mit dieser Arbeit und der Arbeit von Holger Ratke wurden diesen Grundlagen um ein allgemeines Kommunikationsmodell und eine Windows NT Benutzerschnittstelle erweitert. Bevor neben der zugrundeliegenden Steuerungsarchitektur die zentralen Komponenten in Kapitel 3 und 4 erläutert werden, möchte ich noch kurz die Hardware der implementierten Steuerung vorstellen und in Kapitel 2 näher auf einige der erforderlichen Grundlagen eingehen. Den Abschluß bilden die Kapitel 5, 6 und 7, die außer einem Ausblick auf weitere Arbeiten die Literaturliste und den Anhang umfassen.

1

1.1 Hardware / Betriebssystem

Der manutec r2 Roboter (MAX → Abbildung 1.1), Baujahr 1990, befindet sich mit zwei weiteren baugleichen Robotern auf der gleichen Arbeitsplattform ( Abbildung 1.2), ist jedoch zurzeit als einziger funktionsfähig. Der Roboter wird von einer analogen Leistungselektronik

einem LINUX und einem

SOLARIS-System kompiliert und gestartet. Dabei zeigte sich unter anderem der in Abbildung 4.8 dargestellte Unterschied im Leistungsvermögen der drei Test-Computer, aber auch einige Plattformunterschiede, darin resultierten, dass das endgültige verschiedene nicht POSIX-konforme Funktionen des

Betriebssystems QNX nutzt, die bei eventuellem späteren Wechsel des Betriebssystems

2

angepasst werden müssen. Von den drei getesteten Betriebssystemkandidaten erwies sich QNX jedoch als das am besten geeignete System für die Regelungsaufgabe.

2 Grundlagen

Die Grundlagen für das Verständnis der mit der implementierten Robotersteuerung verbundenen Probleme sollen in diesem Kapitel beleuchtet werden. Nach der allgemeinen Erläuterung der Client-Server-Kommunikation wird die Internet-Protokollgruppe TCP/IP beschrieben. Den Abschluß des Kapitels bildet die Vorstellung der Inter-Prozess-Kommunikation unter QNX.

2.1 Client-Server Kommunikation

Zu den wichtigsten Vorgängen im Rahmen der Informationsverarbeitung zählt der Datenaustausch bzw. die Datenübermittlung zwischen verschiedenen

Kommunikationspartnern. Diese Datenübermittlung kann auf verschiedene Arten erfolgen; „bedrucktes Papier von A nach B transportieren“ und „Speicherbereiche kopieren“ seien hier als zwei Beispiele aufgeführt. Generalisierend kann man - bei der Kommunikation zwischen zwei Partnern - einem der Kommunikationspartner die Rolle des „Informationskonsumenten“ (Client) und dem anderen die Rolle des „Informationslieferanten“ (Server) zuordnen. Dieses Kommunikationsmodell wird auch als Client-Server-Modell bezeichnet. Auch in der vorliegenden Arbeit wurde zur Kommunikation das Client-Server-Modell (bis auf zwei Ausnahmen, die später noch erläutert werden) gewählt. Ein Teil der Kommunikationspartner

- die Clients - nutzt also Dienste, die ein anderer Teil der Kommunikationspartner - die Server - zur Verfügung stellt. Vorteile dieser Aufteilung sind

1. die Unmöglichkeit zyklischer Verklemmungen (→ Abbildung 2.1),

2. die erhöhte Systemsicherheit durch Trennung der meist privilegierten Server von den nicht-privilegierten Clients und

3. die gute Wartbarkeit bzw. relativ einfache Implementierung der einzelnen Partner. Zu 1.: Die Verklemmungsfreiheit ergibt sich direkt daraus, dass Kommunikation immer nur zwischen zwei Partnern abläuft, von denen einer nur Dienste anbietet und der andere nur Dienste in Anspruch nimmt, damit ist die in der folgenden Abbildung dargestellte Situation ausgeschlossen.

4

Derartige zyklische Verklemmungen sind insbesondere problematisch, wenn sie unter Beteiligung von mehr als zwei Prozessen stattfinden, da in diesem Fall keiner der beteiligten Prozesse in der Lage ist das Vorliegen einer Verklemmung zu erkennen. Zu 2.: Die Server greifen im allgemeinen auf Systemresourcen zu, deren Benutzung besonderer Privilegien bedarf um die Systemsicherheit gewährleisten zu können (z.B. Zugriffe auf den Massenspeicher). Eine Aufhebung der T rennung der Clients und der Server würde dazu führen, dass jeder ‚kombinierte Client‘ alle Systemresourcen benutzen können muss um seine Aufgabe verrichten zu können. Das bedeutet natürlich auch, dass er gewollt oder ungewollt die gesamte Systemintegrität korrumpieren kann. Bei einer Trennung in Clients und Server ist es die Aufgabe der Server dies zu verhindern. Zu 3.: Zur Wartung des Systems ist es nicht erforderlich das Gesamtsystem zu betrachten, sondern es genügt einzelne Partner, die über wohldefinierte Schnittstellen kommunizieren, zu untersuchen. Ausserdem ist die Entwicklung der beteiligten Clients und Server einfach, da keine Untersuchungen in Bezug auf Blockaden vorgenommen werden müssen. Der prinzipiell verklemmungsfreie Betrieb (siehe 1.) macht derartige Untersuchungen überflüssig.

Zum Abschluss sollen einige Beispiele für denkbare Client-Server-Modelle. Sie sind nicht ausschließlich auf den Kommunikationsbereich bezogen:

• Tankstellen (Server für Benzin) - Autofahrer (Client, der Benzin konsumiert); solange der Server in der Lage ist seinen Dienst zu erfüllen gibt es keine Blockaden,

• „Angerufener Telefonkunde“ (Server für den Anruf) - „Anrufender Telefonkunde“ (Client für den Anruf),

• ein Internet-Host ( →) der „HTML-Seiten zur Verfügung stellt“ ¹ - ein Web-Browser, der auf einem Internet-Host läuft,... .

¹ “HTML-Seiten zur Verfügung stellt” ist in Anführungszeichen gesetzt, da ein Internet-Host eigentlich nicht

primär diese Seiten zur Verfügung stellt, sondern die Möglichkeit eines Verbindungsaufbaus entsprechend

einem bestimmten Protokoll. Diese Verbindung kann dann genutzt werden um HTML-Seiten zu empfangen.

5

2.1.1 Blockade/Verklemmung

Als Blockade (engl. deadlock) wird ein Systemzustand bezeichnet, in dem die beteiligten Prozesse sich gegenseitig durch Benutzung bestimmter Ressourcen blockieren. In Abbildung 2.1 ist beispielhaft ein (fehlerhaftes) System aufgeführt, das dadurch in einen blockierten Systemzustand gelangt ist, dass der eine Partner seine Aufgabe nur unter Benutzung einer Ressource des jeweils anderen Partners verrichten kann. In dem vorliegenden Fall ist es für die beiden Prozesse möglich zu erkennen, dass eine Blockade vorliegt. Wenn jedoch mehr als zwei Prozesse am Zustande kommen einer Blockade beteiligt sind ist dies nicht mehr der Fall. Die auf dem Object-Server basierende Robotersteuerung nutzt hauptsächlich die Nachrichten-Ressourcen des QNX-Steuerungscomputers. Aus diesem Grund waren Blockaden durch das gegenseitige Senden von Nachrichten zwischen zwei Prozessen das Hauptproblem. D er Object-Server ist zurzeit als Kombination von Client und Server in puncto Nachrichtenversand ausgelegt. D.h. für Prozesse die Funktionen der Robotersteuerung benutzen wollen tritt der Object-Server als Server auf, für die Server-Prozesse der Steuerung tritt der Object-Server hingegen als Client auf. Sofern kein anderer Prozess gleichzeitig Server und Client ist führt dies nicht zu Blockaden, da Kommunikation in diesem Fall unter Beteiligung von genau drei Partnern statt findet. Diese Partner bauen aber k eine zyklische Verbindung auf. Im Gegensatz zu diesem „idealen“ Modell sind bei der implementierten Robotersteuerung, die auf der Arbeit von Jörg Hanna [3] basiert, der Regelungsprozess genauso wie der Object-Server Kombinationen aus Client und Server. Eine Strategie zur Beseitigung der damit verbundenen, unvermeidlichen gegenseitigen Blockaden von Object-Server und Regler ist aus diesem Grund unabdingbar. Daher wird diese Problematik im Zusammenhang mit dem Object-Server (→ 3.1 Object-Server) noch einmal aufgegriffen.

6

2.2 TCP/IP

Zur Steuerung des Roboters wurde eine Microsoft Windows Oberfläche, aufgrund der Möglichkeit zur intuitiven Benutzerführung, entworfen und implementiert. Die

Kommunikation mit dem Regelungscomputer findet unter Benutzung der TCP/IP Protokolle statt ( à [7] und [8]; 3.3 TCP/IP Interface). Diese Standardprotokolle werden zur Datenübertragung zwischen Computern oder allgemeiner Hosts benutzt und sollen an dieser Stelle kurz eingeführt werden, da sie insbesondere für die in 3.3 TCP/IP Interface erläuterte TCP/IP-Schnittstelle von besonderer Bedeutung sind.

Die Übertragung der Daten findet auf den einzelnen Hosts in vertikaler Richtung von einer Protokollschicht zur nächsten statt ( Abbildung 2.2). Logisch wird diese Art der Kommunikation so interpretiert, dass sie direkt zwischen den gleichen Protokollebenen auf den beteiligten Hosts stattfindet. Physikalisch hingegen werden die Daten erst auf der tiefsten Ebene über ein die Hosts verbindendes Medium übertragen.

Aufgrund des geschichteten Aufbaus der Übertragungsprotokolle nennt man diese Anordnung auch Protokollstapel bzw. Protocol-Stack.

7

Das Transmission Control Protocol, TCP, ist ein auf Schicht 3 angesiedeltes zuverlässiges und verbindungsorientiertes Protokoll. Um die Zuverlässigkeit zu gewährleisten wird der dem TCP von der darüberliegenden Anwendungsschicht übergebene Datenstrom in einzelne Segmente zerlegt und mit Hilfe eines Positive Acknowledgement with Retransmission ( PAR) genannten Mechanismus übertragen. Dabei wird jedes einzelne Segment solange erneut übertragen, bis der Sender für dieses Segment eine positive Bestätigung erhalten hat. Da TCP zu Beginn jeder Kommunikation eine logische Host zu Host Verbindung aufbaut ist es ein verbindungsorientiertes Protokoll. Jede Verbindung zweier Hosts wird dabei durch so genannte Socket-Paare identifiziert. Eine Socket ist eine Kombination aus der Adresse des Hosts (z.B. IP-Adresse) und einer Port-Nummer. Über das so definierte Port wird auf dem Host der Prozess adressiert mit dem kommuniziert werden soll. Bei diesen Ports handelt es sich nicht um physikalisch vorhandene Ausgänge, sondern um ein gedachtes Konstrukt. TCP kann 65536 verschiedene Ports benutzen von denen 1024 für bestimmte Prozessarten fest vergeben sind (well known ports). Ein Socket-Paar, also eine Kombination aus zwei Host-Adressen und zwei Port-Nummern, definiert eindeutig eine Verbindung zwischen zwei Computern/Hosts mit den zugehörigen Prozessen. Mit einem so genannten Drei-Wege-Handshaking-Verfahren werden beim Verbindungsaufbau Kontrollinformationen zwischen den Kommunikationspartnern

übertragen ( Abbildung 2.3). Der die Verbindung initiierende Partner (Host A) sendet dabei die Verbindungsanforderung. Diese V erbindungsanforderung ist ein Segment, bei dem im Header das SYN-Bit gesetzt ist und das eine Sequenznummer enthält mit der Host A seine Segmente zu nummerieren beginnt. Die Anwort des die Verbindung entgegen nehmenden Partners (Host B) ist ein Segment in dem die Header-Bits SYN und ACK gesetzt sind. Dieses Segment enthält außerdem die Bestätigungsnummer mit der Host B das erste empfangene Segment bestätigen wird. Das Ende dieses Drei-Wege-Handshaking-Verfahrens markiert dann Host A mit der Sendung eines Segments bei dem das Header-Bit ACK gesetzt ist. Mit

diesem Segment bestätigt Host A den Empfang der initialen Bestätigungsnummer von Host B. Außerdem enthält dieses Segment die ersten zu übertragenden Daten.

Abbildung 2.4: IPv4 Header-Aufbau

ermittelt dazu den nach

bestimmten Kriterien besten Weg. Dieser Vorgang wird als Routing bezeichnet. IP überträgt die Daten in Form von Paketen bestimmter Länge, die von dem darüberliegenden TCP entsprechend bereit gestellt werden müssen. Diese Pakete werden vom IP mit einem Header versehen, der verschiedene Kontrollinformationen enthält ( Abbildung 2.4). Zurzeit wird meist der Header der Version 4 des IP benutzt. Dieser enthält 32-bit Host-Adressen, es können also etwa vier Milliarden verschieden Computer adressiert werden. In der Entwicklung befindet sich aber bereits IP Version 6, das einen Header mit 128-bit Adressen vorsieht - also etwa 57000 IP-Adressen pro µg der Erdmasse. Aufgrund der Erweiterbarkeit des IP-Headers (Feld IHL=IP Header Length) wird IPv6 zum aktuellen IPv4 kompatibel sein. (→ [7] und [8])

9

2.3 QNX-Inter-Prozess-Kommunikation

Als letzter Teil dieses Kapitels soll an dieser Stelle noch die Inter-Prozess-Kommunikation (engl. Inter-Process-Communication IPC) des Betriebssystems QNX erläutert werden, da auch sie eine wesentliche Basis für die vorliegende Arbeit darstellt. Die Robotersteuerung basiert auf dem Nachrichtenaustausch zwischen Prozessen insbesondere auf dem QNX-Steuerrechner. Zwei Möglichkeiten des Nachrichtenversands werden daher im folgenden eingeführt. Basis der Interprozesskommunikation ist bei QNX und auch bei dessen Nachfolger QNX Neutrino der im Micro-Kernel ² eingebundene Nachrichtenversand (vgl. hierzu [3] S.8ff, [4] S.11ff, [5] S.17ff und [6]). Zur Verwendung dieser Funktionalität stehen bei der Betriebssystem/Compiler-Kombination QNX 4.25/WATCOM C++ 10.6 die nicht POSIX-konformen Funktionen send, receive und reply zur Verfügung. Die Funktion send blockiert den sendenden Prozess, versetzt ihn also in den Zustand SEND-BLOCKED. Der als Parameter übergebene Speicherbereichszeiger verweist dabei auf den Speicherbereich aus dem die Daten übertragen werden. Die Funktion receive suspendiert die Prozessausführung des aufrufenden Prozesses ebenso wie die Funktion send, versetzt den Prozess jedoch in den Zustand RECEIVE-BLOCKED. Liegt für den receive aufrufenden Prozess eine Nachricht vor, so wird dieser wieder „aufgeweckt“ und die Nachricht wird in den Speicherbereich kopiert, auf den der als Parameter übergebene Zeiger zeigt. Der entsprechende Sendeprozess wird durch dieses receive in den Zustand REPLY-

² AlsKernel wird der Teil eines Betriebssystems bezeichnet, der die Grundfunktionalität zur Disposition stellt.

Dieser kann je nach Umfang der Funktionalität sehr umfangreich werden. Bei QNX und QNX Neutrino wird

mit dem Kernel nur ein sehr geringer Funktionalitätsumfang realisiert, daher ist der Kernel dieser Systeme

sehr klein und man spricht von einem Micro-Kernel.

10