Diplomarbeit - Hochschule für Technik und Wirtschaft Dresden

Hochschule für Technik und Wirtschaft Dresden (FH)
Fachbereich Informatik / Mathematik
Diplomarbeit
im Studiengang Informatik
Thema: Konzeption eines offenen modularen Systems von Sensoren
und Aktoren für den universellen Einsatz am Beispiel eines
Roboters
Eingereicht von: Daniel Popp
Eingereicht am: 27.07.2004
Betreuer: Prof. Dr. rer. nat. habil. Heino Iwe

Diplomarbeit: Modulares System Inhalt
Inhaltsverzeichnis
1. Einleitung................................................................................................................................... 5
1.1. Roboter.............................................................................................................................. 5
1.2. Steuerung.......................................................................................................................... 6
1.3. Ziele .................................................................................................................................. 6
2. Analyse der bestehenden Systeme und Konzepte von Robotern ................................................ 7
2.1. Fixe Komplettsysteme........................................................................................................ 7
2.1.1. Die historische Schildkröte „Elmer“.................................................................... 7
2.1.2. Spider 3............................................................................................................ 8
2.1.3. Beam-Roboter .................................................................................................. 8
2.2. Einfache Eigenbausysteme................................................................................................ 8
2.2.1. 80C535............................................................................................................. 9
2.2.2. C-Control .......................................................................................................... 9
2.2.3. Eigenbau D001................................................................................................. 9
2.3. Programmierbare Komplettsysteme ................................................................................. 10
2.3.1. LEGO Mindstorms .......................................................................................... 10
2.3.2. fischertechnik.................................................................................................. 11
2.3.3. Cybot.............................................................................................................. 11
2.3.4. Khepera.......................................................................................................... 12
2.3.5. Koala.............................................................................................................. 12
2.4. Fazit ................................................................................................................................ 13
3. Hardwareanalyse ..................................................................................................................... 14
3.1. CISC................................................................................................................................ 14
3.2. RISC................................................................................................................................ 14
3.2.1. 32-Bit.............................................................................................................. 14
3.2.2. 16-Bit.............................................................................................................. 15
3.2.3. 8-Bit................................................................................................................ 15
3.3. Wahl der Hardware .......................................................................................................... 15
4. Datenstrukturen und Kommunikation........................................................................................ 16
4.1. Die Elemente des Netzwerks ........................................................................................... 16
4.1.1. Sensoren ........................................................................................................ 16
4.1.2. Aktoren........................................................................................................... 18
4.1.3. Weiterführende Elemente................................................................................ 19
4.2. Datenmenge.................................................................................................................... 20
4.3. Adressierung ................................................................................................................... 21
4.3.1. Direkte Adressierung ...................................................................................... 21
4.3.2. Gruppenadressierung ..................................................................................... 21
4.3.3. Kombinierte Adressierung............................................................................... 22
4.3.4. Adressierung im CAN-Bus .............................................................................. 23
4.4. Adressierung im Netz....................................................................................................... 24
26.07.2004 Seite 2 von 85

Diplomarbeit: Modulares System Inhalt
4.5. Klassifizierung der Gruppentypen und ihrer Adressen ...................................................... 24
4.6. Systemkommandos ......................................................................................................... 25
5. Vergleich von Bussystemen für die Kommunikation.................................................................. 26
5.1. Einteilung der Bussysteme............................................................................................... 26
5.1.1. Parallele Bussysteme ..................................................................................... 27
5.1.2. Serielle Bussysteme ....................................................................................... 27
5.1.3. Serielle Betriebsarten...................................................................................... 28
5.1.4. Symmetrische und asymmetrische serielle Schnittstellen ................................ 28
5.1.5. Synchrone und asynchrone Übertragung ........................................................ 29
5.1.6. Buszugriffsverfahren....................................................................................... 30
5.1.7. Netzwerktopologien ........................................................................................ 30
5.2. Das OSI-Schichtenmodell ................................................................................................ 32
5.3. Überblick über gängige Bussysteme ................................................................................ 33
5.3.1. Paralleler System-Bus PC............................................................................... 33
5.3.2. Paralleler Peripherie-Bus SCSI ....................................................................... 34
5.3.3. Paralleler Instrumentierungsbus IEC ............................................................... 34
5.3.4. Serielle RS232................................................................................................ 34
5.3.5. Serieller Komponenten-Bus I²C....................................................................... 34
5.3.6. Serieller Peripherie-Bus USB .......................................................................... 34
5.3.7. Serieller Feldbus CAN..................................................................................... 35
5.3.8. Serielles Ethernet ........................................................................................... 35
5.3.9. Übersicht ........................................................................................................ 36
5.4. Auswahl des verwendeten Busses................................................................................... 37
6. Programmierung der Knotenpunkte.......................................................................................... 39
6.1. Die Programmiersprache PL0 .......................................................................................... 40
6.2. Beispielanwendung.......................................................................................................... 41
6.2.1. Zentrales Programm ....................................................................................... 42
6.2.2. Verteiltes Programm ....................................................................................... 43
6.3. Umsetzung ...................................................................................................................... 44
6.3.1. Der Compiler .................................................................................................. 44
6.3.2. Die Virtuelle Maschine .................................................................................... 46
6.4. Zusammenfassung .......................................................................................................... 48
7. Testen der Steuerungsskripte im Simulator .............................................................................. 49
7.1. Vergleich verschiedener Simulatoren ............................................................................... 49
7.1.1. LLWin............................................................................................................. 49
7.1.2. Webot............................................................................................................. 50
7.1.3. Easybot .......................................................................................................... 50
7.1.4. Netbot............................................................................................................. 51
7.2. Arbeiten mit der Virtuellen Maschine ................................................................................ 52
7.2.1. Aufbau der VM.DLL ........................................................................................ 52
26.07.2004 Seite 3 von 85

Diplomarbeit: Modulares System Inhalt
7.2.2. Verwendung der VM.DLL................................................................................ 53
7.3. Easybot ........................................................................................................................... 53
7.3.1. Lightvision3D.................................................................................................. 53
7.3.2. Easybot .......................................................................................................... 54
7.3.3. Netzwerk ........................................................................................................ 55
7.3.4. Khepera-Steuerung: Khepera_VM.DLL ........................................................... 55
7.3.5. Cybot-Steuerung: Cybot_VM.DLL ................................................................... 56
7.3.6. Offene Steuerung: Multi_VM.DLL.................................................................... 57
7.4. Netbot.............................................................................................................................. 58
7.4.1. Netzwerk ........................................................................................................ 58
7.4.2. Knotenpunkte ................................................................................................. 59
7.5. Fazit ................................................................................................................................ 61
8. Praktische Anwendung............................................................................................................. 62
8.1. Funktionalität der Knotenpunkte....................................................................................... 62
8.1.1. Grundumfang.................................................................................................. 62
8.1.2. Knotentypspezifische Fähigkeiten ................................................................... 63
8.1.3. Programmierbarkeit ........................................................................................ 63
8.2. Programmierung und Steuerung vom Computer aus........................................................ 64
8.2.1. Firmware ........................................................................................................ 64
8.2.2. Skript .............................................................................................................. 64
8.2.3. Parameter....................................................................................................... 64
8.2.4. Codierung....................................................................................................... 64
8.3. Beispielanwendung: Ausweichen ..................................................................................... 65
8.3.1. Software ......................................................................................................... 66
8.3.2. Aufbau............................................................................................................ 67
8.3.3. Erweiterung .................................................................................................... 67
9. Ergebnisse und Ausblick.......................................................................................................... 69
9.1. Ergebnisse....................................................................................................................... 69
9.2. Ausblick........................................................................................................................... 70
Thesen............................................................................................................................................. 71
Anhang ............................................................................................................................................ 72
CD-Inhalt.......................................................................................................................................... 79
Quellenverzeichnis........................................................................................................................... 80
Abbildungs- und Tabellenverzeichnis ............................................................................................... 81
Abkürzungsverzeichnis..................................................................................................................... 83
Glossar ............................................................................................................................................ 84
Erklärung zur Selbstständigkeit ........................................................................................................ 85
26.07.2004 Seite 4 von 85

Diplomarbeit: Modulares System Einleitung
1. Einleitung
Ziel dieser Diplomarbeit ist es, ein Konzept für ein System von Sensoren (z.B. Entfernungsmesser
oder Bewegungsmelder) und Aktoren (z.B. Motoren oder Lampen) zu schaffen, so dass diese beliebig
miteinander kombinierbar und einzeln programmierbar sind, um die einzelnen Elemente steuern und
regeln zu können. Damit soll es möglich sein, ein „intelligentes“ Netzwerk mit einfachen Mitteln zu
schaffen. Als Einsatzgebiete für dieses Netzwerk sind sowohl Steuerungsanlagen für räumlich
ausgedehnte Objekte (z.B. Haussteuerung für Licht oder Heizung) als auch mobile Roboter denkbar.
In dieser Arbeit stehen Roboter im Mittelpunkt der Entwicklung, dabei wird jedoch immer der Einsatz
als Haussteuerung im Auge behalten.
Die räumliche Anordnung der einzelnen Elemente und das Aussehen des Roboters spielt mit diesem
Netzwerk keine Rolle mehr. Es kann jederzeit geändert und durch neue Elemente ergänzt werden.
Diese lassen sich nahtlos in bestehende Systeme integrieren. Vor allem ist angestrebt, dass es keine
Beschränkung in der Anzahl der anschließbaren Sensoren und Aktoren gibt. Die Programmierung der
einzelnen Elemente soll in einer einfachen Skriptsprache möglich sein.
1.1. Roboter
Der Begriff Roboter leitet sich vom tschechischen „robota“ ab, was soviel wie „schwere Arbeit“ oder
„Sklavenarbeit“ bedeutet. Geprägt hat diesen Ausdruck der tschechische Bühnenautor Karel Capek
1921 durch sein Theaterstück „W.U.R.“ (Werstands Universal Robots). Er erdachte damit künstliche
Wesen, die vor allem den Menschen imitieren, lange vor Wissenschaftlern. 1932 beeindruckte dann
der Roboter Alpha die Besucher der Funkausstellung in Olympia/London. Er konnte einen Revolver
abfeuern, mit Besuchern reden und Text in jeder Sprache lesen. Wie die Funkausstellung hatte kurze
Zeit später jeder Jahrmarkt und jede Ausstellung, die etwas auf sich hielt, ihren eigenen Roboter.
Diese riefen damals viel Aufsehen hervor, können aber, aus heutiger Sicht betrachtet, nur
Fälschungen gewesen sein. Der erste wissenschaftliche Roboter wurde 1938 von Thomas Ross in
Amerika entwickelt. Es handelte sich dabei um eine kleine Maschine, die wie eine Maus durch
Versuch und Irrtum lernend, den Weg aus einem Labyrinth herausfand. Die Entwicklung
hochkomplexer Roboter, wie dem ASIMO von Honda oder SDR und AIBO von Sony, werden von
großen Firmen mit Millionenbudgets vorangetrieben. Auch im Heimbereich sind Roboter immer mehr
im kommen. Sie übernehmen bereits heute einfache Aufgaben wie beispielsweise Staubsaugen. Die
Faszination Roboter erfasst aber auch viele Amateure, die mit ihren eigenen Mitteln einfache Roboter
schaffen und mit ihnen experimentieren.
26.07.2004 Seite 5 von 85

Diplomarbeit: Modulares System Einleitung
1.2. Steuerung
Die heute auf dem Markt befindlichen Robotersysteme sind zum größten Teil entweder sehr
spezialisiert, kostenintensiv oder relativ schwer zu beherrschen. Dadurch ist es für den Robotiker im
nichtprofessionellen Bereich recht schwer, ein passendes System für sich zu finden. Der größte
Nachteil liegt meist in der begrenzten Anzahl anschließbarer Sensoren und Aktoren beziehungsweise
in der teilweise recht komplexen Entwicklungsumgebung.
Die Steuerung von Robotern erfordert ein hohes Maß an Verständnis für die jeweilig verwendete
Hardware und eine Einarbeitung in die entsprechende Entwicklungsumgebung. Die Umsetzung auf
einen anderen Roboter oder auch nur die Verwendung eines neuen Prozessors bringt umfangreiche
Anpassungen mit sich.
1.3. Ziele
Als Ergebnis der Arbeit sollen Sensoren wie Entfernungsmesser und Aktoren wie Motoren auf
einfache Weise miteinander vernetzt werden können. Dieses Netz soll die Steuerung eines Roboters
übernehmen. Jedes Element soll ein eigenes einfach zu entwickelndes Programm ausführen können
und über ein geeignetes Verbindungssystem mit den anderen kommunizieren können. Dabei soll das
Netzwerk in seiner Gesamtheit von der Anzahl der Elemente weitestgehend unabhängig funktionieren
können. Der Ausfall eines Knotens soll das Netzwerk nicht stören, sondern nur die Steuerprogramme,
die ihn benötigen, sollen beeinträchtigt werden. Der Rest muss ungestört davon weiter funktionieren.
Durch die Verwendung einer eigenen einfachen Skriptsprache und die Einbindung einer virtuellen
Maschine in die Robotersteuerung sollen die Probleme, die sich mit Weiterentwicklungen und
Veränderungen der Hardware ergeben, verringern
Um Steueralgorithmen testen zu können, ohne jedes Mal das Modell aufbauen zu müssen, soll eine
Möglichkeit geschaffen werden, diese am Computer zu testen und in einer simulierten Umgebung
ablaufen zu lassen.
26.07.2004 Seite 6 von 85

Diplomarbeit: Modulares System Analyse bestehender Robotersysteme
2. Analyse der bestehenden Systeme und Konzepte von Robotern
Es gibt auf dem Markt eine Vielzahl von mobilen und stationären Robotern. Sie sind speziell auf den
jeweiligen Kundenwunsch angepasst und entwickelt und entsprechend kostenintensiv. In der
folgenden Aufstellung geht es vielmehr um einfache Robotersysteme, die auch für den
„Heimgebrauch“ vorstellbar wären. Verglichen werden hierbei vor allem die Anpassbarkeit der Roboter
an neue Aufgaben und die Art und Weise der Steuerung. Reine Industriespeziallösungen werden
hierbei außen vor gelassen.
2.1. Fixe Komplettsysteme
Beliebt bei Hobbyrobotikern sind Systeme, die nur zusammengebaut werden müssen und dann eine
ganz bestimmte Aufgabe erfüllen. Da sie meist nicht programmierbar sind, ist dieses Konzept nicht
geeignet, um Roboter zu entwickeln, die auf neue Aufgabengebiete einstellbar sind. Dadurch, dass
komplett alles vorbereitet ist, werden kaum Kenntnisse von Mechanik und Programmierung benötigt
und sie bieten somit einen leichten Einstieg in die Thematik.
2.1.1. Die historische Schildkröte „Elmer“
Aus den Anfängen der mobilen Steuerung stammen Bauanleitungen für einfache Steuerungen, die ein
tierhaftes Verhalten nachahmen. Besonders beliebt war die Schildkröte Elmer nach Grey Walter aus
dem Jahr 1949. Sie hatte nur die Aufgabe Licht zu suchen und Hindernissen auszuweichen. Das
erreichte sie mit einer einfachen Schaltung aus einer handvoll elektronischer Bauteile wie Transistoren
und Widerständen. Sie kam komplett ohne Speicher oder Prozessoren aus, sondern reagierte nur
mittels ihrer Schaltung direkt auf die Umgebung. [bb]
Abbildung 2.1 - Die elektronische Schildkröte „Elmer“
26.07.2004 Seite 7 von 85

Diplomarbeit: Modulares System Analyse bestehender Robotersysteme
2.1.2. Spider 3
Der Spider ist „Elmer“ sehr ähnlich. Im Gegensatz zur radgetriebenen Schildkröte besitzt er sechs
Beine, die über zwei Motoren bewegt werden und über einen Entfernungssensor an der Spitze. Eine
einfache Mikrocontrollersteuerung ermöglicht es ihm, Hindernissen auszuweichen. Da das Model über
einen Controller, etwas Speicher und eine komplexere Schaltung als die Schildkröte verfügt, könnten
damit eigene Anwendungen realisiert werden. Durch die geringe Anzahl der Sensoren (einer) und
Motoren (zwei) ist natürlich kaum eine andere Anwendung als die vorgesehene sinnvoll. [spid]
Abbildung 2.2 - Der Laufroboter Spider
2.1.3. Beam-Roboter
Die modernste und interessanteste Variante von Robotern ohne komplizierte Steuerung sind Beam-
Roboter. Sie sind besonders klein und funktionieren, einmal gestartet, komplett autark. So besitzen sie
eine einfache Elektronik ohne Controller und oft eine Solarzelle. Beam-Roboter besitzen ein spezielles
„Gehirn“, BiCore genannt, welches von Mark Tilden entwickelt wurde und lediglich aus einigen
Logikschaltkreisen besteht. Es soll insektoides Verhalten nachahmen und ist für komplexere Aufgaben
leider nicht geeignet. [beam]
Abbildung 2.3 - Der Beamroboter UniBug
2.2. Einfache Eigenbausysteme
Es gibt unzählige Anleitungen um sich einen Roboter selbst zu bauen. Dabei wird im Allgemeinen von
mobilen sich selbst steuernden Fahrzeugen ausgegangen. Die Mechanik wird dabei in der Werkstatt
meist selbst zusammengebastelt und von einer Zentraleinheit gesteuert. Sensoren und Aktoren
werden dabei meist direkt an diese „CPU“ angeschlossen.
26.07.2004 Seite 8 von 85

Diplomarbeit: Modulares System Analyse bestehender Robotersysteme
2.2.1. 80C535
Auf Basis des SAB80C535-Mikrocontrollers sind verschiedene Steuerungen entstanden, die über
gängige Schnittstellen verfügen (RS232, RS485, CAN). Der 80C535 ist ein 12 beziehungsweise 16
MHz-Mikrocontroller von Infineon für den es Compiler in verschiedenen Sprachen (C, Pascal) gibt. Er
muss separat programmiert werden, ist dadurch zwar sehr flexibel aber auch recht umständlich und
nur für erfahrene Entwickler geeignet. Sensoren und Aktoren werden üblicherweise direkt an den
Controller angeschlossen. [C535]
Abbildung 2.4 - Ein Mikrocontrollerboard 80C535
2.2.2. C-Control
Dieses von Conrad-Elektronik angebotene umfangreiche System ist durch den kommerziellen Druck
weit entwickelt, aber natürlich auch recht kostenintensiv. Den Kern bildet ein 4 MHz-Mikrocontroller
von Motorola. Um diesen sind in verschiedenen Ausführungen fertige Boards für unterschiedliche
Anwendungen erhältlich. Größter Nachteil ist hier zum einen der Kostenfaktor und zum anderen die
begrenzte Anschlussmöglichkeit von Sensoren und Aktoren, die direkt an das Zentralmodul
angeschlossen werden. Programmiert wird das C-Control in der Sprache BASIC. [ccon]
Abbildung 2.5 - Das System C-Control
2.2.3. Eigenbau D001
Der D001 ist ein Beispiel für einen runden, dreirädrigen Roboter der zu Test- und
Experimentierzwecken entstanden ist. Als Kern dient ein 12 MHz Intel 80C51GB, der durch
entsprechende Sensoren und Aktoren erweitert wurde. Für die Verbindung mit anderen Robotern
wurde ein CAN-Bus integriert. Der D001 ist in seinen mechanischen und sensorischen Fähigkeiten
festgelegt und kaum erweiterbar. In dieser oder einer ähnlichen Form existieren zahllose Roboter, die
alle zueinander inkompatibel sind, aber im Grunde die gleichen Ziele verfolgen. [d001]
26.07.2004 Seite 9 von 85

Diplomarbeit: Modulares System Analyse bestehender Robotersysteme
Abbildung 2.6 - Der D001-Experimentierroboter
2.3. Programmierbare Komplettsysteme
Da die vorigen Komplettsysteme kaum Raum für eigene Kreativität bieten und die Eigenbausysteme
teils hohe mechanische Fertigkeiten erfordern, gibt es eine Reihe von fertigen Systemen, die frei
programmierbar sind. Im Allgemeinen beschäftigen sie sich mit Fahrzeugsteuerungen und ermögliche
es beispielsweise, Wegsuchalgorithmen zu testen.
2.3.1. LEGO Mindstorms
Die Firma LEGO aus Dänemark ist eigentlich ein Hersteller von Spielzeugkästen für Plastikbausteine.
Vor ein paar Jahren begann sie, neue Märkte zu erschließen. Dazu gehören auch Robotersysteme.
Mindstorms ist ein einfach zu bedienendes System welches durch die bekannten LEGO-Bausteine
den schnellen Aufbau von Mechaniken und Fahrwerken ermöglicht. Die Steuerung übernimmt eine
zentrale Einheit namens RCX, für die in einer grafischen Programmiersprache einfache Programme
per Mausklick erstellt werden können. Es gibt eine Reihe von verschiedenen Sensoren, die direkt an
das RCX angeschlossen werden. Leider ist es nur mit je drei Sensor- und Motoranschlüssen
ausgestattet. Zwar lassen sich mehrere Geräte zusammenschalten um komplexere Aufgaben zu
realisieren, aber sie müssen dann in einer speziellen C-ähnlichen Sprache programmiert werden.
Außerdem sind die Kosten für die RCX recht erheblich. Alles in allem handelt es sich hierbei aber um
ein gutes variables System, um in die Grundlagen der Robotik einzusteigen und mit den
verschiedensten Roboterarten zu experimentieren. [lego]
Abbildung 2.7 - Ein LEGO-Roboter
26.07.2004 Seite 10 von 85

Diplomarbeit: Modulares System Analyse bestehender Robotersysteme
2.3.2. fischertechnik
Die deutsche Firma fischertechnik beschäftigt sich wie LEGO mit der Herstellung von
Modellbaukästen, wobei das Augenmerk mehr auf Industriesimulationen gelegt wird. Ansonsten sind
sich die Angebote sehr ähnlich und auch das Konzept für Roboter ist vergleichbar. Eine zentrale
Einheit steuert eine begrenzte Anzahl von Sensoren und Aktoren. Diese ist bei fischertechnik deutlich
höher als bei LEGO, aber dafür ist die ebenfalls grafisch orientierte Entwicklungsumgebung sehr
komplex und für Einsteiger teilweise schwer verständlich. Vorteilhaft ist, dass sie einen integrierten
Simulator enthält. Dadurch müssen die Programme nicht am fertigen Modell getestet werden. Wie
LEGO ist das fischertechnik-System für Bastler gut geeignet, wobei diese schon Vorkenntnisse in
Programmierung beziehungsweise in Programmablaufsteuerungen mitbringen sollten. [fisch]
2.3.3. Cybot
Abbildung 2.8 - Ein Laufroboter mit fischertechnik
Der Cybot ist als Lernspielzeug konzipiert und wird als Abonnement-Heft vertrieben. Durch monatlich
neue Anbauteile wächst das System mit der Zeit immer mehr an. Mit einer Vielzahl von Sensoren und
Controllern wäre er recht gut geeignet um eigene Anwendungsgebiete zu erschließen. Lediglich die
mechanischen Gegebenheiten (Dreiradsystem und Sensoren in einem Autochassis) sind bindend.
Leider sind die Controller nicht frei programmierbar, sondern enthalten lediglich vorprogrammierte
Steuerungsmechanismen. Am Computer können jedoch eigene einfache Programme entwickelt und
auf dem Fahrzeug abgelaufen lassen werden. [rr]
Abbildung 2.9 - Der Cybot
26.07.2004 Seite 11 von 85

Diplomarbeit: Modulares System Analyse bestehender Robotersysteme
2.3.4. Khepera
Um Steueralgorithmen für autonome Roboter testen zu können, wurde in der Schweiz der Khepera
entwickelt. Er ist ein sehr kleines mobiles Fahrzeug, welches über einige Sensoren und zwei Motoren
verfügt. Im Kern steckt ein sehr leistungsfähiger 25 MHz Motorola Controller welcher mit C
programmiert werden kann. Durch seine Größe (70mm x 30mm) und eine Vielzahl von Anbauteilen
(Zeilenkamera, Greifarm) können Experimente, die eine reale Umgebung simulieren, sehr gut auf
kleinem Raum durchgeführt werden. Durch seine kompakte Bauweise ist er aber mechanisch kaum
änderbar. [kt]
2.3.5. Koala
Abbildung 2.10 - Der Miniaturroboter Khepera
Der Koala ist der große Bruder des Khepera. Er besteht aus einem Autochassis, in dem ein 22 MHz
Motorola Controller montiert ist und verfügt über eine Reihe von Infrarot- und Sonarsensoren. Der
Koala ist dafür gedacht, Experimente in maßstabsgerechten Umgebungen zu ermöglichen. Er ist für
Tests verschiedener Algorithmen vorbereitet, die eine Steuerung von autonomen Fahrzeugen
ermöglichen sollen. Es werden sowohl C als auch LabVIEW oder MATLAB-Programme unterstützt. Er
entspricht in seinen Funktionen weitestgehend dem Khepera, ist aber größer und massiver angelegt
und besitzt ein geländegängiges Fahrwerk. Der Koala bietet schon viel Raum für eigene
Anwendungen, ist aber als Fahrzeug festgelegt und ermöglicht daher kaum abweichende
Experimente.[kt]
Abbildung 2.11 - Der Autoroboter Koala
26.07.2004 Seite 12 von 85

