Kommunikationsmodell einer PC-basierten Robotersteuerung


Mémoire (de fin d'études), 2001

96 Pages, Note: 1,0


Extrait


Inhalt

1 Einleitung
1.1 Hardware / Betriebssystem

2 Grundlagen
2.1 Client-Server Kommunikation
2.1.1 Blockade/Verklemmung
2.2 TCP/IP
2.3 QNX-Inter-Prozess-Kommunikation

3 Architektur der Robotersteuerung
3.1 Object-Server
3.1.1 Nachrichten-Scheduling
3.1.1.1 Motivation
3.1.2 Anfragenbearbeitung
3.1.2.1 Motivation
3.1.3 Limitierung der Nachrichtenbenutzung
3.1.3.1 Motivation
3.1.4 Nachrichtenformat
3.1.5 Konfigurationsdatei
3.1.6 Object-Server Nachrichten
3.1.7 Klassenhierarchie
3.1.7.1 Die Klasse Message
3.1.7.2 Die Klasse connection
3.1.7.3 Die Klasse Scheduler
3.1.7.4 Die Klasse Requests
3.1.7.5 Die Klasse Table
3.1.7.6 Die Klasse ActionPool
3.1.7.7 Die Klasse InitFileEntry
3.2 Datenstrukturen
3.3 TCP/IP Interface

4 Anwendungen
4.1 Modifikation der vorhandenen Steuerung
4.1.1 Treiberanpassung
4.1.2 Regleranpassung
4.2 Eine Benutzeroberfläche
4.3 Leistung des Object-Server

5 Ausblick

6 Literatur

7 Anhang
7.1 Technische Daten Roboter
7.1.1 Referenzierung
7.1.2 Kalibrierung
7.2 Probleme
7.3 Zero++
7.4 Nachrichtenliste
7.4.1 Object-Server
7.4.2 Regler
7.4.3 Treiber
7.5 Programmerzeugung

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 Basisgelenks (Detail)

Abbildung 7.2 Vorreferenzierstellung des Ellenbogengelenks (Detail)

Abbildung 7.3 Vorreferenzierstellung des Schultergelenks (Detail)

Abbildung 7.4 Vorreferenzierstelung des Ellenbogen- und Schultergelenks

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 WindowsNT 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 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 gesteuert, die über eine Anpaßbaugruppe (® [2]) und eine Interface-Karte der Firma Vigilant mit dem Steuerungscomputer verbunden ist. Der Steuerungscomputer ist ein Standard PC mit einem 400MHz Intel Celeron Prozessor und 128MByte RAM, auf dem das Betriebssystem QNX installiert ist. Über eine 10 Mbit Ethernetverbindung ist der Steuerungscomputer via TCP/IP mit einem Windows NT-PC verbunden, der die Funktionalität der Benutzeroberfläche zur Verfügung stellt. In Abbildung 1.3 ist der Steuerungsschrank zu sehen. Die Software wurde möglichst POSIX-konform implementiert. Die Kommunikation wurde sowohl auf dem QNX-System als auch auf einem LINUX und einem SOLARIS-System kompiliert und gestartet. Dabei zeigte sich unter anderem der in Abbildung 4.8 dargestellte Unterschied im Leistungs-vermögen der drei Test-Computer, aber auch einige Plattformunterschiede, die darin resultierten, dass das endgültige Programm verschiedene nicht POSIX-konforme Funktionen des Betriebssystems QNX nutzt, die bei eventuellem späteren Wechsel des Betriebssystems angepasst werden müssen. Von den drei getesteten Betriebssystemkandidaten erwies sich QNX jedoch als das am besten geeignete System für die Regelungsaufgabe.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.3: Steuerungsschrank des Roboters MAX

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.

Abbildung in dieser Leseprobe nicht enthalten

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.

Abbildung in dieser Leseprobe nicht enthalten

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 Trennung 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“[1] – ein Web-Browser, der auf einem Internet-Host läuft,

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

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.

Abbildung in dieser Leseprobe nicht enthalten

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.

Abbildung in dieser Leseprobe nicht enthalten

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

Das Internet Protocol, IP, ist ein Protokoll der Schicht 2. Es übernimmt die Aufgabe die Daten von einem Punkt zum anderen zu leiten und 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 mg der Erdmasse. Aufgrund der Erweiterbarkeit des IP-Headers (Feld IHL=IP Header Length) wird IPv6 zum aktuellen IPv4 kompatibel sein. (® [7] und [8])

Abbildung in dieser Leseprobe nicht enthalten

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[2] 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-BLOCKED versetzt, ist also immer noch blockiert. Um den sendenden Prozess wieder zu aktivieren muss der empfangende Prozess noch die Funktion reply aufrufen. Mit Hilfe dieser Funktion können wiederum Daten vom Empfänger zum Sender übertragen werden. Dies kann zum Beispiel zur Beantwortung einer Nachricht ausgenutzt werden. Das sich aus diesen Aufrufen ergebende Zustandübergangsdiagramm ist in Abbildung 2.5 zu sehen.

Abbildung in dieser Leseprobe nicht enthalten

Zunächst erschienen die eben beschriebenen Funktionen zur Benutzung im Object-Server als ungeeignet, da es jedem Prozess im System möglich ist den Object-Server auszuschalten, indem vergessen wird die Funktion reply aufzurufen. Daher wurden auch Funktionen untersucht, die den Datenaustausch mit Hilfe so genannter Message-Queues ermöglichen. Für Message-Queues steht ein nicht blockierender Sendebefehl zur Verfügung. Leider wird diese prinzipielle Blockadefreiheit nur dadurch erreicht, das ein neuer Message-Queue-Prozess gestartet wird, der die oben beschriebenen, normalen Funktionen nutzt und einfach direkt nach dem Aufruf der Funktion receive die Funktion reply aufruft. Damit ist zwar die Blockadefreiheit für den Sender gewährleistet, jedoch wird diese nur auf Kosten eines wesentlich geringeren Datendurchsatzes erreicht. Lag der Datendurchsatz bei Verwendung der Standard Funktionen auf dem Steuerungsrechner noch bei etwa 6MB/s für Nachrichten mit einer Länge von 90 Bytes (® Abbildung 2.6), so nahm er bei Benutzung der Message-Queue Funktionen auf nur ca. 150kB/s ab. Diese Datentransferrate war aber für die Regelung des Roboters inakzeptabel gering, so dass im Object-Server die Funktionen send, receive und reply Verwendung fanden. Um die Regelung dennoch auch gegenüber schlecht programmierten Prozessen robust zu machen, wurde beim Senden des Object-Servers ein Timeout eingefügt. Dieser liegt zurzeit bei 3ms und ist damit ein Kompromiss zwischen der Notwendigkeit ständig Nachrichten für den laufenden Regelungsprozess übertragen zu müssen und dem Einräumen der maximalen Zeit, die auf die Reply-Nachricht gewartet wird. Dieser Timeout hat zur Folge, dass die Regelung bis zu maximal 3ms ausfallen kann – sofern nicht andere Prozesse durch ihre Aktivität eine größere Pause erzwingen (z.B. erfordert das Laden eines Prozesses von der Festplatte, seine Initialisierung und der Start dieses neuen Prozesses Betriebssystemaktivität, die im Testbetrieb regelmäßig dazu führte, das die Regelung des Roboters länger aussetzte als es die eingestellte Watchdog-Zeit von 50ms erlaubte und der Roboterbetrieb somit unterbrochen wurde). Durch diesen Timeout wird auch eine sehr einfache Strategie zur Auflösung von zyklischen Blockaden realisiert (2.1.1 Blockade/Verklemmung), die bei der aktuellen Implementierung von Regler und Object-Server unvermeidbar sind.

Abbildung in dieser Leseprobe nicht enthalten

3. Architektur der Robotersteuerung

Im mittleren Bereich von Abbildung 3.1 sind die Prozesse dargestellt, die auf dem QNX-Steuerungsrechner arbeiten. Die Verbindungen zwischen diesen Prozessen werden durch den Austausch von Nachrichten hergestellt, die vom zentralen Element, dem Object-Server, an den richtigen Empfänger weitergeleitet werden. Die Verbindung zur Außenwelt auf der linken Seite – dem Roboter – wird durch den Treiber hergestellt, der unter Benutzung einer Interface-Karte Signale an die Leistungselektronik des Roboters sendet. Auf der rechten Seite wird die Möglichkeit zur Kommunikation mit jedem beliebigen Partner durch einen TCP/IP-Interface-Prozess geschaffen, der unter Verwendung der TCP/IP-Protokolle (® 2.2 TCP/IP) Verbindungen aufbauen kann. In Abbildung 3.1 ist beispielhaft ein WindowsNT-PC aufgeführt, da sowohl im Rahmen dieser Arbeit zu Testzwecken ein Benutzerinterface auf einem WindowsNT-PC implementiert wurde, als auch mit der Arbeit von Holger Ratke eine Benutzeroberfläche auf einem WindowsNT-PC zur Verfügung steht.

3.1 Object-Server

Die Hauptaufgabe des Object-Server besteht darin alle Nachrichten, die von den verschiedenen zu einem bestimmten Zeitpunkt laufenden Prozessen verstanden werden, zu verwalten und die Auslieferung jeder Nachricht an den richtigen Empfänger zu gewährleisten. Ausgehend von dieser Aufgabenstellung stehen verschiedene Entwurfsmöglichkeiten zur Verfügung, deren Leistungsvermögen in unterschiedlichen Richtungen am ausgeprägtesten ist. Die erste Entwurfsmöglichkeit ist ein Object-Server, der die Nachrichten mit den Identifikationen der entsprechenden Server speichert, aber keine Kommunikation abwickelt. Eine Anfrage nach einer bestimmten Nachricht würde vom Object-Server lediglich mit der Identifikation des entsprechenden Servers beantwortet werden. Der anfragende Prozess müsste daraufhin diese Identifikation speichern und die Kommunikation in eigener Regie durchführen. Unter der Bedingung, das die Identifikationsanfrage für jeden Nachricht nur einmal vor der Kommunikation erfolgt, ergäben sich die folgenden Vorteile bei dieser Lösung:

- Direkte Kommunikation der beteiligten Prozesse und dadurch maximaler Datendurchsatz
- Vermittlung der Kommunikationspartner, d.h. kein Prozess muss sich seinen „Ansprechpartner“ selber suchen.
Demgegenüber stehen allerdings die Nachteile:
- Jeder Prozess muss eine Nachrichtenliste verwalten, also einen Teil der Object-Server Funktionalität selbst implementieren.
- Der Austausch eines Servers durch einen anderen Server gleichen Typs, der also dieselben Nachrichten versteht, ist nicht möglich, da in diesem Fall die vom Object-Server bereits versandten Prozessidentifikationen für bestimmte Nachrichten ungültig würden.
- Das Gesamtsystem wäre sehr verzahnt, d.h. eine Änderung an einem der Kommunikationspartner könnte Änderungen an allen anderen Kommunikationspartnern nach sich ziehen. Erweiterung und Wartung der Kommunikationspartner wären also unter Umständen sehr komplex.

Das Problem der ungültigen Prozessidentifikationen bei Austausch eines Servers könnte behoben werden indem vor jedem Versenden einer Nachricht die Prozessidentifikation aktualisiert wird, also beim Object-Server nach dem Empfänger gefragt wird. Dies hätte allerdings ein erheblich höheres Kommunikationsaufkommen zur Folge und würde damit keine Vorteile mehr gegenüber der zweiten Implementierungsvariante, die im folgenden beschrieben wird, haben.

Die zweite Variante ist ein Object-Server, der neben der Verwaltung der Nachrichten auch die gesamte Kommunikation abwickelt. D.h. Jede Nachricht wird an den Object-Server gesandt und dieser leitet sie an den (Server-)Prozess weiter, der die Nachricht versteht. Die Vorteile dieser Variante bestehen in:

- Der Austausch aller (Server-)Prozesse kann zur Laufzeit erfolgen, da die gesamte Kommunikation durch den Object-Server geleitet wird, der immer den aktuellen Server für alle Nachrichten kennt.
- Die Flexibilität wird erhöht, da neue Prozesse nur die definierte Kommunikationsschnittstelle respektieren müssen um im System mitarbeiten zu können. Die Wartung wird erleichtert, da die Kommunikation in definierten Bahnen nur mit dem Object-Server abläuft.
- Die Verwaltung aller Nachrichten erfolgt zentral durch den Object-Server und kann somit effizient gestaltet werden. Eine Optimierung dieser Aufgabe beschränkt sich also auch auf den Object-Server und muss nicht für jeden Prozess im System durchgeführt werden.
- Durch die zentrale Position des Object-Server hat er die Möglichkeit Blockaden/Verklemmungen aufgrund zyklischer Anfragen (Prozess 1 fragt Prozess 2, Prozess 2 fragt Prozess 3, Prozess 3 fragt Prozess 1) zu erkennen und damit auch zu verhindern.

Ein Nachteil bei dieser Art der Implementierung liegen im erhöhten Kommunikationsaufkommen, da jede Nachricht zweimal gesendet werden muss ‑ zunächst an den Object-Server und anschließend von diesem an den entsprechenden Zielprozess. Außerdem muss dieser Object-Server sowohl Client als auch Server sein, da er ja Nachrichten empfängt und Nachrichten sendet. Dadurch ist es in Verbindung mit dem ebenfalls als Client und Server implementierten Regelungsprozess unmöglich Verklemmungen per se auszuschließen (® Abbildung 2.1 und Abbildung 3.2). Diese Problematik wurde dadurch gelöst, dass das Senden nach einem eingestellten Timeout abgebrochen wird und die entsprechende Nachricht für ein erneutes, späteres Senden gespeichert wird (® 3.1.1 Nachrichten-Scheduling). Als guter Kompromiss zwischen maximaler Ausfallzeit der Regelung und maximaler Wartezeit auf ein Reply (® Abbildung 2.5, 2.3 QNX-Inter-Prozess-Kommunikation) hat sich ein Timeout von 3ms erwiesen.

Abbildung in dieser Leseprobe nicht enthalten

Eine mögliche dritte Alternative, die im Rahmen dieser Arbeit jedoch nicht untersucht wurde, ist die Implementierung des Object-Server als Klasse bzw. Klassenbibliothek, die mit dem jeweiligen Zielprogramm zusammen gebunden wird. Zumindest die Option eines „in Bereitschaft wartenden“ Object-Server und der Austausch von Kommunikationspartnern zur Laufzeit erfordern bei dieser Alternative intensive Entwurfsarbeit.

Die gewählte Umsetzung des Object-Server entspricht Alternative zwei. Der Object-Server stellt also, wie auch in Abbildung 3.1 zu sehen ist, das zentrale Element der Robotersteuerung dar. Er ist als eigenständiger Prozess implementiert und ermöglicht damit den Austausch aller Kommunikationspartner zur Laufzeit. Seine Aufgabe besteht darin die gesamte Kommunikation auf dem Steuerungsrechner weiterzuleiten. Dabei stellt der Object-Server auch eigene Funktionen zur Verfügung (Tabelle 7.1: Funktionen des Object-Server S.82, 3.1.6 Object-Server Nachrichten).

Die zu diesem Zweck ablaufende Kommunikation soll im folgenden näher erläutert werden.

Zunächst muss der Object-Server-Prozess gestartet werden. Er registriert sich unter dem Namen iRP/ObjectServer. Sowohl mit Hilfe einer Konfigurationsdatei (® 3.1.5 Konfigurationsdatei) als auch durch Senden des Start-Kommandos (Tabelle 7.1: Funktionen des Object-Server S.82, 3.1.6 Object-Server Nachrichten) an den Object-Server, können vom Object-Server weitere Prozesse gestartet werden. Ein Server-Prozess, der eigene Funktionalität verfügbar macht, muss die entsprechenden Nachrichten beim Object-Server registrieren. Diese Registrierung wird im folgenden Programmbeispiel mit Hilfe von Methoden der Klasse Message (® 3.1.7.1 Die Klasse Message) verdeutlicht:

Abbildung in dieser Leseprobe nicht enthalten

Beispiel 1: Programmsegment für die Registrierung des Kommunikationsobjekts “SetPos“ eines Servers

Die auf diese Weise registrierten Nachrichten können von den Client-Prozessen im System genutzt werden um Aufgaben zu erfüllen. Um alle verfügbaren Nachrichten zu ermitteln, kann der Object-Server mit Hilfe der Nachricht „getmsglist“ (® 3.1.6 Object-Server Nachrichten und Tabelle 7.1: Funktionen des Object-Server S.82) aufgefordert werden die Nachrichtenliste als Reply zu versenden. Ein Beispiel für eine derartige Anforderung ist im folgenden Programmsegment angegeben:

Abbildung in dieser Leseprobe nicht enthalten

Beispiel 2: Suchen einer bestimmten Nachricht unter den Object-Server Nachrichten.

3.1.1 Nachrichten-Scheduling

Nachrichten-Scheduling ist das Zwischenspeichern und das anschließende verzögerte Weiterleiten einer Nachricht an einen Zielprozess, den Server für diese Nachricht. Beim verzögerten Weiterleiten einer Nachricht ist zu berücksichtigen, dass die Nachrichten in der Reihenfolge beim Empfänger ankommen in der sie vom Sender abgesandt wurden.

3.1.1.1 Motivation

Der Object-Server ist das zentrale Element der Regelung und darf daher nicht durch mangelnde Empfangsbereitschaft der Server-Prozesse beim Versenden von Nachrichten blockiert werden. Aus diesem Grund wird das Scheduling einer eingehenden Nachricht nötig, wenn der Zielprozess

1. zur Zeit noch Berechnungen durchführt oder
2. auf die Beantwortung einer Anfrage wartet. (® Abbildung 3.3)

Fall 1 kann bei beliebigen Prozessen auftreten und würde beim blockierenden Senden (® 2.3 QNX-Inter-Prozess-Kommunikation) dazu führen, dass der Object-Server solange untätig wartet, bis der Zielprozess seine Berechnungen abgearbeitet hat.

Fall 2 kann nur bei Zielprozessen auftreten, die gleichzeitig Server und Client sind. Ein Beispiel für einen solchen Prozess ist der Regler, der Client des Treibers ist und einen Server für Gelenkstellungen darstellt. Der Object-Server ist natürlich auch gleichzeitig Client und Server. Er ist Client für alle Server im System indem er Nachrichten an diese Server sendet und Server für alle Clients indem er Nachrichten von den Clients entgegennimmt und an die entsprechenden Server weiterleitet. In Fall 2 ist die Empfangsbereitschaft dadurch nicht gegeben, dass der Prozess auf eine bestimmte Nachricht wartet und daher nicht auf beliebige andere Nachrichten reagiert bzw. reagieren kann. In diesem Fall wäre das Nachrichten-Scheduling im Empfängerprozess eine Alternative zum zentralen Nachrichten-Scheduling durch den Object-Server. Diese Alternative wäre allerdings mit erheblichem Mehraufwand im jeweiligen Empfängerprozess verbunden und das zentrale Nachrichten-Scheduling wäre trotzdem weiterhin für Fall 1 notwendig. Daher wurde das Nachrichten-Scheduling zentral im Object-Server eingebaut. Dieser achtet auch darauf, dass die Nachrichten in der richtigen Reihenfolge beim Empfänger eintreffen. Die Erhaltung der Reihenfolge wird dadurch erreicht, dass vor der Weiterleitung einer Nachricht geprüft wird, ob vom Absender zu einem früheren Zeitpunkt eine Nachricht an den Empfänger gesandt wurde, die zwischen gespeichert werden musste. Ist das der Fall, so wird diese ältere Nachricht zuerst gesendet und statt dessen wird die neue Nachricht zwischen gespeichert.

[...]


[1] “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.

[2] Als Kernel 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.

Fin de l'extrait de 96 pages

Résumé des informations

Titre
Kommunikationsmodell einer PC-basierten Robotersteuerung
Université
Technical University of Braunschweig  (Institut für Robotik und Prozessinformatik)
Note
1,0
Auteur
Année
2001
Pages
96
N° de catalogue
V6190
ISBN (ebook)
9783638138222
Taille d'un fichier
2444 KB
Langue
allemand
Annotations
Gegenstand der Arbeit ist die Entwicklung einer Middleware zur Vereinfachung der Anbindung von Robotern an verschiedene Anwendungen (z.B. an eine Windowsoberfläche) auch über ein Netzwerk. 1,94 MB
Mots clés
Middleware, Robotersteuerung, Robotik, Netzwerk, Internet
Citation du texte
Michael Borchard (Auteur), 2001, Kommunikationsmodell einer PC-basierten Robotersteuerung, Munich, GRIN Verlag, https://www.grin.com/document/6190

Commentaires

  • Pas encore de commentaires.
Lire l'ebook
Titre: Kommunikationsmodell einer PC-basierten Robotersteuerung



Télécharger textes

Votre devoir / mémoire:

- Publication en tant qu'eBook et livre
- Honoraires élevés sur les ventes
- Pour vous complètement gratuit - avec ISBN
- Cela dure que 5 minutes
- Chaque œuvre trouve des lecteurs

Devenir un auteur