Maturaarbeit Der Bau und die Programmierung eines

Maturaarbeit
xbot
Der Bau und die Programmierung eines omnidirektionalen
Roboters
von Gerhard Röthlin und Christoph Rüegg, 6Rb, KSLuzern
16. Dezember 2001
Inhaltsverzeichnis
Vorwort
iv
I
1
Organisation
1 Einleitung
2
1.1
Die Gruppe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
Die Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3
Die Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2 Budget
II
4
2.1
Finanzierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2
Planung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
Strategien
5
3 Fortbewegung
6
3.1
Beine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
3.2
Räder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.2.1
Konventionelle Systeme
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.2.2
OmniWheels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
4 Karten
4.1
4.2
8
Speicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
4.1.1
Pixelmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
4.1.2
Vektormap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
4.1.3
Neural Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
Punktreduktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
i
5 Wegberechnung
5.1
5.2
III
11
Methode der Grenzverfolgung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
5.1.1
Backtracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
5.1.2
Probleme und Lösungsansätze . . . . . . . . . . . . . . . . . . . . . . . . .
12
Methode der Ausbreitungsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
5.2.1
14
Probleme und Lösungsansätze . . . . . . . . . . . . . . . . . . . . . . . . .
Hardware
15
6 Gehäuse
16
6.1
Material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
6.2
Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
6.2.1
Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
6.2.2
Mechanik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
7 Controller
18
7.1
Auswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
7.2
Ansteuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
7.3
Ausgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
7.4
Eingabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
8 Stromversorgung
20
8.1
Verteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
8.2
Auswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
8.3
Funktionsweise der Akkumulatoren . . . . . . . . . . . . . . . . . . . . . . . . . .
21
9 Servomotoren
22
9.1
Auswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
9.2
Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
9.2.1
Mechanik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
9.2.2
Elektronik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
9.3
Modifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
9.4
Kalibrierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
9.5
Zusammensetzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
ii
10 Sensoren
25
10.1 Auswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
10.2 Funktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
11 Schaltung
26
11.1 Strom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
11.2 Signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
IV
Software
28
12 Software Architektur
29
12.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
12.2 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
12.3 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
12.3.1 Wahl der Umgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
12.4 Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
12.4.1 Modularität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
12.4.2 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
13 Backend
32
13.1 Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
13.2 Datenfluss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
13.2.1 Phasen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
13.2.2 Koordination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
14 Frontend
34
14.1 Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
14.2 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
14.2.1 Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
14.2.2 Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
14.2.3 Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
14.2.4 Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
15 Arbeiten mit der Software
36
15.1 Vorgehensweise bei einfachen Problemstellungen . . . . . . . . . . . . . . . . . . .
iii
36
15.2 Einbindung von Erweiterungen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
15.3 Erweitern mit Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
V
Ausblick
38
16 Weiterführung
39
16.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
16.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
16.3 Neue Wege . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
16.4 Hilfe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
VI
Anhang
I
A Tabellen
II
B Abbildungen
IV
C Glossar
VII
Literaturverzeichnis
IX
Index
X
iv
Vorwort
Diese Arbeit befasst sich mit der Planung, dem Bau und der Programmierung eines Roboters.
Insbesondere der Bau und die Programmierung waren sehr zeitintensiv, das Ergebnis rechtfertigt
aber die geleistete Arbeit. Der Aufwand war gross und einige Hindernisse standen uns im Weg.
Die Probleme forderten uns heraus, neue, kreative Lösungen auszudenken.
Ende 2000 erhielten alle damaligen Fünftklässler der Kantonsschule Alpenquai den Auftrag
zum Schreiben einer Maturaarbeit. Uns gingen viele Ideen durch den Kopf, es war nur klar, das
die Arbeit etwas mit Computern zu tun haben sollte.
Eine Idee liess uns nicht mehr los: Einen Roboter zu bauen. Wir suchten im Internet nach geeigneten Vorlagen oder Anleitungen und fanden schliesslich auch einen einfachen und günstigen
Roboter (Bot) zum selbst bauen[5], womit der Grundstein zu dieser Arbeit gelegt worden war.
Bei einigen Elementen unseres Projektes konnten wir uns auf Literatur und Informationen
aus dem Internet stützen, bei anderen mussten wir aber selbst überlegen, bis wir eine Lösung
fanden, die unsere Ziele enrfüllte. Wo wir uns bei der Hardware noch teilweise auf den Palmbot
stützen konnten, mussten wir bei den Strategien und der Software, auf die der Roboter aufbaut,
komplettes Neuland beschreiten.
Danken möchten wir Herrn Christoph Arnold, unserem Mentor, der uns während des Projektes
unterstützt und immer mit allen Mitteln geholfen hat, Herrn Fuchsberger und allen Weiteren, die
uns mit ihren Ratschlägen zur Seite standen.
Kommentare oder Vorschläge können über E-Mail oder auch direkt an uns gesendet werden. Wir stehen unter unserer Kontaktadresse [email protected] oder auf unserer Webseite unter
http://xbot.sourceforge.net/ gerne zu Verfügung.
v
Teil I
Organisation
1
Kapitel 1
Einleitung
1.1
Die Gruppe
Unsere Gruppe bestand ursprünglich aus drei Personen, Jonas Renggli, Gerhard Röthlin und
Christoph Rüegg. Zusammen wollten wir versuchen, einen autonomen Roboter (Bot) zu bauen. Da
Jonas Renggli leider die fünfte Klasse repetieren musste, haben die verbliebenen zwei, Christoph
Rüegg und Gerhard Rötlhin, die Arbeit zu zweit fortgeführt.
1.2
Die Arbeit
Die Maturaarbeit setzt sich zusammen aus dieser Dokumentation, dem Roboter, einem Manual
und gut 6000 Zeilen Programmcode.
1.3
Die Dokumentation
Dieses Dokument ist vor allem eine Projektbeschreibung, die Gliederung ist thematisch. Der
Teil “Organisation” behandelt die anfängliche Planung mit der Projekteinführung und dem Aufstellen des Budgets. Im Strategieteil werden einige Vorgehensmöglichkeiten aufgeführt, die uns
vor allem in der Anfangsphase der Arbeit offen waren und die die Realisierung des Bots massgeblich beeinflusst haben. Ausserdem werden dort auch Wege gezeigt, die bei einer Erweiterung der
Programmierung beschritten werden können. Im folgenden Teil wird die Hardware, also der technische Aufbau des Bots, detailliert beschrieben. Im Softwareteil wird der programmatische Aufbau
der Steuersoftware behandelt, die sozusagen die “Intelligenz” des Bots darstellt und die von uns
entwickelt wurde. Weitere Möglichkeiten, den Bot zu verändern und anzupassen, werden im Teil
2
“Weiterführung” gegeben. Am Schluss dieses Dokumentes findet sich das Literaturverzeichnis, die
zusätzlichen Tabellen und Abbildungen und der Index mit wichtigen Stichworten.
3
Kapitel 2
Budget
2.1
Finanzierung
Dank der Stopinc AG, die uns mit Laptops ausrüstete, und der Informatikabteilung der KSL,
die unsere weitere Projektarbeit mit maximal 1000 Fr mitfinanziert, konnten wir unser Vorhaben
erst verwirklichen.
2.2
Planung
Wir haben uns schon früh Gedanken über die Ausstattung des Bots gemacht. Anfängliche Ideen
wurden so vereinfacht oder durch kostengünstigere Alternativen ersetzt. Wärend des Baus des
Bots haben wir versucht, möglichst viele Bauteile in lokalen Geschäften oder durch den inländische Versandhandel zu erwerben. Da die wichtigsten Bauteile, der Controller, die Sensoren und
die OmniWheels, hier nicht erhältlich sind, mussten wir in den USA bestellen und wählten die
sicherste Versandmethode. Das Ergebnis ist als Budget in Tabelle A.1 zu sehen.
4
Teil II
Strategien
5
Kapitel 3
Fortbewegung
Eine zentrale Frage in der Planungsphase eines mobilen Roboters ist die nach der Fortbewegungsmethode. Die Auswahl an verschiedenen Möglichkeiten ist riesig, jede hat ihre eigenen
Stärken und Schwächen. Die geeignete Wahl zu treffen ist schwierig, da viele Faktoren bei dieser
Entscheidung eine Rolle spielen, welche im Voraus nur schwer einzuschätzen sind.
Bodengebundene Fortbewegung lässt sich grundsätzlich in rad- und beinbasierte Fortbewegung
unterscheiden, wobei Raupenfahrzeuge zu den radbasierten Robotern zu zählen sind.
3.1
Beine
Beine bieten eine grosse Flexibilität und Geländegängigkeit, die von Bots mit Rädern nie erreicht werden kann, ihre grössten Nachteile sind jedoch, das ihre Geschwindigkeit und ihre Reaktionszeit weit hinter den Bots mit Rädern hinterherhinken. Auch die Steuerung ist sehr komplex,
denn Beine besitzen oft mehrere Gelenke, die einzeln angesteuert werden müssen und um das
Gleichgewicht zu halten, werden mehr als drei Beine benötigt, wenn nicht auf eine komplexe
Gleichgewichtsautomatik gesetzt wird.
Der Grossteil der wenigen Beinroboter besitzt drei oder mehr Beinpaare, die ähnlich denen von
Insekten relativ autonom voneinander operieren, was eine einfachere Steuerung erlaubt. Andere
experimentelle Roboter besitzen ein oder zwei Beine, auf denen sie hüpfen, um ihr Gleichgewicht
zu halten. Der bekannteste Zweibeiner ist wohl der “humane” Roboter von Hyundai, der über
eine sehr ausgereifte Mechanik verfügt.
6
3.2
3.2.1
Räder
Konventionelle Systeme
Weitaus häufiger sind rollende Roboter anzutreffen, die wesentlich einfacher zu bauen und zu
steuern sind und auch eine höhere Geschwindigkeit erreichen können. Sie arbeiten meistens nach
dem Prinzip eines Autos, verfügen also über eine festen Achse und einer Lenkachse, von denen eine
angetrieben ist, oder nach dem eines Raupenfahrzeuges, wo durch das einzelne, entgegengesetzte
Drehen zweier Räder die Richtung geändert wird.
Der Vorteil für das Raupensystem ist die Fähigkeit, auf dem Platz zu wenden, was vor allem in
engen Umgebungen von Nutzen sein kann. Nachteilig ist, das jedes Rad einen eigenen Antrieb
benötigt und auch einzeln angesteuert werden muss. Ein Servomotor für die Lenkung entfällt
aber. Oft wird auch nur ein Antriebsrad pro Seite verwendet, ein drittes, frei bewegliches, sorgt
für die Stabilisierung.
Roboter nach dem Autoprinzip steuern mit einer Lenkung, die je nach Anstellwinkel der Lenkachse
die Antriebskraft in die gewünschte Richtung lenkt. So wird nur ein Motor für die Bewegung vorund rückwärts und ein Servo für die Lenkung benötigt. Da der Weg, den das äussere Rad in einer
Kurve zurücklegen muss, grösser als der des Innenrades ist, wird ein Differential benutzt (aus
[1]).
3.2.2
OmniWheels
Relativ neu ist das OmniWheel-Prinzip, welches in einigen verschiedenen Implementationen zu
finden ist. OmniWheels sind spezielle Räder, welche sich in einer Richtung wie normale Räder
verhalten, in einer andere aufgrund ihrer Rollen jedoch wiederstandsarm gleiten (Abbildung B.4).
Dies erlaubt in der Anwendung, dass Räder auch, ohne sich gegenseitig zu behindern, nichtparallel
benutzt werden können; ein Differential wird nicht benötigt.
Das am weitesten verbreitete System setzt Räder ein, bei denen die Radachse um 90◦ zur Achse
der Rollen verdreht ist. Die Räder werden im Winkel von 120◦ zueinander angeordnet, wodurch
ein solcher Roboter in jede beliebige Richtung ohne die Notwendigkeit, sich zu drehen, fahren
kann. Die einzelnen Kräfte, die die Räder auf den Untergrund ausüben, können für die Gesamtberechnung einfach vektoriell addiert werden.
7
Kapitel 4
Karten
Um sich in einer Umgebung zurechtzufinden oder zu einem bestimmten Ziel zu kommen,
benötigt ein Roboter eine Karte, welche ihm Aufschluss über seine Position und die möglichen
Wege zum Ziel geben kann. Einige Ansätze kommen auch ohne eine Karte aus, was eine wesentlich höhere Flexibilität zur Folge hat, sich aber auch negativ in der Orientierungsfähigkeit
niederschlägt.
4.1
Speicherung
Um eine Karte zu speichern, stehen verschiedene Wege offen, die von einer simplen Pixelmap,
vergleichbar mit einem GIF-Bild, über eine vektorbasierte Karte, die die Umgebung mathematisch
beschreibt, bis zur Speicherung in neuronalen Mustern reicht. Jeder Weg hat Vor- und Nachteile,
die aber auch stark von der Implementation und den Zielen des Bots abhängen.
4.1.1
Pixelmap
Die Speicherung einer Karte in Form eines Pixelmusters ist die einfachste Lösung. Der Speicherbedarf ist relativ gering, je nach Auflösung der Karte kann er aber schnell wachsen. Jedem Punkt
der Karte, welche in konstanten Abständen gerastert ist, werden Werte oder Farbe zugewiesen,
welche die Art des Materials, die Messsicherheit oder sonst etwas repräsentieren können. Die
Messicherheit kann nützlich sein, wenn sich die Position von Objekten geändert hat, und der Bot
die neuen Messwerte als variabel einträgt. Durch mehrmaliges Messen kann so eine Karte mit
beweglichen und festen Objekten erstellt werden.
Eine Pixelkarte ist auch einfach zu verwalten, da die Anzahl der Punkte, die gemessen werden,
relativ überschaubar ist.
8
4.1.2
Vektormap
Bei einer Karte auf Vektorbasis werden die Punkte nicht in einer Matrix gespeichert und sind
so unabhängig von einem Raster. Die Punkte werden dann verbunden und ergeben so eine angenäherte Polygonenversion der Umgebung. Allen Punkten und Verbindungen können auch hier
noch Parameter zugeordnet werden.
Die Speichermengenbegrenzung ist nicht so einfach wie bei der Pixelmethode, da Punkte nahezu
beliebig nahe beieinander sein können und so der Speicherbedarf bei vielen Messwerten stark
ansteigen kann. Durch eine effiziente Komprimierung und das Löschen überflüssiger Punkte kann
dieser Nachteil aber mehr als ausgeglichen werden. Vor allem in grossen, geradlinigen Umgebungen kann diese Methode ihre Stärken voll ausspielen.
Sehr nützlich ist auch die Möglichkeit mit Hilfe der Mathematik schnell und sicher Wege zu finden und den Gesichtsbereich festzulegen. Bei einer vergleichbaren Pixelkarte ist das nur schwerer
möglich.
4.1.3
Neural Map
Karten können auch in neuronalen Verbindungen gespeichert werden, welche einem Gehirn
ähneln. Diese Art der nichtgeometrischen Orientierung unterscheidet sich stark von anderen, da
sie nicht scharf, sondern in feinen Abstufungen arbeitet.
4.2
Punktreduktion
Vor allem bei der Verwendung einer Vektorkarte ist die Reduktion von überflüssigen Punkten
und das Verschmelzen von doppelten Messwerten wichtig, um eine verwendbare Karte zu erhalten.
Dafür bieten sich zwei Methoden an.
Wärend der Kartenerstellung erhält der Algorithmus viele Punkte, die in geringem Abstand
zueinander stehen. Der erste Ansatz zur Punktreduktion setzt genau dort an, indem, ähnlich
der Pixelmap, ein Raster über die Punkte gelegt wird, so dass sie nur in bestimmten Minimalabständen zueinander stehen können. Das lässt sich unter anderem auch dadurch erreichen, das
die Koordinaten der Punkte in Form eines Vielfachen oder eines Teilers von Ganzzahlenwerten,
so genannten integer, gespeichert werden. Durch die Rundung der Positionswerte entsteht automatisch das gewünschte Raster. Bei einer Pixelkarte geschieht das automatisch, da alle Punkte
immer eine feste Position innehaben.
9
Der zweite Ansatz ist aufwändiger. Die Karte einer geraden Wand, die in unseren Häusern oft
anzutreffen ist, besteht ohne weitere Bearbeitung aus vielen hunderten von Messwerten, die alle
in etwa auf der selben Linie liegen. Dies kann man ausnützen, indem man von Punktetrippeln
den von ihnen eingeschlossenen Winkel bestimmt, welcher bei geraden Wänden idealisiert 0◦ ist.
Wenn der Zwischenwinkel einen Normwert unterschreitet, ist der mittlere Punkt nicht wichtig und
kann entfernt werden, während die zwei äusseren Punkte direkt verbunden werden. Diese Art der
Punkteeinsparung ist besonders in sehr geradliniger Architektur sehr effizient, was Vektorkarten
den Pixelkarten in den Bereichen Speicherbedarf und Berechnungskomplexität überlegen macht.
10
Kapitel 5
Wegberechnung
Eine der komplexeren Aufgaben in der Robotik ist die koordinierte Bewegung zwischen zwei
Punkten. Auch in Fällen, bei denen ein direktes Ansteuern des Zielpunktes durch eine Wand
oder gar eine irrgartenähnliche Raumstruktur verunmöglicht wird, soll der Roboter aus dem
vorliegenden Kartenmaterial einen möglichst idealen Weg berechnen können. Wir werden im
Folgenden auf zwei mögliche Ansätze für die Wegberechnung mit Pixelkarten eingehen.
5.1
Methode der Grenzverfolgung
A
P4
P1
P5
P2
P3
Abbildung 5.1: Pfadfindung durch Randverfolgung
11
B
Die Karte (Abbildung 5.1) zeigt eine von vielen Situationen, bei denen ein direktes Ansteuern
des Zielpunktes durch eine Wand verhindert wird. Die Grundidee zur Suche eines möglichen Weges
basiert auf dem optimistischen Trial and Error Prinzip: Als erstes wird die Direktverbindung A-B
überprüft. Schneidet die Verbindung kein als unpassierbar markiertes Gebiet, so beschreibt diese
Verbindung den idealen Weg. Bei vorliegender Karte wird jedoch ab Punkt P1 ein unpassierbarer
Bereich geschnitten. In diesem Fall soll ein kurzes Stück weit in eine beliebige Richtung die Grenze
verfolgt werden. Vom dadurch errechneten neuen Punkt P2 aus soll nun wieder die Strecke P2-B
geprüft werden. Sofern ideale Richtungsentscheide beim Verfolgen der Grenzen gefällt werden
führt dieses Verfahren wie in der Karte gezeigt nach einigen Zyklen zum Ziel.
5.1.1
Backtracking
Programmatisch kann nicht gewährleistet werden, dass beim Auftreffen auf ein Hindernis jeweils
die ideale Richtung gewählt wird. Abhilfe schafft das aus der Operation Research bekannte und
insbesondere bei regulären Ausdrücken[9] verwendete Prinzip des Backtrackings: Das Verfahren
wird wie oben beschrieben initialisiert. Bei jedem Punkt, an dem eine Richtung gewählt werden
muss, wird eine Möglichkeit überprüft und die andere für spätere Verwendung zwischengespeichert. Führen die gewählten Richtungen nicht zum Ziel, wird jeweils zur vorherigen Entscheidung
zurückgesprungen und die zwischengespeicherte Option gewählt. Dieser Vorgang wird für alle
vorhergehenden Ebenen wiederholt, bis ein Weg gefunden wird.
5.1.2
Probleme und Lösungsansätze
Jede Methode hat Vor- und auch Nachteile. Bei der Methode der Grenzverfolgung mittels
Backtracking sind vor allem folgende Nachteile von Bedeutung:
Performance
Bei Performaceanalysen werden üblicherweise drei Fälle näher untersucht: Der Idealfall, der
Normalfall, sowie der schlechteste Fall (Worst Case). Im Idealfall ist entweder bereits der erste
Verbindungstest erfolgreich, oder es werden alle Entscheidungen ideal gewählt. Im Normalfall
werden 50% der Entscheidung ideal gewählt. Durch geeignete Optimierungen z.B. mit Berücksichtigung des Winkels kann dieser Wert aber schätzungsweise auf über 80% gesteigert werden.
Im Worst Case werden entweder alle Entscheidungen erst falsch getroffen, oder es wird gar kein
Weg gefunden. In beiden Fällen werden alle Entscheidungsmöglichkeiten durchgespielt, was sich
12
sehr negativ auf die Laufzeitgeschwindigkeit auswirkt. Allenfalls kann der zweite Fall durch einen
einfachen Wegexistenztest z.B. durch Einfärbungswerkzeuge vermieden werden.
Endlosschleifen
Ein weiteres Problem ergibt sich, falls Säulen oder andere Objekte mit kleinem Durchmesser
die Verbindungsstrecke schneiden. Wenn die Schrittweite ungefär dem Radius mal 2*π entspricht,
wird das Objekt im schlimmsten Fall endlos umkreist werden. Abhilfe schafft eine vom Winkel
abhängige Schrittweite; wird der Winkel grösser, also der Webgogenradius kleiner, so wird auch
die Schrittweite verkleinert
Benützbarkeit des Weges
Mit dem Grenzverfolgungsverfahren wird zwar ein Weg berechnet, dieser ist jedoch aufgrund
potentieller Engpässe nicht direkt für den Bot verwendbar. Ausserdem arbeitet der Bot mit Schritten, er kann also nicht beliebig feine Bewegungen ausführen. Es muss also aus den berechneten
Daten erst ein brauchbarer vektorisierter Weg extrahiert werden, bei dem gewährleistet wird, dass
der Bot an keiner Wand anstösst.
5.2
Methode der Ausbreitungsanalyse
A
B
Abbildung 5.2: Pfadfindung durch Ausbreitungsanalyse
13
Ein grundsätzlich anderer Ansatz verfolgt die Methode der Ausbreitungsanalyse. Inspiriert vom
Bild einer Flüssigkeit, die in alle Richtungen strömt, werden ausgehend vom Startpunkt ringförmig
jeweils immer allen benachbarten Punkten im freien Raum eine laufende Nummer zugewiesen (bei
einer Pixlemap mit Farben bequem erreichbar). Wird der Zielpunkt erreicht, so wird jeweils immer
in dessen Bereich den Punk mit kleinster Nummer im sichtbaren Bereich gewählt. So entsteht ein
in vielen, auch beliebig komplexen Situationen idealer und bereits vektorisierter Weg.
5.2.1
Probleme und Lösungsansätze
Benützbarkeit des Weges
Anders als bei der Methode der Grenzverfolgung liegen die berechneten Wege mit dieser Methode bereits in einer viel brauchbarerer Form vor. Trotzdem sind einige Transformationen nötig,
um gewährleisten zu können, dass der Bot an keiner Wand anstösst.
Performance
Das “Fliessen” und Durchnummerieren der Pixel kann bei grossen Karten sehr aufwändig sein,
ebenso das Suchen des jeweils kleinsten sichtbaren Punktes. Generell bedeutet das eine kleine
Differenz zwischen Idealfall und Worst Case. Das führt dazu, dass diese Methode bei sehr komplexen Maps mit nur wenig freiem Raum im Vorteil liegt, während bei einfacheren Karten mit
viel Freiraum die Methode der Grenzverfolgung wesentlich besser abschneiden dürfte.
14
Teil III
Hardware
15
Kapitel 6
Gehäuse
Das Gehäuse des Bots wiederspiegelt auf verschiedenen Arten, welche Überlegungen hinter der
Fortbewegungsmethode stecken. In der Form kommt das Grundprinzip eines omnidirektionalen
Roboters unter anderem auch dadurch zum Ausdruck, dass keine Vorderseite erkennbar ist.
6.1
Material
Als Gehäusematerial wird für den Bot Aluminium eingesetzt, das sehr stabil und ausreichend
leicht ist. Ursprünglich war Plexiglas geplant, das aufgrund der Transparenz und der geringeren
Flexibilität einige bauliche Vorteile aufgewiesen hätte. Das Argument, das zur Entscheidung für
Aluminium geführt hat, war der etwas geringere Preis und die gute Verfügbarkeit. Das verwendete
Lochblech ist sehr gut für Prototypen verwendbar, da ohne Bohraufwand Schraubverbindungen
gebildet werden können. Die Gesamtstabilität des Gehäuses nimmt durch die verstärkenden Aluwinkeln zu.
6.2
6.2.1
Aufbau
Platform
Der Roboter ist hexagonal rotationssymmetrisch aufgebaut. Er besteht aus zwei sechseckigen
Platten mit einem Durchmesser von 33.5cm, die mit Winkeln an den Kanten verstärkt sind. Die
beiden Ebenen sind über jeweils zwei Winkel an jeder Ecke miteinander im Abstand von 9cm
verbunden. Der Raum zwischen den Platten bietet ausreichend Platz für die Elektronik und die
Verkabelung. Auf der oberen Platte findet auch ein kleines Notebook platz, das alternativ zu
einem externen Computer verwendet werden kann.
16
Die sechseckige Symmetrie wird auch in der Anordnung der Sensoren (Abbildung B.5) und der
Motoren deutlich. Zwischen den Sensoren und den Motoren liegt jeweils ein Winkel von 120◦ . Da
sich der Bot in jede beliebige Richtung bewegen kann, erreichen wir durch diese Sensoranordnung
die maximale Effektivität und Sensorausnutzung.
6.2.2
Mechanik
Die OmniWheels sind jeweils an einer eigenen tragenden Achse befestigt, die zur Reduktion von
Reibungsverlusten mit Kugellagern ausgestattet sind. Die empfindlichen Servomotoren müssen also keine tragende Funktion einnehmen, sondern nur das Drehmoment liefern. Ihre Verbindung zu
den Rädern wird durch einen Flansch hergestellt (Abbildung B.4). Die ursprüngliche Konstruktion, in der die Motoren das gesamte Gewicht des Bots tragen mussten, war aufgrund der starken
Kräfte auf das Getriebe und der grossen Reibung problematisch.
17
Kapitel 7
Controller
Der Controller ist das eigentliche Herzstück der Bot-Hardware. Er steuert die Motoren und
liest die Spannungsinformationen der Sensoren (Kapitel 10) ein. Die Befehle dazu erhält er über
Kabel von einem Steuercomputer, er übersetzt sie aber in von den Servomotoren verarbeitbare
Signale. Die Sensordaten werden in digitaler Form an den Computer weitergeleitet.
7.1
Auswahl
Für einen Roboter mit einem Computer als Steuer- und Regelinstanz wird auch etwas benötigt,
das zwischen ihm und der ausführenden Hardware steht. Dieser Controller muss vielfältige autonome Aufgaben erfüllen, sollte erschwinglich und auch ausreichend auf Kompatibilität getestet
sein. Ausserdem muss er die Aufgaben eines Mittlers erfüllen können. Bei der Controllerauswahl
ist das die grösste Schwierigkeit.
Eine Suche im Internet förderte nur wenige Ergebnisse zu Tage, wie zum Beispiel die Controllerkarte SV-203 von Pontec, die auch bei unserem Hardwarevorbild, dem PalmBot, eingesetzt wird.
Er ist sicherlich den Anforderungen entsprechend gebaut und bietet alle benötigten Funktionen.
Sein Nachteil ist aber, dass er nur aus den USA bezogen werden kann und nur für geringe Ströme
ausgelegt ist.
Ausserdem gibt es noch einige autonome Controller, die, einmal programmiert, ohne äussere Einwirkungen die Steuerung übernehmen können. Da wir aber eine aufwändige Software vorgesehen
haben, die einen Computer zwingend voraussetzt, scheiden diese “intelligenten” Controller aus.
Zum SV-203 gibt es aus Kostengründen keine Alternativen. Er ist sehr flexibel, und kann mit
jedem Gerät eingesetzt werden, das die schon etwas in die Jahre gekommene Schnittstellentechnologie RS-232 unterstützt (Abbildung B.2).
18
7.2
Ansteuerung
Gesteuert wird der SV-203 über den Serialport eines Computers (RS-232), über den Kommandos in Textform übermittelt werden. So kann beispielsweise mit dem Befehl SV1M128 das Board
angewiesen werden, den ersten Servo zur Position 128 zu bewegen. Mit den modifizierten Servomotoren (Kapitel 9.3) hat das zur Folge, dass die Servos stoppen. Der Controller verfügt über
einen umfangreichen Befehlssatz (Tabelle A.2).
7.3
Ausgabe
Der SV-203 verfügt über acht Ausgänge für Servomotoren, welche auch als digitaler Schalter
verwendet werden können. Servomotoren werden mit der so genannten Pulsweitenmodulation
angesteuert. Dieses Verfahren wendet neben den beiden Stromleitern + (U) und - (Grund)
eine weitere Signalleitung an. Darüber wird in regelmässigen Abständen von 14ms bis 20ms ein
Strompuls mit einer Länge zwischen 0.6ms und 2.4ms gesendet. Die Dauer des Pulses steuert
dabei die Position eines Servomotors. Eine Pulsweite von ungefär 1.52ms repräsentiert die neutrale
Position. Die Pulsweite kann in 255 Schritten eingestellt werden (Siehe auch [1] S.40 und [2] S.2).
7.4
Eingabe
Für die Eingabe stehen fünf Sensorpins zu Verfügung, die eine anliegende Spannung von maximal 5V messen können. Sie können für die Emulation eines Serialports oder auch zum Messen
von Wiederständen verwendet werden, der über die serielle Schnittstelle abgefragt werden kann.
Die Sensoren werden über diesen Weg angesteuert.
19
Kapitel 8
Stromversorgung
Zur Versorgung des Bots mit Energie setzen wir zwei NiMH-Akkus mit einer ungefähren Spannung von ca. 6V ein (Abbildung B.3). Jeder Akku besteht aus fünf Teilzellen, die in Serie geschaltet
sind. Sie können mit dem Ladegerät mit Thermoüberwachung schnell aufgeladen werden.
8.1
Verteilung
Ein Akkupack übernimmt in unserem Bot die Versorgung des Controllers und der Sensoren, der
andere liefert den Motoren ihre Energie. Wir haben diese beiden Kreisläufe soweit wie möglich
getrennt, damit nicht allzu grosse Ströme durch den Controller fliessen, welche ihn möglicherweise
zerstören könnten (Kapitel 11).
8.2
Auswahl
Auf dem Markt existieren grundsätzlich vier Akkutypen, die sich eignen, um den Bot mit Strom
zu versorgen. Bleiakkus schieden schon zu Beginn aus, da ihre Masse für unseren Roboter zu gross
ist. Lithiumionenakkus sind noch zu teuer, sie hätten aber eine sehr hohe Ladungsdichte und eine
grosse Spannung. In die engere Wahl kommen NiCd- und NiMH-Akkus.
Für NiMH sprechen einige Vorteile. Die Ladungsdichte ist um einiges höher als bei NiCd-Zellen
und die Verwendung des Schwermetalls Cadmium ist umweltschädigend. Nachteile sind der relativ
grosse Ladungsverlust und der etwas höhere Preis. Wir entschieden uns aufgrund der grösseren
Ladungsdichte und auch wegen der besseren Umweltverträglichkeit für NiMH (siehe auch [4])
20
8.3
Funktionsweise der Akkumulatoren
NiMH-Akkus sind ihren Vorgängern, den NiCd-Akkus im Aufbau sehr ähnlich. Als + Pol
setzen beide N iO(OH) + H2 O ein. Der - Pol unterscheidet sich aber stark. Das Cadmium wird
durch H2 ersetzt. Der Wasserstoff ist in einer Metalllegierung eingelagert, so dass nahezu keine
Druckabdichtung notwendig ist. Die komplette chemische Reaktion findet an den jeweiligen Polen
wie in Tabelle 8.1 beschrieben wird stat.
Oxidation(- Pol)
Reduktion(+ Pol)
Gedamtreaktion
H2 + 2OH − ↔ 2H2 O + 2e−
2N i3+ O(OH) + 2H2 O ↔ 2N i2+ (OH)2 + 2OH −
H2 + 2N i3+ O(OH) + 2H2 O + 2OH − ↔ 2H2 O + 2{N i(OH)2 }
Tabelle 8.1: Die Reaktion in einer NiMH-Zelle(Aus [4])
Die frei werdenden Elektronen wandern vom - zum + Pol. Zwischen den beiden Polen herrscht
eine Spannung von ca. 1.3 V. Die Reaktionen sind umkehrbar, das heisst, sie können in der
Gegenrichtung ablaufen. Dies ist beim Aufladen der Fall (aus [4]). Wie man erkennen kann, wird
dabei auch Wasserstoff frei, was bei einer hohen Ladegeschwindigkeit dazu führen kann, das die
Legierung das Gas nicht mehr einlagern kann und das Akkugehäuse platzt. Aus diesem Grund
darf die Thermoüberwachung während des Ladens nicht vergessen werden.
21
Kapitel 9
Servomotoren
Als Antrieb setzen wir drei Servomotoren ein, die die gesamte mechanische Arbeit übernehmen.
Dabei setzen wir die übliche Pulsweitensteuerung ein, die sehr bequem ist und es erlaubt, die
Motoren ohne Voltregulator zu steuern. Der Nachteil an Servomotoren ist aber, dass sie sich
üblicherweise um höchstens 360◦ drehen können. Um sie vernünftig einsetzen zu können, muss
man die Servos leichten baulichen Veränderungen unterziehen. Eine gute Anleitung dazu ist in
“Applied Robotics”[1] zu finden.
9.1
Auswahl
An die Motoren werden sehr hohe Anforderungen gestellt. Sie müssen ein hohes Drehmoment
liefern, um die grosse Masse ausreichend schnell beschleunigen zu können. (Auch wenn wir darauf
verzichten, den Laptop auf dem Bot anzubringen, da seine Masse sehr gross ist.) Kugellager sind
sehr wichtig, damit die Motoren, wenn sie für eine kontinuierliche Drehung umgerüstet werden,
die grössere Abnutzung ohne Schaden zu erleiden, verkraften können. Die Stromversorgung muss
mit 6V erfolgen könen, damit die Motoren mit der restlichen Elektronik im selben Kreislauf sein
können. Die Ansteuerung der Motoren muss mit Pulsweitenmodulation (siehe Seite 19) erfolgen,
damit sie auch von unserem Controller gesteuert werden können.
Wir wählten den Onlinehändler Conrad als Lieferant für diese Bauteile. Er bietet die grösste
uns bekannte Auswahl und hat eine Zweigstelle in der Schweiz. Aus den vielen Servomotoren,
die im Angebot sind, erfüllen nur wenige alle Anforderungen. Wir entschieden uns für den Servo
“S-71”(Abbildung B.4), da er ein hohes Drehmoment besitzt und doppelt kugelgelagert ist. Auch
das Metallgetriebe ist ein Pluspunkt.
22
9.2
9.2.1
Aufbau
Mechanik
Das Öffnen des Motorengehäuses ist einfach. Im Gehäuse erkennt man die Steuerelektronik
und das Getriebe. Das Drehmoment des Motors wird über vier Metallzahnräder auf die Achse
umgeleitet. So kann der Motor trotz seiner Grösse ein sehr grosses Drehmoment entwickeln. Die
Elektronik ist kompakt im Gehäuse verstaut (siehe Abbildung 9.1). Im Schema ist ausserdem gut
zu erkennen, wie der Motor seine Position mit einem Feedbackpotentiometer bestimmen kann.
Abbildung 9.1: Servoschema von Mr. Robot [6]
23
9.2.2
Elektronik
Um die Position zu erkennen, verwenden Servomotoren ein Feedbackpotentiometer. Das ist ein
Potentiometer1 , mit dem die Steuerelektronik des Servomotors Rückschlüsse auf die Position der
Achse zieht. Die Signalpulse des Controllers steuern dabei die Position des Motors. Mit abnehmendem Abstand der Achse vom gewünschten Winkel wird auch der Motor verlangsamt. Er steht
still, wenn sie erreicht wird.
9.3
Modifikation
Ein mechanischer Schutz verhinderte das kontinuierliche Drehen. Durch die Entfernung eines
Stiftes hebt man diese Beschränkung auf.
Die Elektronik ist das zweite Hindernis. Entfernt man die Universal Plate, eine Plastikscheibe,
die den Kontakt der Achse zum Potentiometer herstellt, fehlt ihr die Positionsrückmeldung und
die Motoren drehen sich kontinuierlich.
9.4
Kalibrierung
Nach den Umbauarbeiten folgte die Kalibrierung. Da wir das Potentiometer von der Achse
getrennt haben, wird er sich solange drehen, bis die Zielposition mit der, die das Potentiometer
liefert, übereinstimmt. Wir können mit dem Controller die Positionen des Servos in 255 Schritten
bestimmen, der Schritt 128 ist die Mitte. Man kalibriert das Potentiometer exakt auf die Position 128, damit sich die Motoren bei Initialposition nicht drehen und man eine möglichst grosse
Geschwindigkeitspalette zur Auswahl hat (Anders als in [1], wo das Potentiometer durch feste
Wiederstände ersetzt wird). Allfällige Ungenauigkeiten bei diesem Vorgang können aber auch in
der Software korrigiert werden, indem man den Wert für die Nullposition anders wählt.
9.5
Zusammensetzen
Anschliessend wurden die Getriebezahnräder wieder eingesetzt und das Gehäuse verschlossen.
Die Servomotoren drehten sich nun kontinuierlich. Die abschliessende Testserie sollte Fehler beim
Zusammensetzen aufspüren.
1
Regelwiederstand
24
Kapitel 10
Sensoren
Sensoren dienen einem Roboter dazu, eine Rückmeldung über seine Umwelt zu bekommen,
welche ihm ermöglicht, sich in einer Umgebung zurecht zu finden. Sie liefern ihm alle Daten über
die Aussenwelt, aus denen er seine Position und die Umgebung ableiten muss.
10.1
Auswahl
Unser Roboter verwendet, wie der PalmBot, den wir als Vorlage verwenden, drei “Sharp
GP2D12 Infrared Ranger” (Abbildung B.5) als Entfernungssensoren, da sie sehr einfach anzusteuern sind und auch im Preis liegen. Man kann sie auch, im Gegensatz zu Ultraschallsensoren,
direkt an die Sensorpins des Controllers anhängen. Die ebenfalls zur Auswahl stehenden Lasersensoren sind aufgrund des Preises keine Option.
10.2
Funktion
Die Sensoren verwenden zur Messung Infrarotlicht, welches von einer Diode erzeugt und dessen
rückgestrahlter Anteil von einem Photowiderstand gemessen wird. Der interne Signalprozessor
wandelt das gemessene Signal, vermutlich eine Zeit- oder Helligkeitsdifferenz, über einen Voltregulator in das analoge Outputsignal um, welches am Vo -Pin anliegt[3].
25
Kapitel 11
Schaltung
Die einzelnen Bauteile des Roboters sind für sich gesehen nichts besonderes, erst in ihrem Zusammenspiel ergeben sie eine funktionierende Maschine, welche die geforderten Aufgaben erfüllt.
Damit das Zusammenspiel reibungslos gelingt, muss den Eigenheiten jedes Bauteiles Beachtung
geschenkt werden.
Die Verbindung der einzelnen Komponenten ist auch das, was die Hardware unseres Bots vom
kleineren, mechanisch weniger leistungsfähigen Vorbild, dem PPRK[5] auf der Hardwareebene am
meisten unterscheidet. (Abbildung B.1)
Akku
U 6V
SV203
Sensor
Upuls
U 0V
Usignal
Servo
Akku
U 6V
Abbildung 11.1: Schema der Schaltung
26
11.1
Strom
Damit jedes Bauteil seine Funktion erfüllen kann, wird es von den Akkus mit Energie versorgt.
Dabei versorgt ein Akkupack die Servomotoren, ein weiteres ist für die kleineren Verbraucher wie
Sensoren und Controller zuständig. Damit alle Bauteile zusammenspielen können, besitzen sie
einen gemeinsamen Grund, bei uns der Minus-Pol (Abbildung 11.1).
Jeder Servomotor ist am gemeinsamen Grund und am Akku angeschlossen, von wo er seine Energieversorgung erhält. Sie sind die Verbraucher mit dem grössten Strombedarf. Die Sensoren sind
zusammen mit dem Controller parallel mit den zweiten Akku verbunden. Durch diese Trennung
fliessen die grossen Ströme für die Motoren nicht durch die Steuerelektronik, wie es im PPRK[5]
der Fall war, sondern in einem getrennten Stromkreis, was Hitzeprobleme schon im Vorfeld vermeidet.
11.2
Signal
Der Controller, der an einer anderen Spannungsquelle als die Motoren liegt, muss Steuersignale
senden können. Das gelingt trotz der getrennten Stromkreise, da der Steuerchip und der Servo einen gemeinsamen Grund haben. Die Sensoren sind ebenfalls mit einem Pol am Controller
angeschlossen, über den ihre Messdaten als Spannungsdifferenz ausgelesen werden (siehe Figur
11.1).
27
Teil IV
Software
28
Kapitel 12
Software Architektur
12.1
Einführung
Softwareentwicklungsmethoden haben den Anspruch, den Entwicklungsprozess in allen Phasen zu unterstützen. Ein zentrales Element dabei ist die Software Architektur, die verschiedene
Bereiche abdeckt, beginnend bei der Anforderungsanalyse bis zum finalen Objektmodell. Dieser Ansatz der Softwarearchitektur beschränkt sich auf abstrahierte Modelle als Grundlage für
die Implementierung: Komponententeilung, Kommunikation, Datenfluss sowie Sequenzen mit Zustandsübergängen.[7]
In diesem Teil der Dokumentation werden ausschliesslich Bereiche unserer Software Architektur
behandelt. Die Implementation ist gemäss den Konventionen von C#[8] innerhalb des Sourcecodes offen und ausführlich dokumentiert, die Benutzerführung und Administration ist im Manual
beschrieben, das dem Bot beiliegt.
12.2
Anforderungen
Die beste Hardware eines Roboters bringt wenig, wenn sein Gehirn, also die Software, versagt.
Es ist deshalb wichtig, eine einfache aber sichere Lösung zu finden. Da in der Robotik viele
verschiedene Ansätze möglich sind und der Bot auch als Experimentierobjekt konzipiert ist, ist
ausserdem eine hohe Flexibilität und Skalierbarkeit wichtig. Die Architektur muss also modular,
flexibel und möglichst simpel sein.
29
12.3
Environment
12.3.1
Wahl der Umgebung
Unter einer Umgebung versteht man das System, auf dem die Software aufbaut, von dem sie
initialisiert und auch kontrolliert wird. Sie besteht unter anderem aus der benutzen Hardware,
dem Betriebssystem und den benutzten Frameworks und Services. Jede Software ist speziell für
eine Umgebung entwickelt worden, wenn solche Systeme auch manchmal durch Abstraktion eine
Unabhängigkeit vom unterliegenden Subsystem (z.B. Betriebssystem, siehe Java) anstreben.
Die Wahl der Umgebung ist von zentraler Bedeutung in Bezug auf Effizienz, Produktivität
und Potential der zu entwickelnde Applikation. Es wurden verschiedene solche Umgebungen in
Betracht gezogen, einige davon sind die Java RE, ein rohes RT Linux, Windows DNA sowie die
Microsoft .NET Plattform.
Prozess
Die erste Designstudie basierte einfachheitshalber auf Windows DNA und war in VB6.0 umgesetzt. Die Ergebnisse waren viel versprechend, doch ist VB vergleichsweise umständlich und in
den Möglichkeiten begrenzt, sodass wir auf C# und das .NET Framework umstiegen. Als Betriebssystem kam in Folge nur Windows NT in Frage, auf dessen Services wie MSMQ, VSA.NET
und die .NET CLR die Software nun aufsetzt. Die .NET Plattform ist zwar kein Echtzeitsystem
und zu unserer Entwicklungszeit noch in Betaphase, doch sie bietet ein umfassendes, robustes
Framework, und in Kombination mit C# somit eine moderne und produktive Umgebung.
12.4
Komponenten
12.4.1
Modularität
Die geforderte Flexibilität kann durch ein komponentenorientiertes Softwaredesign erreicht werden. Diese Idee wurde in der Designstudie sehr stark gewichtet, wodurch ein Komplex von über
15 eigenständigen Komponenten entstand.
Bei der Umsetzung in C# verlagerte sich die Gewichtung auf die Isolierung logischer Komponenten in Darstellung, Steuerung und Backend, wobei der Bereich Steuerung einerseits mit Plugins
erweitert und andrerseits per Scripts beliebig automatisiert werden kann. Die Software ist in die
Ebene des Frontends und des Backends gegliedert, wobei Ersteres aus einer Hauptapplikation und
30
verschiedenen Modulen, Plugins und Scripts besteht und das Backend die Kommunikation mit
der Hardware koordiniert.
12.4.2
Kommunikation
MessageQueue
Client
Frontend
Server
Log Queue
Backend
Nav Cmd Queue
Nav Stat Queue
Gen In Queue
Gen Out Queue
Abbildung 12.1: Kommunikation der Komponenten
Frontend und Backend sind autonom, müssen aber ständig Informationen abgleichen. Dieses
Problem wird durch Nachrichten mit Steuer- oder Statusinformationen gelöst, die über die systemweite MessageQueue ausgetauscht werden (Abbildung 12.1). Eine nützliche Eigenschaft ist,
dass die MessageQueue auch netzwerkweit agieren kann, wodurch das Backend auch auf einem
anderen Rechner ausgeführt werden kann als das Frontend, zum Beispiel auf einem PDA1 . In
Kombination mit einem WLAN führt das zur interessanten Option, den Bot per Funk zu steuern.
1
mit Windows CE und .NET Unterstützung
31
Kapitel 13
Backend
13.1
Aufgaben
Das Backend ist der Vermittler zwischen dem entscheidenden, steuernden “Bewusstsein” und
dem ausführenden und sensorischen physischen Körper. Auf der einen Seite stehen die Module,
die Bewegungsbefehle senden und dazu ständig Feedbacks erwarten, und auf der anderen Seite
der Controller mit den Motoren und Sensoren.
Das Backend muss also die Befehle der Module abfangen und verwalten, um daraus konkrete
Motorbefehle zu extrahieren und zum Controller zu übermitteln. Gleichzeitig muss es regelmässig
die Daten der Sensoren abfragen und zusammen mit Statusberichten bzgl. Motorbefehle zu den
Modulen zurücksenden.
13.2
Datenfluss
Grundsätzlich fliessen die Informationen im Backend in zwei unabhängigen Kanälen, einer von
den Modulen in Richtung Hardware (Requestchannel), der andere umgekehrt in Richtung Module
(Feedbackchannel).
13.2.1
Phasen
Beiden Kanäle durchlaufen entgegengerichtet vergleichbare Phasen. In Richtung des Requestchannels ist die erste Phase die MessageQueue, welche regelmässig auf neue Nachrichten überprüft
wird. Wird eine Nachricht empfangen, wird sie in der zweiten Phase extrahiert, kategorisiert und
an die dritte Phase weitergeleitet, wo sie verarbeitet und koordiniert wird. Die Verarbeitung
32
umfasst diverse Berechnungen. Bei Bedarf wird in der folgenden Phase eine Nachricht in einem
für die Hardware verständlichen Format generiert. Diese Daten werden unmittelbar an die letzte
Phase übergeben: die geordnete Übermittlung an den Controller über die Schaltkreise des RS232
Bussystems.
Ähnlich verläuft der Fluss im Feedbackchannel. Die Sensoren werden vom Controller abgefragt.
Die Antwortsignale werden extrahiert, analysiert, umgerechnet und zusammengefasst, um dann
in eine Nachricht verpackt und in der MessageQueue in Richtung Module gesendet zu werden.
13.2.2
Koordination
Da die Befehle vom Controller jeweils sofort ausgeführt werden, müssen sie koordiniert gesendet
werden. Dies wird gewährleistet, indem Gruppen von Befehlen erst in einer Queue gesammelt und
in Textbefehle (Tabelle 7.2) konvertiert werden. Dieses Befehlsset wird dann durch einen weiteren
Befehl angestossen und zeitgesteuert an den Controller übergeben.
33
Kapitel 14
Frontend
14.1
Aufgaben
Das Frontend ist die Schnittstelle zwischen dem Menschen und der steuernden Software. Seine
zentrale Aufgabe ist folglich die Interaktion mit dem Benutzer. Neben der Visualisierung der
Softwareprozesse bietet das Fontend dem Benutzer auch die Möglichkeit, in diese einzugreifen.
14.2
Aufbau
Entsprechend der geforderten Modularität besteht das Frontend aus einem Container, der
Grundfunktionalitäten wie Shell und Log zur Verfügung stellt und beliebige Module und Plugins
im Modulbereich laden kann.
Da das Frontend in erster Linie für Notebooks konzipiert ist, die, so die ursprüngliche Idee,
direkt auf dem Roboter stationiert sind, eignet sich eine sonst übliche Maussteuerung für die
Benutzeroberfläche nicht. Wir entschieden uns daher für eine mauslose Benutzerführung mit einer
bildschirmfüllenden Darstellung, die sich im Allgemeinen aus vier Elementen zusammensetzt: in
der linken Spalte der Modulbereich, in der rechten die Shell, das Log, sowie die Statusanzeige.
14.2.1
Shell
Die Shell ist die eigentliche Kommunikationsschnittstelle zum Benutzer. Sie ist einer typischen
Textshell nachempfunden und besteht entsprechend aus der Befehlszeile und einem kleinen Fenster, in welchem die direkten Ausgaben der ausgeführten Befehle ausgegeben werden.
34
Um konsequent den Ideen des objektorientierten Designs zu folgen, basieren die Befehle auf
dem Muster [.]object.method([param1[,param2]*]). Anfangs wird das Objekt gewählt, mit dem
man interagieren möchte, beispielsweise module für das Modulmanagement oder log für das Event
Log. Falls dieses Objekt Teil des Containers ist, muss vor dem Objektnamen ein Punkt gesetzt
werden, ansonsten wird der Befehl an das aktuelle Modul weitergeleitet. Durch einen Punkt
getrennt folgt der Methodenname mit beliebigen Parametern zwischen den Klammern. Beispiel:
.bot.quit() beendet die Robotersoftware, .module.load(script) lädt das Script Modul.
14.2.2
Log
Im Log wird über alle Aktivitäten Protokoll geführt. Dies umfasst alle Befehle an den Controller,
diverse Statusmeldungen sowie allfällige abgefangene Fehler. Per Shell können zu jedem Eintrag
erweiterte Informationen abgefangen werden. Optional kann das Log zur späteren Untersuchung
in ein Textfile geschrieben werden.
14.2.3
Status
Im Statusfenster werden Daten zum aktuellen Zustand gezeigt. Von Bedeutung sind vor allem
die Anzeigen der aktuellen Servobewegungen und Sensormesswerten, die neben der numerischen
Darstellung auch mit Balken graphisch visualisiert werden.
14.2.4
Module
Die Module übernehmen die eigentliche Steuerung des Roboters, indem sie Messages mit Bewegungsanforderungen an das Backend senden und ankommende Sensormesswerte analysieren.
Die Modulansicht ist ein Container, in den die integrierten Module und externen Plugins geladen
werden können. Im Grunde können beliebige neue Module für die Applikation geschrieben werden, einzige Bedingung ist die Implementierung der vorgegebenen PModule Schnittstelle. Schon
zu Beginn stehen folgende Module zur Verfügung: das General Modul, dass allgemeine Aufgaben
wie Kalibrierung, Parametrisierung übernimmt und ein direktes Controller-Terminal anbietet; das
Scripting Modul, das das Erstellen, Kompilieren und Starten von Scripts zur Steuerung des Bots
ermöglicht; das Neuro Modul, mit dem automatisierbare neuronale Netzwerke generiert, trainiert
und propagiert werden können; sowie das Map Modul, mit dem mit Pixelkarten gearbeitet werden
kann.
35
Kapitel 15
Arbeiten mit der Software
Der Benutzerführung jeder Software liegt eine Philosophie zugrunde, die unter anderem die
Art und Weise beinhaltet, mit der eine Problemstellung angegangen wird. Die technische Umsetzung wird im Manual detailliert abgehandelt, während wir hier einige grundsätzliche Aspekte
untersuchen.
15.1
Vorgehensweise bei einfachen Problemstellungen
Mögliche einfache Problemstellungen sind beispielsweise das Fahren um einige Schritte in eine
gegebene Richtung oder das Abfahren eines regelmässigen Sechsecks. Für solche Aufgaben ist das
Script Modul ideal: in kleinen Scripts können beliebig komplexe Bewegungsabläufe konstruiert
werden, die optional auch Sensordaten berücksichtigen.
15.2
Einbindung von Erweiterungen
Das Scripten ist eine schnelle und bequeme Lösung, doch stösst es auch an Grenzen, weswegen
Scripts generell auch beliebige externe .NET oder auch COM Komponenten einbinden können.
Beispielsweise kann eine Komponente geschrieben werden, mit deren Hilfe der Bot via Scripts
auf GPS Navigation zurückgreifen kann. Die Scripts können somit auch als Scharnier verwendet
werden, das verschiedene Komponenten koordiniert und mit dem Backend synchronisiert.
15.3
Erweitern mit Plugins
Bei einigen Problemstellungen macht es Sinn, gleich ein ganzes Plugin zu schreiben. Plugins
haben im Gegensatz zu eingebundenen externen Komponenten eine eigene Oberfläche im Fron36
tend, können direkt vom User per Command Line beeinflusst werden und sind standalone, das
heisst sie können direkt aufgerufen werden, ohne dass dafür Scripts nötig sind.
Plugins können in zwei Kategorien geteilt werden: Erstens die steuernden Plugins, die direkt
mit dem Bot kommunizieren. Ein Beipiel für ein solches Plugin ist das Map Modul, mit dem die
Navigation mit Karten ermöglicht wird. Soll eine Karte aufgezeichnet oder in einer aufgezeichneten
Karte navigiert werden, so wird das Map Modul geladen und in Folge direkt mit ihm gearbeitet.
Anders in der zweiten Kategorie, wo die Plugins ausschliesslich Hilfsobjekte sind, die nicht selber
mit dem Backend kommunizieren. Ein Beispiel für diese Kategorie ist das Neuro Modul, mit dem
neuronale Netzwerke erstellt, propagiert und trainiert werden können, die dann aber per Scripts
eingebunden und gelinkt werden.
Zusammenfassend werden für einfache Problemstellungen Scripts verwendet, deren Funktionalität durch beliebige externe Komponenten erweitert werden kann, während bei Problemstellungen, die auf einer Kommunikation mit dem Benutzer basieren, mit Plugins gearbeitet wird.
37
Teil V
Ausblick
38
Kapitel 16
Weiterführung
Der Bot in seiner jetzigen Version ist keinesfalls ein fertiges Produkt, er ist eher eine Plattform,
auf die man aufbauen kann, die man verändert oder verbessert. In dieser Hinsicht bietet er viele
mögliche Ansetzpunkte für Veränderungen: Die Hardware, also die Elektronik, die Mechanik oder
den Steuercomputer, oder die Software, also das Backend, das Frontend oder auch das Scripting.
16.1
Hardware
Der erste Ansatzpunkt für Hardwareveränderungen ist der Computer, auf dem die Steuersoftware arbeitet: Er kann frei gewählt werden, sofern er über eine RS232 Schnittstelle verfügt.
Neben den üblichen Desktop PCs oder Notebooks erfüllen auch einige Sub-Notebooks und sogar
Handhelds diese Anforderung. Wenn allerdings die Plattform gewechselt wird, muss die Software
angepasst oder neu geschrieben werden.
Auch andere Bauteile können ausgetauscht oder erweitert werden. Für zukünftige Applikationen
werden unter Umständen die drei Sensoren nicht ausreichen, der Controller kann aber noch von
zwei weitere Datenquellen einlesen. Stärkere Motoren könnten es erlauben, einen Computer, zumindest ein leichtes Notebook, direkt auf dem Gehäuse anzubringen. Bessere Sensoren könnten
die Reichweite erweitern. Manipulatorarme könnten eine grössere Interaktion mit der Umwelt
erlauben, indem Gegenstände bewegt werden können.
16.2
Software
Die Software bietet noch viel mehr Möglichkeiten für Veränderungen. Die Einfachste davon
ist, ein neues Script zu schreiben, wodurch selbst komplexere Vorgänge, wie das Ausweichen von
39
Wänden oder das Zeichnen von Schriftzügen, ermöglicht werden können. Das NeuroBox Modul
stellt dabei eine leistungsfähige Umgebung für die Simulation der Denkweise von biologischen
Lebewesen zu verfügung.
Ein weiterer Angriffspunkt sind die Module, die dynamisch ausgetauscht werden können und mit
denen selbst sehr komplexe Verhaltensweisen implementiert werden können. Das MapModul kann
Beispielsweise auf die Verarbeitung von Vektordaten umgebaut werden, oder man schreibt gleich
ein komplett neues Modul wie eines für Fussball1 oder das Finden von Wegen aus einem Labyrinth.
Ein Frontend mit einem anderen User Interface könnte die Steuerung durch Sprach- oder andere
akustische Signale erlauben, oder duch eine Kamera, deren optische Informationen direkt ausgewertet werden, reagiert der Bot auf Gesten.
Auch das komplette Backend kann neu programmiert werden, wie es bei einem einschneidenden
Plattformwechsel erforderlich ist. Dabei kann auf die einfache aber leistungsfähige Befehlssprache
(Tabelle A.2) des Controllers direkt zugegriffen werden.
16.3
Neue Wege
Anstatt den Roboter nur zu erweitern, kann er auch komplett auf ein neues Einsatzgebiet hin
ausgerichtet werden. Als autonomer Staubsauger könnte er Böden reinigen, mit einer Kamera
liesse er sich für die Raumüberwachung einsetzen. Der Phantasie sind nur durch die eigenen
Fähigkeiten oder die Technologie Grenzen gesetzt.
16.4
Hilfe
Für weiterführende Projekte stehen wir gern mit Rat und Tat zur Seite. Auch wenn diese
Maturaarbeit mit der Abgabe von Dokumentation, Hardware und Software abgeschlossen ist,
werden wir noch weiter am Bot arbeiten, damit er noch leistungsfähiger und vielseitiger wird,
und unterstützen gerne andere bei einem ähnlichen Vorhaben. sourceforge.net, eine der grössten
Plattformen für Opensource Projekte, unterstützt auf http://sourceforge.net/projects/xbot auch
die koordinierte Weiterentwicklung unserer Software.
1
Wie auch bei http://www.robocup.org/
40
Teil VI
Anhang
I
Anhang A
Tabellen
Objekt
Anzahl
Preis
Gesamtpreis Fr.
Akkupack (NiMH, 6V)
2
68.35
Fr.
136.70 Fr.
Ladegerät
1 119.95
Fr.
119.95 Fr.
Servo S-71
3
62.95
Fr.
188.85 Fr.
Verpackung
1
2.00
Fr.
2.00 Fr.
IR-Sensor GP2D12
3
13.50
$
68.00 Fr.
Omni Wheels, 3Pack
1
45.00
$
75.60 Fr.
Controller SV-203
1
62.00
$
104.20 Fr.
Versandkosten
1
29.00
$
48.70 Fr.
UPS-Gebüren, Zoll
1
35.30
Fr.
35.30 Fr.
RS-232 Kabel, 3m
1
22.90
Fr.
22.90 Fr.
Alu-Blech, gelocht
1
79.00
Fr.
79.00 Fr.
Alu-Profile, 1m
4
5.00
Fr.
20.00 Fr.
Steckverbindung
1
1.00
Fr.
1.00 Fr.
Schrauben + Muttern
42
0.25 Fr.
10.50 Fr.
Schrauben + Muttern
65
0.25 Fr.
16.25 Fr.
Metallbohrer
1
4.40
Fr.
Gesamt
4.40 Fr.
933.35 Fr.
Tabelle A.1: Das endgültige Budget
II
Befehl
Parameter (n)
Beschreibung
BDn
0 bis 255
Board Auswahl
SVn
1 bis 8
Servo Auswahl
Mn
0 bis 255
Zu einer absoluten Position bewegen
In
-128 bis 127
Zu einer relativen Position bewegen
Dn
1 bis 65535
Verzögerung (ms)
PSn
1 bis 8
Setzt ein einziges Pin von Servoport n
PCn
1 bis 8
Löscht ein einziges Pin von Servoport n
PTn
1 bis 8
Ändert ein einziges Pin von Servoport n
ADn
1 bis 5
Lies A/D Wert, das board gibt einen Wert zwischen 0 und
255 gefolgt von ASCII 13 zurück, repräsentiert einen Wert
zwischen 0V und 5V.
SOn
0 bis 255
Gibt ein Bit über den SPI Port aus
SI
-
Liest ein Bit über den SPI Port ein
WRm n
m = 0 bis 255 Schreibe ins interne RAM, m ist Speicherposition, n ist der
n = 0 bis 255
zu schreibende Wert
RRm
m = 0 bis 255
Lies den Inhalt des internen RAM, m ist die Speicherposition
WEm n
m = 0 bis 8190 Schreibe ins externe EEPROM, m ist die Speicherposition,
n = 0 bis 255
REm
n ist der zu schreibende Wert
m = 0 bis 8190 Lies den Inhalt des externen EEPROM, m ist die Speicherposition
?
-
Hilfe, gibt Kurzfassung der Kommandoliste zurück
V?
-
Gibt die Firmware Version zurück.
Tabelle A.2: Die Befehlsliste des SV-203 (Aus [2])
III
Anhang B
Abbildungen
Abbildung B.1: Übersicht der Elektronik
IV
Abbildung B.2: Der SV203 Controller von Pontech
Abbildung B.3: Ein NiMH Akkupack mit fünf Zellen
V
Abbildung B.4: Ein Servomotor mit angeschlossenem Omniwheel
Abbildung B.5: Ein GP2D12 IR Entfernungsmesser
VI
Anhang C
Glossar
Framework Ein Framework ist eine Softwareumgebung, die Programmen Grundfunktionen des
Betriebssystems, wie Filesystem- oder Memorymenagement, oder höhere Funktionen, wie
das Zeichnen von 3D Bildern oder das Interagieren mit dem User, zu verfügung stellt.
Java RE JRE bedeutet Java Runtime Environment, SUN’s Java Laufzeitumgebung. Java Applikationen werden in Zwischencode kompiliert, der dann von der JRE interpretiert und
schrittweise ausgeführt wird. Dieses auch als JIT bekannte Prinzip ermöglicht eine Unabhängigkeit von Betriebssystem und Hardware und erlaubt dank Sandboxing einen individuellen Sicherheitskontext.
.NET CLR Die .NET Common Language Runtime ist das Pendant zur Java RE in der .NET
Welt. Weitere Informationen zu .NET:
http://www.heise.de/ix/artikel/2001/12/122/
http://msdn.microsoft.com/net/
http://www.microsoft.com/net/
Neuronales Netzwerk Neuronale Netzwerke (NN), oft auch als künstliche neuronale Netzwerke
(KNN) oder Artificial Neural Networks (ANN) bezeichnet, sind informationsverarbeitende
Systeme, die aus einer grossen Anzahl einfacher Einheiten (Zellen, Neuronen) bestehen,
die sich Informationen in Form der Aktivierung der Zellen über gerichtete Verbindungen
zusenden.[10]
Omnidirektional Bedeutet “in alle Richtungen gerichtet”, Omni = alle, direktional = gerichtet.
Oft auch “Ungerichtet”
Reguläre Ausdrücke Regular Expressions sind ein mächtiges, flexibles und effizientes MitVII
tel um Texte zu parsen und bearbeiten.[9] Für das Parsen der Befehle mit dem Muster
[.]object.method([param1[,param2]*]) haben wir beispielsweise folgenden regulären Ausdruck
entwickelt:
^(\w+)\.(\w+)\((([^,]+)(,([^,]+))*)?\)$.
Roboter Bedeutet ursprünglich Sklave, heute ist damit aber vor allem eine unabhängig von
menschlicher Steuerung agierende Maschine gemeint, die verschiedene Aufgaben erledigen
kann. Abkürzung: Bot.
RS232 RS-232 ist eine simple, universelle aber etwas in die Jahre gekommene serielle Schnittstelle, deren Bandbreite auf 256kbps und Länge auf 15m beschränkt ist. RS-232 ist neben
der parallelen die einzige Schnittstelle, auf die mit NT ohne spezielle Treiber direkt per
FileStream (“COM1”) zugegriffen werden kann. http://www.arcelect.com/rs232.htm bietet
weiterführende Informationen.
Trial and Error Prinzip Eine einfache Vorgehensweise zur Lösung von Problemen: Es werden
alle Möglichkeiten getestet, bis eine funktionierende gefunden wird oder oder keine weiteren
Möglichkeiten mehr vorhanden sind. Das Verfahren wird im Deutschen auch als “Versuch
und Irrtum” bezeichnet.
VSA.NET VisualStudio for Applications.NET ist ein Framework für die interne Automation
von .NET Applikationen.
Windows DNA Windows DNA steht für Distributed interNet Applications Architecture und
bietet eine auf COM+ (Component Objetc Model) basierende proprietäre Infrastruktur für
verteilte n-Tier Lösungen. Eine Alternative zu COM+ ist CORBA, auf dem zum Beispiel
Bonobo, eine Linux Komponentenschnittstelle, aufbaut.
WLAN Ein WLAN (Wireless Local Area Network) ist ein LAN, das anderst als Ethernet nicht
über Kabel, sondern per Funk kommuniziert. Der heute aktuelle Standard IEEE 802.11b
arbeitet mit einer Geschwindigkeit von bis zu 11Mbps und hat eine Reichweite von etwa
50m.
http://www.apple.com/chde/airport/specs.html
http://www.csdmag.com/main/2000/06/0006stand.htm
VIII
Literaturverzeichnis
[1] Edwin Wise, Applied Robotics, Prompt Publications, 1999, ISBN 0-7906-1184-8.
[2] SV203 Servo Motor Controller Board: User’s Manual Pontec, 1998.
http://www.pontech.com/products/sv200/sv203 v.1.20 webmanual.pdf
[3] GP2D12 Manual, Sharp.
http://www.sharp.co.jp/ecg/opto/products/pdf/optical sd/optical sd/gp2d12.pdf
[4] Ivo Steiner, Chemieblätterset: “Batterien und Akkumulatoren”, 2000/2001.
[5] Palm Robot Kit
http://www.cs.cmu.edu/ pprk/
http://www.acroname.com/robotics/info/PPRK/PPRK.html
[6] Mr. Robot, Robots & Microcontrollers for the Future,
http://www.mrrobot.com/
[7] Ruth Breu, Objektorientierter Softwareentwurf, Springer Verlag, 2001, ISBN 3-540-41286-7
[8] Eric Gunnerson, C#, Die neue Sprache für Microsofts .NET Plattform, Galileo Press, 2001,
ISBN 1-893115-86-0
[9] Jeffred E.F. Friedl, Reguläre Ausdrücke, O’Reilly Verlag, 1998, ISBN 3-930673-62-2
[10] Andreas Zell, Simulation neuronaler Netzwerke, R. Oldenbourg Verlag, 1994, ISBN 3-48624350-0
IX
Index
Mechanik, 17
Akkumulator, 20
Funktionsweise, 21
Karten, 8
Anforderungen, 29
Neural Map, 9
Architektur, 29
Pixelmap, 8
Backend, 32
Speicherung, 8
Aufgaben, 32
Vektormap, 9
Datenfluss, 32
Kommunikation, 31
Koordination, 33
Komponenten, 30
Budget, 4
Koordination
Liste, II
Backend, 33
Controller, 18
Maps, 11
Befehlsliste, III
Mechanik, 17
Modularität, 30
Datenfluss
Backend, 32
Navigation
Dokumentation, 2
Wegberechnung, 11
Einsatzgebiete, 40
Neural Map, 9
Elektronik, 26
OmniWheel, 7
Feedbackpotentiometer, 24
Pixelmap, 8
Fortbewegung, 6
Platform, 30
Frontend, 34
Pulsweitenmodulation, 19
Aufgaben, 34
Punktreduktion, 9
Strukturierung, 34
Schaltung, 26
Gehäuse, 16
Sensor
Funktion, 25
Hardware
Anpassung, 39
Sensoren, 25
Gehäuse, 16
Servo
X
Modifikation, 24
Servomotoren, 22
Schema, 23
Software
Anforderungen, 29
Anpassung, 39
Architektur, 29
Backend, 32
Designstudie, 30
Einführung, 29
Frontend, 34
Kommunikation, 31
Komponenten, 30
Modularität, 30
Umgebung, 30
Weiterentwicklung, 40
Strategie
Wegberechnung, 11
Stromversorgung, 20
Vektormap, 9
Wegberechnung, 11
Wegpunktberechnung
Ausbreitungsanalyse, 13
Grenzverfolgung, 11
XI