Diplomarbeit: Modulares System Analyse bestehender Robotersysteme
2.4. Fazit
Auch wenn es eine Vielzahl von Robotersystemen käuflich zu erwerben gibt, so haben doch alle mehr
oder weniger große Nachteile aufzuweisen. Die meisten Systeme sind zu starr in ihren Möglichkeiten.
Am schwersten wiegt dabei die Beschränkung in der Anzahl der Sensoren und Aktoren. Um ein
Fahrzeug zu steuern sind ein paar wenige Sensoren sicher ausreichend und es werden auch nur zwei
Motoren benötigt. Um einen komplexeren Roboter oder auch nur einen Teil wie beispielsweise einen
Arm bauen zu können, sind aber wesentlich mehr Elemente nötig.
Systeme wie der Khepera und der Koala bieten durch ihre leistungsfähigen Prozessoren viel Raum für
Experimente. Für ihre Aufgaben verfügen sie über ausreichend viele Sensoranschlüsse
beziehungsweise ein eigenes Bussystem. Mit Kameras und Greifarmen als Anbauteilen sind sie gut
ausgestattet. Aber zum einen erfordern sie eine eigene spezifische Programmierung und zum
anderen können eben nur Fahrzeuge gebaut werden. Eine komplexere Steuerung wird wieder sehr
aufwendig oder muss als Komplettmodul gekauft werden, was die Kosten erhöht.
Ein verteiltes Netzwerk von Sensoren und Aktoren bietet dagegen die Möglichkeit, diese Probleme
weitestgehend zu lösen. Die Kosten sind im Vergleich zu den meisten Systemen geringer und durch
den dynamischen variablen Aufbau lassen sich alle denkbaren Roboter entwickeln. Es kann in
vorhandene Mechaniken wie dem Cybot-Fahrwerk installiert werden oder auch auf völlig neu
entwickelte, wie sie zum Beispiel mit LEGO-Bausteinen möglich sind. Dadurch kann jeder beliebige
Roboter erdacht und realisiert werden.
26.07.2004 Seite 13 von 85

Diplomarbeit: Modulares System Hardwareanalyse
3. Hardwareanalyse
Um einen Roboter zu steuern, gibt es unterschiedliche Herangehensweisen. Zum einen kann die
Steuerung über ein rechenstarkes zentrales Element erfolgen und zum anderen durch eine Vielzahl
kleinerer Prozessoren.
Es existieren zwei unterschiedliche Philosophien für Prozessor-Architekturen. Dies sind auf der einen
Seite die CISC (komplexer Befehlssatz mit über 100 Maschinenbefehlen), auf denen auch die
Prozessoren in Personalcomputern aufbauen. Andererseits gibt es die RISC (reduzierter Befehlssatz
mit weniger als 100 Befehlssätzen) mit den Erweiterungen ARM oder POWER-PC. Die Prozessoren
in PDA (mobile Miniaturcomputer) sind meist ARM.
3.1. CISC
Neben den sehr leistungsstarken Computerprozessoren, die allerdings ohne jede Peripherie
ausgeliefert werden, existieren noch so genannte Miniatur-PC die schon über die Grundbausteine
verfügen, die für den Betrieb benötigt werden. Dabei haben sich zwei Bereiche herausgebildet, die
sich aber hauptsächlich im mechanischen Aufbau und in der Wahl der Anschlüsse unterscheiden.
Dies sind PC/104 und Dimm-PC. Sie können Prozessoren von 386SX mit 40MHz bis 1GHz-Celeron
enthalten und verfügen über Grafikkarten und die herkömmlichen PC-Busse, so dass sie wie ein
normaler PC betrieben und auch programmiert werden können. Lediglich die Baugröße unterscheidet
sich. Dimm-PC können etwa eine Größe von 8x8cm haben und PC/104-Module sind mit unter
10x10cm kaum größer. Auf diesen Geräten können natürlich prinzipiell die gleichen Betriebssysteme
laufen, wie auf den herkömmlichen Computern. Die Kosten für einen solchen Miniaturcomputer liegen
zwischen 150 und 400 Euro, je nach Leistungsfähigkeit.
3.2. RISC
Neben der Architektur ist auch die Prozessor- beziehungsweise die Registergröße entscheidend für
die Leistungsfähigkeit des Gerätes. Die kleinsten Einheiten besitzen ein 8-Bit-Register und die
größten sind derzeit mit 64-Bit-Registern ausgestattet.
3.2.1. 32-Bit
RISC-Controller mit 32-Bit-Registern sind derzeit stark im kommen. Sie haben eine hohe
Reichenleistung und können im Prinzip das gleiche leisten, wie ein Computerprozessor. Es gibt für sie
inzwischen Anpassungen der gängigen Betriebssysteme wie Microsoft Windows CE, Palm OS oder
Linux. Sie haben Taktfrequenzen von 150 bis 400MHz und können sich damit zumindest auf dem
Mobilsektor mit den Personalcomputern messen. Prozessoren dieser Größenordnung werden zum
Beispiel in fast allen PDA (mobile Miniaturcomputer) verwendet. Die Preise fangen bei ca. 100 Euro
für fertige Boards an, bei denen die nötige Peripherie schon enthalten ist.
26.07.2004 Seite 14 von 85

Diplomarbeit: Modulares System Hardwareanalyse
3.2.2. 16-Bit
Die 16-Bit-Prozessoren sind im Mittelfeld eingeordnet. Sie haben eine höhere Leistung als die kleinen
8-Bit-Einheiten, kommen aber bei weitem nicht an die Leistungsfähigkeit der 32-Bit-Controller heran.
Sie verfügen neben einem internen Speicher über einen programmierbaren Speicherbaustein
(EEPROM oder Flash) auf dem die Programme abgelegt werden. Sie können Geschwindigkeiten
zwischen 8 und 60 MHz aufweisen und besitzen für den Betrieb gängiger Bustypen (z.B. RS232 oder
CAN) die nötigen Voraussetzungen. Sie sind mit 30-50€ schon deutlich preisgünstiger.
3.2.3. 8-Bit
Dies ist die Familie der kleinsten verfügbaren Controller. Sie besitzen nur sehr wenig Arbeitsspeicher
(bis 128kByte) und verfügen ebenfalls über einen programmierbaren Speicherbaustein. Der Preis (3-
10€) wird durch die Speichergröße und die Anzahl der Anschlüsse bestimmt. Je mehr Anschlüsse ein
Controller hat, desto mehr Peripherie kann er verwalten. Für die gängigen Bussysteme existieren
auch hier die nötigen Voraussetzungen.
3.3. Wahl der Hardware
Auch wenn Prozessoren der CISC oder auch die großen RISC-Rechner sehr leistungsstark sind,
fallen sie durch ihren hohen Preis als Knotenpunkte aus. Sie sind nur geeignet, um als zentrale
Steuereinheit zu dienen. Eine einfache Fahrsteuerung besteht schon aus wenigstens drei Elementen:
ein Entfernungsmesser, der nach vorn gerichtet ist und zwei Motoren für den Antrieb. Sollen diese
jeweils mit einer eigenen Steuerung versehen werden, steigen die Kosten enorm an (zwischen 150
und 500 Euro). Außerdem bieten sie extrem viele Möglichkeiten, die in solch einem Netzwerk
überhaupt nicht benötigt werden. Nicht jeder Knotenpunkt muss zum Beispiel einen Bildschirm
ansteuern können oder Emails verschicken, wie es große Prozessoren mit einem entsprechenden
Betriebssystem wie beispielsweise Microsoft Windows CE können.
Die richtige Wahl ist ein preisgünstiger Mikrocontroller mit 8-Bit-RISC-Architektur. Sie haben zwar
wesentlich weniger Speicher und bieten nicht die gleichen Möglichkeiten wie ein großer Controller,
aber die Leistung reicht aus, um eine oder auch mehrere Virtuelle Maschine zu betreiben, die
angeschlossenen Sensoren und Aktoren zu bedienen und die Kommunikation mit dem Netzwerk zu
übernehmen. Die Steuerung eines Roboters, wie dem Khepera mit seinen zwei Motoren und acht
Entfernungsmessern ist mit zehn Mikrocontrollern realisierbar, die im Einzelstückpreis bei ca. 5 Euro
liegen. Die gesamte Rechenleistung der Steuerung ist damit für ca. 50 Euro zu haben. Stattdessen
einen zentralen Prozessor für diesen Preis zu bekommen, erweist sich bereits schwierig. Er könnte
auch nicht ohne weiteres um neue Fähigkeiten erweitert werden, was mit dem Netzwerk kleiner
preiswerter Elemente kein Problem ist.
26.07.2004 Seite 15 von 85

Diplomarbeit: Modulares System Datenstrukturen und Kommunikation
4. Datenstrukturen und Kommunikation
Um die Kommunikation zwischen den Elementen eines verteilten Netzwerks in einem Roboter sinnvoll
gestalten zu können, müssen die Informationsmengen und Strukturen bekannt sein. Je nach Typ
können und müssen die unterschiedlichsten Informationen ausgetauscht werden.
4.1. Die Elemente des Netzwerks
In einem herkömmlichen Roboter übernimmt eine zentrale Recheneinheit die Steuerung. An sie sind
meist direkt die Sensoren und Aktoren angeschlossen. Diese entsprechen weitestgehend jenen, die
auch in einem Netzwerk von selbst steuernden Sensoren und Aktoren eingesetzt werden.
4.1.1. Sensoren
Das Wort Sensor ist vom Lateinischen „sentio“ abgeleitet, was soviel wie fühlen oder wahrnehmen
bedeutet. Ein Sensor ist also eine Einrichtung, um etwas wahrzunehmen. Die Technik ist dabei
bestrebt, die vorhandenen Sensoren (auch Rezeptoren genannt) der Natur nachzuahmen. Der
Mensch besitzt fünf so genannte Sinne: sehen, hören, fühlen, schmecken und riechen. Des Weiteren
gibt es noch den Gleichgewichtssinn, der aber kein dem Menschen permanent bewusster Sinn ist und
den Temperatursinn. Dazu kommen noch einige aus der Natur, die ein Mensch so nicht besitzt, wie
zum Beispiel: Ultraschall bei Fledermäusen und Delphinen, Magnetfeldorientierung bei Vögeln oder
Tag-Nacht-Rhythmus bei einigen Pflanzen (in einem abgedunkelten Raum zu beobachten). Die
meisten dieser Fähigkeiten sind sehr komplex und erfordern sehr viel Rechenaufwand bei der
Auswertung. Daher werden weltweit Sensoren entwickelt, die ein sehr eng umgrenztes
Aufgabengebiet haben. Dazu müssen die natürlichen Fähigkeiten der Menschen, Tiere und Pflanzen
näher betrachtet, vereinfacht und nach Möglichkeit zusammengefasst werden.
Sinn Natur Technik
Fühlen /
Druckempfindlichkeit
Mechanik
Druckempfindliche Zellen reagieren auf
Berührungen und senden ein Signal
aus
Gleichgewicht Unbewusstes „fühlen“ von winzigen
Härchen die auf die Schwerkraft
reagieren und die Lageänderungen
registrieren
Magnetfeldlinien Ähnlich Gleichgewicht, nur dass sehr
kleine magnetische Späne sich nach
dem Magnetfeld ausrichten und dies
erfasst wird
- Taster an/aus
- Drucksensor
- Kreiselsysteme
- Beschleunigungs
sensoren
- Magnetometer
26.07.2004 Seite 16 von 85

Diplomarbeit: Modulares System Datenstrukturen und Kommunikation
Sinn Natur Technik
Akustik
Hören Wellen in der Luft werden mechanisch
auf druck- oder schwingungs-
empfindliche Zellen übertragen
Ultraschall Hochfrequente Schallwellen werden
Schmecken /
Riechen
ausgestoßen und anhand der Lauflänge
des Signals wird die Entfernung
bestimmt
Chemie
Moleküle „docken“ an speziellen nur für
sie passende Rezeptorzellen an und
verursachen ein Signal
Optik
Sehen Lichtstrahlen werden auf zwei
verschiedene Zellarten geleitet:
- Stäbchen -> Farbsehen
- Zäpfchen -> Hell/Dunkel
- Mikrofon
- Ultraschallsensor
- Chemischer
Analysator
- Helligkeitssensor
- Kamera
Tabelle 4.1 - natürlich vorkommende Sensoren und ihre technische Umsetzung
Aus der obigen Auflistung ist erkennbar, dass es eigentlich für jeden natürlichen Sinn auch eine
technische Entsprechung gibt. Zum Teil sind diese aber in der Auswertung sehr rechenintensiv. Zum
Beispiel lässt sich das menschliche Sehen trotz hoch entwickelter Kameras und
Auswertungsschaltkreise nicht realitätsnah nachbauen. Es ist zu komplex und besteht nicht nur aus
der rein optischen Aufnahme der Informationen, sondern aus der unbewussten Verarbeitung und
Aufbereitung. Gleiches gilt für die meisten anderen Sinne, da die Natur verschwenderisch mit den
Rezeptoren umgehen kann. So enthält die Haut unzählige druckempfindliche Zellen. Ein Roboter, der
die gleiche Empfindlichkeit aufweisen wollte, würde einen immensen Rechenaufwand betreiben
müssen und allein schon durch die Anzahl der benötigten Sensoren extrem teuer. Daher werden nur
so viele Sensoren eingesetzt, wie unbedingt notwendig oder diese soweit vereinfacht, dass sie billig
sind und einfach auszuwerten. So reichen vielfach statt komplizierter Drucksensoren einfache Taster
aus, die nur an/aus als Zustand kennen und in einem größeren Abstand verteilt sind. Teilweise reicht
ein einziger Sensor pro Seite aus.
26.07.2004 Seite 17 von 85

Diplomarbeit: Modulares System Datenstrukturen und Kommunikation
Weiterhin existiert eine Vielzahl von Sensoren (z.B. Entfernungsmesser), die so in der Natur gar nicht
vorkommen, da sie aufgrund der Komplexität und des erstaunlichen unbewussten
Erinnerungsvermögens des Gehirns nicht benötigt werden.
Sensor Sinnvoller Wertebereich
Temperatur -100..100°C
Berührung/Taster aus/an = 0/1
Druck 0..x bar/pascal
Beschleunigung/Neigung 0..1000g (+ Richtung, meist durch Einbaurichtung bekannt)
Helligkeit Lichtdichte Lux (Lumen/m²)
Schalldruckpegel 0..130 dB (dezibel)
Umdrehung/Zähler 0..x
Drehzahl 0..100.000 U/min
Lichtstärke Candela (Lumen*Steradian-1)
Entfernung (IR, Sonar) 0..10.0000 mm (100m)
Video/Audio Datenstrom
Tabelle 4.2 - häufig verwendete Sensoren
Ein großer Wertebereich und damit auch eine hohe Genauigkeit mag für einige Anwendungen sinnvoll
sein, wird aber durch die Einschränkungen, wie sie in Kapitel 5 beschrieben werden, teilweise nicht
erreicht. Für die meisten Sensoren reicht ein Wertebereich von zwei Byte (also 65.536 verschiede
Werte), wie ihn die verwendeten Controller unterstützen, bei weitem aus.
4.1.2. Aktoren
Das Wort Aktor stammt ebenfalls aus dem Lateinischen und ist von ago, was (be)treiben
beziehungsweise tun bedeutet, abgeleitet. Ein Aktor tut also etwas. In der Natur ist damit meist eine
(Muskel-) Bewegung gemeint. In selteneren Fällen kann es sich auch um chemische (z.B. die
Verfärbung eines Chamäleons) oder optische (z.B. leuchtende Tiefseefische) Effekte handeln.
Muskeln lassen sich nur mit technisch hohem Aufwand umsetzen. Ein Muskel ist aus vielen kleinen
Muskelfasern zusammengesetzt, die sich, sobald ein Signal anliegt, zusammenziehen. Für genau
dieses Verhalten gibt es mittlerweile technische Lösungen. Lange Zeit war dies undenkbar und so ist
die häufigste Antriebsquelle ein (Servo-) Motor. Wird er mit Strom (bzw. einer alternativen
Energiequelle) versorgt, dreht sich seine Achse und diese Bewegung kann genutzt werden. Motoren
mit diesem Funktionsprinzip gibt es schon recht lange und dementsprechend sind sie hoch entwickelt
und in zahlreichen Varianten verfügbar. Als zweiten Motortypen haben sich Schrittmotoren etabliert.
Sie funktionieren ähnlich wie Servomotoren, drehen sich im Unterschied zu diesen aber nicht
26.07.2004 Seite 18 von 85

Diplomarbeit: Modulares System Datenstrukturen und Kommunikation
unkontrolliert lange, solange Strom anliegt, sondern benötigen eine extra Steuerung, die den Motor
jeweils nur um eine bestimmte Anzahl von Gradschritten weiterdreht. Damit können solche Motoren
sehr gut für Positionierungsarbeiten verwendet werden. Ein Nachteil liegt zum einen in der
Beschränkung auf die Gradschritte und zum anderen darin, dass wiederum nur eine Drehbewegung
erzeugt wird. Um dieses Problem zu lösen, wurden lineare Motoren entwickelt. Sie bewegen sich
längs auf einer Schiene und können damit die Energie direkt ohne den Umweg über eine Mechanik
(wie z.B. Seilzüge oder Schneckenradgetriebe) in lineare Bewegungen umsetzen. Die relativ neu auf
dem Markt befindlichen künstlichen Muskelfasern erzeugen ebenfalls eine lineare Bewegung. Sie
können aber im Vergleich zu den linearen Motoren weit weniger Kraft aufbringen. Dafür haben sie den
Vorteil, sehr klein zu sein. Da im Roboterbau oft beide Voraussetzungen gelten, finden sich sehr
häufig auch Pneumatiken oder Hydrauliken im Einsatz. Da die Kraft dabei durch flexible
Schlauchverbindungen übertragen wird, können die großen, die Kraft erzeugenden Bauteile an einem
beliebigen Ort untergebracht werden und müssen nicht direkt am zu bewegenden Bauteil angebracht
sein. Auf diese Art werden häufig Hände und Arme nachgebildet.
Aktor Einstellbarer Wert
Lampe, LED, … Helligkeit
Lautsprecher Ton (Frequenz)
Motoren
- Servo
- Schritt
- Linear
- Muskelfasern
Pneumatik / Hydraulik
Drehzahl, -richtung
Schritte, Grad
Entfernung
an /aus
Druck
Magnete an/aus
Tabelle 4.3 - häufig verwendete Aktoren
Wie schon bei den Sensoren gilt auch bei den Aktoren, dass ein hoher Wertebereich eine hohe
Genauigkeit erzeugt, diese aber durch die technischen Voraussetzungen (siehe Kapitel 5) auf zwei
Byte begrenzt werden muss. Dies sollte aber für die hier aufgeführten Aktoren ausreichen.
4.1.3. Weiterführende Elemente
Abgesehen von den in den vorigen Abschnitten angesprochenen Elementen sind noch viele weitere
denkbar und sinnvoll. Dies sind vor allem Spezialanwendungen, wie zum Beispiel ein neuronales
Netz, eine FFT oder eine Kamera mit Objekterkennung. Diese müssen über die gleichen
Kommunikationsmechanismen verfügen, wie die „normalen“ Knotenpunkte.
26.07.2004 Seite 19 von 85

Diplomarbeit: Modulares System Datenstrukturen und Kommunikation
4.2. Datenmenge
Wenn ein Netzwerk aus vielen verschiedenen Sensoren und Aktoren aufgebaut werden soll, muss die
Kommunikation möglichst einfach durchzuführen und doch so dynamisch sein, dass alle Daten
übertragen werden können. Dies gilt sowohl für die in Abschnitt 1 dieses Kapitels aufgeführten
Sensoren und Aktoren als auch für noch nicht bedachte neue Elemente. Für jedes dieser Elemente
könnte nun eine eigene spezifische Datenstruktur angelegt werden, die die abzufragenden Daten
enthält.
Diese könnte für einen Entfernungssensor zum Beispiel so aussehen:
Um den Sensor aber überhaupt zum laufen zu bringen, benötigt er auch Kenntnis über die Art der
Entfernungsmessung (Infrarot, Ultraschall) und Parameter, um die Daten auswerten zu können. Dazu
wird eine zweite Struktur benötigt:
Diese Strukturen wären für die meisten Sensoren unterschiedlich und sehr spezifisch. Ein Motor
beispielsweise bräuchte nur einen Parameter (Drehzahl) um ihn zum drehen zu bringen. Dazu
kommen aber noch etliche Parameter, die nur einmal eingestellt werden müssen, um verschiedene
Motortypen gleich anzusprechen.
Von einer einfachen für zukünftige neue Elemente offenen Kommunikation kann dabei also nicht die
Rede sein. Es könnte eine dynamische Struktur entwickelt werden, in der am Anfang der Aufbau steht
(ähnlich den Chunks im Grafikformat GIF) und damit alle möglichen Datenmengen erfasst werden,
aber dies ließe sich mit der in Kapitel 5 vorgestellten Programmiersprache nur schwer realisieren.
Einfacher ist es stattdessen, für jeden Parameter einen eigenen Funktionsaufruf vorzusehen. Der
fragende Netzwerkknoten kann also ganz gezielt die Informationen abrufen, die für ihn wichtig sind
und die Parameter setzen, die ein anderer Knoten unter Umständen benötigt. Weiterhin ermöglicht
diese Herangehensweise ein einfaches Antwortverfahren.
Statt der komplexen Datenstrukturen erfolgen die Aufrufe lediglich mit zwei beziehungsweise drei
Parametern:
typedef struct TDistanceSensor
{
int Distance;
int Reach;
};
typedef struct TDistanceSensorParameter
{
int Reach;
int Type; // infrared, ultrasonics
int EmissionAngle;
...
};
value:=Get(id,parameter_id);
Put(id,parameter_id,value);
26.07.2004 Seite 20 von 85

Diplomarbeit: Modulares System Datenstrukturen und Kommunikation
Die ID gibt an, welcher Knotenpunkt im Netzwerk gemeint ist. Um nicht nur einen (den Haupt-) Wert
setzen und lesen zu können, sondern um auch die Einstellungen des Elements einfach einstellen zu
können, muss noch angegeben werden, welcher Wert oder welche Eigenschaft gemeint ist.
Parameter-ID Beschreibung
0 Hauptwert (Entfernung, Helligkeit, Drehzahl usw.)
1 erste Eigenschaft (maximale Entfernung usw.)
2 …
Tabelle 4.4 - Parametrisierung
4.3. Adressierung
Um die Knotenpunkte ansprechen zu können, müssen diese adressiert werden. Dafür gibt es
verschiedene Herangehensweisen. Diese sollen an einem Beispiel erläutert werden.
4.3.1. Direkte Adressierung
Der Roboter soll bei einer bestimmten Umgebungstemperatur stehen bleiben. Dafür muss ein
Knotenpunkt dazu programmiert werden, dies zu tun. Praktischerweise übernimmt dies die Einheit, die
sowieso die Motoren ansteuert. Dies kann direkt mit der bekannten Adresse eines Temperatursensors
dessen Wert abfragen. Wenn der Sensor die ID 4 hat, sieht der Programmteil folgendermaßen aus:
...
temperature:=Get(4,0);
if temperature>60 then
motor_speed:=0;
...
Der Nachteil dabei ist, dass die ID des Temperatursensors bekannt sein muss.
4.3.2. Gruppenadressierung
Um zu erreichen, dass auch ohne Kenntnis der genauen Adresse ein Wert eines bestimmten Typs (im
Beispiel die Temperatur) abfragbar ist, können Broadcast-Aufrufe (Gruppenaufrufe) verwendet
werden. Das Programm fragt nicht mehr einen bestimmten Temperatursensor, dessen Adresse es
kennen muss, sondern erkundigt sich im Netzwerk allgemein: hat irgendein Sensor eine Temperatur.
Dazu muss die Adressierung gruppenweise erfolgen. So könnte die ID 8 für Temperaturen vorgemerkt
sein. Der Programmteil muss dann folgendermaßen lauten:
...
temperature:=Get(8,0);
if temperature>60 then
motor_speed:=0;
...
In dieser Variante der Adressierung würden aber alle Temperatursensoren antworten und es müsste
ein Auswahlverfahren existieren, welcher nun vom Programm verwendet wird.
26.07.2004 Seite 21 von 85

Diplomarbeit: Modulares System Datenstrukturen und Kommunikation
Diese Art der Adressierung macht daher bei einigen Sensor- und Aktortypen keinen Sinn. Gerade das
Setzen von Werten, wie beispielsweise der Motordrehzahl, benötigt meist die direkte Angabe der
richtigen Adresse, da sonst das Verhalten des Roboters unvorhersagbar wäre. Eine Ausnahme ist die
Abschaltung aller Teilnehmer oder eine ähnliche Aktion.
4.3.3. Kombinierte Adressierung
Am idealsten ist daher eine kombinierte Anwendung, die die Verwendung beider Verfahren
unterstützt.
Wie im Kapitel 5 noch erläutert werden wird, existiert in der verwendeten Programmiersprache nur ein
einziger Datentyp: die 2-Byte-Ordinalzahl. Durch diese Einschränkung können maximal 65.536
verschiedene Adressen genutzt werden. Dies ist auch für einen Roboter, der aus vernetzen Sensoren
und Aktoren besteht, eine recht hohe Zahl, die in einem einzigen Roboter wohl kaum erreicht werden
wird.
Um Gruppenadressen einzuführen, kann ein einzelnes Bit benutzt werden, um anzuzeigen, ob eine
Geräteadresse verwendet wird oder eine Gruppenadresse. Dadurch reduziert sich die Anzahl der
direkten Geräteadressen auf 32.767. Hinzu kommt aber die gleiche Anzahl an Typengruppen.
Um zu unterscheiden, welche Art von Adresse vorliegt, ist es am sinnvollsten, das höchste Bit in der
Adresse zu verwenden. Damit liegen alle Gruppenadressen oberhalb der 32.768.
Die beiden Beispielaufrufe würden dann so aussehen:
...
temperature:=Get(4,0);
if temperature>60 then
motor_speed:=0;
...
Als zweite Variante könnten die 16 zur Verfügung stehenden Bits so unterteilt werden, dass ein Teil
die Gruppenzugehörigkeit und der Rest die Nummer innerhalb der Gruppe angibt.
Mögliche sinnvolle Kombinationen (Einteilungen) sind:
Gruppe Geräte
Bit Gruppen Bit Geräte pro Gruppe
4 16 12 4096
8 256 8 256
...
temperature:=Get(32776,0);
if temperature>60 then
motor_speed:=0;
...
Die Zusammenfassung zu einer Adresse muss entweder der Endanwender vornehmen oder kann
sinnvollerweise auch automatisch von der Maschine übernommen werden.
26.07.2004 Seite 22 von 85

Diplomarbeit: Modulares System Datenstrukturen und Kommunikation
Die Aufrufe müssen dafür folgendermaßen geändert werden: GET(group_id,id,parameter);
Das Beispiel sieht dann wie folgt aus:
...
temperature:=Get(8,4,0);
if temperature>60 then
motor_speed:=0;
...
Diese Art der Adressierung ist die variabelste und kann am besten auf die verschiedenen
Robotertypen angewendet werden.
4.3.4. Adressierung im CAN-Bus
Die Verwendung des CAN-Busses (siehe auch Kapitel 4) bringt eine Einschränkung in der Vergabe
der Adressen mit sich. In einer CAN-Nachricht sind 29 Bit für die Adressierung vorgesehen. Diese ist
keine Adresse im herkömmlichen Sinne. Sie bestimmt nicht den Empfänger sondern versieht die
Nachricht mit einer Kennung. Physikalisch gesehen empfangen alle Knotenpunkte die Nachricht. Ein
Empfangsregister mit einer frei konfigurierbaren Bitmaske entscheidet automatisch, ob die Nachricht
für den Knoten interessant ist oder nicht. Dies erfolgt bereits im Bus-Controller und ist von der darüber
liegenden Software unabhängig.
Von den 29 Bit werden normalerweise fünf Bit für eine Priorisierung der Nachrichten und die Fluss-
Steuerung verwendet. Durch die Priorisierung ist es möglich, dass sich im Kollisionsfall die höher
priorisierte und damit wichtigere Nachricht durchsetzt und gesendet wird. Außerdem wird es möglich,
dass eine laufende Sendung durch eine höher priorisierte Nachricht unterbrochen wird, die zum
Beispiel einen Fehler meldet.
Von den zur Verfügung stehenden 29 Bit sind also nur 24 Bit für die Adressierung verwendbar. Um
auf Anfragen reagieren zu können und um den Nachrichtenempfang bestätigen zu können, wie es im
CAN-Protokoll vorgeschrieben ist, benötigt der Empfänger die Adresse des Senders. Diese könnte in
den Datenbytes der Nachricht verpackt werden. Da diese aber aus maximal acht Bytes bestehen und
zusätzlich zu den eigentlichen Daten noch einiges an Zusatzinformationen übertragen werden muss,
wird die Senderadresse mit in dem Identifier verpackt. Es kann also nur die Hälfte der Adressbits für
eine Adresse verwendet werden, also 12 Bit.
Diese 12 Bit können in einer kombinierten Adressierung wie im vorigen Abschnitt beschrieben
verwendet werden. Es würden dann 2.047 Geräte in 2.047 verschiedenen Gruppen ansprechbar sein.
Dies ist eine ausreichend hohe Anzahl.
Bei der zweiten Variante besteht das Problem, dass 12 Bit knapp bemessen sind. So können zum
Beispiel 15 Gruppen mit jeweils bis zu 255 Geräten angesprochen werden. Sie bietet allerdings einen
Vorteil, der diese Beschränkung größtenteils wieder gut macht. Dadurch, dass der Identifier einer
Nachricht nicht nur mit einer Adresse belegt ist, sondern auch über eine Gruppenkennung verfügt,
26.07.2004 Seite 23 von 85

Diplomarbeit: Modulares System Datenstrukturen und Kommunikation
kann der Empfänger entscheiden, ob er eine Anfrage von diesem Sendertyp überhaupt bearbeitet.
Dadurch kann ein Rechtesystem geschaffen werden, welches die Sicherheit im Bus erhöht. So
können zum Beispiel Systemkommandos nur von autorisierten Knotenpunkten verschickt werden und
nicht von irgendeinem Sensor, der nur das System stören würde. Daher wird diese Art der
Adressierung im Weiteren verwendet. [etsch], [law]
4.4. Adressierung im Netz
Die kombinierte Adressierung nach der im vorigen Abschnitt beschriebenen zweiten Variante
ermöglicht die größtmögliche Variabilität bei gleichzeitiger hoher Sicherheit. Die Elemente des
Netzwerkes werden also in maximal 15 Gruppen eingeteilt und mit einer 8-Bit-Identifizierungsnummer
versehen. Bei allen Anfragen und Schreiboperationen muss angegeben werden, welchen Parameter
die Operation betrifft.
4.5. Klassifizierung der Gruppentypen und ihrer Adressen
Für die im ersten Abschnitt dieses Kapitels vorgestellten Sensoren und Aktoren müssen für die
Gruppenadressierung ID vergeben werden. Weiterhin sind zusätzliche Eigenschaftswerte aufgeführt,
die abgefragt und je nach Berechtigung auch gesetzt werden können.
Nr. Sensor/Aktor - Hauptwert (param=0) Zusätzliche Werte (param=1,2,..)
1 Temperatur Minimal- und Maximaltemperatur
2 Berührung/Taster -
3 Druck Maximaler Druck
4 Beschleunigung/Neigung -
5 Helligkeit -
6 Umdrehung/Zähler -
7 Drehzahl -
8 Entfernung (IR, Sonar) Maximale Entfernung
9 Lampe, LED - Helligkeit -
10 Motoren - Drehzahl Maximale Drehzahl
11 Pneumatik / Hydraulik - Druck Maximaler Druck
12 Magnete -
13 Lautsprecher -
14 Mikrofon -
15 Kontrollgeräte / Programmiereinheiten usw. -
Tabelle 4.5 - Gruppentypen und -adressen
26.07.2004 Seite 24 von 85

Diplomarbeit: Modulares System Datenstrukturen und Kommunikation
Falls diese Gruppen nicht ausreichen muss entweder die Adressierung verschoben werden (mehr
Gruppen, weniger Elemente pro Gruppe) oder die Datenbreite erhöht werden, was eine Vergrößerung
des Speicherbedarfs der Virtuellen Maschine hervorruft. Als dritte Möglichkeit könnten die acht
Adressbit, die für die Geräteidentifizierung nötig sind, je nach Bedarf nochmals für eine
Untergruppierung verwendet werden, wenn nur wenige Geräte dieses Typs erwartet werden. Die
verwendeten Controller im Netzwerk sind auf diese Arbeitsweise vorbereitet, nur die Adressierung aus
der Virtuellen Maschine heraus muss angepasst oder per Hand vollzogen werden.
4.6. Systemkommandos
Jeder Knoten im Netzwerk besitzt eine Virtuelle Maschine, deren ablaufendes Programm über zwei
Befehle (Get, Put) mit den anderen Knotenpunkten kommunizieren kann. So können die Werte
abgefragt und gesetzt werden, die im vorigen Abschnitt aufgeführt sind.
Zusätzlich wird noch eine Anzahl von Systemkommandos benötigt, die die Virtuellen Maschinen
steuern. Damit diese die normalen Werte aus dem vorigen Abschnitt (die durch spätere Erweiterungen
eventuell wesentlich umfangreicher ausfallen) nicht stören, sind sie mit einer hohen Nummerierung
versehen. Sie werden von dem Programm auf dem Controller direkt ausgeführt, ohne dass dafür ein
Skript innerhalb der Virtuellen Maschine gestartet werden muss.
Parameter-ID Funktion
1001 Deaktivieren
1002 Neustart
1003 Selbsttest
1004 Speicherplatz
1005 Gruppe
1006 Uhrzeit abfragen/setzen
1007 Programmanzahl
1008 Programmgröße
1009 Programmdownload
1010 Skript starten
1011 Skript stoppen
1012 Skript in einer Schleife aufrufen (Anzahl)
1013 Skript zu einer bestimmten Zeit starten
1014 Skript zu einer bestimmten Zeit stoppen
1015 Skript bei einem bestimmten Schwellwert starten
1016 Skript bei einem bestimmten Schwellwert stoppen
Tabelle 4.6 - Systemkommandos
26.07.2004 Seite 25 von 85

Diplomarbeit: Modulares System Vergleich von Bussystemen für die Kommunikation
5. Vergleich von Bussystemen für die Kommunikation
Der Begriff Roboter ist sehr weit gefasst. Zum einen kann ein kleines, mobiles und autarkes Fahrzeug
gemeint sein. Es wird meist von zwei getrennt motorisierten Rädern angetrieben oder besitzt sogar
einfache Beine. Zum anderen kann ein Roboter auch eine Nachbildung des menschlichen Körpers
oder eines Körperteiles sein. Millionenteure Entwicklungen bei Honda und anderen Firmen machen
dort immer schnellere Fortschritte und bringen Roboter, die uns ähnlich sehen und bald ebenso
geschickt sind, hervor. Dann gibt es noch die Gruppe der Haussysteme, die roboterartige Züge
aufweisen, aber räumlich festgelegt sind. So kann eine Überwachung eines großen Gebäudes von
einem Roboter übernommen werden, der aus verschiedenen stationären und mobilen Teilen besteht.
Die visuelle Einheit eines Wächterroboters muss nicht an ihm befestigt sein, sondern kann auch aus
vielen Kameras bestehen, die am Gebäude montiert sind und auf die er über ein geeignetes
Kommunikationsmedium zugreift.
In der Praxis wird für jede dieser Anwendungen ein eigenes Verfahren eingesetzt. Die Anzahl der
Sensoren und Aktoren, die Art der Recheneinheit und auch die Datenübertragung sind spezifisch für
jedes einzelne Problem gelöst. Damit wird es aber unmöglich, mit nur einem System variabel zu
bauen und zu experimentieren und alle Bereiche abzudecken. Um nun mit einem verteilten Netzwerk
all diese Aufgaben wahrnehmen zu können, muss es über einen einfachen robusten
Datenübertragungsmechanismus verfügen.
5.1. Einteilung der Bussysteme
Um Systeme und Komponenten miteinander zu verbinden, werden zwischen diesen Schnittstellen
vereinbart. Diese können durch ein busfähiges (z.B. SCSI) oder durch ein nicht busfähiges (z.B.
RS232) System realisiert werden. Nicht busfähige Verbindungen dienen dem direkten Anschluss
eines Gerätes (z.B. ein Modem) an eine zentrale Recheneinheit. Busfähige Verbindungen
ermöglichen den Betrieb mehrerer Teilnehmer (z.B. Festplatten). Dadurch können viele Geräte relativ
einfach miteinander kommunizieren. Jeder Teilnehmer verfügt über ein Interface, welches die Signale
auf dem Bus dekodiert und diejenigen auswertet und weitergibt, die für dieses Gerät bestimmt sind.
Für ein Netzwerk von Sensoren und Aktoren sind busfähige Verbindungen die richtige Wahl.
Busfähige Verbindungen lassen sich in verschiedene Gruppen einteilen. Die Bandbreite geht von
integrierten Bussystemen, wie sie in kleinen integrierten Schaltungen vorkommen, bis zu ganze
Gebäudekomplexe umfassende Feldbusse. Dabei wird nach seriellen und parallelen Bussystemen
und synchronen und asynchronen Übertragungen unterschieden.
26.07.2004 Seite 26 von 85

Diplomarbeit: Modulares System Vergleich von Bussystemen für die Kommunikation
5.1.1. Parallele Bussysteme
Das Prinzip der parallelen Datenübertragung beruht darauf, dass alle Bits einer Dateninformation
gleichzeitig (bitparallel) vom Sender zum Empfänger übertragen werden. Für eine Datenübertragung
werden neben den eigentlichen Zeichen noch weitere Informationen benötigt, die die Übertragung
steuern und Auskunft über den Zustand der Geräte geben. Die Steuerung kann sowohl in Software als
auch in Hardware erfolgen. Übernimmt es die Software, müssen Steuersignale vereinbart sein. Erfolgt
es hardwareseitig, werden zusätzliche Leitungen benötigt. Die Daten werden adressiert übertragen.
Dadurch kann schon durch die Hardware festgelegt werden, ob die Nachricht für den Empfänger von
Bedeutung ist. Parallele Schnittstellen sind in verschiedenen Ausführungen anzutreffen:
Integrierter Bus
Ein integrierter Bus verbindet sowohl integrierte Komponenten (z.B. Speicher, Interrupt-Controller)
direkt innerhalb eines hoch integrierten Bauelementes (z.B. Mikrocontroller) als auch externe vom
Mikroprozessor abhängige Komponenten (z.B. auf einem PC-Mainboard).
Beispiele: Daten-, Adress- und Steuerleitungen
System-Bus
Ein System-Bus ermöglicht die Ankopplung von Baugruppen (Platinen und Einschübe) wie Grafik-,
Prozessor-, oder Speicherkarten.
Beispiele: VME-, Multi-, PC-Bus
Paralleler Peripherie-Bus
Ein paralleler Peripherie-Bus dient der Ankopplung von Peripheriegeräten wie Druckern oder
Scannern an ein Computersystem.
Beispiel: SCSI
Instrumentierungs-Bus
Ein Instrumentierungs-Bus wird hauptsächlich in der Messtechnik zum Koppeln von Messgeräten
eingesetzt.
Beispiel: VXI, IEC
5.1.2. Serielle Bussysteme
Die serielle Datenübertragung zeichnet sich dadurch aus, dass im Gegensatz zur parallelen
Übertragung weit weniger Verbindungsleitungen benötigt werden, die in der Regel auch weit größere
Entfernungen überbrücken können. Die Daten werden bitweise zwischen den Geräten übertragen.
Zwischen dem Sender und dem Empfänger müssen Vereinbarungen getroffen werden, wann die
Daten gültig sind. Dafür ist es notwendig, dass Beginn und Ende der Bitfolge eindeutig festgelegt sind.
26.07.2004 Seite 27 von 85

Diplomarbeit: Modulares System Vergleich von Bussystemen für die Kommunikation
Komponenten-Bus
Ein Komponenten-Bus dient sowohl der Verbindung von Bauelementen (zum Beispiel Audio- oder
Video-IC) als auch der von kompletten Schaltungseinheiten.
Beispiele: I²C, Access Bus
Serieller Peripherie-Bus
Ein serieller Peripherie-Bus ist eine kostengünstige Alternative zum parallelen Peripherie-Bus. Er
weist eine einfachere Verkabelung auf und dient dem Anschluss von unterschiedlichsten
Peripherieeinheiten wie Kameras, Tastaturen oder auch Festplatten.
Beispiel: USB
Feldbus
Ein Feldbus ist ein lokales Bussystem für Industrieumgebungen, welches in der Regel mit einem
übergeordneten Bussystem (Systembus) verbunden wird.
Beispiele: Bitbus, Profibus, CAN-Bus
5.1.3. Serielle Betriebsarten
Es wird zwischen drei Betriebsarten (Richtungen) unterschieden.
Richtungsbetrieb
(Simplex)
Wechselbetrieb
(Half Duplex)
Gegenbetrieb
(Duplex, Full Duplex)
Die Rollen von Sender und Empfänger
sind exakt festgelegt. Der Datenfluss
erfolgt nur in eine Richtung.
Alle Geräte können sowohl senden, als
auch empfangen. Aber immer nur eins
davon.
Tabelle 5.1 - serielle Betriebsarten
Alle Geräte können zur gleichen Zeit
Sender und Empfänger sein.
5.1.4. Symmetrische und asymmetrische serielle Schnittstellen
Im Prinzip benötigt eine serielle Verbindung nur eine einzige Leitung für die Datenübertragung. Dies
wird bei asymmetrischen Schnittstellen umgesetzt. Das Datensignal bezieht sich auf die Masseleitung.
Störimpulse wirken sich direkt als Fehler aus. Symmetrische Schnittstellen verwenden zwei
Datenleitungen und die Dateninformation entspricht der Differenz des Spannungspegels, der auf den
beiden Leitungen übertragen wird. Diese Schnittstellen stellen sich daher störungssicherer dar.
26.07.2004 Seite 28 von 85

Diplomarbeit: Modulares System Vergleich von Bussystemen für die Kommunikation
Signal
Signal +
Signal -
Abbildung 5.1 - Asymmetrische und symmetrische Schnittstelle
5.1.5. Synchrone und asynchrone Übertragung
Synchrone Übertragung
Für synchrone Übertragungen werden Taktleitungen verwendet. Der Sender gibt gleichzeitig mit den
Daten auf einer extra Leitung ein Taktsignal aus. Die zu übertragenden Daten werden zu Blöcken
zusammengefasst, die von speziellen Steuerzeichen eingefasst sind. Der Taktgenerator des
Empfängers synchronisiert sich dadurch auf die eingehenden Daten.
Asynchrone Übertragung
Sender
Asymmetrische Schnittstelle
Störimpuls
101100111101011
Sender
101100100001011
kein Fehler
Bei asynchronen Übertragungen werden keine Taktleitungen verwendet. Die Informationen zur
Synchronisierung werden jedem einzelnen Zeichen mitgegeben. Es werden keine Blöcke gebildet.
Dadurch weist diese Form der Übertragung ein niedrigeres Nutzdatenverhältnis als die synchrone auf.
Durch die einfachere Schaltungstechnik ist sie aber ideal für den Anschluss langsamerer Peripherie.
26.07.2004 Seite 29 von 85
Fehler
Symmetrische Schnittstelle
Störimpuls
Empfänger
Empfänger

Diplomarbeit: Modulares System Vergleich von Bussystemen für die Kommunikation
5.1.6. Buszugriffsverfahren
Es werden verschiedene Buszugriffsverfahren unterschieden:
Master/Slave Gesteuert durch eine zentrale Instanz (Master) durch Aufruf
der Teilnehmer (Slave) in einer bestimmten Reihenfolge
Delegated Token Gesteuert durch eine zentrale Instanz die das Buszugriffsrecht
vergibt, das der Teilnehmer vom Master erhält und an diesen
zurückgibt
Token-Passing Das Buszugriffsrecht wird vom Teilnehmer an den nächsten
Zeitschlitze
(Time Division
Multiple Access)
Zufälliger Buszugriff
(Carrier Sense,
Multiple Access)
Teilnehmer weitergereicht (alle sind Master)
Jeder Teilnehmer besitzt nach einem festen Zeitplan das
Buszugriffsrecht
Jeder Teilnehmer ist bezüglich des Buszugriffs
gleichberechtigt und ist somit Master. Er kann damit auf den
Bus zugreifen, sobald dieser frei ist. Durch
Kollisionserkennung muss die Fehlerfreiheit der Daten
garantiert werden.
Ringschiebeprinzip Kein Buszugriffsverfahren im eigentlichen Sinne. Die
Teilnehmer sind über Punkt-zu-Punkt-Verbindungen in einer
Ringstruktur mit dem Master verbunden und geben die Daten
zyklisch weiter.
Tabelle 5.2 - Buszugriffsverfahren
5.1.7. Netzwerktopologien
Die Topologie eines Netzwerks ist die Verbindungsstruktur zwischen den Teilnehmern. Sie ist
maßgeblich für den Aufwand der physikalischen Netzstruktur, die Einsatzgrenzen und die
Randbedingungen.
Sterntopologie
Alle Teilnehmer sind über Punkt-zu-Punkt-Verbindungen mit einem zentralen Teilnehmer verbunden.
Vorteile Nachteile
- jeder hat eine eigene Verbindung
- einfache Einbindung neuer Teilnehmer
- keine Zugriffsregelung nötig
- große Gesamtlänge der Verbindungen
- Ausfall der Zentrale beendet das Netz
- zentraler Teilnehmer benötigt viele
Schnittstellen
26.07.2004 Seite 30 von 85

Diplomarbeit: Modulares System Vergleich von Bussystemen für die Kommunikation
Bustopologie
In einem Bus erfolgt eine elektrisch passive Ankopplung aller Teilnehmer an ein gemeinsames
Medium. Die von den Teilnehmern gesendeten Informationen stehen allen zur Verfügung.
Baumtopologie
Vorteile Nachteile
- einfache Verkabelung
- einfache Ankopplung
- einfache Erweiterung
- Ausfall eines Teilnehmers hat keinen
Einfluss auf den Rest
- Beliebige logische
Kommunikationsstrukturen möglich
- begrenzte Buslänge (durch Repeater
erweiterbar)
- Buszugriffsregelung erforderlich
- Teilnehmeridentifizierung nötig
In einem Baum ist durch Verzweigungselemente die Aufspaltung des Netzes in Abhängigkeit von
geografischen Anforderungen möglich. Auch die Verbindung verschiedener Topologien wird möglich.
Ringtopologie
Vorteile Nachteile
- minimierter Verkabelungsaufwand
- variabler Aufbau des Netzwerks
möglich
- höhere Kosten durch die
Verzweigungselemente
Ein Ring besteht aus einer geschlossenen Kette von gerichteten Punkt-zu-Punkt-Verbindungen.
Vorteile Nachteile
- hohe Buslänge, da jeder Teilnehmer
das Signal auffrischt
- einfache Teilnehmeridentifizierung
über die geografische Position
- bei Ausfall eines Teilnehmers fällt das
ganze Netz aus (durch Redundanz oder
Überbrückung vermeidbar)
- Eingliederung eines neuen Teilnehmers
erfordert eine Betriebsunterbrechung
26.07.2004 Seite 31 von 85

Diplomarbeit: Modulares System Vergleich von Bussystemen für die Kommunikation
5.2. Das OSI-Schichtenmodell
Einen internationalen Standard für Kommunikationssysteme stellt das OSI-Modell (Open System
Interconnection) dar. Es bildet ein Basisreferenzmodell für Schnittstellen, in dem eine Protokollstruktur
beschrieben ist, welche eine Unabhängigkeit von Hard- und Software und die Kommunikation
zwischen unterschiedlichen Systemen ermöglichen soll. Das OSI-Modell besteht aus sieben
Schichten, die eindeutig festgelegte Aufgaben übernehmen. Die Informationen werden grundsätzlich
nur zwischen benachbarten Schichten ausgetauscht. In der Praxis werden nicht immer alle Ebenen
getrennt voneinander ausgeführt. In der Minimalausführung besteht ein OSI-System aus mindestens
den unteren beiden Ebenen. Alle darüber liegenden Schichten werden dann zu einer einzigen
zusammengefasst.
Schicht Bezeichnung Funktion
7 Anwendungsschicht Anwendung
6 Darstellungsschicht Darstellung
5 Sitzungsschicht Steuerung
4 Transportschicht Transport
3 Vermittlungsschicht Vermittlung
2 Sicherungsschicht Sicherung
1 Physikalische Schicht Bitübertragung
Tabelle 5.3 - Das OSI-Schichtenmodell
Physikalische Schicht
Anwendungsorientierte
Schichten
Netzorientierte Schichten
Hier werden die elektrischen, mechanischen und funktionalen Eigenschaften der Schnittstelle
festgelegt.
Sicherungsschicht
Diese Schicht regelt die Synchronisation zwischen den Teilnehmern und beinhaltet die
Fehlererkennung und die Korrekturmechanismen.
Vermittlungsschicht
Hier erfolgt der Aufbau der Verbindung zwischen den Kommunikationspartnern. Des Weiteren
realisiert diese Schicht auch die Adressierung, die Vermittlung und den Verbindungsauf- und -abbau.
26.07.2004 Seite 32 von 85

Diplomarbeit: Modulares System Vergleich von Bussystemen für die Kommunikation
Transportschicht
In dieser Schicht erfolgt der Datentransport zwischen den Endteilnehmern. Weiterhin erfolgt - wenn
nötig - die Zerlegung in kleinere Einzelpakete und eine weitere Fehlerkontrolle. Bei fehlenden oder
verfälschten Daten wird eine Wiederholung angeregt und es wird die korrekte Reihenfolge der Pakete
wiederhergestellt.
Sitzungsschicht
Hier erfolgt die Synchronisation und Organisation der Daten- und Steuerinformationen für die sich im
Dialog befindlichen Stationen. Sie wird auch als Kommunikationssteuerschicht bezeichnet und steuert
unter anderem den Datenfluss, die Datenzwischenspeicherung und die Zeitspanne zwischen
Verbindungsauf- und -abbau (auch als Sitzung bezeichnet).
Darstellungsschicht
In dieser Schicht erfolgt eine Aufbereitung der Daten für die Anwendungsschicht. Es erfolgt eine
Kontrolle der Datenein- und -ausgabe, die Durchführung von Datenkonvertierungen und
Formatanpassungen.
Anwendungsschicht
Hier erfolgt die Regelung für den Zugriff auf die Anwenderprogramme. Die Aufgabe der
Anwendungsschicht ist die Bereitstellung von anwenderspezifischen Protokollen wie die
Identifizierung der Teilnehmer und die Überprüfung der Zugriffsberechtigung.
5.3. Überblick über gängige Bussysteme
Für ein vernetztes System von Sensoren und Aktoren sind einige Faktoren für das zu verwendende
Bussystem ausschlaggebend. Dies sind zum einen Robustheit und Fehlertoleranz. Wird ein
Knotenpunkt entfernt, sollte das restliche System weiterlaufen. Zum anderen muss eine einfache
Anschlussmöglichkeit gegeben sein. Kabel mit sehr vielen Leitungen sind anfälliger gegen
mechanische Belastungen. Die Stecker- beziehungsweise Verbindungseinheiten werden mit
zunehmender Leitungszahl komplizierter und damit fehleranfälliger.
5.3.1. Paralleler System-Bus PC
Die allgemein als PC (Personal Computer) bezeichneten Computer auf der Basis von Intel-
Prozessoren stellen den größten Marktanteil auf dem Computersektor dar. Ein Grund dafür ist das
verwendete Slotkonzept, welches eine individuelle Ausstattung des Computers mit verschiedener
Hardware gestattet. Mit dem Original-PC der Firma IBM wurde der 8-Bit-PC-Bus eingeführt, der später
als 16-Bit-Variante unter der Bezeichnung ISA in nahezu jedem Rechner verwendet wurde. Dieser
Bus ist aber durch die hohe Leitungszahl nicht für verteilte Netze geeignet.
26.07.2004 Seite 33 von 85

Diplomarbeit: Modulares System Vergleich von Bussystemen für die Kommunikation
5.3.2. Paralleler Peripherie-Bus SCSI
SCSI bietet eine busorientierte Geräteschnittstelle als Peripheriebus und ähnelt in seiner Art dem IEC-
Bus. Im Unterschied zu diesem ist er multi-master-fähig. Das heißt, es kann prinzipiell jeder
Teilnehmer die Funktionalität des Masters übernehmen, falls der Master ausfällt. Nachteilig sind die
Begrenzungen der Anzahl der Teilnehmer, die maximale Kabellänge und die hohe Leitungsanzahl.
Positiv fällt die höhere Datenübertragungsrate ins Gewicht.
5.3.3. Paralleler Instrumentierungsbus IEC
Der IEC-Bus ist ein weltweiter Standard in der Messtechnik zur Kopplung von Geräten wie Voltmetern
oder Frequenzzählern. Nachteil dieser Lösung ist, dass ein IEC-Bus auf 15 Geräte (inklusive
Controller) beschränkt ist und die Kabellänge auf maximal 2 Meter spezifiziert ist. Die definierte
maximale Datenübertragungsrate von 1MByte/s wäre aber ausreichend. Er arbeitet asynchron und
das langsamste Gerät bestimmt über ein 3-Leitungs-Handshakeverfahren die Geschwindigkeit. Es
sind ziemlich viele Leitungen für den Betrieb notwendig, was potentielle Fehlerquellen erzeugt.
5.3.4. Serielle RS232
Die RS232 (auch V24 genannt) ist die wohl am häufigsten verwendete serielle Schnittstelle. Da sie
nur für die direkte Verbindung zweier Geräte gedacht ist, fällt sie von vornherein als Wahl für ein
Netzwerk heraus.
5.3.5. Serieller Komponenten-Bus I²C
Der I²C-Bus ist eine Entwicklung von Philips für die serielle Verbindung von integrierten Schaltungen
auf einer Platine. Da lediglich zwei Datenübertragungsleitungen (Datenleitung und Taktleitung)
benötigt werden, ist der Anschluss einfacher als bei parallelen Systemen. Jedes I²C-Bauelement
verfügt über eine eigene Adresse und kann sowohl als Sender als auch als Empfänger arbeiten. Des
Weiteren ist der Bus multi-master-fähig. Die Generierung des Taktsignals wird vom Master
übernommen. Ein Nachteil ist, dass die Adressen der Bauelemente meist vom Hersteller festgesetzt
sind und nur in einigen Fällen minimal angepasst werden können (untere 3 Bits). Auf dem Bus darf
keine Adresse mehrfach vorkommen. Der I²C ist damit mit Einschränkungen für ein verteiltes
Netzwerk gut geeignet.
5.3.6. Serieller Peripherie-Bus USB
Im Gegensatz zum I²C werden beim USB (Universal Serial Bus) die Adressen nicht vom Hersteller
vergeben, sondern werden vom Master nach dem Einschalten des Systems automatisch zugewiesen.
Da der USB mit einer differentiellen (symmetrischen) Datenübertragung arbeitet, benötigt er zwei
Datenleitungen. Zusätzlich wird eine Leitung zur Spannungsversorgung für die Endgeräte hinzugefügt.
Über diese können sich Geräte mit geringer Stromaufnahme (= 500mA) mit Energie versorgen. Die
Verbindungen werden von Gerät zu Gerät ausgeführt. Damit ist USB im eigentlichen Sinne kein Bus,
sondern stellt sich topologisch als kombinierte Strang-Sternstruktur dar. Ein Gerät sollte aus diesem
Grund immer auch als Hub fungieren, um den Anschluss weiterer Geräte zu ermöglichen. Parallel
26.07.2004 Seite 34 von 85

Diplomarbeit: Modulares System Vergleich von Bussystemen für die Kommunikation
können auch separate Hubs eingesetzt werden. Durch diesen Zusatzaufwand eignet sich USB kaum
für komplexe Netzwerke.
5.3.7. Serieller Feldbus CAN
CAN (Controller Area Network) ist ein Bus aus der Automobilindustrie und seit 1994 das am meisten
verbreitete Protokoll in diesem Sektor. Da der CAN-Bus multi-master-fähig ist und dies noch durch ein
zufallsorientiertes Zugriffsverfahren mit Kollisionserkennung erweitert wird, ist er ideal für ein verteiltes
Netzwerk geeignet. Jeder Teilnehmer kann, sobald der Bus frei ist, eine priorisierte Nachricht
absetzen. Kollidieren die Anfragen „gewinnt“ die Nachricht mit der höchsten Priorität, wobei die
„unterlegene“ Nachricht automatisch neu gesendet wird, sobald der Bus frei wird. Außerdem verfügen
CAN-Busse über umfangreiche Fehlererkennungsmechanismen in verschiedenen Ebenen. Sie sind
damit für das Netzwerk sehr gut geeignet.
5.3.8. Serielles Ethernet
Ethernet ist der zurzeit am weitesten verbreitete Standard für Netzwerke. Der Name (Ether = Äther)
weist noch auf die ersten Funknetze hin. Die Datenübertragung erfolgt wie bei dem CAN-Bus mit
einem zufallsorientierten Zugriffsverfahren mit Kollisionserkennung. Anders als beim CAN werden im
Kollisionsfall aber beide Nachrichten nicht übertragen und die Sender verhandeln, wer die Nachricht
zuerst absetzen darf. Da jedoch die Protokollstruktur die auf dem Ethernet aufsetzt (TCP) von kaum
einem Controller direkt unterstützt wird, ist er für das geplante Netz eher ungeeignet.
26.07.2004 Seite 35 von 85

Diplomarbeit: Modulares System Vergleich von Bussystemen für die Kommunikation
5.3.9. Übersicht
Parallele Systeme
Name PC SCSI IEC
Geräteanzahl - 8 - 32 15
Kabellänge - 6 - 25 m 2 m
Leitungen 62 50 - 110 23
Datenbusbreite 8 Bit 8 - 32 Bit 8 Bit
Adressbreite 1 MByte 3 - 5 Bit 5 Bit
Datenübertragungsrate 1 MByte/s 5 - 20 MByte/s 1 MByte/s
Übertragungsart Synch. Asynch. Asynch.
Buszugriffsart - Master/Slave
Multi-master
Master/Slave
Topologie Bus Bus Bus
Serielle Systeme
Name RS232 I²C USB CAN Ethernet
Geräteanzahl 2 127 127 1024
Kabellänge 15 m Wenige
Meter
3 - 5 m Bis 1000
26.07.2004 Seite 36 von 85
m
2500 m
Leitungen 3 2 3 1 - 2 1 - 2
Adressbreite - 7 Bit 7 Bit 5 - 29 Bit 10 Bit
Datenübertragungsrate 20
kBit/s
100
kByte/s
1,5 - 480
MByte/s
Übertragungsart Asym. Synch. Sym.,
Buszugriffsart - Master/Slave
Topologie Punkt-zu-
Punkt
multi-master
Tabelle 5.4 - Übersicht über Bussysteme
[etsch], [law], [dem]
Asynch.
Bus Punkt-zu-
Bis 1
MBit/s
Sym.,
Asynch.
Master/Slave Zufall
Punkt
multi-m.
10 - 100
MBit/s
Alles
möglich
Zufall
multi-m.
Bus Bus

Diplomarbeit: Modulares System Vergleich von Bussystemen für die Kommunikation
5.4. Auswahl des verwendeten Busses
Für ein verteiltes Netzwerk von Sensoren und Aktoren spielen folgende Faktoren eine wichtige Rolle:
- einfache Anschlussmöglichkeit
- ausreichende Kabellänge
- robuste Verbindung
- Fehlertoleranz
- einfaches Einfügen/Auskoppeln von Teilnehmern
Aus der Tabelle 4.4 ist ersichtlich, dass es in Hinblick auf Geschwindigkeit kaum Vorteile durch
parallele Bussysteme gibt. Da serielle Verbindungen durch die geringe Leitungsanzahl wesentlich
einfacher aufzubauen und zu warten sind, überwiegt dieser Vorteil bei weitem. Ein Nachteil ist
generell die begrenzte Anzahl von anschließbaren Geräten.
Der CAN-Bus sticht hierbei heraus, da er die Anzahl der Teilnehmer nicht vom Protokoll her begrenzt,
sondern diese nur von der Leistungsfähigkeit der eingesetzten Treiberbausteine abhängt. Des
Weiteren verfügt er über mehrere, einander ergänzende Fehlererkennungsmechanismen. Da der
CAN-Bus symmetrisch betrieben wird und somit eine sehr geringe Fehlerquote aufweist, ist er die
beste Wahl für ein verteiltes Netzwerk. Die im Vergleich zum Ethernet geringere
Datenübertragungsrate wirkt sich im Projekt nicht negativ aus. Außerdem finden sich preisgünstige
Umsetzungen des CAN in vielen Mikrocontrollern. Ethernet ist dagegen vergleichsweise teuer. Daher
wurde für die Realisierung des Netzwerkes der CAN-Bus gewählt.
Wegen der begrenzten Ausbreitungsgeschwindigkeit (17-20cm/s) der Signale auf den Leitungen und
der Tatsache, dass in einigen Protokoll-Abschnitten eine Reaktion anderer Bus-Teilnehmer verlangt
wird, sind Bitrate und Buslänge beim CAN-Bus direkt miteinander gekoppelt. Das heißt, je länger die
Leitungen sind, umso geringer kann die Übertragungsrate sein.
Formel: Buslänge * Bitrate < 40m * 1MBit/s.
Daraus ergeben sich zum Beispiel folgende Beziehungen:
40 m Buslänge bei 1 MBit/s
400 m Buslänge bei 100 kBit/s
1000 m Buslänge bei 40 kBit/s
Diese sollten für einen normalen Betrieb eines Netzwerkes ausreichen. Für höhere Datenströme, wie
sie unter Umständen bei Videoanwendungen auftreten können, muss dann partiell auf ein anderes
System umgestiegen werden. Die Datenüberragungsrate muss dem CAN-Controller bekannt sein.
Der CAN-Bus ist im OSI-Modell in den Schichten 1 (physikalische Schicht) und 2 (Sicherungsschicht)
angesiedelt. Er übernimmt also die physikalische Übertragung und die Sicherstellung der
Fehlererkennung und Korrektur der ankommenden Daten. Dazu verfügt jede CAN-Botschaft über eine
15-Bit-CRC-Prüfsumme, es wird ein Frame-Check durchgeführt und der Sender erwartet eine
26.07.2004 Seite 37 von 85

Diplomarbeit: Modulares System Vergleich von Bussystemen für die Kommunikation
Bestätigung über den Empfang seiner Nachricht. Im Fehlerfall erfolgt eine automatische Wiederholung
der fehlerhaften Nachrichtensendung. Parallel dazu existieren noch zwei Mechanismen zur
Fehlererkennung auf Bitebene. Das ist zum einen das so genannte Monitoring: jeder Sender
beobachtet den Buspegel. Durch Differenzen zwischen gesendetem und empfangenem Bit können
Bitfehler schnell erkannt werden. Zum anderen werden die Synchronisationsflanken nach der
Methode des Bit-stuffings erzeugt. Die NRZ-Codierung (Non-Return-To-Zero) gewährleistet die
maximale Effizienz bei der Bitcodierung.
Durch den Aufbau als echter Bus und sein Zugriffsverfahren ist CAN sehr robust, was den Ausfall
oder das Einfügen von Teilnehmern angeht. Dafür muss nicht das gesamte Netzwerk abgeschaltet
werden, sondern es kann im laufenden Betrieb geschehen. Tritt ein Fehler mehrfach auf, deaktivieren
sich die störenden Teilnehmer automatisch selbst.
Eine CAN-Nachricht kann bis zu acht Byte Daten enthalten und ist in ein so genanntes Frame
eingebettet. Dieses besteht aus dem Identifier, Steuer- und Acknowledge-Bit. Für den Identifier sind
zwei verschiedene Größen vorgesehen. Die ältere Reglementierung (CAN 2.0A) sieht einen 11-Bit-
Identifier vor. Neuere Umsetzungen setzen auf einen 29-Bit-Identifier nach dem Standard CAN 2.0B.
Aufbau des Identifiers: siehe Kapitel 3.3.
Der CAN-Bus ist durch seine Eigenschaften die beste Wahl für dieses Projekt. Er ist robust, schnell,
einfach zu bedienen und kostengünstig. An Stellen wo seine Fähigkeiten nicht mehr ausreichen, kann
auf ein anderes Bussystem umgestiegen werden. So genannte Bridges ermöglichen dann die
Kommunikation über die Busgrenzen hinweg.
26.07.2004 Seite 38 von 85

Diplomarbeit: Modulares System Programmierung der Knotenpunkte
6. Programmierung der Knotenpunkte
Herkömmliche Robotersysteme besitzen im Allgemeinen einen leistungsfähigen Prozessor als
zentrale Einheit, an den die Sensoren und Aktoren direkt angeschlossen werden. Der Vorteil dieses
Aufbaus liegt darin, dass nur eine einzige rechenstarke Einheit programmiert werden muss. Der
Nachteil ist, dass solche Systeme in der Anzahl der anschließbaren Sensoren und Aktoren meist stark
begrenzt sind. Oft sind nicht mehr als zehn Anschlüsse vorhanden. Für größere Roboter müssen dann
mehrere dieser Prozessoren vernetzt oder ein Bussystem integriert werden. Zusätzlich ist der
Wechsel auf einen anderen leistungsfähigeren Prozessor zum Teil sehr aufwendig, da viele Teile der
Programme neu entwickelt werden müssen. Des Weiteren ist eine Erweiterung des bestehenden
Roboters meist nur durch Abschalten und Neuprogrammierung möglich. Eingriffe in ein laufendes
System sind normalerweise nicht vorgesehen.
Mit einem Netzwerk von einzeln agierenden Sensoren und Aktoren ist es möglich, genau diese
Nachteile zu umgehen. Jeder Knotenpunkt läuft weitestgehend autark und kann zu jeder Zeit aus dem
Netzwerk entfernt werden. Sollten andere Teilnehmer auf Informationen von ihm angewiesen sein,
bekommen sie zwar eine Fehlermeldung und können unter Umständen ihre Aufgabe nicht mehr
vollständig wahrnehmen, aber dies beeinflusst in vielen Fällen nicht das Gesamtsystem. Es kann
weiter laufen und sobald der entfernte Knotenpunkt wieder aktiv wird, ist der alte Zustand ohne
Unterbrechung wiederhergestellt. Dadurch können (nahezu) beliebig viele Sensoren und Aktoren
miteinander kombiniert werden. Damit sich die Kosten für so ein Netzwerk nicht überschlagen,
müssen die Steuereinheiten für jeden Sensor und Aktor entsprechend günstig sein. Statt einem
leistungsfähigen Zentralrechner wird eine Vielzahl kleinerer Controller verwendet.
Der Nachteil bei dieser Herangehensweise ist, dass jeder dieser Controller separat programmiert
werden muss. Solange alle vom gleichen Typ sind, ist der Aufwand noch überschaubar, aber sobald
später einmal das Netzwerk erweitert werden soll und die verwendeten Controller nicht mehr
verfügbar sind oder leistungsfähigere Controller verwendet werden sollen, würde der Aufwand wieder
stark ansteigen. Sinn macht es daher, von Anfang an auf den Controllern eine Virtuelle Maschine zu
installieren. Werden die Controller ausgetauscht, muss nur die Virtuelle Maschine für den neuen
Controllertyp angepasst werden und alle Steuerungsprogramme funktionieren ohne Änderung weiter.
Am einfachsten wäre es für den Entwickler, wenn er für die Programmierung des Netzwerkes eine der
momentan verbreiteten Sprachen (wie C++, Pascal oder JAVA) verwenden könnte. Leider sind diese
Sprachen mittlerweile so komplex und umfangreich, dass eine dazugehörige virtuelle Maschine die
Leistungsfähigkeit eines einfachen Controllers mit wenig Speicher schnell übersteigen würde. Nach
Rücksprache mit Prof. Dr.-Ing. Beck (Professor für Compiler/Interpreter-Bau an der HTW-Dresden) fiel
die Wahl auf einen von ihm verwendeten Compiler, der auf der Sprache PL0 basiert. Die zugehörige
Virtuelle Maschine ist so klein gehalten, dass sie auch auf Controllern mit wenigen hundert Byte
Speicher zumindest einfache kleine Programme noch ausführen kann, die zu Steuerzwecken in der
Regel ausreichen.
26.07.2004 Seite 39 von 85

Diplomarbeit: Modulares System Programmierung der Knotenpunkte
6.1. Die Programmiersprache PL0
Die Syntax von PL0 ist dem Pascal sehr ähnlich. Eine Vereinfachung zu Pascal besteht in der
Beschränkung auf einen einzigen Datentyp (integer für ganzzahlige Konstanten und Variablen).
Dadurch reduziert sich die Größe der Virtuellen Maschine enorm. Um effizient programmieren zu
können, sind in PL0 Prozeduraufrufe vorgesehen. Diese wurden für diese Arbeit zusätzlich um die
Möglichkeit von Funktionsaufrufen, also mit Rückgabewert, erweitert, da dies die Programmierung
enorm erleichtert und kaum Zusatzaufwand in der Virtuellen Maschine bedeutet.
Standardmäßig waren im vorhandenen PL0-Compiler folgende Befehle realisiert:
Befehl Bedeutung
VAR a,b; Variablendefinition
IF bedingung THEN anweisung Einseitige Bedingung
WHILE bedingung DO anweisung Kopfgesteuerte Schleife
PROCEDURE name; Prozedur-Deklaration
BEGIN anweisungen END Anweisungsblock
CALL name Prozeduraufruf
? a Eingabeaufforderung für eine Zahl
! a Ausgabe einer Zahl
odd
= #
< >=
Vergleichsoperatoren:
ungerade
gleich, ungleich
kleiner, kleiner gleich
größer, größer gleich
+ - * / Mathematische Operatoren
Tabelle 6.1 - Sprachumfang von PL0
Die Befehle PUT und GET wurden hinzugefügt, um die Kommunikation zwischen den Knotenpunkten
zu realisieren. Sie sind möglichst einfach gehalten, um unabhängig von der Art des Knotenpunkts alle
Daten übermitteln zu können. Jeder Sensor und Aktor verfügt über eine definierte Parametermenge,
die unterschiedlich groß sein kann. Jeder Parameter kann einzeln abgefragt und gesetzt werden
(siehe auch Kapitel 3).
Im Anhang A.1 befinden sich die Syntaxgraphen, die die Sprache abbilden.
[beck]
26.07.2004 Seite 40 von 85

Diplomarbeit: Modulares System Programmierung der Knotenpunkte
Erweitert wurden folgende Elemente:
Befehl Erweiterung
{ text } Kommentar
IF bedingung THEN anweisung
ELSE anweisung
Zweiseitige Bedingung
FUNCTION name; Funktionsdeklaration. Gibt einen Wert zurück.
PUT(group,id,parameter,value); Anweisung an den Knotenpunkt id den Wert value
an die Stelle parameter zu schreiben
GET(group,id,parameter); Anweisung an den Knotenpunkt id den Wert an
der Stelle parameter zu lesen und
zurückzusenden
Tabelle 6.2 - Erweiterung von PL0 für den Einsatz im Netzwerk
6.2. Beispielanwendung
Um den Unterschied zwischen einem zentral gesteuerten Roboter und einem verteilten Netzwerk von
Sensoren und Aktoren zu verdeutlichen, eignet sich folgendes Beispiel recht gut. Dabei wird von der
Steuerung des Khepera - Roboters ausgegangen. Er ist als Beispiel im in Kapitel 6 aufgeführten
Simulator Easybot enthalten und kann daher verwendet werden, um die Vorgehensweise zu testen.
Der Khepera verfügt über sechs frontale und zwei rückwärtige Entfernungssensoren. Als Antrieb
werden zwei Motoren eingesetzt. Die Sensoren und die Motoren werden durchnummeriert, um sie
ansteuern zu können.
Abbildung 6.1 - Schematische Darstellung eines Khepera
Das Programm soll durch eine einfache Zusammenrechnung der einzelnen Sensorwerte sicherstellen,
dass der Roboter nicht gegen eine Wand fährt.
26.07.2004 Seite 41 von 85

Diplomarbeit: Modulares System Programmierung der Knotenpunkte
6.2.1. Zentrales Programm
Für den zentralen Prozessor wird das Programm am Stück übersetzt und auf den Khepera geladen.
Die Abkürzungen der Variablen bedeuten:
sfl - sensor front left
shl - sensor front half left
sl - sensor left
srl - sensor rear left
ml - motor left
Für rechts erfolgt die Namensgebung nach dem gleichen Schema.
Das Programm liest die einzelnen Sensorwerte aus (über die gleichen Funktionen, die auch im
Netzwerk verwendet werden), und rechnet sie für beide Motoren zusammen und setzt diese Werte.
var sfl,shl,sl,sfr,shr,sr,srl,srr,ml,mr,sreach,speed;
BEGIN
speed:=5;
sreach :=get(8,1,1); {get sensor reach}
sfl:=get(8,3,0); if sfl>sreach then sfl:=sreach; {get sensor front left}
shl:=get(8,2,0); if shl>sreach then shl:=sreach; {get sensor half left}
sl :=get(8,1,0); if sl >sreach then sl :=sreach; {get sensor left}
sfr:=get(8,4,0); if sfr>sreach then sfr:=sreach; {get sensor front right}
shr:=get(8,5,0); if shr>sreach then shr:=sreach; {get sensor half right}
sr :=get(8,6,0); if sr >sreach then sr :=sreach; {get sensor right}
srl:=get(8,8,0); if srl>sreach then srl:=sreach; {get sensor rear left}
srr:=get(8,7,0); if srr>sreach then srr:=sreach; {get sensor rear right}
ml:=sfl+shl+sl-(sfr+shr+sr)/(speed/2);
mr:=sfr+shr+sr-(srl+shl+sl)/(speed/2);
put(10,1,0,mr/speed); {set right motor speed}
put(10,2,0,ml/speed); {set left motor speed}
END.
Abbildung 6.2 - Beispielprogramm für eine zentrale Steuerung
Soll nun der Roboter zum Beispiel um Scheinwerfer erweitert werden, muss er angehalten und
umprogrammiert werden. Erst danach kann er mit der neuen Funktionalität seine Arbeit wieder
aufnehmen. Die Scheinwerfer leuchten in Abhängigkeit davon, ob sich der Roboter bewegt.
var sfl,shl,sl,sfr,shr,sr,srl,srr,ml,mr,sreach,speed;
BEGIN
speed:=5;
sreach :=get(8,1,1); {get sensor reach}
...
...
put(10,1,0,mr/speed); {set right motor speed}
put(10,2,0,ml/speed); {set left motor speed}
if (mr*ml)=0 then put(9,1,0,0); {set headlights off}
else put(9,1,0,1); {set headlights on}
END.
Abbildung 6.3 - Das erweiterte zentralgesteuerte Programm
26.07.2004 Seite 42 von 85

Diplomarbeit: Modulares System Programmierung der Knotenpunkte
6.2.2. Verteiltes Programm
Im verteilten Netzwerk, in dem jeder Sensor und jeder Aktor eine eigene Rechenlogik besitzt, könnte
jeder Knotenpunkt obiges Programm ausführen. Das Programm kann aber auch in Teile zerlegt
werden, die jeweils die Steuerung eines Motors übernehmen. Diese können dann direkt auf dem dem
Motor zugehörigen Controller laufen. Fällt nun ein Motor aus, funktioniert der andere weiter (in diesem
Beispiel nicht sinnvoll, da der Roboter im Kreis fahren würde, aber immerhin wäre es möglich). Wenn
dieses Prinzip für andere Anwendungen adaptiert wird, kann so die Funktionalität jederzeit erweitert
werden, ohne die laufenden Programme zu unterbrechen. So können die im Beispiel verwendeten
Scheinwerfer nachträglich hinzugefügt werden Der Programmteil dazu funktioniert unabhängig von
den beiden anderen auf dem Controller der Scheinwerfer und kann jederzeit ersetzt oder entfernt
werden. Auch wenn die Motorsteuerung geändert wird, hat das keinen Einfluss auf das
Scheinwerferprogramm.
var sfl,shl,sl,sfr,shr,sr,srl,srr,ml,sreach,speed;
BEGIN
speed:=5;
sreach :=get(8,1,1); {get sensor reach}
sfl:=get(8,3,0); if sfl>sreach then sfl:=sreach; {get sensor front left}
shl:=get(8,2,0); if shl>sreach then shl:=sreach; {get sensor half left}
sl :=get(8,1,0); if sl >sreach then sl :=sreach; {get sensor left}
sfr:=get(8,4,0); if sfr>sreach then sfr:=sreach; {get sensor front right}
shr:=get(8,5,0); if shr>sreach then shr:=sreach; {get sensor half right}
sr :=get(8,6,0); if sr >sreach then sr :=sreach; {get sensor right}
srl:=get(8,8,0); if srl>sreach then srl:=sreach; {get sensor rear left}
srr:=get(8,7,0); if srr>sreach then srr:=sreach; {get sensor rear right}
ml:=sfl+shl+sl-(sfr+shr+sr)/(speed/2);
put(10,2,0,ml/speed); {set left motor speed}
END.
Abbildung 6.4 - Verteiltes Programm: linker Motor
var sfl,shl,sl,sfr,shr,sr,srl,srr,mr,sreach,speed;
BEGIN
speed:=5;
sreach :=get(8,1,1); {get sensor reach}
sfl:=get(8,3,0); if sfl>sreach then sfl:=sreach; {get sensor front left}
...
...
srr:=get(8,7,0); if srr>sreach then srr:=sreach; {get sensor rear right}
mr:=sfr+shr+sr-(srl+shl+sl)/(speed/2);
put(10,1,0,mr/speed); {set right motor speed}
END.
Abbildung 6.5 - Verteiltes Programm: rechter Motor
var ml,mr;
BEGIN
mr:=get(10,1,0);
ml:=get(10,2,0);
if (mr*ml)=0 then put(9,1,0,0); {set headlights off}
else put(9,1,0,1); {set headlights on}
END.
Abbildung 6.6 - Verteiltes Programm: Scheinwerfer
26.07.2004 Seite 43 von 85

Diplomarbeit: Modulares System Programmierung der Knotenpunkte
6.3. Umsetzung
Um die Sensoren und Aktoren beziehungsweise die dazugehörigen Controller in die Lage zu
versetzen, Steuerprogramme ausführen zu können, müssen die PL0-Programme in einen Code
übersetzt werden, den die Controller verstehen. Um die Programme nicht für jeden Controllertypen
spezifisch zu übersetzen, wird ein Code erzeugt, der von einer Virtuellen Maschine ausgeführt
werden kann. Diese verfügt über einen Kellerspeicher, auf dem alle Daten abgelegt werden. Damit sie
auch auf kleineren Controllern mit wenig Arbeitsspeicher lauffähig ist, ist die Breite des Maschinen-
Speichers auf zwei Byte festgelegt.
Der Code ist relativ klein gehalten und kommt mit derzeit 35 Befehlen aus. Damit ist er bereits
gegenüber dem von Prof. Beck verwendeten Zwischencode um einige Befehle erweitert worden. Sie
dienen zum einen dem Alternativ-Zweig der zweiseitigen Verzweigung (IF THEN ELSE) und den
Funktionsaufrufen und zum anderen wurden zwei neue Befehle eingeführt, um mit den anderen
Knotenpunkten kommunizieren zu können. Diese Befehle holen sich ihre Parameter vom
Kellerspeicher und schreiben die Ergebnisse dorthin zurück. Die Virtuelle Maschine entscheidet dabei,
ob sich die Anfrage an einen entfernten Knoten richtet oder die Daten direkt vom gleichen Controller
bezogen werden können. Dadurch, dass keine Unterschiede bei diesen beiden Aufrufen in der
Skriptsprache gemacht werden, vereinfacht sich die Programmierung und die Programme können mit
gleichen Ergebnissen auf jedem Knoten ausgeführt werden, ohne extra angepasst werden zu
müssen.
6.3.1. Der Compiler
Auf die genaue Entwicklung eines Compilers soll hier nicht eingegangen werden, sondern es wird nur
ein grober Überblick gegeben.
Ein Compilervorgang besteht aus mehreren Phasen. Am folgenden Beispiel werden diese kurz
erläutert.
CONST pi=3;
VAR a,x;
BEGIN
IF a>0 THEN
x:=2*pi+a;
END.
Phase Bedeutung
Lexikalische Analyse Der Quelltext wird in eine Folge von Symbolen zerlegt.
(const)(id,pi)(=)(num,3)(;)
(var)(id,a)(,)(id,x)(;)
(begin)
(if)(id,a)(>)(then)
(id,x)(:=)(num,2)(*)(id,pi)(+)(id,a)(;)
(end)(;)
26.07.2004 Seite 44 von 85

Diplomarbeit: Modulares System Programmierung der Knotenpunkte
Syntaxanalyse Die Symbole der lexikalischen Analyse werden in einen
Syntaxbaum überführt und dabei auf ihre formale
Korrektheit geprüft.
Semantische Analyse Der Syntaxbaum wird attributiert und in eine Symboltabelle
überführt. Dazu wird die inhaltliche Korrektheit des
Programms überprüft.
Name Art Wert/Adresse
pi const 3
a var 0
x var 4
Zwischencodegenerierung Der Baum wird in maschinenunabhängigen Zwischencode
überführt.
if a > 0 goto L1
goto L2
L1: t1 = 2 * 3
t2 = t1 + a
x = t2
L2:
Codeoptimierung Aus dem Zwischencode werden überflüssige Anweisungen
und unnötige Zugriffe (z.B. auf den Arbeitsspeicher)
entfernt.
L:
if a

Diplomarbeit: Modulares System Programmierung der Knotenpunkte
Die Phasen können nacheinander ausgeführt werden. Dies wird aber in der Praxis aus
Geschwindigkeitsgründen eher selten gemacht, sondern die Phasen werden zusammengefasst und
parallel ausgeführt. Es wird dann von einem Ein-Pass-Compiler gesprochen.
Der verwendete Compiler ist ein solcher Ein-Pass-Compiler mit Syntax- und Codetabellen.
Änderungen können einfach durchgeführt werden, indem die Tabellen angepasst werden. Die
lexikalische Analyse wird durch einen endlichen Automaten (Zustandsmaschine) mit
Zeichenklassenvektor, Schaltmatrize und Symboltabelle durchgeführt. Er liefert schrittweise die
Symbole an die nachfolgenden Phasen. Die Syntax- und die semantische Analyse und die
Codeerzeugung werden über Überführungsgraphen realisiert. Dazu werden die Syntaxgraphen
umgeformt und so genannte Bögen definiert. Durch diese Bögen wird die Korrektheit des Programms
sichergestellt und die Überführung in den Zielcode realisiert. Der Automat geht dabei vom ersten
erkannten Symbol aus und versucht es in den Bögen zu finden. Nur wenn dies gelingt und der weitere
Ablauf des Programms ebenfalls durch die Bögen realisiert werden kann, ist es korrekt und kann in
Maschinencode übersetzt werden. An den Knotenpunkten jedes Bogens werden Funktionen
aufgerufen, die der Codeerzeugung dienen.
Der fertige Code kann auf den Controller gespielt und von der dort befindlichen Virtuellen Maschine
direkt ausgeführt werden.
Abbildung 6.7 - Codedatei
Im Anhang A.2 und A.3 befinden sich die Symboltabellen und Bogengraphen des Compilers.
[beck]
00: 03 00 01 00 1B 22 00 00|00 08 00 01 00 00 06 01
10: 00 13 1E 19 0F 00 04 04|00 06 02 00 06 00 00 0E
20: 01 00 00 0C 07 17 03 00|00 00 02 00
6.3.2. Die Virtuelle Maschine
Die virtuelle Maschine muss den vom Compiler erzeugten Code verstehen und ausführen können.
Sie besitzt einen Kellerspeicher, auf dem die Operationen ausgeführt werden.
In den Code wurde am Anfang eine Versionsnummer integriert. Anhand dieser kann die Virtuelle
Maschine entscheiden, ob sie den Code ausführen kann oder nicht. Am Ende der Codedatei folgt die
Konstantentabelle. Der Code ist prozedurweise abgelegt und wird komplett eingelesen, umgeformt
und als Listen und Tabellen im Speicher abgelegt. Danach wird die Hauptroutine Befehl für Befehl
ausgeführt und falls es nötig ist in die Unterfunktionen verzweigt.
Die Prozeduren enthalten in ihrer Deklaration ihre Codelänge, eine fortlaufende Nummer und die
Größe des Variablenspeichers. [beck]
26.07.2004 Seite 46 von 85

Diplomarbeit: Modulares System Programmierung der Knotenpunkte
Das Beispiel aus dem vorigen Abschnitt wird also von der Maschine so gelesen:
03 00 - Versionsnummer (3)
01 00 - Anzahl Prozeduren (1)
1B 22 00 00 00 08 00 - Prozedur 0 mit 34 Byte Codelänge und 8 Byte Datenlänge
01 00 00 - puValVrMain 0 (a)
06 01 00 - puConst 1 (0)
13 - cmpGT
1E - dup
19 0F 00 - jnot
04 04 00 - puAdrVrMain 4 (x)
06 02 00 - puConst 2 (3)
06 00 00 - puConst 0 (0)
0E - OpMult
01 00 00 - puValVrMain 0 (a)
0C - OpAdd
07 - storeVal
17 - retProc
03 00 - Konstante 0 (3)
00 00 - Konstante 1 (0)
02 00 - Konstante 2 (2)
Abbildung 6.8 - Interpretierte Codedatei
Für jeden Befehl, den die Maschine ausführen soll, existiert eine Funktion, die ihn realisiert und auf
dem Kellerspeicher und mit dem Speicher arbeitet. Identisch arbeitende Funktionen (z.B. die
Vergleichsoperatoren) wurden dabei weitestgehend zusammengefasst.
while (!Ende)
{
switch (*pC++)
{
case puValVrLocl:FcpuValVrLocl(); break;
case puValVrMain:FcpuValVrMain(); break;
...
}
}
/*--- Push Value Variable local ---*/
int FcpuValVrLocl(void)
{
short Displ,Val;
Displ=getShortParameter(pC);pC+=2;
Val=rd2(pInfProc[iCProc].pVar+Displ);
push2(Val);
return OK;
}
...
Abbildung 6.9 - Beispiele für Funktionen der Virtuellen Maschine
26.07.2004 Seite 47 von 85

Diplomarbeit: Modulares System Programmierung der Knotenpunkte
6.4. Zusammenfassung
Da moderne Hochsprachen sehr komplex sind und sich diese Komplexität auch in der Virtuelle
Maschine niederschlagen würde, es aber erklärtes Ziel ist, diese auch auf leistungsschwächeren
Controllern laufen zu lassen, wurde eine einfache Sprache (PL0) gewählt. Die für die Umsetzung
benötigten Komponenten ließen sich aus dem von Prof. Beck bereitgestellten Quellen realisieren.
Der verwendete Compiler kann als Lexer, als Parser oder als Compiler übersetzt werden. Der Lexer
ist nur für die lexikalische Analyse zuständig. Der Parser versucht, die Symbole, die der Lexer liefert,
in den Bogengraphen einzusortieren. Mit den Knotenpunkten der Graphen sind Funktionen
verbunden, die für die Codegenerierung zuständig sind. Damit wird aus dem Parser der Compiler.
Dazu gehört noch die virtuelle Maschine, die die Codedateien ausführt. Alle Programme sind in C
geschrieben und als Kommandozeilenversion übersetzt. Es existiert ein MS Visual C++ 6.0 - Projekt,
in das alle Einzelprogramme integriert wurden, so dass sie auf der gleichen Codebasis arbeiten. Mit
diesen vier Programmen ist eine Basis vorhanden, mit der eigene Skripte übersetzt und ausgeführt
werden können.
Als Kommandozeilenvariante funktioniert zwar der Compiler, er ist aber wenig komfortabel. Er sollte in
einer späteren Arbeit aufbereitet und in eine grafisch orientierte Windows-Oberfläche überführt
werden. In erster Linie ist ein „normaler“ Editor mit entsprechenden Compilermöglichkeiten
ausreichend. Weiterführend wäre dann eine Programmierung aus „Bausteinen“, wie sie auch von
LEGO Mindstorms und fischertechnik angeboten wird, sinnvoll. Dabei wird nicht herkömmlicher
Quelltext geschrieben, sondern er wird aus Programmbausteinen wie beispielsweise zweiseitigen
Bedingungen oder kopfgesteuerten Schleifen aufgebaut, die dann grafisch miteinander verbunden
werden. In dieser Richtung gibt es noch viel Entwicklungsspielraum.
Abbildung 6.10 - Grafische Programmierung bei LEGO
26.07.2004 Seite 48 von 85

Diplomarbeit: Modulares System Testen der Steuerungsskripte im Simulator
7. Testen der Steuerungsskripte im Simulator
Wenn eine Robotersteuerung entwickelt wird, ist es oft schwierig, alle Abläufe exakt zu bedenken und
alle Fehlerquellen von Anfang an auszuschließen. Viele Tests am echten Objekt sind nötig, um die
Algorithmen und Verfahren zu testen und zu optimieren. Dies ist natürlich immer mit der Gefahr
verbunden, dass ein Test fehlschlägt und wertvolle Technik beschädigt wird. Außerdem sind
umfangreiche Testserien, die immer wieder die gleiche Ausgangssituation benötigen (wie dies zum
Beispiel bei der Entwicklung genetischer Algorithmen oder neuronaler Netze der Fall ist), sehr
aufwendig und oft schon dadurch verfälscht, dass der Mensch nie exakt die gleiche Ausgangssituation
herstellen kann.
Diese Probleme lassen sich reduzieren, wenn die Tests mit einem Simulator ausgeführt werden
können. Zum einen entfallen die aufwendigen Testvorbereitungen (Umgebung bauen, Roboter
technisch vorbereiten und programmieren usw.) und zum anderen ist es möglich, exakt die gleiche
Umgebung immer und immer wieder als Ausgangssituation zu nutzen.
Die Arbeit, um einen solchen Simulator zu entwickeln, ist enorm. Zusätzlich zu den Erfordernissen, die
die Programmierbarkeit des zu simulierenden Roboters mit sich bringt, kommen noch einige weitere.
So muss der Simulator in der Lage sein, eine mögliche Umgebung realitätstreu nachzuahmen. Er
sollte einfach zu bedienen sein und dynamische Anpassungen ermöglichen.
7.1. Vergleich verschiedener Simulatoren
In diesem Abschnitt werden verschiedene Simulatoren auf ihre Tauglichkeit untersucht, das verteilte
Netzwerk von Sensoren und Aktoren in einer realen Umgebung zu simulieren.
7.1.1. LLWin
Die Firma fischertechnik aus Deutschland liefert zu ihrem Roboterbaukasten eine
Entwicklungsumgebung mit. Diese ermöglicht das einfache Verbinden von Funktionsbausteinen. Es
wird nicht wie zum Beispiel im MS Visual C++ textbasiert programmiert, sondern vielmehr ein
Programm mit Mausklicks zusammengestellt. Der Vorteil dieser Entwicklungsumgebung im Vergleich
zur funktionsmäßig sehr ähnlichen der dänischen Firma LEGO ist, dass sie über einen
Simulationsmodus verfügt. Dieser ermöglicht es den Entwicklern, ihre Programme zu testen, ohne das
reale Modell aufbauen zu müssen. Die Software hat einen hohen Abstraktionsgrad und erfordert
einiges an Vorstellungsvermögen, um den programmierten Roboter mit den Aktionen in Verbindung
zu bringen. Leider ermöglicht LLWin keine freie Programmierung mit einer eigenen Sprache, so dass
das Programm als Simulator für das verteilte Netzwerk nicht geeignet ist. [fisch]
26.07.2004 Seite 49 von 85

Diplomarbeit: Modulares System Testen der Steuerungsskripte im Simulator
7.1.2. Webot
Abbildung 7.1 - LLWin
Die Schweizer Firma K-Team entwickelt und vertreibt die Roboter Khepera und Koala. Um für diese
effiziente Programme schreiben zu können, wird von der Firma cyberbotics der Simulator Webot
angeboten. Diese Software ist bereits mit einer Simulation dreidimensionaler Welten ausgestattet.
Dies ermöglicht es dem Programmierer sehr gut, reale Umgebungen zu simulieren und seine
Programme nicht nur abstrakt im Kopf oder am echten Objekt zu testen. Webot liefert fertige Beispiele
für die Programmierung für viele verschiedene Roboter mit. Leider sind diese aber nur in der
kommerziellen Version einsetzbar. Die frei erhältliche Version hat diese Fähigkeit nicht und ist daher
für dieses Projekt nicht geeignet. [cb]
Abbildung 7.2 - Webot
7.1.3. Easybot
Mit der Diplomarbeit von Dipl. Inform. O. Michel ist ein weiterer Simulator entstanden. Aufbauend auf
dem von ihm entwickelten 3D-Modellierer Lightvision3D hat er eine Robotersteuerungsschnittstelle
entwickelt. Lightvision3D ist vom Umfang eher ein einfacher Modellierer, der sich mit kommerziellen
Lösungen wie dem 3D-Studio von Kinetex (Autodesk) nicht messen kann. Dafür ist er sehr einfach
bedienbar und durch die Erweiterungsmöglichkeiten sehr gut als Simulator geeignet. Die Erweiterung
Easybot ermöglicht es, Gruppenobjekte in Lightvision3D, die Sensoren enthalten, als Roboter
anzusteuern. Da sowohl die Umgebung im Lightvision3D als auch die Robotersteuerung so variabel
26.07.2004 Seite 50 von 85

Diplomarbeit: Modulares System Testen der Steuerungsskripte im Simulator
gehalten sind, dass beliebige Roboter in den unterschiedlichsten Szenarien simuliert werden können,
ist Easybot sehr gut geeignet, um neue Konzepte zu testen. Da Lighvision3D leider keine getrennte
Steuerung für jeden Sensor eines Roboters unterstützt, müssen in diesem Bereich einige Abstriche
gemacht werden. Es können zwar mehrere Objekte mit eigenen Sensoren versehen werden, aber
diese können mechanisch nicht miteinander verbunden werden. Trotzdem ist er eine gute Wahl, um
zumindest die Virtuelle Maschine zu testen. (siehe Kapitel 6.3) [mich]
7.1.4. Netbot
Abbildung 7.3 - Easybot
Um die Funktionen zu testen, die Easybot nicht unterstützt, war es notwendig, eine eigene
Testumgebung zu schaffen. Diese betrifft vor allem die Kommunikation und Interaktion unter den
Sensoren und Aktoren. Zu diesem Zweck ist eine DCOM-Client-Server-Architektur entstanden, wobei
der Server den Bus simuliert und die Clients die Sensoren und Aktoren. (siehe Kapitel 6.4)
Abbildung 7.4 - Netbot
26.07.2004 Seite 51 von 85

Diplomarbeit: Modulares System Testen der Steuerungsskripte im Simulator
7.2. Arbeiten mit der Virtuellen Maschine
Während der Entwicklung der verschiedenen Steuerungen, die in den folgenden Abschnitten
beschrieben werden, hat sich herausgestellt, dass es einen enormen Aufwand darstellt, bei einer
Änderung der Virtuellen Maschine die verschiedenen Steuerungen mit zu ändern. Da einige Fehler
und Unschönheiten erst im laufenden Betrieb sichtbar werden, sind solche Änderungen aber
unabdingbar. Daher wurde die Virtuelle Maschine in eine DLL eingebettet, die von allen
Steuermodulen verwendet werden kann. Sie hat zusätzlich den Vorteil, dass die Programmiersprache
des Entwicklers (ob VC++, Delphi oder Java), der ein Steuermodul schreiben will, keine Rolle mehr
spielt.
7.2.1. Aufbau der VM.DLL
Die originale Virtuelle Maschine, wie sie auch als Kommandozeilenversion vorliegt, ist als
prozedurales Programm geschrieben. Um die Übersichtlichkeit zu erhöhen und die Maschine stärker
vom Kellerspeicher zu trennen, wurden die einzelnen Funktionen in Klassen eingebettet. Um auf die
Virtuelle Maschine von außen zugreifen zu können, müssen einige Funktionen freigegeben werden
und Funktionen des Steuermoduls der DLL bekannt gegeben werden. Da der Code und die
Ressourcen der DLL nur einmal global im Programmspeicher gehalten werden und von jedem
Steuermodul innerhalb des Programms nur referenziert werden, muss das aufrufende Modul bei jeder
Funktion eindeutig identifiziert werden. Dafür wird von der DLL beim initialisieren eine eindeutige
Nummer vergeben, die bei den Funktionsaufrufen mit übergeben werden muss. Zusätzlich kann vom
aufrufenden Modul ein Zeiger übergeben werden, der bei Funktionsaufrufen aus der DLL heraus in
das Modul hinein wieder übergeben wird. Dadurch können spezifische Daten (z.B. welcher Roboter
gemeint ist) gespeichert werden.
exportierte Funktionen:
vmInit Initialisiert die Virtuelle Maschine und erwartet Zeiger auf die von der
Virtuellen Maschine benötigten Funktionen (Get, Put, GetValue,
PutValue), um Werte einzulesen und auszugeben
Liefert die ID zurück
vmOpenFile Öffnet eine Codedatei (auch im laufenden Betrieb möglich)
vmRun Startet den Ablauf der Codedatei
vmRestart Setzt die Virtuelle Maschine in ihren Ausgangszustand zurück
vmStep Ermöglicht die Schrittweise Ausführung der Codedatei
Abbildung 7.5 - Aufbau der VM.DLL
26.07.2004 Seite 52 von 85

Diplomarbeit: Modulares System Testen der Steuerungsskripte im Simulator
7.2.2. Verwendung der VM.DLL
Um die Virtuelle Maschine zu verwenden, muss die DLL geladen und initialisiert werden. Dies kann
statisch passieren, also die DLL direkt fest in das Programm eingebunden werden oder es kann
dynamisch geschehen, das heißt, dass die DLL erst geladen wird, wenn sie verwendet wird und damit
auch jederzeit im laufenden Betrieb entladen und getauscht werden kann. Die Funktionen der DLL
müssen an Funktionszeiger gebunden werden, damit sie verwendet werden können. Im ersten Aufruf
muss die Virtuellen Maschine initialisiert werden und es müssen ihr die Zeiger auf die beiden
Kommunikationskommandos (Get, Put) bekannt gemacht werden. Als Rückgabewert erhält das
aufrufende Programm eine Nummer, über die die DLL die richtige Maschine erkennen kann.
Abbildung 7.6 - Einbinden der VM.DLL
7.3. Easybot
FARPROC funcptr;
dllhandle=LoadLibrary("vm.dll");
if (dllhandle==0) AfxMessageBox("DLL nicht gefunden!");
funcptr=GetProcAddress(dllhandle, "vmOpenFile");
if (funcptr)
vm_openfile=(FXOpenFile)funcptr;
else
AfxMessageBox("Funktion vmOpenFile nicht gefunden!");
funcptr=GetProcAddress(dllhandle, "vmStep");
if (funcptr)
vm_step=(FXStep)funcptr;
else
AfxMessageBox("Funktion vmStep nicht gefunden!");
...
if (vm_init)
nr=vm_init(robot,NULL,NULL,Get,Put);
else
nr=-1;
Der Simulator Easybot von O. Michel ist sehr gut geeignet, um Algorithmen zur Steuerung von
Robotern zu testen, die nur aus einem Antrieb und Entfernungssensoren bestehen. Er bietet gute
Möglichkeiten, um eine reale Umgebung nachzuempfinden. In diese können Roboter gesetzt werden,
die einen Satz Sensoren enthalten, die aber in erster Linie nur die Entfernung zum nächsten Objekt
angeben. Über eine Schnittstelle können diese Sensoren abgefragt und der Roboter bewegt werden.
Dies wird durch die Schnittstelle Easybot in Lightvision3D realisiert.
7.3.1. Lightvision3D
Lightvision3D ist ein einfacher 3D-Modellierer. Er ermöglicht das Erzeugen einfacher 3D-Welten, die
als Testumgebung für Roboter dienen können.
Erzeugt werden die Objekte direkt im Programm. Hierfür steht eine Reihe von Grundkörpern wie zum
Beispiel Dreieck, Kugel oder Pyramide zur Verfügung. Um auch komplexere Objekte erzeugen zu
können und gleichzeitig eine größtmögliche Dynamik zu erreichen, ist der Modellierer mit mehreren
freien Schnittstellen versehen. Diese ermöglichen sowohl die Anbindung komplexerer
Konstruktionswerkzeuge als auch spezieller Lade- und Speicherfunktionen für andere Dateiformate,
wie zum Beispiel .3ds, einem Format des professionellen 3D-Modellierers 3D-Studio Max von Kinetix.
Diese Erweiterungen müssen als DLL vorhanden sein. Jedes Objekt kann mit Materialeigenschaften
26.07.2004 Seite 53 von 85

Diplomarbeit: Modulares System Testen der Steuerungsskripte im Simulator
oder Texturen belegt werden und wird entsprechend der frei setzbaren Lichtquellen beleuchtet. Dies
erhöht zum einen die optische Unterscheidungsfähigkeit und zum anderen das Realismusempfinden.
Der Blickwinkel ist mit beliebig setzbaren Kameras frei wählbar. [mich]
Abbildung 7.7 - Lightvision3D
7.3.2. Easybot
Lightvision3D bietet vor allem den großen Vorteil der Erweiterbarkeit. Die für die Robotersimulation
wichtigste Schnittstelle ist die so genannte „FreeJob“-PlugIn-Schnittstelle. Sie ermöglicht den
steuernden Zugriff von „außen“ auf alle Objekte innerhalb von Lightvision3D.
Easybot greift auf diese Schnittstelle zu und ermittelt alle Gruppenobjekte, die ein Unterobjekt namens
„sensor...“ enthalten und stellt diese als Einzelroboter zur Verfügung. Für jedes dieser Gruppenobjekte
kann ein Steuermodul geladen werden. Dieses muss als speziell strukturierte DLL vorliegen. Das
Hauptprogramm ruft in einem einstellbaren zyklischen Zeitintervall eine Funktion (Navigate) der
Steuermodule auf. In dieser Funktion können die Sensorwerte verarbeitet werden und die Position
und Richtung des Roboters geändert werden.
Die Sensoren werden in Lightvision3D durch Strahlen ausgehend von einem Dreieck simuliert. Da der
3D-Modellierer Kenntnis von den Eigenschaften des Objektes besitzt, auf das der Strahl trifft, können
mehr Informationen bereitgestellt werden, als nur die Entfernung.
Dem Entwickler steht innerhalb der Steuer-DLL für jeden erkannten Sensor eine Sammlung von
Werten zur Verfügung:
- Entfernung vom Startpunkt (Dreieck) bis zum Schnittpunkt des Strahls mit dem Objekt
- Name
- Materialname
- Farbe des Materials
- Absolute Position des Schnittpunktes
- Start- und Endpunkt des Strahls
Mit der Farbe lässt sich eine einfache Ein-Punkt-Kamera simulieren. Durch die Kombination mehrerer
Sensoren könnte so ein normales Kamerabild erzeugt werden. Durch die Verwendung von geeigneten
Materialnamen können Temperaturen oder andere Materialeigenschaften übermittelt werden.
26.07.2004 Seite 54 von 85

Diplomarbeit: Modulares System Testen der Steuerungsskripte im Simulator
Das Grundgerüst für ein solches Steuermodul steht von O. Michel zur Verfügung. Der Entwickler
braucht sich ausschließlich um die Erstellung der Algorithmen kümmern.
Um einen Roboter mit einem Steuermodul zu verbinden, muss in Lightvision3D das Plugin Easybot
gestartet werden und in diesem auf dem Roboternamen doppelt geklickt werden. Im sich öffnenden
Dialog kann die entsprechende DLL geladen werden. Mit „open dialog“ wird dann der Steuerdialog der
DLL geladen (siehe nächste Abschnitte). Mit den Buttons im Bereich „simulation control“ kann der
Ablauf der Simulation gesteuert werden.
[mich]
# Stopp der Simulation
> Start der Simulation (Einzelschritte im eingestellten Zeitintervall)
>| Einzelschritt (die Funktion „navigate“ des Steuermoduls wird einmal aufgerufen)
Abbildung 7.8 - Lightvision3D mit Easybot
7.3.3. Netzwerk
Dadurch, dass das Modul Easybot lediglich ein Gruppenobjekt der obersten Ebene als Roboter
erkennen kann und keine Untergruppen als eigenständige Roboter aufführt, können die Sensoren
nicht getrennt voneinander programmiert werden. Ein verteiltes Netzwerk von Sensoren und Aktoren
lässt sich so nicht aufbauen. Es könnten zwar mehrere Objekte mit Sensoren aufgebaut werden, aber
es müsste eine Möglichkeit geschaffen werden, wie diese miteinander kommunizieren können und vor
allem, wie sie gemeinsam eine Bewegung ausführen können. Vor allem der Aspekt der Koordination
der Bewegungen der einzelnen Objekte bedingt einen hohen Entwicklungsaufwand, der in dieser
Diplomarbeit nicht betrieben wurde. Es wurden drei Varianten des Steuerungsmoduls geschaffen, die
die Virtuelle Maschine enthalten und jeweils in der Lage sind, ein Fahrzeug mit zwei angetriebenen
Rädern zu simulieren.
7.3.4. Khepera-Steuerung: Khepera_VM.DLL
Da O. Michel in seiner Diplomarbeit auf dem Khepera aufbaut, sind bei ihm Modelle dieses Roboters
bereits enthalten. Der Khepera ist ein kleines mobiles Fahrzeug, das über zwei Motoren verfügt und
über acht Infrarotsensoren seine Umgebung wahrnehmen kann. Damit können Algorithmen zur
Fahrzeugsteuerung gut getestet werden.
26.07.2004 Seite 55 von 85

Diplomarbeit: Modulares System Testen der Steuerungsskripte im Simulator
Um den Khepera mit Skripten steuern zu können, muss im Modul Easybot die Khepera_VM.DLL
geladen werden. Diese lädt automatisch die Virtuelle Maschine aus dem vorigen Abschnitt und bindet
die wichtigen Funktionen. Als Dialog wird dann eine symbolhafte Darstellung in 2D des Khepera von
oben dargestellt. Jeder Infrarotsensor hat eine Nummer und ist der Gruppe 8 zugeordnet (siehe
Kapitel 3). Die Räder haben ebenfalls eine Nummer und sind in der Gruppe 10. Alle anderen Gruppen
und Nummern werden in diesem Steuermodul nicht unterstützt. Die Nummern können für die
Programmierung aus der untenstehenden Abbildung entnommen werden.
Als Beispielprogramm kann der in Abbildung 5.2 dargestellte Quellcode verwendet werden. Dazu
muss auf dem gelb umrahmten schwarzen Viereck in der Mitte doppelt geklickt werden. Um den
Roboter an die Ausgangsposition zurückzusetzen, muss auf den darunter liegenden doppelt geklickt
werden. Die gemessenen Entfernungswerte stehen direkt neben dem jeweiligen Sensor und die
Motorgeschwindigkeiten werden ebenfalls direkt in der Grafik angezeigt.
Abbildung 7.9 - Kheperamodell
7.3.5. Cybot-Steuerung: Cybot_VM.DLL
Im Gegensatz zum Khepera, der nicht in der Lage ist, von einem verteilten Netzwerk von Sensoren
und Aktoren gesteuert zu werden (siehe Kapitel 2.3) kann das Chassis des Cybot genutzt werden, um
ein solches Netzwerk zu installieren. Der Rumpf bietet genügend Raum für Platinen und alle
originalen Bauteile sind nur gesteckt oder geschraubt, so dass die vorhandene Elektronik gegen das
Netzwerk ausgetauscht werden kann. Um den Cybot (der auch in Kapitel 7 Anwendung findet)
simulieren zu können, ist ein dem Khepera ähnliches Modell für Lightvision3D entstanden. Der größte
Unterschied ist der, dass der Cybot nur über zwei Entfernungssensoren verfügt, die in Fahrtrichtung
zeigen. Die rückseitigen Sensoren entfallen. Um einfache Steuerungen testen zu können, wurde die
Khepera-Steuerung so abgewandelt, dass sie für den Cybot tauglich ist.
Abbildung 7.10 - Cybotmodell
26.07.2004 Seite 56 von 85

Diplomarbeit: Modulares System Testen der Steuerungsskripte im Simulator
7.3.6. Offene Steuerung: Multi_VM.DLL
Da mit den beiden vorangegangenen Steuermodulen nur zentrale Programme, die exakt auf einen
bestimmten Roboter zugeschnitten sind, testbar sind, war es notwendig, ein dynamisches, in der
Anzahl der Sensoren nicht beschränktes Steuermodul zu programmieren. In der Funktionalität
unterscheidet es sich nicht von den beiden anderen. Es ist aber in der Lage, für die beiden Motoren
und für jeden Sensor ein getrenntes Programm ablaufen zu lassen. Im Unterschied zu den beiden
vorigen Modulen können die Sensoren nur schwer optisch angeordnet werden. Die Wahl fiel auf eine
einfachere Listenausgabe.
Am Anfang der Liste steht die aktuelle Position mit der Rücksetzmöglichkeit auf den Nullpunkt per
Doppelklick. Darunter folgt die Liste mit den beiden Motoren und allen Sensoren. Durch einen
Doppelklick auf eine Motor- oder Sensorbezeichnung kann ein Skript für diesen geladen werden. Es
wird automatisch ausgeführt, wenn die Simulation läuft. Um verschiedene Skripte parallel testen zu
können, ohne sie ständig neu laden zu müssen, ist es aber möglich, einzelne Motor- oder
Sensorskripte anzuhalten. Dies erfolgt durch Klick auf das Pausensymbol (||) hinter der jeweiligen
Bezeichnung. Angehaltene Skripte können jederzeit durch einen Klick auf das Abspielsymbol (>)
wieder gestartet werden.
Am Anfang jeder Zeile steht der Wert des Sensors und am Ende die Bezeichnung der geladenen
Skriptdatei.
Abbildung 7.11 - Dialogbeispiele einer offenen Steuerung für Easybot
Mit diesem Steuermodul ist es somit möglich, jedes Fahrzeug mit zwei Motoren und einer beliebigen
Anzahl von Entfernungssensoren innerhalb von Lightvision3D und damit in einer echten 3D-Welt-
Umgebung zu testen. Durch die Unterstützung von je einem Skript je Motor und Sensor können auch
verteilte Programme gut getestet werden. Wie schon in den beiden vorangegangenen Steuermodulen
wird das geladene Skript beim Aufruf der Navigate-Funktion von Easybot aus komplett abgearbeitet.
Es sollte also keine Endlosschleife enthalten. Dafür ist dieser Simulator nicht ausgelegt.
Im Folgenden ist ein Beispiel für die Steuerung des Cybot mit zwei Einzelprogrammen aufgeführt,
wobei jedes Programm in einem der beiden Motoren laufen kann. Cybot weicht dabei Hindernissen
immer nach rechts aus.
26.07.2004 Seite 57 von 85

Diplomarbeit: Modulares System Testen der Steuerungsskripte im Simulator
Abbildung 7.12 - Steuerprogramm Cybot, linker Motor
Abbildung 7.13 - Steuerprogramm Cybot, rechter Motor
7.4. Netbot
Um Roboter entwickeln und testen zu können, die nicht einem Fahrzeug entsprechen, war es nötig,
eine weitere Simulationsumgebung zu schaffen. Dabei wurde Wert darauf gelegt, dass es sich wirklich
um voneinander getrennt laufende Programme handelt, die miteinander kommunizieren. Die
Schaffung einer weiteren realen 3D-Umgebung spielte dabei keine Rolle. In einer weiterführenden
Arbeit kann dieses Verfahren mit Easybot verknüpft werden, um die Vorteile beider Simulatoren
miteinander zu verbinden.
7.4.1. Netzwerk
var sl,sr,ml,sreach,speed,fak;
BEGIN
fak:=15;
speed:=10;
sreach :=get(8,1,1); {get sensor reach}
sl := get(8,1,0); if sl>sreach then sl:=sreach; {get sensor left}
sr := get(8,2,0); if sr>sreach then sr:=sreach; {get sensor right}
if slsreach then sr:=sreach; {get sensor right}
if sl(sreach/fak) then
mr:=sreach/2;
if sl>(sreach/fak) then
if sr(sreach/fak) then
if sl

Diplomarbeit: Modulares System Testen der Steuerungsskripte im Simulator
Zielknoten bekannt ist und leitet die Anfrage dorthin um. Die Antwort wird dann an den aufrufenden
Knoten zurückgegeben. Um sich beim Server zu registrieren, muss jeder Client seine Gruppe und
seine Nummer bekannt geben. Damit der Server die Anfragen weiterleiten kann, muss er aber auch
selbst die Clients erreichen können. Dies könnte durch ein Polling-Verfahren erreicht werden, bei dem
der Client in bestimmten Zeitintervallen beim Server nachsieht, ob eine Anfrage für ihn vorliegt. Dies
erzeugt aber eine hohe Buslast und wird daher hier nicht verwendet. Jeder Client stellt einen
eigenständigen DCOM-Server dar, dessen Interface er dem NetbotServer bekannt gibt. Durch dieses
so genannte Callback-Verfahren kann der NetbotServer jeden Client jederzeit erreichen und Werte
abfragen, die er an den aufrufenden Client zurückgeben kann.
Abbildung 7.14 - Typbibliotheken NetbotServer und NetbotClient
Der NetbotServer muss als DCOM-Objekt in Windows angemeldet werden. Dies erfolgt durch einen
einmaligen direkten Aufruf. Danach wird er automatisch gestartet, sobald ein Client darauf zugreifen
will. Der Server funktioniert komplett ohne Nutzereingaben und kann daher auch versteckt laufen (dies
ist in den DCOM-Eigenschaften einstellbar). Anschaulicher ist jedoch die grafische Oberfläche. Auf
dieser werden im Mittelteil die angemeldeten Knotenpunkte (Clients) farbig dargestellt. Wie in Kapitel
3 beschrieben, kann der Server 15 Gruppen mit jeweils 255 Clients bedienen. Dazu hält er eine
statische Tabelle mit allen angemeldeten Knotenpunkten. Zusätzlich werden alle Anfragen mit
Ergebnis in der Statuszeile angezeigt.
Abbildung 7.15 - NetbotServer
7.4.2. Knotenpunkte
Um die Knotenpunkte, also die Sensoren und Aktoren, im Netzwerk abzubilden, müssen diese eine
Virtuelle Maschine enthalten und sich am Netzwerk (in der Simulation der NetbotServer) anmelden
können. Da die Knotenpunkte in ihrem Aufbau nahezu identisch sind, wurde nur ein Client
programmiert, der jede der in Kapitel 3 beschriebenen Gruppen simulieren kann. Die jeweilige Gruppe
wird zur Erstellungszeit festgelegt und kann dann nicht mehr geändert werden. Beim Aufruf startet der
26.07.2004 Seite 59 von 85

Diplomarbeit: Modulares System Testen der Steuerungsskripte im Simulator
Client automatisch den NetbotServer. Danach muss dem Server noch die Nummer (ID) des Clients
bekannt gegeben werden. Dabei werden automatisch auch die Callback-Routinen verbunden.
Abbildung 7.16 - Aufruf des NetbotServer durch den Client
Der Knotenpunkt ist damit schon im Netzwerk eingebunden und kann bereits seine Aufgabe
wahrnehmen. Je nach Gruppentyp kann der Wert des Knotens (z.B. die Entfernung) in der Oberfläche
eingestellt werden. Dieser wird auf Anfrage von außen weitergereicht. Soll ein Wert von außen gesetzt
werden, prüft der Client, ob dies überhaupt möglich ist (es ist nicht möglich, die Temperatur von
außen zu setzen, da dies ein Messwert ist!). Um das Netzwerk mit Logik zu versehen, kann jeder
Knotenpunkt eine Skriptdatei laden und ausführen. Dies entspricht weitestgehend dem Verfahren, das
auch im Easybot eingesetzt wurde. Es wird die gleiche VM.DLL als Grundlage genutzt.
Abbildung 7.17 - Beispiel für NetbotClients
Die Abbildung 6.4 am Anfang dieses Kapitels zeigt eine simulierte Umgebung des auch im Easybot
vorhandenen Cybot. Im laufenden Betrieb zeigt der sich drehende rote Strich beim Motor dessen
Bewegung an. Im Gegensatz zum Easybot kann diese Simulation im Netbot jederzeit um
Funktionalitäten erweitert werden. Beispielsweise kann der Cybot mit zwei Lampen (LED) versehen
werden, die (als Warnsignal) zu leuchten beginnen, wenn einer der Sensoren einem Objekt zu nahe
kommt.
// Create DCOM-Server
FNetbot = CoNetbotCB.Create();
FCallback = (ICallback)CoNetbotCallbackObj.Create();
// Initialize and bind Callback
FNetbot.SetCallback(group,id,FCallback);
// call for value
FNetbot.GetValue(group_id,id,param,value);
...
var sl,ll,sreach,fak;
BEGIN
fak:=15;
sreach :=get(8,1,1); {get sensor reach}
sl := get(8,1,0); if sl>sreach then sl:=sreach; {get sensor left}
if sl

Diplomarbeit: Modulares System Testen der Steuerungsskripte im Simulator
7.5. Fazit
Die in diesem Kapitel vorgestellten Simulatoren Easybot und Netbot sind mit ihren jeweiligen
Einschränkungen gut geeignet, um die Steuerung eines Roboters mit einem Netzwerk von Sensoren
und Aktoren zu simulieren.
Easybot eignet sich hervorragend, um Fahrzeuge mit zwei angetriebenen Rädern zu simulieren und
mit dem offenen Steuermodul ist er auch in der Lage mehrere Skripte ablaufen zu lassen, wie es im
Netzwerk der Fall sein wird.
Der Netbot ist durch die fehlende optische 3D-Unterstützung weniger gut geeignet, wenn reale sich
bewegende Objekte abgebildet werden sollen. Er erfordert ein hohes Abstraktionsvermögen des
Anwenders. Auf der anderen Seite hat er aber den Vorteil, nicht auf Fahrzeuge festgelegt zu sein,
sondern die Simulation beliebiger Roboter (so z.B. auch Haussteuerungen) zu ermöglichen.
In einer weiterführenden Arbeit sollten beide miteinander kombiniert werden, um die größtmögliche
Effizienz zu erreichen. Dazu müssen die Easybot-Steuermodule mit dem DCOM-Server verbunden
werden. Dieser benötigt gleichzeitig neue Funktionalitäten, die die mechanischen Zusammenhänge
der einzelnen Roboter abbildet. So sollte sich der Arm eines Roboters mitbewegen, sobald sich der
Grundkörper bewegt. Dieses Verhalten kann durch den Server mit gesteuert werden. Einfacher wäre
jedoch eine Weiterentwicklung des Easybot in dieser Richtung.
Ein Ansatz in dieser Richtung bietet die Diplomarbeit von K. Hofmann, ebenfalls Studentin der HTW-
Dresden, die mir leider zu spät vorlag, um sie komplett als Grundlage dieser Arbeit zu nutzen. Bei
dem von ihr geschaffenen Simulator JRoboSim wurde Wert auf die Erweiterbarkeit und Flexibilität
gelegt. Im Unterschied zu Easybot sind von JRoboSim alle Quellen frei erhätlich und können
demzufolge an die eigenen Bedürfnisse angepasst werden. Die Ausprägung für eine verteilte
Simulation bietet diese Software ebenfalls noch nicht, wurde aber von Frau Hofmann bereits
vorgesehen und als Erweiterung in Aussicht gestellt.
26.07.2004 Seite 61 von 85

Diplomarbeit: Modulares System Praktische Anwendung
8. Praktische Anwendung
Die mit den Hilfsmitteln des vorigen Kapitels entwickelten und getesteten Robotersteuerungen sollen
nicht nur in einem Simulator sondern auch in der Praxis Verwendung finden.
Wie in den vorangegangenen Kapiteln beschrieben soll der Roboter nicht aus einer einzelnen
Zentralsteuerung mit einem leistungsfähigen Prozessor bestehen, an den alle Sensoren und Aktoren
direkt angeschlossen sind, sondern aus einem Netzwerk von Controllern, mit denen jeweils ein
Sensor oder Aktor verbunden ist. Die Controller müssen Kenntnis über ihr angeschlossenes Endgerät
haben und mit ihm arbeiten können. Alle anderen Geräte sind für sie abstrakt und können über das
Netzwerk abgefragt und gesetzt werden, ohne zu wissen, was für Parameter genau für eine Messung
benötigt werden.
Im Gegensatz zu einem Heimcomputer haben Controller sehr wenig Speicher (wenige Kilobyte) und
müssen schon daher völlig anders programmiert werden. Zum Beispiel sollten Funktionsaufrufe
möglichst vermieden werden und Speicher allozieren ist komplizierter (der Speicher ist meist in Blöcke
von 256 Byte eingeteilt und muss selbst verwaltet werden) als bei den heute üblichen Verfahren bei
Personalcomputern. Daher wurde die Programmierung der Controllersteuerung und der Entwurf und
Aufbau der dazugehörigen elektrischen Schaltungen von Dipl. Ing. M. Dittmar übernommen. Er ist auf
die Programmierung von Controllern und dem Entwerfen von den zugehörigen Platinen spezialisiert.
Im Anhang A.7 findet sich ein Beispiel für die Programmierung der Maschine auf dem Controller.
Bei der Auswahl des Controllers spielten mehrere Faktoren eine Rolle. Gesucht wurde ein preiswerter
Controller, der genügend Anschlussmöglichkeiten für die verschiedenen Knotentypen bietet und über
ausreichend Speicher verfügt. Außerdem sollte er den in Kapitel 4 gewählten Bus (CAN) unterstützen.
Die Wahl fiel auf Mikrocontroller der Baureihe PIC18 von der amerikanischen Firma Microchip. Sie
bieten alle benötigten Fähigkeiten und liegen preislich in einem annehmbaren Rahmen (ca. 3-6€ pro
Einzelstück, je nach Ausführung).
8.1. Funktionalität der Knotenpunkte
Jeder Knotenpunkt muss zum einen über Fähigkeiten verfügen, die alle gemein haben und zum
anderen über einige, die auf sein spezifisches Endgerät zugeschnitten sind.
8.1.1. Grundumfang
Die wichtigste Aufgabe aus Anwendersicht ist die Fähigkeit, Codedateien auszuführen. Dazu musste
die Virtuelle Maschine in eine Form gebracht werden, die der Controller ausführen kann und es
müssen die beiden Steuerbefehle (Get, Put) umgesetzt werden. Des Weiteren muss die
Kommunikation zwischen den einzelnen Elementen des Netzwerkes sichergestellt und auf
Systemkommandos von außen reagiert werden. Um für zukünftige Erweiterungen vorbereitet zu sein,
wurden die Controller von M. Dittmar so programmiert, dass sie auch mehrere Virtuelle Maschinen
gleichzeitig ablaufen lassen können.
26.07.2004 Seite 62 von 85

Diplomarbeit: Modulares System Praktische Anwendung
8.1.2. Knotentypspezifische Fähigkeiten
Darüber hinaus muss jeder Knotenpunkt über die Fähigkeit verfügen, mit seinem speziellen Sensor
beziehungsweise Aktor zu interagieren und dessen Werte und Fähigkeiten dem Netzwerk zur
Verfügung zu stellen. Die dazu benötigten Parameter müssen im Controllerprogramm enthalten sein
und können später noch angepasst werden. Jeder Knotentyp hat einen eigenen spezifischen
Programmteil innerhalb des Controllers. Das von M. Dittmar entwickelte Controllerprogramm enthält
die spezifischen Programmteile für alle Knotentypen. Es wird erst im Controller entschieden, welcher
Typ verwendet wird. Dadurch sind die Controller universell einsetzbar und müssen nicht jedes Mal
neu programmiert werden.
8.1.3. Programmierbarkeit
Um den Controller in die Lage zu versetzen die vorgenannten Fähigkeiten ausführen zu können, muss
er immer wieder neu programmiert werden. Dies geschieht zu Anfang mit einem so genannten
Programmiergerät. Es spielt das Programm direkt in den Controllerspeicher ein. Dies ist sehr
umständlich und erfordert einen Eingriff in die umgebende Elektronik. Da aber vor allem die
Steuerungsskripte jederzeit austauschbar sein sollen, ist dieses Verfahren zu umständlich. Daher
besteht eine Grundfunktion der Controllersoftware darin, Updates über eine RS232-Schnittstelle, die
von einem Computer direkt angesprochen werden kann, zu empfangen. Um den Controller zu
programmieren versieht das Computerprogramm die Daten mit einer Kennung, die besagt, was getan
werden soll (Firmwareupdate, Skriptupdate, Parametereinstellung) und schickt sie über die RS232 an
den Controller Um den Programmiervorgang überwachen zu können, wird jedes Byte vom Controller
im Echomodus bestätigt. Das bedeutet, dass er das empfange Byte direkt wieder zurücksendet.
Daran kann das Computerprogramm erkennen, ob die Programmierung erfolgreich war und sie im
Fehlerfall abbrechen oder wiederholen.
In einer Weiterentwicklung soll der Computer ebenfalls mit einer CAN-Schnittstelle versehen werden
und die Programmierung im laufenden Netzwerk vonstatten gehen. Dies hat den Vorteil, dass keine
Umbauten am Roboter nötig sind, sondern sich nur der Personalcomputer in den Bus einklinken
muss. Wie schon in den Systemkommandos (Tabelle 3.6) vorgesehen, kann er dann jeden
Knotenpunkt einzeln steuern und überwachen. Auch die Fehlersuche, die momentan an jedem
Controller einzeln mittels einer RS232-Debug-Schnittstelle geschieht, kann dann über den CAN-Bus
leichter erfolgen.
26.07.2004 Seite 63 von 85

Diplomarbeit: Modulares System Praktische Anwendung
8.2. Programmierung und Steuerung vom Computer aus
Um jeden Knotenpunkt mit einem neuen Programm versehen und die Parameter, die für den Betrieb
notwendig sind, einstellen zu können, wurde ein spezielles Computerprogramm entwickelt. Es
kommuniziert über eine RS232-Schnittstelle (im Computer als COM vorhanden) mit dem Controller.
Abbildung 8.1 - Netbot Setup Programm
8.2.1. Firmware
Mit der Funktion „Send Firmware“ kann ein komplettes Firmwareupdate übertragen werden. Das
heißt, die komplette Software des Controllers wird ausgetauscht. Dies birgt natürlich das Risiko, dass,
wenn etwas fehlschlägt, der Controller nicht mehr verwendbar wird. Daher sind die Grundroutinen, die
zum Betrieb des Controllers und die Kommunikation mit der RS232 betreffen, von der
Programmierung ausgeschlossen. Sollen sie ersetzt werden, muss auf das umständlichere
Programmiergerät zurückgegriffen werden.
8.2.2. Skript
Damit die Virtuelle Maschine einfach mit neuen Skriptdateien versorgt werden kann, können diese mit
dem Computerprogramm über die RS232 an den Controller übertragen werden. Die Übertragung
erfolgt wie bei einem Firmware-Update und wird nur von einer anderen Kennung eingeleitet.
8.2.3. Parameter
Um die Sensoren und Aktoren korrekt ansteuern zu können, müssen dem Controller der
Knotenpunkttyp, seine ID und die Geschwindigkeit bekannt sein, mit der er über den CAN-Bus
kommunizieren kann. Diese Werte können gelesen und geschrieben werden.
8.2.4. Codierung
Um die dargestellten Aufgaben erledigen zu können, muss das Programm die Daten verpacken. Sie
werden mit einer Kennung versehen, die angibt, was getan werden soll. Zusätzlich wird am Ende eine
Checksumme übertragen, mit der der Controller überprüfen kann, ob die Übertragung fehlerfrei war.
Kennung
Länge
Daten
Checksumme
Abbildung 8.2 - Aufbau der Kommunikation zwischen Computer und Controller
26.07.2004 Seite 64 von 85

Diplomarbeit: Modulares System Praktische Anwendung
Kennung Bedeutung
10 Schreibe Firmware
20 Schreibe Skript
30 Schreibe Parameter
40 Lese Parameter
50 Statusabfrage
Tabelle 8.1 - Kennung der Übertragung zwischen Computer und Controller
8.3. Beispielanwendung: Ausweichen
Da der in der Simulation im vorigen Kapitel verwendete Khepera sich elektronisch und mechanisch
nicht verändern lässt, wird bei diesem Beispiel lediglich das Fahrzeugchassis von Cybot benutzt.
Dazu wird die originale Elektronik entfernt und durch vier Controller-Knotenpunkte ersetzt, die über
CAN miteinander verbunden sind. Dabei kann die Stromversorgung (vier Batterien Typ AA, 1.5V und
ein 9V-Block) genutzt werden. Die einzelnen Knotenpunkte werden mit einem 5-adrigen
Flachbandkabel mit der Stromversorgung verbunden. Gleichzeitig werden damit die CAN-Leitungen
verbunden.
Das Kabel enthält folgende Leitungen:
- Masse
- Strom für die Controller
- Strom für die Endgeräte (Spannung je nach angeschlossenem Erzeuger)
- zweimal CAN
Abbildung 8.3 - Fahrwerk des Cybot und die originale Elektronik
Abbildung 8.4 - Aktoren und Sensoren als Einzelkomponenten
26.07.2004 Seite 65 von 85

Diplomarbeit: Modulares System Praktische Anwendung
8.3.1. Software
In diesem Beispiel finden die bereits vorgestellten Programme aus den vorigen Kapiteln ihre
Anwendung. Der Roboter soll sich durch den Raum bewegen und Hindernissen ausweichen.
var sl,sr,ml,sreach,speed,fak;
BEGIN
fak:=15;
speed:=10;
sreach :=get(8,1,1); {get sensor reach}
sl := get(8,1,0); if sl>sreach then sl:=sreach; {get sensor left}
sr := get(8,2,0); if sr>sreach then sr:=sreach; {get sensor right}
if slsreach then sr:=sreach; {get sensor right}
if sl(sreach/fak) then
mr:=sreach/2;
if sl>(sreach/fak) then
if sr(sreach/fak) then
if sl

Diplomarbeit: Modulares System Praktische Anwendung
8.3.2. Aufbau
Abbildung 8.7 - Weg des Roboters im Simulator
Um dieses Verhalten in der Realität nachzuvollziehen, müssen die Steuerungsskripte mit dem
Computerprogramm NetbotSetup in die beiden Motorsteuerungen geladen werden. Die beiden
Entfernungsmesser erhalten keine Skripte. Sie liefern den Motorsteuerungen auf Anfrage ihre Werte.
Der linke Motor muss nach diesem Beispiel mit der Nummer 1 und der rechte mit der Nummer 2
versehen werden. Dies gilt ebenso für die Sensoren. Diese Nummern können natürlich frei gewählt
werden. Es müssen dann lediglich die Steuerprogramme entsprechend angepasst werden.
Sind alle Controller eingestellt, können sie, soweit dies noch nicht geschehen ist, auf dem Fahrwerk
montiert werden. Die Programmierung kann auch im eingebauten Zustand erfolgen, da dafür nur ein
serielles Verbindungskabel mit Adapter angebracht werden muss. Dafür muss lediglich darauf
geachtet werden, dass die Anschlüsse von außen gut erreichbar sind.
Abbildung 8.8 - Cybot mit Netbot-Controllern
Der Roboter kann damit in Betrieb genommen werden und sich im Raum bewegen.
Abbildung 8.9 - Netbot in Bewegung
8.3.3. Erweiterung
Soll der Roboter zusätzlich zu diesen Funktionen noch eine weitere übernehmen, beispielsweise das
Einschalten einer Warnlampe, wenn ein Hindernis zu nah ist, kann dies ohne Eingriff in die laufenden
26.07.2004 Seite 67 von 85

Diplomarbeit: Modulares System Praktische Anwendung
Systeme geschehen. Es müssen lediglich zwei neue Controller eingestellt und angeschlossen
werden. Die linke Warnlampe erhält wieder die Nummer 1 und die rechte die Nummer 2. Damit
können die untenstehenden Programme verwendet werden.
Abbildung 8.10 - Steuerprogramm linke Warnlampe
Abbildung 8.11 - Steuerprogramm rechte Warnlampe
Die beiden Controller mit den Lampen müssen montiert werden. Da dies bei einem sich bewegenden
Roboter schwierig ist, muss er in diesem Beispiel dafür abgeschaltet werden. Da das System aber
dafür ausgelegt ist, dies auch im laufenden Betrieb zu machen, können die Erweiterungen installiert
werden, ohne das Netzwerk zu stören. Falls die ID falsch vergeben wurden und bereits im Netzwerk
existieren, deaktivieren sich die neu hinzukommenden Einheiten automatisch.
Abbildung 8.12 - Netbot mit installierten Warnlampen
Wird der Roboter nach dieser Erweiterung wieder in Betrieb genommen, vollführt er immer noch die
gleichen Bewegungen im Raum. Zusätzlich aber leuchten die Warnlampen auf, wenn sich ein
Hindernis nähert.
var sl,ll,sreach,fak;
BEGIN
fak:=15;
sreach :=get(8,1,1); {get sensor reach}
sl := get(8,1,0); if sl>sreach then sl:=sreach; {get sensor left}
if slsreach then sr:=sreach; {get sensor right}
if sr

Diplomarbeit: Modulares System Ergebnisse und Ausblick
9. Ergebnisse und Ausblick
Wie das im März dieses Jahres stattgefundene erste Wettrennen autonom steuernder Fahrzeuge
gezeigt hat, ist das Thema Roboter und effiziente Steuerung aktueller denn je. Bei dem 160 Meilen
Rennen kam das beste Team knapp 7,4 Meilen weit. Zum zweiten Wettlauf im Herbst nächsten
Jahres werden wieder viele Verbesserungen erwartet. Die meisten Teams waren mit der Zielsetzung
gestartet, offenes Gelände zu erreichen. Davon, das Ziel zu erreichen, träumten nur wenige.
9.1. Ergebnisse
Das in dieser Arbeit vorgestellte Konzept eines verteilten Netzwerkes von selbstständigen Sensoren
und Aktoren kann auch dazu verwendet werden, eine solch komplexe Aufgabe zu übernehmen. Dazu
werden dann aber weitere Elemente, die in dieser Arbeit nicht betrachtet wurden, benötigt. Dies betrifft
vor allem optische Wahrnehmungen und Objekt- beziehungsweise Wegerkennung. Diese Arbeiten
werden kaum von Skripten übernommen werden können, sondern müssen in speziellen dafür
vorgesehenen DSP-Controllern aufbereitet werden.
Vor allem der Test von Algorithmen sowohl im Simulator als auch im realen Modell kann mit den hier
vorgestellten Techniken gut vollzogen werden. Es sind sowohl mobile autarke Fahrzeuge mit wenig
Aufwand programmier- und testbar, als auch Haussteuerungen, die aus einer Vielzahl von einzelnen
Elementen bestehen. Die Testläufe können sowohl in den beiden Simulatoren (Steuermodule für
Easybot und der selbst entwickelte Netbot) als auch in der Realität mit den von Diplomingenieur M.
Dittmar programmierten Mikrocontrollern durchgeführt werden. Ein späterer Austausch der
verwendeten Controller durch einen anderen Typ ist jederzeit ohne Änderung der Steuerungsskripte
möglich. Es muss lediglich die Virtuelle Maschine an den neuen Controllertyp angepasst werden.
Durch die Kapselung der Virtuellen Maschine als DLL kann diese in jedem beliebigen Programm
eingesetzt werden. Dadurch ist es möglich, sie später auch in neuen Simulatoren ohne eine
Veränderung der Maschinenfunktionen einzubinden. Soll die Virtuelle Maschine um Fähigkeiten
erweitert werden, die nicht die Kommunikation zwischen den Elementen des Netzwerkes betreffen, so
brauch nur die DLL geändert und ausgetauscht werden. Die Endprogramme bleiben von diesen
Änderungen weitestgehend unberührt.
Durch die Entwicklung von Netbot als DCOM-Client-Server-Architektur wurde bereits der erste Schritt
für eine über viele Rechner gehende Testumgebung geschaffen.
Das System ist jederzeit um neue, einfach zu programmierende, Elemente erweiterbar. So kann sich
eine Vielzahl neuer Elemente einfügen, die sich an die geschaffenen Kommunikationsrichtlinien
halten.
Damit wurden die Ziele der Arbeit erreicht.
26.07.2004 Seite 69 von 85

Diplomarbeit: Modulares System Ergebnisse und Ausblick
9.2. Ausblick
Weiterentwicklungen sind in vielerlei Hinsicht erstrebenswert. Dies betrifft in erster Linie den Komfort
bei der Erstellung der Steuerskripte. Der hier verwendete Kommandozeilencompiler sollte mit einem
grafisch orientierten Editor ähnlich denen von Microsoft oder Borland verbunden werden. Auch die
Ausgabe von Fehlercodes, die zum Abbruch des Übersetzungsvorgangs führen, sollte eingearbeitet
werden. Derzeit erfolgt nur eine ungefähre Angabe der Position im Quelltext. Ein nächster großer
Schritt für die Verwendbarkeit auch zu Schulzwecken wäre eine grafische Programmierumgebung,
wie sie die Firmen LEGO oder fischertechnik vormachen. Diese ermöglichen gerade Anfängern einen
leichten Einstieg in die Thematik, ohne sie gleich mit einer fremden Programmiersprache zu belasten.
Auch auf dem Gebiet des Sprachumfangs besteht durchaus Weiterentwicklungspotential. Zusätzlich
zu den kopfgesteuerten Schleifen sollten Zählschleifen eingeführt werden. Eine Mehrfachverzweigung
und vor allem logische Operatoren würden das System vervollständigen. Die Einführung eines
zweiten Datentyps (reelle Zahl) würde dem Entwickler die Arbeit mit dem System vereinfachen. Da
dies für die Controller eine erhebliche Belastung darstellt (extrem rechenaufwendig) könnte dafür über
eine Erweiterung um eine Art Coprozessor, der nur im Bedarfsfall verwendet wird, oder ein ähnliches
Verfahren nachgedacht werden. Denkbar wäre auch die Unterstützung einer moderneren
Hochsprache wie C++. Dazu muss aber erst die Leistungsfähigkeit der Controller in der Realität
getestet werden, um entscheiden zu könne, ob sie komplexere Virtuelle Maschinen beherrschen
können.
Die Simulation auf einem Personalcomputer kann noch entscheidend verbessert werden. Dazu
müssen die Fähigkeiten eines dreidimensionalen Simulators wie dem Easybot mit denen eines
verteilten Netzwerkes kombiniert werden.
Im Easybot sollten neue Sensoren und Aktoren wie zum Beispiel Lampen eingeführt werden. Das
vorhandene System im Lightvision3D sollte um eine Kollisionserkennung erweitert werden, um das
Realitätsempfinden zu erhöhen. (Nachtrag: mittlerweile mit der Diplomarbeit von M. Lelle geschehen).
Eine der vordringlichsten Änderungen wäre aber die Schaffung der Möglichkeit, auf andere Objekte
zuzugreifen, um auch komplexere Roboter steuern zu können, die aus mehreren Teilen bestehen und
nicht nur aus einem Fahrwerk mit direkt angebrachten Sensoren.
Einen Ansatz in diese Richtung bietet JRoboSim. Durch sein offenes flexibles System ist er in der
Lage, genau diese Aufgaben zu übernehmen. Die Ausprägung als verteiltes System liegt zwar noch
nicht vor, kann aber einfacher realisiert werden, als bei Easybot.
Der Simulator Netbot kann um die Fähigkeit erweitert werden, über eine geeignete Schnittstelle (z.B.
einer RS232-CAN-Bridge) mit dem real existierenden Controller-Netzwerk zu interagieren und so
einen weiteren Knotenpunkt dazustellen.
26.07.2004 Seite 70 von 85

Diplomarbeit: Modulares System Thesen
Thesen
Die dezentrale Steuerung von Robotern auf Basis eines intelligenten Netzwerkes von eigenständig
agierenden Sensoren und Aktoren ist eine kostengünstige effiziente Alternative zu herkömmlichen
Systemen.
Die Verwendung eines Netzwerkes von Controllern statt einer zentralen Recheneinheit ermöglicht den
einfachen Austausch einzelner Elemente, ohne das Gesamtsystem wesentlich zu beeinflussen.
Im Gegensatz zu zentral gesteuerten Robotern, bei denen die Sensoren und Aktoren meist direkt an
den Rechenkern angeschlossen werden und deren Anzahl daher meist beschränkt ist, ermöglicht das
Netzwerk eine wesentlich höhere Anzahl von Elementen.
Die Nutzung einer Virtuellen Maschine bringt eine Verringerung des Entwicklungsaufwandes für den
Endnutzer. Änderungen an den Controllern haben keinen Einfluss auf die Steuerskripte.
Durch die Verwendung einer Virtuellen Maschine können Steuerprogramme leicht in einem Simulator
getestet werden und ohne Änderung im realen Roboter ablaufen.
Durch die Ausprägung der Virtuellen Maschine als DLL kann sie in jedem beliebigen
Windowsprogramm eingesetzt werden. Also auch in anderen, neuen Simulatoren. Außerdem ist sie
dadurch sprachunabhängig.
Die Steuerskripte werden in PL0, einer einfachen pascalähnlichen Sprache, entwickelt und von einem
Kommandozeilencompiler übersetzt.
Die Codedateien laufen in allen Implementierungen der Virtuellen Maschine identisch ab, egal ob im
Simulator oder im realen Roboter.
Für den Simulator Easybot sind drei verschiedene Steuerungsmodule (Khepera, Cybot, multi)
entstanden, die die Virtuelle Maschine enthalten und Steuerprogramme ausführen können.
Ein zweiter Simulator, Netbot, speziell für die Simulation der Kommunikation auch über
Rechnergrenzen hinaus, wurde mit einer DCOM-Client-Server-Architektur entwickelt.
Es wurde auf Basis von PIC-Mikrocontrollern der Firma Microchip ein reales Netzwerk aufgebaut und
erfolgreich getestet.
26.07.2004 Seite 71 von 85

Diplomarbeit: Modulares System Anhang
Anhang
program block
.
PROGRAM
ident ;
block CONST ident
VAR
PROCEDURE
FUNCTION
statement
factor ident
number
( express )
GET ( express , express )
Abbildung A.1 - Syntaxgraphen in PL0
;
,
ident
statement ident := express
CALL
;
,
ident
= number
ident ; block
;
IF condition
THEN statement
ELSE statement
WHILE condition
DO statement
BEGIN statement
END
? ident
! express
;
PUT ( express , express , express )
condition ODD express
express
express
term factor
+
-
*
/
= # < >=
term
+
-
26.07.2004 Seite 72 von 85

Diplomarbeit: Modulares System Anhang
/* Zeichenklassenvektor */
static char vZKI[256]=
/* 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 1 2 3 4 5 6 7 8 9 A B C D E F */
/*--------------------------------------------------------------------------------*/
/* 0 */ {7,7, 7,7,7,7,7,7,7,7,7,7,7,7, 7,7, //
/* 1 */ 7,7, 7,7,7,7,7,7,7,7,7,7,7,7, 7,7, //
/* 2 */ 7,0,11,0,0,0,0,0,0,0,0,0,0,0,10,0, // ! " # $ % & ' ( ) * + , - . /
/* 3 */ 1,1, 1,1,1,1,1,1,1,1,3,0,5,4, 6,0, // 0 1 2 3 4 5 6 7 8 9 : ; < = > ?
/* 4 */ 0,2, 2,2,2,2,2,2,2,2,2,2,2,2, 2,2, // @ A B C D E F G H I J K L M N O
/* 5 */ 2,2, 2,2,2,2,2,2,2,2,2,0,0,0, 0,0, // P Q R S T U V W X Y Z [ \ ] ^ _
/* 6 */ 0,2, 2,2,2,2,2,2,2,2,2,2,2,2, 2,2, // ` a b c d e f g h i j k l m n o
/* 7 */ 2,2, 2,2,2,2,2,2,2,2,2,8,0,9, 0,0, // p q r s t u v w x y z { | } ~
/* 8 */ 0,0, 0,0,0,0,0,0,0,0,0,0,0,0, 0,0, // € ‚ ƒ „ … † ‡ ˆ ‰ Š ‹ Œ Ž
/* 9 */ 0,0, 0,0,0,0,0,0,0,0,0,0,0,0, 0,0, // ‘ ’ “ ” • - — ˜ š › œ ž Ÿ
/* A */ 0,0, 0,0,0,0,0,0,0,0,0,0,0,0, 0,0, // ¡ ¢ £ ¤ ¥ ¦ § ¨ © ª « ¬ ­ ® ¯
/* B */ 0,0, 0,0,0,0,0,0,0,0,0,0,0,0, 0,0, // ° ± ² ³ ´ µ ¶ · ¸ ¹ º » ¼ ½ ¾ ¿
/* C */ 0,0, 0,0,0,0,0,0,0,0,0,0,0,0, 0,0, // À Á Â Ã Ä Å Æ Ç È É Ê Ë Ì Í Î Ï
/* D */ 0,0, 0,0,0,0,0,0,0,0,0,0,0,0, 0,0, // Ð Ñ Ò Ó Ô Õ Ö × Ø Ù Ú Û Ü Ý Þ ß
/* E */ 0,0, 0,0,0,0,0,0,0,0,0,0,0,0, 0,0, // à á â ã ä å æ ç è é ê ë ì í î ï
/* F */ 0,0, 0,0,0,0,0,0,0,0,0,0,0,0, 0,0}; // ð ñ ò ó ô õ ö ÷ ø ù ú û ü ý þ ÿ
/* Schaltmatrix des Automaten */
static char vSMatrix[9][12]=
/* So Zi Bu ':' '=' '' Space { }
. " */
/*-------0--------1-------2-------3-------4-------5--------6-------7-------8-------
9-------10-------11------*/
/* 0 */ {0+ifslb, 1+ifsl, 2+ifgl, 3+ifsl, 0+ifslb, 4+ifsl, 5+ifsl, 0+ifl, 6+ifl,
0+ifslb, 0+ifslb, 8+ifl, // normal
/* 1 */ 0+ifb, 1+ifsl, 0+ifb, 0+ifb, 0+ifb, 0+ifb, 0+ifb, 0+ifb, 0+ifb,
0+ifb, 7+ifsl, 0+ifb, // oNumber
/* 2 */ 0+ifb, 2+ifsl, 2+ifgl, 0+ifb, 0+ifb, 0+ifb, 0+ifb, 0+ifb, 0+ifb,
0+ifb, 0+ifb, 0+ifb, // char
/* 3 */ 0+ifb, 0+ifb, 0+ifb, 0+ifb, 0+ifslb, 0+ifb, 0+ifb, 0+ifb, 0+ifb,
0+ifb, 0+ifb, 0+ifb, // :
/* 4 */ 0+ifb, 0+ifb, 0+ifb, 0+ifb, 0+ifslb, 0+ifb, 0+ifb, 0+ifb, 0+ifb,
0+ifb, 0+ifb, 0+ifb, // <
/* 5 */ 0+ifb, 0+ifb, 0+ifb, 0+ifb, 0+ifslb, 0+ifb, 0+ifb, 0+ifb, 0+ifb,
0+ifb, 0+ifb, 0+ifb, // >
/* 6 */ 6+ifsl, 6+ifsl, 6+ifsl, 6+ifsl, 6+ifsl, 6+ifsl, 6+ifsl, 6+ifsl,
6+ifsl,0+iflb, 6+ifsl, 6+ifsl, // {}
/* 7 */ 0+ifb, 7+ifsl, 0+ifb, 0+ifb, 0+ifb, 0+ifb, 0+ifb, 0+ifb, 0+ifb,
0+ifb, 0+ifb, 0+ifb, // fNumber
/* 8 */ 8+ifsl, 8+ifsl, 8+ifsl, 8+ifsl, 8+ifsl, 8+ifsl, 8+ifsl, 8+ifsl,
8+ifsl,8+ifsl, 8+ifsl, 0+iflb // ""
};
// Symboltabelle
const int vWSymbCount=19;
char* vWSymb[vWSymbCount]={"BEGIN", "CALL", "CONST", "DO", "ELSE", "END", "IF",
"ODD", "PROCEDURE", "FUNCTION", "THEN", "VAR", "WHILE", "PROGRAM", "INTEGER",
"FLOAT", "STRING", "GET", "PUT"};
Abbildung A.2 - Tabellen der lexikalischen Analyse in PL0
26.07.2004 Seite 73 von 85

Diplomarbeit: Modulares System Anhang
/* Nr tBg BgX Action,Next,Alt */
tBog gProgram[]=
{
/* 0 */ {BgSy,{(unsigned long)zPRG }, NULL , 1, 3}, /*(0) --'PROGRAM'--> (1)*/
/* 1 */ {BgMo,{(unsigned long)mcIdent }, NULL , 2, 0}, /*(1) ---ident-----> (2)*/
/* 2 */ {BgSy,{(unsigned long) ';' }, NULL , 3, 0}, /*(2) ----';'------> (3)*/
/* 3 */ {BgGr,{(unsigned long)gBlock }, NULL , 4, 0}, /*(3) ---block-----> (4)*/
/* 4 */ {BgSy,{(unsigned long) '.' }, Pr_04, 5, 0}, /*(4) ----'.'------> (5)*/
/* 5 */ {BgEn,{(unsigned long) 0 }, NULL , 0, 0} /*(5) ------------->(ENDE)*/
};
tBog gBlock[]=
{
/* 0 */ {BgSy,{(unsigned long)zCST }, NULL , 1, 6}, /*(0) --'CONST'--> (1)*/
/* 1 */ {BgMo,{(unsigned long)mcIdent }, Bl_01, 2, 0}, /*(1) ---ident---> (2)*/
/* 2 */ {BgSy,{(unsigned long) '=' }, NULL , 3, 0}, /*(2) ----'='----> (3)*/
/* 3 */ {BgMo,{(unsigned long)mcONumb }, Bl_03, 4, 0}, /*(3) ---o-number--> (5)*/
/* 4 */ {BgSy,{(unsigned long) ',' }, NULL , 1, 5}, /*(5) ----','----> (1)*/
/* 5 */ {BgSy,{(unsigned long) ';' }, NULL , 6, 0}, /* + ----';'----> (7)*/
/* 6 */ {BgSy,{(unsigned long)zVAR }, NULL , 7,10}, /*(6) ---'VAR'---> (7)*/
/* 7 */ {BgMo,{(unsigned long)mcIdent }, Bl_08, 8, 0}, /*(7) ---ident---> (8)*/
/* 8 */ {BgSy,{(unsigned long) ',' }, NULL , 7, 9}, /*(8) ----','----> (7)*/
/* 9 */ {BgSy,{(unsigned long) ';' }, NULL ,10, 0}, /* + ----';'---->(10)*/
/*10 */ {BgSy,{(unsigned long)zPRC }, NULL ,11,15}, /*(10)--'PROCEDURE'-->(11)*/
/*11 */ {BgMo,{(unsigned long)mcIdent }, Bl_12,12, 0}, /*(11)---ident--->(12)*/
/*12 */ {BgSy,{(unsigned long) ';' }, NULL ,13, 0}, /*(12)----';'---->(13)*/
/*13 */ {BgGr,{(unsigned long)gBlock }, NULL ,14, 0}, /*(13) --block--->(14)*/
/*14 */ {BgSy,{(unsigned long) ';' }, Bl_15,10, 0}, /*(14)----';'---->(10)*/
/*15 */ {BgSy,{(unsigned long)zFNC }, NULL ,16,20}, /*(10)--'FUNCTION'-->(11)*/
/*16 */ {BgMo,{(unsigned long)mcIdent }, Bl_17,17, 0}, /*(11)---ident--->(12)*/
/*17 */ {BgSy,{(unsigned long) ';' }, NULL ,18, 0}, /*(12)----';'---->(13)*/
/*18 */ {BgGr,{(unsigned long)gBlock }, NULL ,19, 0}, /*(13) --block--->(14)*/
/*19 */ {BgSy,{(unsigned long) ';' }, Bl_20,10, 0}, /*(14)----';'---->(10)*/
/*20 */ {BgNl,{(unsigned long) 0 }, Bl_21,21, 0}, /*(15)----nil---->(16)*/
/*21 */ {BgGr,{(unsigned long)gStatement}, NULL ,22, 0}, /*(16)-Statement->(17)*/
/*22 */ {BgEn,{(unsigned long) 0 }, NULL , 0, 0} /*(17)----------->(ENDE)*/
};
tBog gStatement[]=
{
/* 0 */ {BgMo,{(unsigned long)mcIdent },St_00, 1, 3}, /*( 0)---ident---> (1)*/
/* 1 */ {BgSy,{(unsigned long)zErg },NULL , 2, 0}, /*( 1)---':='----> (2)*/
/* 2 */ {BgGr,{(unsigned long)gExpr },St_02,31, 0}, /*( 2)--express-->(23)*/
/* 3 */ {BgSy,{(unsigned long)zCLL },NULL , 4, 5}, /*( 3)--'CALL'---> (4)*/
/* 4 */ {BgMo,{(unsigned long)mcIdent },St_04,31, 0}, /*( 4)---ident--->(23)*/
/* 5 */ {BgSy,{(unsigned long)zIF },NULL , 6,11}, /*( 5)----'IF'---> (6)*/
/* 6 */ {BgGr,{(unsigned long)gCondition},St_06, 7, 0}, /*( 6)-condition-> (7)*/
/* 7 */ {BgSy,{(unsigned long)zTHN },NULL , 8, 0}, /*( 7)---'THEN'--> (8)*/
/* 8 */ {BgGr,{(unsigned long)gStatement},St_08, 9, 0}, /*( 8)-statement-> (9)*/
/* 9 */ {BgSy,{(unsigned long)zELSE },St_09,10,31}, /*( 9)---'ELSE'-->(10)*/
/*10 */ {BgGr,{(unsigned long)gStatement},St_10,31, 0}, /*(10)-statement->(23)*/
/*11 */ {BgSy,{(unsigned long)zWHL },St_11,12,15}, /*(11)--'WHILE'-->(12)*/
/*12 */ {BgGr,{(unsigned long)gCondition},St_12,13, 0}, /*(12)-condition->(13)*/
/*13 */ {BgSy,{(unsigned long)zDO },NULL ,14, 0}, /*(13)----'DO'--->(14)*/
/*14 */ {BgGr,{(unsigned long)gStatement},St_14,31, 0}, /*(14)-statement->(23)*/
/*15 */ {BgSy,{(unsigned long)zBGN },NULL ,16,19}, /*(15)--'BEGIN'-->(16)*/
/*16 */ {BgGr,{(unsigned long)gStatement},NULL ,17,18}, /*(16)-statement->(17)*/
/*17 */ {BgSy,{(unsigned long)';' },NULL ,16, 0}, /*(17)----';'---->(16)*/
/*18 */ {BgSy,{(unsigned long)zEND },NULL ,31, 0}, /*(18)---'END'--->(23)*/
/*19 */ {BgSy,{(unsigned long)'?' },NULL ,20,21}, /*(19)----'?'---->(20)*/
/*20 */ {BgMo,{(unsigned long)mcIdent },St_20,31, 0}, /*(20)---ident--->(23)*/
/*21 */ {BgSy,{(unsigned long)'!' },NULL ,22,23}, /*(21)----'!'---->(22)*/
/*22 */ {BgGr,{(unsigned long)gExpr },St_22,31, 0}, /*(22)--express-->(23)*/
/*23 */ {BgSy,{(unsigned long)zPUT },NULL ,24, 0}, /*(21)----'Put'---->(22)*/
/*24 */ {BgSy,{(unsigned long) '(' },NULL ,25, 0}, /* + ----'('----> (1)*/
/*25 */ {BgGr,{(unsigned long) gExpr },NULL ,26, 0}, /*(1) --express--> (2)*/
/*26 */ {BgSy,{(unsigned long) ',' },NULL ,27, 0}, /* + ----','----> (1)*/
/*27 */ {BgGr,{(unsigned long) gExpr },NULL ,28, 0}, /*(1) --express--> (2)*/
/*28 */ {BgSy,{(unsigned long) ',' },NULL ,29, 0}, /* + ----','----> (1)*/
/*29 */ {BgGr,{(unsigned long) gExpr },NULL ,30, 0}, /*(1) --express--> (2)*/
/*30 */ {BgSy,{(unsigned long) ')' },St_30,31, 0}, /*(2) ----')'----> (3)*/
/*31 */ {BgEn,{(unsigned long)0 },NULL , 0, 0} /*(23)--------->(ENDE)*/
};
26.07.2004 Seite 74 von 85

Diplomarbeit: Modulares System Anhang
tBog gCondition[]=
{
/* 0 */ {BgSy,{(unsigned long) zODD }, NULL , 1, 2}, /*(0) ---'ODD'---> (1)*/
/* 1 */ {BgGr,{(unsigned long) gExpr }, Co_01,15, 0}, /*(1) --express-->(15)*/
/* 2 */ {BgGr,{(unsigned long) gExpr }, NULL , 3, 0}, /* + --express--> (3)*/
/* 3 */ {BgSy,{(unsigned long) '=' }, NULL , 4, 5}, /*(3) ----'='----> (4)*/
/* 4 */ {BgGr,{(unsigned long) gExpr }, Co_04,15, 0}, /*(4) --express-->(15)*/
/* 5 */ {BgSy,{(unsigned long) '#' }, NULL , 6, 7}, /* + ----'#'----> (6)*/
/* 6 */ {BgGr,{(unsigned long) gExpr }, Co_06,15, 0}, /*(6) --express-->(15)*/
/* 7 */ {BgSy,{(unsigned long) '' }, NULL ,12,13}, /* + ----'>'---->(12)*/
/*12 */ {BgGr,{(unsigned long) gExpr }, Co_12,15, 0}, /*(12)--express-->(15)*/
/*13 */ {BgSy,{(unsigned long) zge }, NULL ,14, 0}, /* + ----'>='--->(14)*/
/*14 */ {BgGr,{(unsigned long) gExpr }, Co_14,15, 0}, /*(14)--express-->(15)*/
/*15 */ {BgEn,{(unsigned long) 0 }, NULL , 0, 0} /*(10)--------->(ENDE)*/
};
tBog gExpr[]=
{
/* 0 */ {BgSy,{(unsigned long) '+' }, NULL , 3, 1}, /*(0) ----'+'----> (3)*/
/* 1 */ {BgSy,{(unsigned long) '-' }, NULL , 4, 2}, /* + ----'-'----> (4)*/
/* 2 */ {BgNl,{(unsigned long) 0 }, NULL , 3, 0}, /* + ----nil----> (3)*/
/* 3 */ {BgGr,{(unsigned long) gTerm }, NULL , 5, 0}, /*(3) ----nil----> (5)*/
/* 4 */ {BgGr,{(unsigned long) gTerm }, Ex_04, 5, 0}, /*(4) ----nil----> (5)*/
/* 5 */ {BgSy,{(unsigned long) '+' }, NULL , 8, 6}, /*(5) ----'+'----> (8)*/
/* 6 */ {BgSy,{(unsigned long) '-' }, NULL , 9, 7}, /* + ----'-'----> (9)*/
/* 7 */ {BgNl,{(unsigned long) 0 }, NULL ,10, 0}, /* + ----nil---->(10)*/
/* 8 */ {BgGr,{(unsigned long) gTerm }, Ex_08, 5, 0}, /*(8) --- term---> (5)*/
/* 9 */ {BgGr,{(unsigned long) gTerm }, Ex_09, 5, 0}, /*(9) --- term---> (5)*/
/*10 */ {BgEn,{(unsigned long) 0 }, NULL , 0, 0} /*(10)--------->(ENDE)*/
};
tBog gTerm[]=
{
/* 0 */ {BgGr,{(unsigned long) gFact }, NULL , 1, 0}, /*(0) ---factor--> (1)*/
/* 1 */ {BgSy,{(unsigned long) '*' }, NULL , 4, 2}, /*(1) ----'*'----> (4)*/
/* 2 */ {BgSy,{(unsigned long) '/' }, NULL , 5, 3}, /* + ----'/'----> (4)*/
/* 3 */ {BgNl,{(unsigned long) 0 }, NULL , 6, 0}, /* + ----nil----> (6)*/
/* 4 */ {BgGr,{(unsigned long) gFact }, Te_04, 1, 0}, /*(4) ---factor--> (1)*/
/* 5 */ {BgGr,{(unsigned long) gFact }, Te_05, 1, 0}, /*(5) ---factor--> (1)*/
/* 6 */ {BgEn,{(unsigned long) 0 }, NULL , 0, 0} /*(6) --------->(ENDE)*/
};
tBog gFact[]=
{
/* 0 */ {BgMo,{(unsigned long)mcIdent}, Fc_00,11, 1}, /*(0) ---ident---> (6)*/
/* 1 */ {BgMo,{(unsigned long)mcONumb}, Fc_01,11, 2}, /* + ---o-number--> (6)*/
/* 2 */ {BgSy,{(unsigned long) '(' }, NULL , 3, 5}, /* + ----'('----> (1)*/
/* 3 */ {BgGr,{(unsigned long) gExpr }, NULL , 4, 0}, /*(1) --express--> (2)*/
/* 4 */ {BgSy,{(unsigned long) ')' }, NULL ,11, 0}, /*(2) ----')'----> (3)*/
/* 5 */ {BgSy,{(unsigned long) zGET }, NULL , 6, 0}, /* + ----'GET'--->(14)*/
/* 6 */ {BgSy,{(unsigned long) '(' }, NULL , 7, 0}, /* + ----'('----> (1)*/
/* 7 */ {BgGr,{(unsigned long) gExpr }, NULL , 8, 0}, /*(1) --express--> (2)*/
/* 8 */ {BgSy,{(unsigned long) ',' }, NULL , 9, 0}, /* + ----','----> (1)*/
/* 9 */ {BgGr,{(unsigned long) gExpr }, NULL ,10, 0}, /*(1) --express--> (2)*/
/*10 */ {BgSy,{(unsigned long) ')' }, Fc_11,11, 0}, /*(2) ----')'----> (3)*/
/*11 */ {BgEn,{(unsigned long) 0 }, NULL , 0, 0} /*(3) --------->(ENDE)*/
};
Abbildung A.3 - Bogengraphen des PL0-Compilers
26.07.2004 Seite 75 von 85

Diplomarbeit: Modulares System Anhang
typedef enum TCODE
{
/*--- Kellerbefehle ---*/
puValVrLocl,/*00 (int Displ) [Kellern Wert lokale Variable] */
puValVrMain,/*01 (int Displ) [Kellern Wert Main Variable] */
puValVrGlob,/*02 (int Displ,int iProc) */
puAdrVrLocl,/*03 (int Displ) [Kellern Adresse lokale Variable] */
puAdrVrMain,/*04 (int Displ) [Kellern Adresse Main Variable] */
puAdrVrGlob,/*05 (int Displ,int iProc) [Kellern Adresse globale Variable] */
puConst ,/*06 (int Index) [Kellern einer Konstanten] */
storeVal ,/*07 () [Speichern Wert -> Adresse, beides aus Keller]*/
putVal ,/*08 () [Ausgabe eines Wertes aus Keller nach stdout] */
getVal ,/*09 () [Eingabe und Speichern eines Wertes */
/*--- arithmetische Befehle ---*/
vzMinus ,/*0A () [Vorzeichen -] */
odd ,/*0B () [ungerade -> 0/1] */
/*--- binaere Operatoren kellern 2 Operanden aus und das Ergebnis ein ----*/
OpAdd ,/*0C () [Addition] */
OpSub ,/*0D () [Subtraktion ] */
OpMult ,/*0E () [Multiplikation ] */
OpDiv ,/*0F () [Division ] */
cmpEQ ,/*10 () [Vergleich = -> 0/1] */
cmpNE ,/*11 () [Vergleich # -> 0/1] */
cmpLT ,/*12 () [Vergleich < -> 0/1] */
cmpGT ,/*13 () [Vergleich > -> 0/1] */
cmpLE ,/*14 () [Vergleich 0/1] */
cmpGE ,/*15 () [Vergleich >=-> 0/1] */
/*--- Sprungbefehle ---*/
call ,/*16 (int ProzNr) [Prozeduraufruf] */
retProc ,/*17 () [Ruecksprung] */
jmp ,/*18 (int RelAdr) [SPZZ innerhalb der Funktion] */
jnot ,/*19 (int RelAdr) [SPZZ innerhalb der Funkt.,Beding.aus Keller] */
jnut ,/*1A (int RelAdr) [SPZZ innerhalb der Funkt.,Beding.aus Keller] */
entryProc ,/*1B (int CodeLen, int ProcIdx, int VarLen) */
putStrg ,/*1C (char[]) */
EndOfCode ,/*1D */
dup ,/*1E () [dupliziert obersten Stackeintrag] */
pop ,/*1F () [entfernt obersten Stackeintrag] */
retFunc ,/*20 () [Ruecksprung] */
getValPara ,/*21 () [Hole Sensordaten zum Keller] */
putValPara /*22 () [Gebe Sensordaten aus Keller] */
}tCode;
Abbildung A.4 - Code der Virtuellen Maschine
Abbildung A.5 - Aufbau der Klassen der Virtuellen Maschine
26.07.2004 Seite 76 von 85

Diplomarbeit: Modulares System Anhang
Baugruppe Prozessor
U3
Baugruppe RS232-Treiber
J5
1 2
8
7
6
5
TX0 RS
GND CANH
VCC CANL
RX0 RX1
A82C250
1
2
3
4
U1
TST2
TST3
TST4
TST5
C5 1µF
28
27
26
25
24
23
22
21
20
19
18
17
16
15
RB7
RB6
RB5
RB4
RB3/CANRX
RB2/CANTX
RB1
RB0
VDD
VSS
RC7/RX
RC6/TX
RC5
RC4/SDA
MCLR
RA0
RA1
RA2
RA3
RA4
RA5
VSS
OSC1
OSC2
RC0
RC1
RC2/CCP1
RC3/SCL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
R2 220
X4
C6 1µF
RM 2,54mm
X1
1 +12V
2 CANH
3 CANL
4 GND
5 +5V
5x1
R9
120
Lötjumper
5P
C3
100n
1
2
3
4
5
12P
TST1
U5
R1 4,7k
LED1
R7 220
1
2
3
4
5
6
7
8
9
1
2
3
4
5
6
7
8
9
RM 2,54mm
X3
C7 1µF
16
2
15
6
C1+
C1-
C2+
C2-
1
3
4
5
TST6
TST7
TST8
TST9
TST10
TST11
5P
5P
VCC
V+
GND
V-
5P
C4 1µF
14
7
13
8
T1IN
T2IN
R1OUT
R2OUT
11
10
12
9
5P
T1OUT
T2OUT
R1IN
R2IN
1
2
3
4
+5V
GND
RS232-0 RX
X2
1 +5V
2 GND
3 RS232-0 RX
4 RS232-0 TX
4x1
RM 2,54mm
LED2
R8 220
C1 22pF
R5 1k
4x1
DSUB-9
C15
15pF
MAX232
X1
10 MHz
C2 22pF
Abbildung A.6 - Schaltpläne
RS232-0 TX
5P
5P
C17
15pF
B
R6 1k
PIC18F258
R4 1k
R3 1k
5P
SDA
SCL
Typische Sensoren und Aktoren
R14
TST2
X3
TST2
1k
LED2
Taster
Baugruppe Stromversorgung
26.07.2004 Seite 77 von 85
O1
R12 220
TST2
+12V
R15
R13 1k
1k
X6
1
2
3
4
5
5x1
1
2
3
4
5
SI1
X5
SG2
CANH
J1
TST2
U4
LM7805C/TO220
B1
+
-
Piezo
CANL
R11 120
2
1
fuse
5P
GND
+5V
3
1
OUT
IN
Opt_Sens
C11
10µ
C9
100n
C8
100n
C10
100µ
1
2
3
4
4x1
TST6
X7
1
2
3
4
5
5x1
GND
+12V
1
2
3
4
5
2
CANH
CANL
GND
+5V
TST6
T1
A
LSP1
1
2
VBB OUT
IN GND
BTS450
4
3
12P
R10
5P
TST2
Trimmpotential
+12V
R16
1k
CANH
CANL
GND
X8
1
2
3
4
5
5x1
1
2
3
4
5
+5V

Diplomarbeit: Modulares System Anhang
unsigned char Init_VM (tVM_Struct *VM)
{
unsigned char uc;
const rom char *codePtr;
unsigned int ui, ui1, ui2, ui3;
unsigned long uli;
VM->pCodeFile = VM_CODE;
uc=CheckCodeFileVersion(VM->pCodeFile);
if(uc) return(uc);
VM->VM_StackSize = _VM_StackSize;
VM->VM_StackPtr = 0;
VM->VM_Stack = VM_Stack;
VM->Flags = DebugFlag;
}
VM->pProzedure = VM->pCodeFile + 8; // Pointer auf erste Prozedur
codePtr = VM->pProzedure;
VM_ReadLong (VM->pCodeFile + 4,(long*)&uli);
if(uli & 0xFFFF0000L) return(ERROR_READ_PROCHEADER);
VM->ProcCount = (unsigned int)uli;
for(ui=0; ui < VM->ProcCount; ui++) {
if(!ScanProcHeader(codePtr,&ui1,&ui2,&ui3)) codePtr += ui2;
else return(ERROR_READ_PROCHEADER);
}
VM->pConstant = codePtr + ui2; // Start Konstantenarea
VM->pCodeFile = codePtr; // Start Hauptprozedur
VM->ProcCount = 0; // Aktuelle Prozedur
return(OK);
Abbildung A.7 - Initialisierungsteil der Virtuellen Maschine auf dem Controller
26.07.2004 Seite 78 von 85

Diplomarbeit: Modulares System Anhang
CD-Inhalt
Abbildung A.8 - CD-Inhalt
26.07.2004 Seite 79 von 85

Diplomarbeit: Modulares System Quellenverzeichnis
Quellenverzeichnis
[dem] Computerschnittstellen und Bussysteme
Klaus Dembowski; ISBN: 3-7785-2526-3;Hüthig GmbH, Heidelberg, 1997
[etsch] Controller-Area-Network Grundlagen, Protokolle, Bausteine, Anwendungen
Konrad Etschberger; ISBN: 3-446-19431-2; Carl Hanser Verlag, München, Wien, 2000
[law] CAN Controller Area Network Grundlagenund Praxis
Wolfgang Lawrenz; ISBN: 3-7785-2575-1; Hüthig GmbH, Heidelberg, 1997
[jon] Mobile Roboter Von der Idee zur Implementierung
J. L. Jones, A.M. Flynn; ISBN: 3-89319-855-5; Addison-Weslay GmbH, 1996
[bb] Bastelbuch für Modellelektronik
Autorenkollektiv; Deutscher Militärverlag, Berlin 1970
[beck] Vorlesungsskript Compiler/Interpreter
Prof. Dr.-Ing. A. Beck, HTW-Dresden
[mich] Entwicklung einer Softwarelösung für die Simulation autonomer Roboter in einer 3-
dimensionalen Umgebung
Dipl. Inform. O. Michel, Diplomarbeit, 2000
[ccon] http://www.c-control.de
[lego] http://www.mindstorms.com
[fisch] http://www.fischertechnik.de
[d001] http://me.in-berlin.de/~urmel/robot
[rr] http://www.realrobots.de
[kt] http://www.k-team.com
[cb] http://www.cyberbotics.com
[cc] http://www.cc-i.com
[awa] http://www.saar.de/~awa/compiler.htm
[beam] http://www.buildcoolstuff.com/topics/BEAM_Walker/3.shtml
[C535] http://alf.zfn.uni-bremen.de/~g16i/80c535.htm
[spid] http://www.robotstore.com/catalog/display.asp?pid=254
26.07.2004 Seite 80 von 85

Diplomarbeit: Modulares System Abbildungen und Tabellen
Abbildungs- und Tabellenverzeichnis
Abbildung 2.1 - Die elektronische Schildkröte „Elmer“......................................................................... 7
Abbildung 2.2 - Der Laufroboter Spider............................................................................................... 8
Abbildung 2.3 - Der Beamroboter UniBug........................................................................................... 8
Abbildung 2.4 - Ein Mikrocontrollerboard 80C535 ............................................................................... 9
Abbildung 2.5 - Das System C-Control ............................................................................................... 9
Abbildung 2.6 - Der D001-Experimentierroboter ............................................................................... 10
Abbildung 2.7 - Ein LEGO-Roboter................................................................................................... 10
Abbildung 2.8 - Ein Laufroboter mit fischertechnik ............................................................................ 11
Abbildung 2.9 - Der Cybot ................................................................................................................ 11
Abbildung 2.10 - Der Miniaturroboter Khepera.................................................................................. 12
Abbildung 2.11 - Der Autoroboter Koala ........................................................................................... 12
Abbildung 5.1 - Asymmetrische und symmetrische Schnittstelle ....................................................... 29
Abbildung 6.1 - Schematische Darstellung eines Khepera ................................................................ 41
Abbildung 6.2 - Beispielprogramm für eine zentrale Steuerung ......................................................... 42
Abbildung 6.3 - Das erweiterte zentralgesteuerte Programm............................................................. 42
Abbildung 6.4 - Verteiltes Programm: linker Motor ............................................................................ 43
Abbildung 6.5 - Verteiltes Programm: rechter Motor.......................................................................... 43
Abbildung 6.6 - Verteiltes Programm: Scheinwerfer.......................................................................... 43
Abbildung 6.7 - Codedatei ................................................................................................................ 46
Abbildung 6.8 - Interpretierte Codedatei ........................................................................................... 47
Abbildung 6.9 - Beispiele für Funktionen der Virtuellen Maschine ..................................................... 47
Abbildung 6.10 - Grafische Programmierung bei LEGO.................................................................... 48
Abbildung 7.1 - LLWin...................................................................................................................... 50
Abbildung 7.2 - Webot...................................................................................................................... 50
Abbildung 7.3 - Easybot ................................................................................................................... 51
Abbildung 7.4 - Netbot...................................................................................................................... 51
Abbildung 7.5 - Aufbau der VM.DLL ................................................................................................. 52
Abbildung 7.6 - Einbinden der VM.DLL............................................................................................. 53
Abbildung 7.7 - Lightvision3D ........................................................................................................... 54
Abbildung 7.8 - Lightvision3D mit Easybot ........................................................................................ 55
Abbildung 7.9 - Kheperamodell......................................................................................................... 56
Abbildung 7.10 - Cybotmodell........................................................................................................... 56
Abbildung 7.11 - Dialogbeispiele einer offenen Steuerung für Easybot.............................................. 57
Abbildung 7.12 - Steuerprogramm Cybot, linker Motor...................................................................... 58
Abbildung 7.13 - Steuerprogramm Cybot, rechter Motor ................................................................... 58
Abbildung 7.14 - Typbibliotheken NetbotServer und NetbotClient ..................................................... 59
Abbildung 7.15 - NetbotServer.......................................................................................................... 59
Abbildung 7.16 - Aufruf des NetbotServer durch den Client .............................................................. 60
26.07.2004 Seite 81 von 85

Diplomarbeit: Modulares System Abbildungen und Tabellen
Abbildung 7.17 - Beispiel für NetbotClients....................................................................................... 60
Abbildung 7.18 - Warnlampe links für den Cybot .............................................................................. 60
Abbildung 8.1 - Netbot Setup Programm .......................................................................................... 64
Abbildung 8.2 - Aufbau der Kommunikation zwischen Computer und Controller................................ 64
Abbildung 8.3 - Fahrwerk des Cybot und die originale Elektronik ...................................................... 65
Abbildung 8.4 - Aktoren und Sensoren als Einzelkomponenten......................................................... 65
Abbildung 8.5 - Steuerprogramm linker Motor................................................................................... 66
Abbildung 8.6 - Steuerprogramm rechter Motor ................................................................................ 66
Abbildung 8.7 - Weg des Roboters im Simulator............................................................................... 67
Abbildung 8.8 - Cybot mit Netbot-Controllern.................................................................................... 67
Abbildung 8.9 - Netbot in Bewegung................................................................................................. 67
Abbildung 8.10 - Steuerprogramm linke Warnlampe ......................................................................... 68
Abbildung 8.11 - Steuerprogramm rechte Warnlampe....................................................................... 68
Abbildung 8.12 - Netbot mit installierten Warnlampen....................................................................... 68
Abbildung 8.13 - Netbot in Bewegung............................................................................................... 68
Abbildung A.1 - Syntaxgraphen in PL0 ............................................................................................. 72
Abbildung A.2 - Tabellen der lexikalischen Analyse in PL0 ............................................................... 73
Abbildung A.3 - Bogengraphen des PL0-Compilers .......................................................................... 75
Abbildung A.4 - Code der Virtuellen Maschine.................................................................................. 76
Abbildung A.5 - Aufbau der Klassen der Virtuellen Maschine............................................................ 76
Abbildung A.6 - Schaltpläne ............................................................................................................. 77
Abbildung A.7 - Initialisierungsteil der Virtuellen Maschine auf dem Controller .................................. 78
Abbildung A.8 - CD-Inhalt................................................................................................................. 79
Tabelle 4.1 - natürlich vorkommende Sensoren und ihre technische Umsetzung .............................. 17
Tabelle 4.2 - häufig verwendete Sensoren........................................................................................ 18
Tabelle 4.3 - häufig verwendete Aktoren........................................................................................... 19
Tabelle 4.4 - Parametrisierung.......................................................................................................... 21
Tabelle 4.5 - Gruppentypen und -adressen....................................................................................... 24
Tabelle 4.6 - Systemkommandos ..................................................................................................... 25
Tabelle 5.1 - serielle Betriebsarten ................................................................................................... 28
Tabelle 5.2 - Buszugriffsverfahren .................................................................................................... 30
Tabelle 5.3 - Das OSI-Schichtenmodell ............................................................................................ 32
Tabelle 5.4 - Übersicht über Bussysteme ......................................................................................... 36
Tabelle 6.1 - Sprachumfang von PL0................................................................................................ 40
Tabelle 6.2 - Erweiterung von PL0 für den Einsatz im Netzwerk ....................................................... 41
Tabelle 6.3 - Phasen eines Compilers .............................................................................................. 45
Tabelle 8.1 - Kennung der Übertragung zwischen Computer und Controller...................................... 65
26.07.2004 Seite 82 von 85

Diplomarbeit: Modulares System Abkürzungen und Glossar
Abkürzungsverzeichnis
ARM Advanced RISC Machine
BEAM Biology Electronics Astetics Mechanics
CAN Controller Area Network
CISC Complex Instruction Set Computer
CPU Central Processing Unit (dt: zentrale Verarbeitungseinheit)
CRC Cyclic Redundancy Check (Prüfsumme)
DLL Dynamic Link Library (dt: dynamisch ladbare Bibliothek)
COM Communication Port (serielle Schnittstelle am Personalcomputer)
DCOM Distributed Component Object Model (rechnerübergreifende Prozessschnittstelle)
DSP Digital Signal Processor
FFT Fast Fourier Transformation
GIF Graphics Interchange Format
I²C Inter IC-Bus (interner integrierter Schaltungsbus)
IC Integrated Circuit (dt: Integrierter Schaltkreis)
IEC Instrumentierungsbus nach der IEC625 (International Electronic Commission)
ISO International Standard Organisation
MS Microsoft
OS Operating System (Betriebssystem)
OSI Open System Interconnection
PC Personal Computer
PDA Personal Digital Assistant (mobile Mini-Computer)
POWER Performance Optimisation With Enhanced RISC
RCX Robotic Command Explorer
RISC Reduced Instruction Set Computer
SCSI Small Computer System Interface
TCP Transmission Control Protocol (verbindungsorientiertes Transportprotokoll)
USB Universal Serial Bus
VME Versa Module Europe Bus
VXI VMEbus eXtensions for Instrumentation
VC++ Visual C++
26.07.2004 Seite 83 von 85

Diplomarbeit: Modulares System Abkürzungen und Glossar
Glossar
Acknowledgebit Empfangsbestätigung
Bit-stuffing „Bitstopfen“: Jeder Bitfolge von fünf 1-Bits in den Anwendungsdaten wird ein
zusätzliches 0-Bit angehängt. Dadurch wird verhindert, das Flags als Datenzeichen
aufgefasst werden.
Bridge Verbindungselement zwischen verschiedenen Netzwerken
Callback Rückrufverfahren. D.h. ein Server kann damit den Client von sich aus erreichen,
zurückrufen.
Frame Byte-Rahmen um die Nutzdaten (z.B. Steuerbits)
Hub engl.: Mittelpunkt. Knotenpunkt von Leitungen in einem sternförmig angelegten
Netzwerk
Identifier Bezeichner / Identifizierungsmerkmal
Master zentrale Instanz auf einem Bus, der die Entscheidungsgewalt hat
Multi-Master Falls der eigentliche Master ausfällt, kann jeder Teilnehmer dessen Funktion
übernehmen
NRZ „non return to zero“ – Kodierungsverfahren in der seriellen Signalübertragung.
Jedem Bit wird ein konkretes Signal zugeordnet (z.B. 0=0-Spannung, 1=positive
Spannung).
OSI-Modell internationaler Standard für Kommunikationssysteme der ISO
Slave Teilnehmer auf einem Bus, der vom Master das „Rederecht“ zugewiesen bekommt
26.07.2004 Seite 84 von 85

Diplomarbeit: Modulares System
Erklärung zur Selbstständigkeit
Ich versichere, dass ich die Diplomarbeit selbstständig verfasst und keine anderen als die
angegebenen Quellen und Hilfsmittel benutzt habe.
Daniel Popp
Dresden, den 26.07.2004
26.07.2004 Seite 85 von 85