Studienarbeit von Jendrik Bertram

Transcrição

Universität Paderborn
Fakultät für Elektrotechnik, Informatik und Mathematik
Bachelorarbeit
Re-Engineering eines LEGO Hochregallagers
und Konzeption der Steuerung mit Hilfe
von Mindstorms NXT-Modulen
Jendrik Bertram
13. Dezember 2007
betreut von
Michael Dohmen
vorgelegt bei
Prof. Dr. Johannes Magenheim
Prof. Dr. Stefan Böttcher
Erklärung
Ich versichere, dass ich die vorliegende Arbeit selbstständig und ohne unerlaubte Hilfe
Dritter angefertigt habe. Alle Stellen, die inhaltlich oder wörtlich aus anderen Veröffentlichungen
stammen, sind kenntlich gemacht. Diese Arbeit lag in gleicher oder ähnlicher Weise noch
keiner Prüfungsbehörde vor und wurde bisher noch nicht veröffentlicht.
Jendrik Bertram
Paderborn, 13. Dezember 2007
i
Zusammenfassung
In Hochregallagern sind oft viele tausende Palettenstellplätze vorhanden, welche durch
schienengeführte Regalbediengeräte beladen werden. Diese Regalbediengeräte werden
über Förderbandsysteme oder autonome Transportfahrzeuge mit den Paletten beliefert.
Im Rahmen des MuSoft Projekts ist ein Model solch eines Hochregallagers mit Hilfe der
LEGO Mindstorms entstanden, dessen Steuerung durch das Robotics Invention System
(RIS) umgesetzt wurde. Hierbei wurde nicht auf die von LEGO entwickelte Mindstorms
Programmierumgebung zurückgegriffen, sondern auf das OpenSource Projekt leJOS.
Mit leJOS ist es möglich die programmierbaren Bausteine mit Hilfe von Java zu programmieren. Dafür wurde eine Java Virtual Machine entwickelt, die auf diesen Bausteinen funktioniert. Außerdem wurde eine Bibliothek zur Verfügung gestellt, die es
ermöglicht, die Aktoren und Sensoren anzusprechen. Zusätzlich stellt leJOS Funktionen
bereit, die es vereinfacht, oft benutzte Konzepte der Robotik umzusetzen.
Die LEGO Mindstorms RCX Serie wurde mittlerweile von der LEGO Mindstorms
NXT Serie abgelöst. Das leJOS Projekt hat mit der Arbeit begonnen, die Virtual Machine und die Bibliothek zu portieren und zu erweitern, um von den neu hinzu gekommenen
Funktionalitäten Gebrauch machen zu können.
Diese Bachelorarbeit stellt die Neuerungen der Mindstorms NXT vor und zieht einen
Vergleich zu den Mindstorms RCX. Dabei wird neben der grundsätzlich unterschiedlichen Konstruktion, auf die neuen Sensoren und Aktoren, aber auch die Änderungen in
der Programmierung eingegangen.
Alle Elemente des bestehenden Hochregallagers werden mit den neuen NXT Bausteinen
in der stud-less Bauweise neu aufgebaut, wobei versucht wird von den Neuerungen so
weit wie möglich Gebrauch zu machen und Schwachstellen des alten Systems so weit wie
möglich zu umgehen.
Der Schwerpunkt liegt darin die störanfällige und langsame Infrarot-Kommunikation
gegen eine Bluetooth-Kommunikation einzutauschen und die Steuerung mit Hilfe eines
einfachen Menüsystems auf einem der programmierbaren NXT Bausteine umzusetzen.
Zusätzlich werden Ansätze dargestellt, wie sich das System mit weiterer Funktionalität
ausbauen lässt. Diese sind hauptsächlich darauf angesetzt, zu versuchen das Model einem
wirklichen Hochregallager von der Funktionalität her ähnlicher zu machen.
ii
Inhaltsverzeichnis
1 Einleitung
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Ziele der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1
2
3
2 Definitionen
4
3 RCX und NXT
3.1 Die programmierbaren Bausteine .
3.2 Die Aktoren . . . . . . . . . . . . .
3.2.1 Der RCX Motor . . . . . .
3.2.2 Der NXT Motor . . . . . .
3.3 Die Sensoren . . . . . . . . . . . .
3.3.1 Der Drucktaster . . . . . .
3.3.2 Der Licht Sensor . . . . . .
3.3.3 Der Sound Sensor . . . . .
3.3.4 Der Ultrasonic Sensor . . .
3.3.5 Der Rotations Sensor . . .
3.3.6 Produkte anderer Hersteller
3.4 Programmierung . . . . . . . . . .
3.4.1 NXT-G . . . . . . . . . . .
3.4.2 leJOS . . . . . . . . . . . .
4 Konstruktion
4.1 Das Hochregal . . . . . . . . . . .
4.2 Das Regalbediengerät . . . . . . .
4.2.1 Die Fahreinheit . . . . . . .
4.2.2 Die Hubeinheit . . . . . . .
4.2.3 Die Lastaufnahmeeinheit .
4.3 Die Übergabestation . . . . . . . .
4.4 Das Autonome Transportfahrzeug
4.5 Die Fahrbahn . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
9
10
10
11
12
12
13
15
15
16
17
19
19
20
.
.
.
.
.
.
.
.
24
26
27
27
28
29
30
31
33
5 Implementierung
35
5.1 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1.1 Die Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2 Der Master Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
iii
Inhaltsverzeichnis
Inhaltsverzeichnis
.
.
.
.
.
.
.
.
.
41
42
43
45
46
46
47
48
51
6 Erweiterungsmölichkeiten
6.1 ATF Erweiterung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 UEG Erweiterung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Lagerverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
54
55
56
7 Fazit und Ausblick
57
5.3
5.4
5.5
5.2.1 Das Menüsystem . . . . . . .
5.2.2 Das Lagerverwaltungssystem
Das Regalbediengerät . . . . . . . .
Die Übergabestation . . . . . . . . .
Das Transportfahrzeug . . . . . . . .
5.5.1 Initialisierung . . . . . . . . .
5.5.2 Linienverfolgung . . . . . . .
5.5.3 Positionsbestimmung . . . . .
5.5.4 Anfahrt der Zielpositionen . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
A UML Diagramme
58
A.1 Klassendiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
A.2 Sequenzdiagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
B Konstruktionsabbildungen
61
B.1 Anschlussbelegung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
C Inhalt der beiliegenden CD
65
D Inbetriebnahme
66
Literaturverzeichnis
67
iv
Abbildungsverzeichnis
2.1
Ein Hochregallager mit Regalbediengerät . . . . . . . . . . . . . . . . . .
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
Der RCX Baustein . . . . . . . . . .
Der NXT Intelligent Brick . . . . . .
Der RCX Motor . . . . . . . . . . .
Der NXT Motor . . . . . . . . . . .
Der RCX Drucktaster . . . . . . . .
Der NXT Drucktaster . . . . . . . .
Der RCX Licht Sensor . . . . . . . .
Der NXT Licht Sensor . . . . . . . .
Der NXT Sound Sensor . . . . . . .
Der NXT Abstands Sensor . . . . .
Der RCX Rotations Sensor . . . . .
Der HiTechnic Kompass Sensor . . .
Die NXT-G Entwicklungsumgebung
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
8
10
11
12
13
13
14
15
16
16
17
19
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
Das RCX Hochregallager . . . . . . . .
Das Hochregal . . . . . . . . . . . . . .
Die Fahreinheit . . . . . . . . . . . . . .
Die Hubeinheit . . . . . . . . . . . . . .
Die Übergabestation . . . . . . . . . . .
Das Autonome Transportfahrzeug . . .
Der Initialisierungsbereich für das ATF
Die Fahrbahn . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
26
28
29
30
31
33
34
5.1
5.2
5.3
5.4
5.5
5.6
5.7
Sequenzdiagramm Einlagern . . . . . . . .
Die Command Hierarchie . . . . . . . . .
Klassendiagramm des Master Controllers
Klassendiagramm des Regalbediengerätes
Klassendiagramm der Übergabestation . .
Schema einer Positionsveränderung . . . .
Anfahrt der Zielposition . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
37
38
42
44
45
49
51
.
.
.
.
.
.
.
.
.
.
.
.
.
4
A.1 Klassendiagramm upb.hrl.comm . . . . . . . . . . . . . . . . . . . . . . . 58
A.2 Klassendiagramm des Autonomen Transportfahrzeuges . . . . . . . . . . . 59
A.3 Sequenzdiagramm Auslagern . . . . . . . . . . . . . . . . . . . . . . . . . 60
v
B.1 Das Regalbediengerät mit Hochregal . . . . . . . . . . . . . . . . . . . . . 61
B.2 Das Regalbediengerät . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
B.3 Die Lastaufnahmeeinheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
vi
1 Einleitung
1.1 Motivation
Im Rahmen des MuSoft Projekts1 ist ein Hochregallager auf Basis des LEGO2 Mindstorms3 Robotics Invention System (RIS) entstanden, welches ein Modell des Avarto4
Hochregallagers von Bertelsmann in Bielefeld darstellt.
Das System wird von insgesamt 10 RCX Bausteinen gesteuert, die auf autonome Transportfahrzeuge, Übergabestationen und Regalbediensysteme verteilt sind. Die RCX Module kommunizieren dabei über die eingebaute Infrarotschnittstelle mit einem speziell
entwickelten Protokoll, welches einen Tokenmanager einsetzt.
Obwohl LEGO eine grafische Programmierumgebung zur Erstellung von Programmen
mitliefert, wurde sich dafür entschieden die Programmierung mit Hilfe der frei verfügbaren,
auf Java basierenden, leJOS5 Bibliothek durchzuführen. Dadurch konnten einige elementare Einschränkungen umgangen werden.
Im Jahr 2006 wurde von LEGO eine neue Generation der programmierbaren Bausteine, welche das Robotics Invention System ablösen, in das Sortiment aufgenommen. Die
neuen Mindstorms NXT Module sind deutlich leistungsfähiger als die alten RCX Module, aber leider nicht kompatibel. Die Programmierbausteine, sowie die Motoren und
Sensoren, haben andere Dimensionen und werden mit Hilfe der neuen studd-less Technik
zusammen gebaut. Außerdem unterscheiden sich die Komponenten teilweise deutlich in
ihrer Funktionalität.
Auch die alten leJOS Bibliotheken sind in der Form nicht weiter benutzbar. Das OpenSource Projekt arbeitet jedoch daran die Java Virtual Machine auf die neuen Bausteine zu portieren und die dazugehörige Bibliothek anzupassen, um von den neuen
Möglichkeiten, wie Bluetooth und neuartigen Sensoren, Gebrauch machen zu können.
Zum aktuellen Zeitpunkt steht leJOS NXJ in der frühen beta Version 0.4 zur Verfügung.
Somit bietet sich LEGO Mindstorms NXT, in Verbindung mit leJOS NXJ, dazu an,
das Model des Hochregallagers umzurüsten und dessen Funktionalität zu erweitern.
1
http://www.musoft.org
http://www.lego.de
3
http://www.legomindstorms.com
4
http://www.arvato-systems.de
5
http://www.lejos.org
2
1
1.2. ZIELE DER ARBEIT
KAPITEL 1. EINLEITUNG
1.2 Ziele der Arbeit
In dieser Bachelorarbeit wird das bestehende LEGO Mindstorms RIS Hochregallager
der FG Didaktik6 mit Hilfe der LEGO Mindstorms NXT neu aufgebaut. Die Steuerung
soll von leJOS RCX nach leJOS NXJ portiert und alle Elemente mit Hilfe der stud-less
Technik neu konstruiert werden. Dieses ist nötig, da weder die leJOS Bibliotheken, noch
die Konstruktion der beiden Systeme miteinander kompatibel ist.
Für die Konstruktion der überarbeiteten Elemente ist es notwendig die Möglichkeiten
der mitgelieferten, aber auch anderweitig erhältlichen, Aktoren und Sensoren genauer
zu betrachten, um diese bestmöglich einsetzen zu können. Es muss ein Regalbediengerät, eine Übergabestation und ein autonomes Transportfahrzeug konstruiert werden.
Zusätzlich muss die vorhandene Fahrbahn angepasst werden.
Die in Java implementierte Steuerung muss komplett überarbeitet werden, um von den
neuen Möglichkeiten, vor allem der Motoren, Gebrauch machen zu können. Zusätzlich
kann auf neue Funktionen der leJOS NXJ Bibliothek zurückgegriffen werden.
Ein besonderes Augenmerk wird auf die neuen Möglichkeiten der Kommunikation zwischen den NXT Programmierbausteinen gelegt. Diese verfügen nicht mehr über die bisher eingesetzte Infrarot Schnittstelle. Dafür steht aber Bluetooth Unterstützung zur
Verfügung. Dementsprechend muss die Kommunikation mit dessen Hilfe, so weit es der
aktuelle Entwicklungsstand von leJOS zulässt, neu implementiert werden.
Die Steuerung des Gesamtsystems soll über ein dediziertes NXT Modul realisiert werden. Dieses soll die Möglichkeit bieten, grundlegende Tests des Systems durchzuführen
und neue Aufträge zum Ein- und Auslagern von Paletten auszuführen. Dieses Modul
soll auch die grundlegenden Aufgaben eines Lagerverwaltungssystems übernehmen.
Ein zusätzliches Ziel der Arbeit ist es, mögliche Erweiterungen für das System herauszuarbeiten und zu erläutern. Die Erweiterungen sollen darstellen, wie einzelne Komponenten des Hochregallagers verbessert werden können, aber auch wie das gesamte
System einem reellem Hochregallager, von dem Aufbau und der Funktion her, ähnlicher
umgesetzt werden kann.
Die Programmierung wird in Java 1.57 von Sun durchgeführt. Des weiteren soll die
leJOS NXJ Bibliothek genutzt werden. Diese steht zum aktuellen Zeitpunkt in der Version 0.4 zur Verfügung, welche jedoch nicht alle benötigten Features, besonders die für
die Bluetooth Kommunikation, unterstützt. Daher muss auf eine aktuellere Version aus
dem Subversion8 Repository des Projektes zurückgegriffen werden.
6
http://ddi.uni-paderborn.de
http://java.sun.com
8
http://subversion.tigris.org
7
2
1.3. AUFBAU DER ARBEIT
KAPITEL 1. EINLEITUNG
1.3 Aufbau der Arbeit
Diese Bachelorarbeit versucht den Aufbau des Hochregallagers von Grund auf darzustellen. Dazu wird in Kapitel 2 ein Überblick über den Aufbau eines Hochregallagers geschaffen und Definitionen der grundlegenden Begriffe, die im Verlauf der Arbeit häufig
verwendet werden, gegeben. Dabei werden insbesondere die Funktionen der einzelnen
Komponenten eines Hochregallagers veranschaulicht.
Das darauf folgende Kapitel 3 beschreibt, welche Änderungen sich durch die Umstellung von RCX auf NXT Bausteine ergeben und wie diese sich auf den Aufbau und die
Programmierung des Hochregallagers auswirken.
Dabei wird sowohl auf die Programmierung als auch die mechanische Konstruktion eigegangen. Ein besonderes Augenmerk wird auf die von LEGO, und anderen Herstellern,
verfügbaren Sensoren und deren Anwendungsmöglichkeiten gelegt. Es wird dabei besonders versucht Bezug darauf zu nehmen, wie die Sensoren in den Komponenten des
Hochregallagers zum Tragen kommen.
In Kapitel 4 wird für die einzelnen Elemente des Hochregallagers die neue Konstruktion beschrieben.
Dazu wird der Aufbau der Komponenten beschrieben und darauf eingegangen, welche
Techniken und welche der, im vorherigen Kapitel beschriebenen, Sensoren zum Einsatz
kommen. Die detaillierten Aufbauanleitungen sind mit Hilfe entsprechender CAD Programme umgesetzt und auf der beiliegenden CD gesammelt.
Das anschließende Kapitel 5 beschreibt die neu entstandene Implementierung der
Steuerung.
Es wird damit begonnen den Aufbau der neu entstandenen Kommunikation darzustellen,
da diese von allen Elementen gemeinsam benutzt wird. Daraufhin wird die Implementierung des zur Steuerung und als Lagerverwaltungssystem benutzen NXT Bausteins
vorgestellt.
Im Weiteren wird auf die Umsetzung der Steuerung der restlichen Komponenten des
Hochregallagers eingegangen.
In Kapitel 6 werden mögliche Erweiterungen des Hochregallagers und deren Nutzen
vorgestellt.
Es wird darauf eingegangen wie zusätzliche, von dritten Herstellern vertriebenen, Sensoren dazu beitragen können, einzelne Komponenten des Hochregallagers weiter auszubauen. Desweiteren wird dargestellt, wie das Hochregallager mit einem komplexeren
Lagerverwaltungssystem kombiniert werden kann, um so realistischer zu arbeiten.
Das abschließende Kapitel 7 fasst die Ergebnisse der Arbeit und den erreichten Entwicklungsstand des Hochregallagers zusammen.
3
2 Definitionen
Dieses Kapitel gibt einen Überblick über die grundlegenden Begriffe, die im Verlauf der
Arbeit häufig verwendet werden. In Abbildung 2.1 ist der Aufbau eines Hochregallagers
schematisch gezeigt.
Es ist ein Regalbediengerät dargestellt, welches sich in einer Gasse zwischen zwei Regalen
bewegt und gerade dabei ist eine Lagereinheit mit einer beladenen Palette zu bestücken.
Abbildung 2.1: Ein Hochregallager mit Regalbediengerät
Lagersysteme können anhand verschiedener Kriterien aufgeteilt werden. Darunter fallen:
• Art der Ladeeinheiten (Paletten, Gitterboxen, etc.).
• Zum Einsatz kommende Regalkonstruktion.
4
KAPITEL 2. DEFINITIONEN
• Zur Lagerbedienung verwendete Hilfsmittel.
Das Hochregallager ist ein automatisiertes Palettenlager mit wahlfreiem Zugriff auf
das Lagergut. In einem solchen Zeilenlager wird die Bedienung durch Regalförderzeuge
(auch Regalbediengerät genannt) oder automatische Regalstapler durchgeführt. Dadurch, dass ein Hochregallager wahlfreien Zugriff auf das Lagergut gestattet, wird dieses
hauptsächlich zur Lagerung von großen Artikelzahlen mit geringem bis mittleren Bestand pro Artikel eingesetzt [lag83, SJ91].
Das in dieser Arbeit umgesetzte Lager entspricht einem Hochregallager mit Bedienung
durch automatische Regalbediengeräte.
Solche Lager werden seit den sechziger Jahren gebaut und haben die folgenden charakteristischen Merkmale:
• Die Ladeeinheiten (meist Paletten oder Gitterboxen) sind für die Aufbewahrungsdauer ortsfest, da Hochregallager zu den statischen Lagersystemen zählen.
• Die Regale sind meist zeilenförmig angeordnet und haben eine Höhe von mindestens 8m.
• Auf die Lagereinheiten kann wahlfrei zugegriffen werden.
• Die Lagerbedienung erfolgt mit Hilfe der automatischen Regalbediengeräte, welche
sich in der Regel in den Gassen zwischen den Regalzeilen bewegen.
Die für die Bestückung des Lagers zuständigen Regalbediengeräte können sich entlang
drei Achsen bewegen:
• x-Achse: Ganglängsrichtung (Fahreinheit)
• y-Achse: vertikale Richtung (Hubeinheit)
• z-Achse: Gangquerrichung (Lastaufnahmeeinheit)
Die Bestückung der Lagereinheiten kann durch unterschiedliche Konstruktionen geschehen, meist wird jedoch auf eine Gabel, ähnlich der eines Gabelstaplers zurückgegriffen.
Die Regalbediengeräte sind mit ausschlaggebend für die Umschlagleistung eines Hochregallagers. Von Wichtigkeit ist dabei deren mittlere Spielzeit für Einzel- und Doppelspiel. Das Einzelspiel beschreibt die Summe aller Zeiten für eine Ein- oder Auslagerung.
Das Doppelspiel beschreibt eine kombinierte Ein- und Auslagerung.
Bevor die Paletten von dem Regalbediengerät eingelagert werden können, müssen
sich diese in einer Position befinden, auf die das Regalbediengerät zugreifen kann. Dieser
Bereich wird im Allgemeinen Ein- und Auslagerungsbereich genannt, wobei die beiden
Bereiche nicht zwangsläufig miteinander übereinstimmen müssen.
5
KAPITEL 2. DEFINITIONEN
Die Anlieferung zu diesem Bereich kann je nach externen Gegebenheiten unterschiedlich
geschehen. Dieses kann z.B. von Kettenförderern, Rollenbahnen, Hub- und Drehtischen,
Vertikalförderern oder fahrerlosen Transportfahrzeugen übernommen werden.
In dem vorhandenen System wird dieses mit der Hilfe von autonomen Transportfahrzeugen (ATF) bewerkstelligt. Diese sind dafür zuständig die Ladeeinheiten in eine für die
Regalbediengeräte erreichbare Position zu befördern.
Ein ATF ist ein Fahrzeug mit Ladefläche für ein oder mehrere Ladeeinheiten, welches
auf Befehle des Lagerverwaltungssystems reagiert und selbstständig vorgegebene Positionen anfahren kann. Die Wegfindung wird dabei von dem ATF selbst vorgenommen und
kann mit Hilfe unterschiedlicher Systeme umgesetzt werden. Dieses kann zum Beispiel
mit Hilfe einfacher Schienenführungen oder Induktionsführungen geschehen, bei welchen
ein Leitdraht im Fußboden verbaut ist [hrl01].
Das ATF selbst bekommt die Ladeeinheiten von einer Übergabestation (UEG) aufgeladen. Der Aufbau einer solchen Übergabestation kann, entsprechend der benötigten
Funktionen, unterschiedlich ausfallen. Die Hauptaufgabe liegt darin das ATF zu be- und
entladen und die Ladeeinheiten, im Normalfall, auf einem anderen Transportmedium
abzusetzen.
Gesteuert wird ein solches Hochregallagersystem durch ein Lagerverwaltungssystem
(LVS), und bei komplexeren Systemen zusätzlich einem Materialflussrechner (MFR),
wobei diese Aufgabe auch von dem LVS übernommen werden kann.
Die Lagerung erfolgt normalerweise nach dem Prinzip der Chaotischen Lagerhaltung.
Dieses bedeutet, dass sich das System selbstständig einen freien Lagerplatz sucht, an welchem die Ladeeinheit eingelagert wird. Das Lagerverwaltungssystem ist dafür zuständig
diese Positionen zu speichern [lvs07].
6
3 RCX und NXT
Die Portierung des Hochregallagers von RCX zu NXT Bausteinen bringt eine Reihe von
neuen Möglichkeiten mit sich, birgt aber auch eine Menge Probleme. In diesem Kapitel
wird einen Vergleich der beiden Mindstorms Serien angestellt und darauf eingegangen,
wie die, für die Automatisierung notwendigen, Sensoren und Aktoren benutzt werden.
Im Jahr 1987 begann am MIT Media Laboratory1 die von LEGO gesponsorte Entwicklung eines programmierbaren Bausteines. Als Hauptentwickler entwarf Fred G. Martin2
zwischen 1987 und 1998 mehrere Versionen des programmierbaren Bausteines. Aus der
endgültigen Version, einem roten Baustein mit 4 Eingängen und 6 Ausgängen, wurde
das Robotics Invention System (RIS) entwickelt. Das Herz davon bildet der in Abbildung 3.1 dargestellte gelbe RCX Baustein, welcher allerdings nur 3 Eingänge (1-3) und
3 Ausgänge (A-C) besitzt.
Abbildung 3.1: Der RCX Baustein
2004 begann LEGO, unter der Leitung von Søren Lund, mit der Entwicklung des
Mindstorms NXT Kit. Dabei wurde darauf geachtet, möglichst geläufige Standards zu
1
2
http://www.media.mit.edu
http://www.cs.uml.edu/∼fredm/
7
KAPITEL 3. RCX UND NXT
verwenden. So kam es, dass der NXT Intelligent Brick über Bluetooth3 kommunizieren kann und die Sensoranschlüsse den Inter-Integrated Circuit4 Bus benutzen. Als die
Entwicklung begann hing Lund ein Schild, mit dem Satz
We will do for robotics what iPod did for music.“
”
in dem Entwicklungslabor auf. Der entstandene NXT Intelligent Brick (siehe Abbildung 3.2) hat tatsächlich von der Farbe und Menüführung Ähnlichkeiten mit dem iPod
[Bag07].
Abbildung 3.2: Der NXT Intelligent Brick
Die Mindstorms Komponenten werden, dank ihrer Einfachheit, Robustheit und Flexibilität, in vielen Schulen eingesetzt, um den Schülern Technologie näher zu bringen.
Die Produkte werden aber auch, wie bei diesem Hochregallager, von vielen Universitäten
genutzt, um komplexere Projekte umzusetzen.
3
4
http://www.bluetooth.com
http://www.i2c-bus.org
8
3.1. DIE PROGRAMMIERBAREN BAUSTEINE
3.1 Die programmierbaren Bausteine
Während die technische Ausstattung der programmierbaren RCX Bausteine noch relativ
spartanisch war, hat sich dieses bei denen der NXT Generation deutlich geändert. Um
die Leistungsmerkmale in Perspektive zu rücken, kann gesagt werden, dass die NXT Bausteine mehr als zehn mal so viel Speicher haben und dank der Co-Prozessoren ungefähr
sechs mal so schnell sind wie die RCX Bausteine. Ein genauer Vergleich der technischen
Daten ist in Tabelle 3.1 aufgeführt [Bag02, Bag07, rcx07].
Prozessor
Flash Memory
RAM
Co-Prozessor
Display
USB
Infrarot
Bluetooth
Sensoren
Aktoren
NXT
32-bit ARM7 48 MHz
256 KB
64 KB
8-bit AVR
100 x 64 Pixel LCD Matrix
12 MBit/s
mit optionalem Zubehör
Bluetooth Class II V2.0 compliant
4
3
RCX
8-bit 16 MHz
16 KB
32 KB
1-zeiliges Text Display
ja
3
3
Tabelle 3.1: Leistungsmerkmale der programmierbaren Bausteine.
Der NXT benutzt für die vier Eingänge das standarisierte, von Philips entwickelte
Inter-Integrated Circuit (I2 C) Protokoll. Dieses ermöglicht es, dass, mit Hilfe eines Expanders, mehr als nur vier Sensoren benutzt werden können. Diese müssen dafür lediglich
die Autodetecting Parallel Architecture (ADPA) benutzen.
Besonders hervorzuheben ist der Klasse 2 Bluetooth Chip (IEEE 802.15.1) der NXT
Bausteine. Dieser hat eine Reichweite von ungefähr 10m und ermöglicht es, dass zwei oder
mehr Geräte mit Bluetooth Unterstützung auch ohne direkten Sichtkontakt, miteinander
kommunizieren können. Dieses ist ein großer Vorteil gegenüber der Infrarotschnittstelle
der RCX Bausteine. Trotzt einer, im Gegensatz zu USB und WiFi, relativ langsamen
Geschwindigkeit ist Bluetooth für die meisten Anwendungsgebiete völlig ausreichend.
Ein weiteres Highlight ist das, mit 26,0mm ∗ 40,6mm, deutlich größere LCD Display.
Dieses ermöglicht es jetzt auch Menüs und sogar Icons darzustellen, während man vorher
nur an die Darstellung von wenigen Zeichen gebunden war. Dieses hat es ermöglicht ein
intuitives und einfach zu bedienendes Menüsystem für die Steuerung des Systems zu
implementieren (siehe Kapitel 5.2). Da das Display eine Refresh Rate von fast 60 Hz
hat, geht es so weit, dass sogar schon Spiele wie Tetris und Centipede auf den NXT
Baustein portiert wurden [BDD+ 07].
9
3.2. DIE AKTOREN
3.2 Die Aktoren
Die Motoren sind die einzigen in den Baukästen enthaltenen Aktoren. Für die neueren
NXT Baukästen wird es jedoch in Zukunft noch andere Motoren geben, welche zur Zeit
allerdings noch nicht verfügbar sind. Da es zwischen den beiden Generationen einige
signifikante Unterschiede gibt, werden diese hier darstellt.
3.2.1 Der RCX Motor
Der RCX Motor (siehe Abbildung 3.3) ist ein einfacher Motor, ohne besondere zusätzliche
Funktionen. Zur Steuerung des Motors kann nur die Drehrichtung angegeben werden.
Die Geschwindigkeit muss über eine entsprechende Umsetzung mit Hilfe von Zahnrädern
geregelt werden. Die wirkliche Drehgeschwindigkeit hängt jedoch sehr stark von Typ und
Ladezustand der benutzten Stromversorgung ab.
Abbildung 3.3: Der RCX Motor
Um genauere Informationen darüber zu erlangen, wie viele Umdrehungen der Motor
durchgeführt hat, muss der, wie in Kapitel 3.3.5 beschriebene, Rotations Sensor zur Hilfe genommen werden. Der große Nachteil dabei ist jedoch, dass bei der Benutzung von
drei Motoren, in vielen Fällen, auch drei Rotations Sensoren verwendet werden müssen.
Dadurch werden somit auch gleich alle Sensoreingänge verwendet und es bleibt keine
Möglichkeit noch weitere Sensoren an den selben RCX Baustein anzuschließen, wodurch
die Funktionalität der entstandenen Modelle oft deutlich eingeschränkt wird.
10
3.2. DIE AKTOREN
3.2.2 Der NXT Motor
Der neue NXT Motor (siehe Abbildung 3.4) hebt sich durch seine neuen Funktionen
deutlich von der alten Version ab. Die neue Form mag zwar etwas ungewöhnlich aussehen, aber der Motor bringt, trotz einer deutlichen Vergrößerung, einige entscheidende
Vorteile mit sich.
Abbildung 3.4: Der NXT Motor
Der Motor hat einen Tachometer, welcher mit Hilfe eines optischen Encoders umgesetzt wurde, und ein Getriebe für mehrere Geschwindigkeiten direkt eingebaut.
Dieses ermöglicht es zum Einen, den Motor viele Umdrehungen in unterschiedliche Richtungen durchführen zu lassen, und trotzdem zu der exakten Ausgangsposition zurückzukehren.
Die jeweils gewünschte Position kann auf das Grad genau angesteuert werden.
Zum Anderen ist es möglich eine bestimmte Drehgeschwindigkeit in Grad pro Sekunde
vorzugeben, wodurch oft auf komplizierte Kostruktionen mit vielen Zahnrädern verzichtet werden kann. Wird beispielsweise eine Geschwindigkeit von 720 festgelegt, so
entspricht dieses 2 Umdrehungen pro Sekunde. Die maximale Geschwindigkeit liegt bei
ungefähr 900 (2, 5 Umdrehungen pro Sekunde), ist aber stark abhängig von dem Ladezustand der benutzten Batterien [Bag07].
Auf Basis der neuen Funktionen des Motors lassen sich beispielsweise Fahrzeuge
mit Odometrie zur Positionsbestimmung umsetzten. Das autonome Transportfahrzeug
macht von diesem Verfahren intensiven Gebrauch. In Kapitel 5.5.3 ist dieses Verfahren
erläutert.
Dadurch, dass es mit Hilfe der neuen Features möglich ist die wirkliche Drehgeschwindigkeit des Motors zu ermitteln, kann dieses in vielen Fällen als zusätzlicher Sensor benutzt
werden. Weicht die wirkliche Drehgeschwindigkeit von der Gewünschten nach unten hin
ab, kann davon ausgegangen werden, dass der Roboter gegen ein Hindernis gefahren ist.
11
3.3. DIE SENSOREN
3.3 Die Sensoren
Die Sensoren dienen dazu Informationen aus der Umwelt für die Roboter erfassbar zu
machen.
Die Sensoren haben innerhalb der Baureihen alle die selben Ausmaße, lediglich der Ultrasonic Senor (siehe Abschnitt 3.3.4) weicht davon ab. Dadurch, dass auch die Befestigungsmöglichkeiten aller Sensoren übereinstimmen, lassen sich die Sensoren in den Modellen auch leicht gegeneinander austauschen. So ist es z.B. manchmal hilfreich den Licht
Sensor (siehe Abschnitt 3.3.2) gegen einen Farb Sensor von HiTechnic (siehe Abschnitt
3.3.6) auszutauschen, um Erweiterungen wie in Kapitel 6.3 beschrieben, zu ermöglichen.
3.3.1 Der Drucktaster
Die Drucktaster (oder Touch Sensoren) sind in den Abbildungen 3.5 (RCX Drucktaster)
und 3.6 (NXT Drucktaster) dargestellt. Sie sind die einfachsten, der in den Baukästen
enthaltenen, Sensoren. Sie bieten lediglich eine Abfragemöglichkeit, ob der Taster aktiviert ist, oder nicht.
Abbildung 3.5: Der RCX Drucktaster
Außer einer Anpassung der Bauform auf das neue Format und der damit verbundenen
Zunahme der Größe, sind diese beiden Sensoren weitgehend identisch. Der NXT Sensor
bietet nur die zusätzliche Möglichkeit an dem orangenen Taster eine Achse zu befestigen,
um andere Bauteile direkt mit dem Taster des Sensors zu verbinden.
Die Drucktaster sind eine einfache Möglichkeit um zu erkennen, wann eine bestimmte
Position eines beweglichen Bauteils erreicht wurde. Dieses wurde in dem Aufbau des
neuen Hochregallagers zum Beispiel dazu benutzt, mit dem Regalbediengerät und der
Übergabestation sicher eine Ausgangsposition für alle Achsen anfahren zu können.
12
3.3. DIE SENSOREN
Abbildung 3.6: Der NXT Drucktaster
3.3.2 Der Licht Sensor
Die Licht Sensoren (siehe Abbildungen 3.7 und 3.8) messen die Intensität des Lichts, welches durch eine kleine Öffnung an der Vorderseite eintritt. Die Sensoren sind zusätzlich
mit einer roten LED ausgestattet, welche dazu benutzt werden kann, den Bereich vor
dem Sensor auszuleuchten. Es ist mit den Sensoren auch möglich Licht, in für Menschen
unsichtbaren Bereichen, wie zum Beispiel Infrarot, wahrzunehmen.
Auch diese Sensoren wurden, außer der Anpassung der Bauform, keinen weiteren funktionalen Änderungen unterzogen.
Abbildung 3.7: Der RCX Licht Sensor
Die Sensoren können für viele verschiedene Bereiche eingesetzt werden. Besonders
geläufig sind dabei die Folgenden:
• Wenn man den Sensor auf den Untergrund richtet, kann er dazu benutzt werden
dunklen Linien zu folgen. Dieses wurde bei dem Aufbau des ATF (siehe Kapitel
4.4) umgesetzt.
• Der Sensor kann dazu benutzt werden Abgründe zu erkennen. Lässt man einen
Roboter auf einer Tischplatte umherfahren, kann ein auf den Boden gerichteter
13
3.3. DIE SENSOREN
Licht Sensor diesen vor dem Abstürzen bewahren. Wenn der Roboter dem Rand
des Tisches zu nahe kommt und der Licht Sensor schon über die Kante schaut, so
ändert sich die, von dem Sensor wahrgenommene Helligkeit merklich.
• Hellen Lichtquellen, wie etwa der Bewegung einer Taschenlampe, kann gefolgt werden.
• Es kann die hellste bzw. dunkelste Stelle im Raum gefunden werden. Hierdurch
lassen sich einfache Verhaltensweisen von Insekten nachbilden.
• Unterschiedliche Objekte können anhand ihrer Farbintensität (nicht Farbe) erkannt
werden. Dieses ist möglich, da dunkle Objekte weniger Licht reflektieren als hellere.
Abbildung 3.8: Der NXT Licht Sensor
Je nach Anwendungsbereich kann der Licht Sensor in zwei verschiedenen Modi betrieben werden:
• Aktiver Modus - Die LED ist eingeschaltet. Dieser Modus wird benutzt, um Linien
zu folgen und Objekte zu unterscheiden.
• Passiver Modus - Die LED ist ausgeschaltet. Dieser Modus kann benutzt werden,
um Umgebungslicht zu erkennen, aber auch wenn eine externe Lichtquelle zum
Einsatz kommt.
Die Licht Sensoren können einen Wert zwischen 0 und 1023 zurückgeben, die Werte
schwanken aber normalerweise zwischen 145 (Dunkelheit) und 890 (Sonnenlicht).
Zum einfacheren Umgang gibt es noch eine Methode, die Werte in einem normalisierten
Bereich von 0 bis 100 zurückliefert. Dafür ist es jedoch sinnvoll, den Sensor zuerst für
den aktuellen Einsatz und die Umgebungsverhältnisse zu kalibrieren. Dieses geschieht
durch einfache Aufrufe je einer Methode für den minimalen und maximalen Wert.
Diese Technik wurde bei dem autonomen Transportfahrzeug umgesetzt, so dass dieses,
unabhängig vom Umgebungslicht, sicher den Führungslinien folgen kann.
14
3.3. DIE SENSOREN
3.3.3 Der Sound Sensor
Der Sound Sensor (siehe Abbildung 3.9) ist einer der neuen Sensoren in den NXT Mindstorms Baukästen.
Obwohl dieser Sensor aussieht wie ein Mikrofon, wird nur die Lautstärke in Dezibel (dB)
gemessen, deshalb ist es nicht möglich damit Tonaufnahmen zu machen. Der Sensor kann
in zwei verschiedenen Modi betrieben werden. Im Standardmodus wird die Lautstärke
in dB zurückgegeben. Im Zweiten wird sie als A-Bewerteter Schalldruckpegel (dBA)
zurückgegeben, welcher den Frequenzgang des menschlichen Gehörs berücksichtigt.
Abbildung 3.9: Der NXT Sound Sensor
Der Sensor kann beispielsweise dazu benutzt werden Geräuschquellen zu finden oder
auf Klatschen zu reagieren.
3.3.4 Der Ultrasonic Sensor
Der Ultrasonic Sensor (siehe Abbildung 3.10) ist ein weiterer neuer Sensor in der NXT
Mindstorm Serie, der viele interessante Anwendungen ermöglicht.
Dieser Sensor wird dazu benutzt Entfernungen zu messen. Dazu wird ein, für Menschen
nicht wahrnehmbarer Ton ausgesandt und dann gemessen, wie lange es dauert bis dessen
Reflexion wieder empfangen wird. Da die Ausbreitungsgeschwindigkeit bekannt ist, kann
daraus die zurückgelegte Distanz berechnet werden.
Der Sensor ist dazu in der Lage Entfernungen bis zu 255 Zentimeter zu messen, die
Werte sind jedoch in dieser Entfernung relativ ungenau. Die besten Ergebnisse werden
zwischen 6cm und 180cm erlangt.
Die Entfernung wird in einem kegelförmigen Bereich gemessen. Der Kegel öffnet sich
in einem Winkel von ungefähr 30◦ , somit hat er bei einer Entfernung von 180cm einen
Durchmesser von ca. 90cm.
15
3.3. DIE SENSOREN
Abbildung 3.10: Der NXT Abstands Sensor
Eingesetzt wird dieser Sensor an der Front des Transportfahrzeuges, um den Bereich
vor diesem auf Hindernisse zu überprüfen. Wird ein Hindernis in einem zu geringen Abstand zu einem ATF wahrgenommen, hat dieses so die Möglichkeit vor diesem zu stoppen.
3.3.5 Der Rotations Sensor
Der Rotations Sensor (siehe Abbildung 3.11) ist einer der Sensoren, die in den NXT
Baukästen nicht mehr vorhanden sind und auch nicht mehr benötigt werden, da die
Funktionalität direkt in den neuen NXT Motoren integriert ist (siehe 3.2.2).
Abbildung 3.11: Der RCX Rotations Sensor
Eingesetzt wurde dieser Sensor, um Umdrehungen, der an diesen angeschlossenen
Achsen, zu zählen. Die Auslösung beträgt 16 Schritte pro Umdrehung. Somit ist die
Genauigkeit dieses Sensors deutlich geringer, als die des direkt in den NXT Motor
eingebauten[Hur06].
16
3.3. DIE SENSOREN
3.3.6 Produkte anderer Hersteller
HiTechnic
HiTechnic5 war die erste Firma, die mit LEGO einen Vertrag zur Vermarktung weiterer
Sensoren hatte. LEGO beliefert HiTechnic mit den Plastik Gehäusen, damit die Sensoren aussehen wie die eigenen, und verkauft diese auch über die LEGO Webseite. Durch
das selbe Aussehen sind diese die beliebtesten Sensoren von externen Herstellern. Um
Verwechslungen mit den Original Sensoren zu vermeiden, haben diese ein leicht anderes
Farbschema und sind an der Unterseite beschriftet.
Abbildung 3.12: Der HiTechnic Kompass Sensor
Zur Zeit umfasst die Palette der angebotenen Produkte:
• Kompass Sensor (siehe Abbildung 3.12)
• Color Sensor
• Tilt Sensor
• RCX Adapter Kabel
• IR Link mit RCX
• Infrarot Sucher
• Port Expander
• Motor Multiplexer
• NXT Prototype Board
Mindsensors
Mindsensors6 bietet eine breite Palette an Sensoren an. Diese sind allerdings nicht in
den üblichen Plastikformen, werden dafür aber mit extra Kabeln geliefert.
5
6
http://www.hitechnic.com
http://www.mindsensors.com
17
3.3. DIE SENSOREN
Mindsensors liefert zur Zeit die folgenden Produkte:
• RCX zu NXT Kommunikations Adapter
• Neigungs Sensor
• RCX Motor Multiplexer
• Kompass Sensor
• Sony PS2 Controller Interface
• Pneumatics Pressure Sensor
• Infrarot Abstands Sensor
• RCX zu NXT Anschluss Adapter
• NXT Motor Multiplexer
Vernier
Vernier7 stellt Sensoren nicht speziell für Mindstorms her, bietet aber einen Adapter,
um die Sensoren mit den NXT Bausteinen zu verbinden. Vernier vertreibt einige, für die
Benutzung mit LEGO Mindstorms Produkten einzigartige, dafür aber oft recht teuere
Sensoren.
Es werden weit über 40 verschiedene Sensoren angeboten, darunter:
• pH Probe
• Low-g Accelerometer
• Conductivity Probe
• Dissolved Oxygen Sensor
• UV Sensor
• Temperature Probe
• Magnetic Field Sensor
7
http://www.vernier.com/nxt/
18
3.4. PROGRAMMIERUNG
3.4 Programmierung
Zur Programmierung der LEGO Mindstorms Module gibt es eine Reihe verschiedener
Möglichkeiten. Die sicherlich Einfachste ist die Benutzung der mitgelieferten grafischen
Entwicklungsumgebung NXT-G (siehe 3.4.1). Für fortgeschrittene Projekte ist es jedoch
oftmals sinnvoll auf eine der vielen anderen Möglichkeiten, wie z.B leJOS (siehe 3.4.2)
oder RobotC8 zurückzugreifen.
3.4.1 NXT-G
Die texanische Firma National Instruments hat in Zusammenarbeit mit LEGO eine Entwicklungsumgebung für die LEGO Mindstorms NXT geschaffen, die auf der grafischen
Entwicklungsplatform LabVIEW9 (Laboratory Virtual Instrumentation Engineering
Workbench) basiert.
Abbildung 3.13: Die NXT-G Entwicklungsumgebung
8
9
http://www.robotc.net
http://www.ni.com/labview/
19
3.4. PROGRAMMIERUNG
Die NXT-G genannte Software wird in zwei verschiedenen Versionen ausgeliefert. Es
gibt die normale Verkaufsversion und die in Abbildung 3.13 dargestellte Educational
Version, welche speziell für den Gebrauch in Schulen angepasst ist.
Die von LabVIEW benutzte grafische Programmiersprache wird ‘G’ genannt und
ermöglicht es, Programme in Form von Datenflussgraphen darzustellen.
Die Programmierung geschieht über das Ziehen von vorgefertigten Programmblöcken in
den Programmierbereich. Jeder dieser Blöcke ist prinzipiell eine Funktion, für die der
Benutzer mehrere Parameter mit Hilfe von Schiebereglern und Eingabefeldern festlegen kann. Außerdem können so selbst komplexere Blöcke mit Hilfe der Software erstellt
werden, wodurch es möglich ist viel Programmcode in einem kleinen grafischen Fenster
darzustellen.
Da die Software durchgängig gewartet wird, können neue Blöcke aus dem Internet
heruntergeladen und importiert werden, wenn neue Sensoren und Aktoren für die LEGO Mindstorms zur Verfügung stehen.
Die grafische Programmierung ist relativ einfach zu verstehen und somit gut geeignet
für Personen mit wenig Programmiererfahrung. Wenn man jedoch Programmiersprachen
wie Java gewöhnt ist, sind einige der Paradigmen der Programmierumgebung schwer zu
verstehen. Außerdem ist es problematisch mit Hilfe der grafischen Oberfläche Programme zu erstellen, die eine gewisse Größe überschreiten.
3.4.2 leJOS
leJOS ermöglicht es, Programme für die RCX und NXT Bausteine in Java zu entwickeln. Dafür stehen unterschiedliche verschiedene Versionen der zu leJOS gehörenden
Java Virtual Machine (JVM) und Bibliothek zur Verfügung.
Zum Einen gibt es das, mittlerweile sehr ausgereifte, leJOS RXJ, welches aktuell in der
Version 3.0 zur Verfügung steht und für die RCX Module bestimmt ist. Zum Anderen
gibt es leJOS NXJ für die NXT Module, welches relativ neu ist und noch nicht alle
Features der programmierbaren NXT Bausteine unterstützt. Dieses steht im Moment
erst in der frühen Beta Version 0.4 zur Verfügung.
Die Java Virtual Machine
Die leJOS Java Virtual Machine basiert auf der in C geschriebenen TinyVM10 , bei der
darauf geachtet wurde, die Codebasis möglichst plattformunabhängig zu halten. Dieses
ermöglicht es der VM auf den RCX und NXT Bausteinen, so wie dem Nintendo GameBoy Advance11 zu laufen.
10
11
http://tinyvm.sourceforge.net
http://www.gameboy.com
20
3.4. PROGRAMMIERUNG
Die leJOS NXJ Plattform ist essenziell eine Erweiterung derer für RCX. leJOS NXJ
wird als eigenständiges Projekt weiterentwickelt, um nicht auf Kompatibilität für die
RCX Bausteine achten zu müssen.
Auf den RCX Bausteinen verbraucht die VM alleine ungefähr 16KB des Speichers, was
nur noch 16KB für eigenen Programmcode übrig lässt. Dank des großzügigeren Speicherausbaus bleiben auf den NXT Bausteinen noch ungefähr 229KB verfügbar, obwohl die
VM dort ganze 27KB Speicherplatz benötigt.
Die leJOS VM unterstützt viele Features einer gewöhnlichen Java Virtual Machine,
wie z.B. der von Sun12 . Darin enthalten sind:
• Preemptive Threads - Die leJOS VM ermöglicht die Benutzung von Threads mit
Unterstützung für Synchronisierung und Interrupts. Der dazugehörige Scheduler
arbeitet auf eine denkbar einfache Weise und lässt jeden Thread 128 Instruktionen
ausführen, bevor zum nächsten Thread gewechselt wird. Theoretisch können bis
zu 255 Threads gleichzeitig benutzt werden, allerdings ist dafür der verfügbare
Speicher nicht ausreichend groß genug.
• Arrays - Es werden sogar multdimensionale Arrays. Macht man jedoch einen zu
umfangreichen Gebrauch von multidimensionallen Arrays, dann verbrauchen diese
zu viel Speicher und die VM stürzt ab.
• Rekursion - Wie die meisten Programmiersprachen unterstützt auch Java Rekursionen. Die leJOS VM kann zur Zeit allerdings nur Rekursionen bis zu einer Tiefe
von 10 ausführen.
• Exceptions - leJOS unterstützt, wie jede andere JVM auch, den Gebrauch von
Exceptions.
• Event Model - Das Event Model von Java wird auch von leJOS unterstützt. Dieses ermöglicht es auf, von Sensoren oder den Knöpfen an den NXT Bausteinen,
ausgelöste Events zu reagieren.
• float, long, String - leJOS unterstützt viele Java Typen. Um Speicher zu sparen
wird jedoch darauf verzichtet, 64bit Typen wie double und long vollständig zu
unterstützten. Die beiden Typen können benutzt werden, die VM verwaltet diese
aber intern als 32bit floats.
Allerdings hat die leJOS VM einige wichtige Einschränkungen, die umfangreichere
Probleme noch deutlich verkomplizieren oder den Code einfach nur schwerer lesbar machen:
12
http://java.sun.com
21
3.4. PROGRAMMIERUNG
• Garbage Collector - Eine JVM entfernt normalerweise Objekte aus dem Speicher,
die nicht mehr benötigt werden. Dieses geschieht durch einen automatischen Garbage Collector.
In der aktuellen VM von leJOS ist dieses noch nicht der Fall und führt, besonders
bei längerer Programmausführung, zu Abstürzen. Dieser Punkt hat eine hohe Priorität auf der Liste der leJOS Entwickler und es kann davon ausgegangen werden,
dass diese Funktion in einer der nächsten Versionen enthalten sein wird.
• switch-Statements - die leJOS VM unterstützt keine switch Statements. Diese Unzulänglichkeit kann durch den Gebrauch von if und else if umgangen werden,
führt aber zu einer deutlich schlechteren Lesbarkeit des Programmcodes.
• Klassen Größe - Java Klassen können zur Zeit eine maximale Größe von 64Kb
haben. Diese Grenze ist sehr schnell erreicht und nicht immer elegant zu umgehen
und hat vor allem bei der Entwicklung eines Menüsystems für die NXT Bausteine
Probleme verursacht.
Trifft man auf eine der angedeuteten Einschränkungen, wird man davon meist schon,
bei dem vor der Übertragung des Programmcodes auf den NXT Baustein notwendigen,
linking Vorgang mit der folgenden Meldung darauf hingewiesen:
leJOS NXJ> Linking...
The following features/conditions are currently unsupported:
- Switch statements.
- Integer increment constant too large. (If > 255, declare it).
- Arithmetic or logical operations on variables of type long.
- Remainder operations on floats or doubles.
- Too many constants or locals ( > 255).
- Method code too long ( > 64 Kb!).
Die Java Bibliothek
Die, in den beiden Versionen des leJOS Paketes enthaltenen Java Bibliotheken sind, zumindest größtenteils, gut dokumentiert und bieten einen großen Umfang an Funktionen
an.
Die Robotik APIs der RCX und NXJ Versionen sind jedoch vom Aufbau her unterschiedlich und nicht miteinander kompatibel. Dieses kommt zum Einen daher, dass die
neuen Sensoren und Aktoren teilweise einen andern Funktionsumfang haben, aber auch
daher, dass die Kommunikationsmöglichkeiten grundlegend verschieden sind.
Da es möglich ist, mit der Hilfe von Adaptern, die RCX Motoren und Sensoren an den
NXT Bausteinen zu verwenden, stehen für diese Elemente spezielle RCX Klassen zur
Verfügung.
22
3.4. PROGRAMMIERUNG
An sich ist die Robotik API von leJOS NXJ relativ komplett und ermöglicht es, die
meisten Funktionen der Sensoren in vollem Umfang zu nutzen. Viele Probleme gibt es
jedoch noch in dem Bereich der Kommunikation, insbesondere mit Bluetooth. Einige
dieser Probleme stammen daher, dass der in den NXT verbaute BC4 Chip zwei Modi
hat, zwischen denen umgeschaltet werden muss:
• Command Mode - In diesem Modus können neue Verbindungen hergestellt werden
und nach anderen Bluetooth Geräten gesucht werden.
• Data Mode - Dieser Modus ermöglicht das Senden und Empfangen von Daten an
bereits verbundene Bluetooth Geräte.
Die Umschaltung zwischen den beiden Modi funktioniert in der Version 0.4 noch nicht
sicher und führt zu vielen Abstürzen des NXT Bausteines. Daher ist es mit dieser Version auch nur möglich eine Bluetooth Verbindung zu einem anderen Gerät aufzubauen.
In aktuellen Versionen aus dem Subversion Repository ist es möglich, Verbindungen zu
mehreren Geräten herzustellen. Da aber die Umschaltung zwischen den beiden Modi
auch dort noch nicht richtig funktioniert, ist es danach nicht immer möglich zu allen
verbundenen Geräten Daten zu senden. In der kommenden Version 0.5 von leJOS NXJ
soll dieses Problem aber voraussichtlich behoben sein.
Die Packages lejos.navigation und lejos.subsumption bieten einige Klassen an, die
häufig benutzte Konzepte der Robotik zusammenfassen. So ist es möglich viele Modelle ohne großen Programmieraufwand zu sinnvollen Aktionen zu überreden. Leider sind
auch hier noch einige Bugs enthalten, welche besonders bei dem ATF aufgefallen sind
und umgangen werden mussten.
Zusätzlich sind einige Komponenten des standardisierten javax.microedition Packages
in leJOS enthalten. In diesem Packet ist vor allem die Ansteuerung des LCD-Displays
und der vier Buttons der NXT Bausteine umgesetzt.
23
4 Konstruktion
Die Portierung des Gesamtsystems besteht im wesentlichen aus zwei Blöcken.
Im Ersten muss die Konstruktion der Komponenten des Hochregallagers auf die neue
Bauweise übertragen werden. Der Zweite besteht daraus, die Steuerung entsprechend
der neuen Gegebenheiten anzupassen.
Begonnen wird damit die bestehenden Komponenten des alten Hochregallagers zu
erläutern und darauf einzugehen, welche Änderungen für den Neuaufbau umgesetzt werden. Daraufhin wird die Konstruktion und der Einsatz der dabei benutzten Motoren und
Sensoren im Einzelnen geschildert.
Durch die nötige Änderung der Konstruktionsweise der LEGO Modelle auf die neue
studd-less Bauweise der Mindstorms NXT, müssen alle Komponenten des Systems von
Grund auf neu aufgebaut werden. Dieses ist notwendig, damit die neuen NXT Motoren,
Sensoren und programmierbaren Bausteine benutzt werden können.
Es wird dabei versucht die in Kapitel 3 beschrieben Sensoren bestmöglich einzusetzen,
um von der neuen Funktionalität Gebrauch machen zu können und Probleme zu vermeiden, die der bestehende Aufbau in sich birgt.
Der Aufbau in der studd-less Bauweise ermöglicht es einige Komponenten der Modelle
sehr kompakt, aber trotzdem funktional und stabil zu konstruieren [Mar95]. Ein besonders gutes Beispiel dafür ist die in Abschnitt 4.2.2 beschriebene Hubeinheit.
Das bestehende Hochregallagersystem (siehe Abbildung 4.1) ist aus mehreren Transportfahrzeugen, Regalbediengeräten und Übergabestationen zusammengesetzt.
Pro ATF und Übergabestation wurde je ein programmierbarer RCX Baustein und je
Hochregal (Regalbediengerät und die dazugehörige Übergabestation) zwei programmierbare RCX Bausteine verwendet.
Dieses stammt daher, dass das Regalbediengerät für jede der drei Bewegungsrichtungen
einen Motor benötigt und die Übergabestation zusätzlich einen. Somit wurden zwei RCX
Programmierbausteine benötigt, da jeder dieser Bausteine nur drei Motoren ansteuern
kann.
Da die NXT Bausteine auch nur Anschlussmöglichkeiten für drei Motoren haben, wurde versucht die Paletten direkt mit Hilfe des Regalbediengerätes von der Ladefläche zu
entnehmen. Auf diese Weise kann auf einen NXT Baustein und den damit verbundenen
zusätzlichen Kommunikationsaufwand verzichtet werden.
24
KAPITEL 4. KONSTRUKTION
Abbildung 4.1: Das RCX Hochregallager
Durch diese Schritte war es möglich bei den Transportfahrzeugen auch auf einen der
Motoren zu verzichten, da die Ladefläche so ohne bewegliche Teile umgesetzt werden
konnte und keinen Motor benötigt, der das Förderband der Ladefläche antreibt. Zudem
wird, durch den Verzicht auf einen weiteren Motor, die Bauweise des ATF relativ kompakt gehalten.
Die Übergabestation wurde komplett überarbeitet und dem Regalbediengerät vom Aufbau her angeglichen.
Außerdem wurden alle Komponenten noch mit zusätzlichen Sensoren, vor allem Drucktastern, ausgestattet. Die genauen Hintergründe dafür werden in den jeweiligen Abschnitten der Komponenten verdeutlicht.
Auf der beigelegten CD sind alle Konstruktionsanleitungen und Stücklisten, in detaillierter Form, als pdf und ldraw -Datei abgelegt. Kapitel B.1 beinhaltet eine Liste der
benutzen Anschlussbelegungen der einzelnen Modelle.
Die Konstruktionsanleitungen wurden mit Hilfe der LDraw1 Biblothek und den darauf
basierenden CAD Programmen Bricksmith2 und MLCad3 erstellt.
1
http://www.ldraw.org
http://bricksmith.sourceforge.net
3
http://www.lm-software.com/mlcad/
2
25
4.1. DAS HOCHREGAL
4.1 Das Hochregal
Das Hochregal (siehe Abbildung 4.2) ist der eigentliche Lagerort für die Paletten und
stellt eine einfache Konstruktion ohne bewegliche Teile dar.
In der aktuellen Ausbaustufe stehen insgesamt 16 Lagerplätze für Paletten in 4 Zeilen und 4 Spalten zur Verfügung. Dieses ist die einzige Komponente, deren Aufbau
größtenteils von dem bestehenden Aufbau übernommen werden konnte. Das Regalgerüst entspricht dem des alten Hochregallagers (vgl. Abbildung 4.1). Es wurden nur
die Führungsschienen für das neue Regalbediengerät angepasst.
Die Paletten wurden unverändert von dem bestehenden Modell übernommen.
Abbildung 4.2: Das Hochregal
Das Regal ist durch den simplen, aber trotzdem robusten, Aufbau sehr einfach in
der Größe veränderbar. Wichtig ist, dass alle Lagerplätze eine einheitliche Größe und
Abstand zu einander haben. Bei einer Änderung der Anzahl der Ladeeinheiten muss der
Steuerung somit lediglich mitgeteilt werden, wie viele Zeilen und Spalten zur Lagerung
von Paletten zur Verfügung stehen.
26
4.2. DAS REGALBEDIENGERÄT
4.2 Das Regalbediengerät
Das alte Regalbediengerät benutzt drei Motoren, einen für jede der drei nötigen Bewegungsrichtungen. Damit der Steuerung die aktuelle Position bekannt ist, sind zusätzlich
drei Rotationssensoren verbaut und somit alle Anschlüsse des RCX Bausteins belegt.
Das RCX RBG arbeitet mit einer Übergabestation zusammen, welche als Ein- und Auslagerungsbereich dient. Die UEG benötigt zusätzlich noch einen Motor und einen RCX
Baustein.
Wie schon früher erwähnt, soll das neue RBG in der Lage sein die Paletten direkt
von der Ladefläche des ATF, ohne den Umweg über eine UEG, entnehmen zu können.
Dieses ist möglich, da das neue RBG deutlich stabiler konstruiert ist und so eine längere
Lastaufnahmeeinheit benutzen kann.
Als weitere Verbesserung wurde das Regalbediengerät für alle drei Bewegungsrichtungen
mit einem Drucktaster (siehe Kapitel 3.3.1) ausgestattet, um zu ermöglichen in eine, zur
Initialisierung dienende, Grundposition zu fahren. Von dieser Position aus sind die Wege
zu allen anderen anfahrbaren Positionen bekannt, bzw. leicht errechenbar.
Der Einsatz der Taster ist möglich geworden, da die NXT Motoren über den eingebauten Tacho verfügen und somit nicht mehr, auf den zusätzlichen Rotations Sensor
zurückgreifen müssen. Hierdurch sind die benötigten Sensoranschlüsse an den NXT Bausteinen frei geworden.
Das Regalbediengerät (siehe Abbildung B.2) besitzt die komplizierteste mechanische
Konstruktion aller Komponenten. Es besteht im Wesentlichen aus drei zusammenarbeitenden Teilen, welche jeweils für eine der drei Bewegungsrichtungen zuständig sind.
4.2.1 Die Fahreinheit
Die Fahreinheit (siehe Abbildung 4.3) ist dafür zuständig das Regalbediengerät in die
gewünschte Position in der x -Richtung zu bewegen. Dadurch lässt sich eine Position für
das ATF und jede Spalte des Regals anfahren. Auf der Bodenplatte des Hochregals (siehe Abbildung 4.2) sind Führungsschienen montiert, welche für einen sicheren Halt der
Fahreinheit garantieren.
Zur Fortbewegung benutzt die Fahreinheit vier 40-zähnige Zahnräder, welche alle über
einen gemeinsamen Motor angetrieben werden. Die Zahnräder sind an einer Bodenplatte
befestigt, auf welcher der Mast aufgesetzt ist. Der Mast besteht aus vier Säulen, wobei,
an den beiden zum Regal zeigenden Säulen, auf der Innenseite verzahne Bausteine angebracht sind.
An der Fahreinheit ist ein Drucktaster befestigt, welcher erkennt, wann die Ausgangsposition erreicht ist. Die Ausgangsposition ist zugleich die Position, von der aus das
Transportfahrzeug be- und entladen wird.
27
Abbildung 4.3: Die Fahreinheit
4.2.2 Die Hubeinheit
Die Hubeinheit (siehe Abbildung 4.4) ist dafür zuständig die Lastaufnahmeeinheit auf
die gewünschte Höhe (y-Richtung) zu bewegen.
Üblicherweise wird die Bewegung in y-Richtung durch einen auf Bodenebene montierten
Motor vollzogen, der ein Stahlseil auf einer Winde auf oder ab wickelt. An dem Stahlseil
ist wiederum die Hubeinheit befestigt.
Etwas ähnliches wurde versucht in dem alten Model umzusetzen. Die Positionierung war
dadurch jedoch auf Grund der Bauweise relativ ungenau und die Lastaufnahmeeinheit
sehr wackelig in der Positionierung. Um dieses Problem zu umgehen, wurden Bausteine
mit Zähnen vertikal an den Masten des Regalbediengerätes angebracht. Entlang dieser
können sich dann Zahnräder auf beiden Seiten auf und ab arbeiten. Durch diese Methode
ließ sich ein kompakter, aber trotzdem mechanisch stabiler Aufbau realisieren. Entlang
des Mastes wird die Hubeinheit sicher geführt, da der Mast vollständig umschlossen wird.
Zusätzlich verfügt die Hubeinheit über zwei Drucktaster, so wie eine Führung und den
Antrieb für die Lastaufnahmeeinheit. Der an der Unterseite der Hubeinheit befestigte
28
Abbildung 4.4: Die Hubeinheit
Drucktaster ist dafür zuständig, zu erkennen, wann die Lastaufnahmeeinheit vollständig
eingefahren ist. Der an dem, für den Hub zuständigen, Motor befestigte Drucktaster
erkennt, wann die Hubeinheit ganz nach unten gefahren ist.
4.2.3 Die Lastaufnahmeeinheit
Die Lastaufnahmeeinheit (siehe Abbildung B.3) ist für die Bewegung in die z -Richtung
zuständig. Der Aufbau erinnert sehr an den der Gabel eines Gabelstaplers und auch die
Funktion entspricht diesem.
Primär ist die Lastaufnahmeeinheit so weit wie möglich eingefahren. Denn nur wenn die
Lastaufnahmeeinheit sich in dieser Position befindet, kann sich das Regal ungehindert
auch in x und/oder y-Richtung bewegen. Zusätzlich gibt es eine Position zum bedienen
des Hochregals und eine weitere zum bedienen des Autonomen Transportfahrzeugs.
Ähnlich der Bauweise der Hubeinheit wird die Kraft des an der Hubeinheit angebrachten
Motors der Lastaufnahmeeinheit mittels eines Zahnrades auf die Bausteine mit Zähnen
übertragen. Der Unterschied besteht jedoch hier darin, dass in diesem Fall das Zahnrad
fest positioniert ist und dadurch die Lastaufnahmeeinheit, an der die bezahnten Bausteine befestigt sind, vor und zurück schiebt.
Der Aufbau der Lastaufnahmeeinheit wird so durchgeführt, dass diese genau in die dafür
vorgesehene Führung der Hubeinheit passt, sich aber trotzdem leicht bewegen lässt.
29
4.3. DIE ÜBERGABESTATION
4.3 Die Übergabestation
Der Aufbau der neuen Übergabestation (siehe Abbildung 4.5) unterscheidet sich signifikant von dem in dem bestehenden RCX Model. Zuvor wurde die Übergabe der Paletten zwischen der Übergabestation und dem Transportfahrzeug mit Hilfe einer Art
Förderband vollzogen. Zwischen der Übergabestation und dem ATF war jedoch immer
eine Lücke, über die die Paletten befördert werden mussten, wodurch die Paletten unsicheren Halt hatten, bzw. sich leicht verkannten konnten. Zusätzlich wurde auch auf dem
ATF ein Förderband benötigt, um das Be- und Entladen zu bewerkstelligen.
Aus diesen Gründen wurde die Bauweise des Regalbediengerätes, in einer etwas abgeänderten Form, für die Übergabestationen verwendet. Die Übergabestation benötigt
nur die Bewegungsfreiheit in y und z -Richtung, womit auf eine Fahreinheit verzichtet
werden kann. Somit konnten die in Kapitel 4.2.2 und 4.2.3 beschriebenen Hub- und Lastaufnahmeeinheiten des Regalbediengerätes übernommen werden. Der Mast der Fahreinheit wurde direkt auf einer Bodenplatte stationär befestigt.
Abbildung 4.5: Die Übergabestation
30
4.4. DAS AUTONOME TRANSPORTFAHRZEUG KAPITEL 4. KONSTRUKTION
4.4 Das Autonome Transportfahrzeug
Die alten RCX Transportfahrzeuge benutzen zur Steuerung einen RCX Baustein, drei
RCX Motoren, so wie zwei RCX Lichtsensoren. Von zwei der Motoren wird der Antrieb
bewerkstelligt, der Dritte ist für die Steuerung der Ladefläche zuständig. Von den Lichtsensoren ist einer für die Erkennung der Fahrbahnline, der Andere zur Erkennung von
zusätzlichen Markern auf der Fahrbahn im Einsatz.
Abbildung 4.6: Das Autonome Transportfahrzeug
Die alten ATFs sind aufgrund der kleinen Bauteile sehr kompakt und ließen sich daher
leider nicht in dieser Form mit Hilfe der Mindstorms NXT Bausteine umsetzten.
Wie bei dem vorherigen Modell wurde auf eine dreirädrige Bauweise mit automatisch
einlenkendem Hinterrad umgesetzt. Dieses hat den Vorteil, dass wenig Reibung bei der
Kurvenfahrt auftritt und dadurch die Odometrie bei der Positionsbestimmung zu Hilfe
genommen werden kann. Da der Antrieb durch die, unabhängig von einander steuerbaren, Vorderräder geschieht, ist es mit dem ATF (siehe Abbildung 4.6) sogar möglich auf
31
4.4. DAS AUTONOME TRANSPORTFAHRZEUG KAPITEL 4. KONSTRUKTION
der Stellte zu wenden.
Dank der Bauweise der Übergabestationen und Regalbediengeräte konnte auf den dritten Motor zum übergeben der Paletten verzichtet werden. Dieses hat gerade bei den
deutlich größer gewordenen Motoren Vorteile und spart eine Menge an der Größe des
Transportfahrzeuges ein.
An der Front besitzt das ATF, genau wie das alte Modell, zwei Lichtsensoren. Zusätzlich
wurde zwischen den beiden Lichtsensoren ein Ultraschallsensor zur Abstandsmessung
verbaut. Dieser wird dazu benutzt um Hindernisse zu erkennen und dadurch Unfälle zu
vermeiden.
Für das alte Modell war vorgesehen, dass ein ATF, bevor ein bestimmter Streckenabschnitt befahren werden konnte, nach einer Genehmigung von der Steuerung dafür fragt.
Der Code bestand jedoch nur aus Platzhaltern und wurde nie implementiert. Um den
Nachrichtenverkehr möglichst gering und die Implementierung simpel zu halten, wurde
auf derartige Abfragen komplett verzichtet und dieses Problem durch den neuartigen
Sensor gelöst.
32
4.5. DIE FAHRBAHN
4.5 Die Fahrbahn
An der Fahrbahn (siehe Abbildung 4.8) wurde vom Layout her keine wesentlichen
Veränderungen vorgenommen. Die Strecke besteht weiterhin aus einem Oval mit mehreren Abzweigungen zu Parkplätzen, Übergabestationen und Regalbediengeräten. Die die
Orientierung für das ATF benötigten Führungslinien bestehen auch weiterhin aus einem
Farbverlauf von hellgrau bis schwarz und es gibt auch weiterhin schwarze Marker, die
dem ATF genaue Informationen über den aktuellen Standpunkt geben.
Abbildung 4.7: Der Initialisierungsbereich für das ATF
Neu hinzugekommen ist ein Initialisierungsbereich (siehe Abbildung 4.7), an der unteren rechten Ecke der Fahrbahn. Dieser wird dazu benutzt die Lichtsensoren des ATF auf
die benutzen Markierungsfarben und aktuellen Umgebungsbeleuchtungen zu justieren.
So wird eine genauere Positionierung und sicherere Linienerkennung gewährleistet.
Der Initialisierungsbereich besteht prinzipiell aus drei großen Rechtecken in verschiedenen Farben. Zur Initialiserung wird ein ATF mit den beiden Licht Sensoren mittig zu
dem Initialisierungsbereich, mit den Licht Sensoren auf der schwarzen Umrandungslinie
platziert. Das ATF fährt dann selbstständig über den weißen Bereich speichert den dort
ermittelten Wert dann als Maximalwert (100%), da der weiße Untergrund am meisten
Licht reflektiert. Daraufhin fährt das ATF mit den Sensoren in den schwarzen Bereich
und benutzt den dort ermittelten Wert wird als Minimalwert (0%) kalibriert. Als letztes
wird der Wert des grauen Rechteckes eingelesen. Dieses ist der Wert entspricht dem der
Führungslinie, der gefolgt werden soll. Dieser Wert liegt bei etwa 60% − 65%.
Eine weitere Änderung der Fahrbahn ist, dass über die gesamte Karte ein Koordinaten System gelegt wurde. Je nach Größe des Ausdruckes, im Idealfall 100cm ∗ 200cm,
33
4.5. DIE FAHRBAHN
entspricht eine Einheit des Koordinatensystems 1cm. Alle 10cm ist eine dünnes graues
Raster eingezeichnet und alle 50cm ein Raster aus dicken schwarzen Linien, welche als
Marker genutzt werden.
Die Richtung der Achsen des Koordinatensystems und die von dem ATF genutzten Winkel für die Fahrtrichtungen sind in einer Legende in der unteren linken Ecke der Fahrbahn
eingezeichnet.
Das schwarze Raster wird von dem ATF, zusätzlich zu der Odometrie, zur genauen Positionsbestimmung genutzt. Durch diese Kombination ist es möglich, ein ATF direkt an
eine beliebige Position durch die Angabe von x und y-Koordinate und einen Winkel zu
senden.
0◦
x
−90◦
90◦
y
180◦
Abbildung 4.8: Die Fahrbahn
Zur Erstellung der alten Fahrbahnen wurde der Roads Untergrundeditor4 von Jörg
Schmalzbauer und Olaf Scheel entwickelt. Versuche, diesen für die Erstellung der neuen
Fahrbahn zu benutzen, schlugen leider fehl, da der Editor leider nicht stabil gearbeitet
hat und reproduzierbar abgestürzt ist.
Aus diesem Grund wurde die neue Fahrbahn mit Hilfe von LATEX5 und dem Packet
PSTricks6 erstellt. Dieses funktioniert problemlos und man erhält den Untergrund als
verlustfrei skalierbare pdf -Datei, die deutlich weniger Speicher verbraucht als etwa eine
png-Datei mit den selben Ausmaßen.
4
http://ddi.uni-paderborn.de/software/roads-untergrundeditor.html
http://www.latex-project.org
6
http://tug.org/PSTricks/
5
34
5 Implementierung
Eine der Hauptaufgaben dieser Arbeit ist es, die Steuerung des Hochregallagersystems
von leJOS RCX nach leJOS NXJ zu portieren. Dieser Arbeitsschritt wird in diesem Kapitel ausführlich beschrieben.
Dadurch, dass die Elemente des Hochregallagers, durch die neu eingesetzten Bauteile,
größtenteils anders funktionieren als die RCX Modelle und auch die leJOS Bibliothek
sich grundlegend geändert hat, macht es nicht viel Sinn große Teile des bestehenden
Quellcodes zu übernehmen.
Der Großteil des bestehenden Quellcodes, für das RCX Hochregallager, ist für die
umständliche Kommunikation über die Infrarotschnittstelle zuständig. Für diese Kommunikation wurde ein eigenständiges Protokoll mit einem Tokenmanager implementiert.
Da die Kommunikation zwischen den NXT Bausteienen auf Bluetooth basiert, musste
dieser Teil vollständig verworfen werden.
Auch die Implementierung des ATF hat sich grundlegend geändert, da auf, in der leJOS
NXJ Bibliothek, vorhandene Klassen zur Navigation zurückgegriffen werden konnte. Diese machen intensiven Gebrauch von den Möglichkeiten der neuen NXT Motoren.
Ähnlich verhält es sich mit dem Aufbau des Regalbediengerätes und der Übergabestation.
Da diese beiden Geräte ohne die zusätzlichen Rotatoinssensoren auskommen, dafür aber
Drucktaster einsetzen, musste die Steuerung komplett anders aufgebaut werden.
Zusätzlich wurde eine Steuerungssoftware entwickelt, mit deren Hilfe über einen NXT
Baustein die Aktionen des Hochregallagers steuerbar sind.
In Abschnitt 5.1 wird der Aufbau der, mit Hilfe von Bluetooth, umgesetzten Kommunikation dargestellt. Dazu werden die zum Ein- und Auslagerung benötigten Befehle und
deren genaue Aufgabe erläutert. Zusätzlich wird auf die Problematik, die Bluetooth, in
Verbindung mit dem frühen Entwicklungsstand von leJOS NXJ, mit sich bringt eingegangen.
Für die Verwaltung des Hochregallagers ist ein in Abschnitt 5.2 beschriebener NXT Baustein zuständig, welcher auch Aufgaben eines Lagerverwaltungssystems übernimmt.
Abschnitt 5.3 geht auf die Implementierung des Regalbediengerätes, Abschnitt 5.4 die
der Übergabestation und letztendlich Abschnitt 5.5 auf die des autonomen Transportfahrzeuges ein.
35
5.1. KOMMUNIKATION
KAPITEL 5. IMPLEMENTIERUNG
5.1 Kommunikation
Die Kommunikation zwischen den NXT Bausteinen dient, im aktuellen Ausbauzustand
des Hochregallagers, in erster Linie der Koordinierung der Ein- und Auslagerungen. Es
wäre jedoch denkbar die Kommunikation auszubauen um z.B. Status Meldungen und
weitere Informationen von den einzelnen Komponenten zu sammeln.
Eine Einlagerung besteht grundsätzlich aus den folgenden Schritten:
1. Das Transportfahrzeug fährt zu der Übergabestation.
2. Die Übergabestation lädt eine Palette auf die Ladefläche des ATF.
3. Das ATF fährt zu dem Regalbediengerät.
4. Das Regalbediengerät entnimmt die Palette von dem ATF und lagert diese an einer
freien Position im Regal ein.
5. Das ATF begibt sich zu dem Parkplatz.
Die Auslagerung erfolgt analog dazu, jedoch wird dabei als erstes von dem Transportfahrzeug ein Regalbediengerät angesteuert. Das Sequenzdiagramm 5.1 gibt anschaulich
wieder, welche Befehle (Commands) für die Einlagerung benötigt werden. Das Diagramm
A.3 stellt den entsprechenden Ablauf einer Auslagerung dar.
Es lässt sich aus den Diagrammen schon erkennen, dass die Kommunikation durch
eine Master-Slave Architektur umgesetzt wurde. Den Master bildet der in Abschnitt 5.2
beschriebene Master Controller, welcher auch die Funktion des LVS übernimmt. Nur
dieser hat auch die Möglichkeit direkt mit allen anderen NXT Bausteinen zu kommunizieren.
Die gesamte Kommunikation wurde in dem Paket upb.hrl.comm umgesetzt. In der
Abbildung A.1 ist das entsprechende Klassendiagramm dargestellt.
Die Klasse Kommunikation ermöglicht es Befehle (siehe Abschnitt 5.1.1) zu senden und
empfangen. Somit ist dieses die einzige Stelle im Quellcode an der der genaue Aufbau
und der Typ der einzelnen Parameter bekannt sein muss.
Von der Klasse Kommunikation wurde die Klasse ClientKommunikation, speziell für die
Kommunikation auf der Client Seite abgeleitet. Diese wird von dem Regalbediengerät,
ATF und der Übergabestation verwendet. Die ebenfalls von der Klasse Kommunikation
abgeleitete Klasse MasterKommunikation wird von dem Steuerungs Modul verwendet.
Der Unterschied der beiden abgeleiteten Klassen besteht darin, wie die Bluetooth Verbindungen zu dem jeweiligen Kommunikationspartner aufgebaut werden.
36
5.1. KOMMUNIKATION
RC : RC
ATF1 : ATF
UEG1 : UEG
Benutzer
Einlagern
GoToUEGCommand
InUEGPositionCommand
UnloadUEGCommand
UnloadedUEGCommand
GoToRBGCommand
InRBGPositionCommand
LoadRBGCommand
LoadedRBGCommand
Abbildung 5.1: Sequenzdiagramm Einlagern
37
RBG1 : RBG
5.1. KOMMUNIKATION
5.1.1 Die Commands
Die zwischen den verschiedenen Modulen ausgetauschten Nachrichten werden als Commands definiert. Ein Command ist eine einfache Java Klasse, die das Inteface Command
implementiert und der ein eindeutiger Identifier zugeordnet ist. Der Identifier besteht,
auf Grund der relativ geringen Anzahl an Commands, aus nur einem Byte. Alle Identifier
sind in dem Interface upb.hrl.comm.Protocol definiert.
Zusätzlich kann ein Command mehrere Parameter enthalten. Diese sind im Moment von
dem Typ int oder float, mögliche Erweiterungen können aber auch einfach Daten vom
Typ String oder byte übertragen.
Dieser Aufbau wurde gewählt, um die Kommunikation und somit auch die Funktionalität des Systems leicht erweitern zu können. Außerdem ist es so möglich den Sourcecode
gut lesbar und vor allem wartbar zu halten.
Der Aufbau der Command Hierarchie ist in Abbildung 5.2 dargestellt. Auch wenn
zwei Commands die selben Parameter enthalten, aber an unterschiedliche Komponenten
gesendet werden, wurde dieses durch zwei separate Klassen umgesetzt, die von der selben
Oberklasse geerbt haben. Dieses ist nötig, da aus den Nachrichten sonst nicht abgeleitet
werden kann, welche Aktion im Anschluss ausgeführt werden muss.
LoadUEGCommand
UnloadUEGCommand
UnloadedUEGCommand
UnloadedRBGCommand
LoadedRBGCommand
LoadedUEGCommand
«interface »
Command
GoToCommand
PositionCommand
# angle
#x
#x
#y
#y
InPositionCommand
- GoToCommand()
- PositionCommand()
+ getAngle()
+ getX()
+ getX()
+ getY()
+ getY()
GoToUEGCommand
GoToRBGCommand
+ GoToUEGCommand()
+ GoToRBGCommand()
UnloadRBGCommand
LoadRBGCommand
+ UnloadRBGCommand()
- LoadRBGCommand()
Abbildung 5.2: Die Command Hierarchie
Im Folgenden sind die Aufgaben der einzelnen Commands erklärt. Die Auflistung
wurde danach gegliedert, welche Komponenten des Systems die Commands verarbeiten.
Außer dem Master Controller sendet keines der Komponenten selbstständig einen Command, sonder antwortet nur auf vorher erhaltenen Commands.
38
5.1. KOMMUNIKATION
Die RBG Commands
Das Regalbediengerät reagiert auf zwei Commands und sendet nach erfolgreicher Verarbeitung zur Antwort jeweils einen Command:
• Der LoadRBGCommand teilt einem RBG mit, dass sich ein ATF direkt vor diesem
befindet und dass die, auf dessen Ladefläche befindliche, Palette eingelagert werden
soll. Dieser Command enthält zwei int Parameter, welche die x und y Koordinate
des Lagerfaches angeben in dem die Palette eingeordnet werden soll.
Wenn die Einlagerung vollzogen wurde, quitiert das RBG dieses dem Master mit
einem LoadedRBGCommand.
• Das Gegenstück zu dem LoadRBGCommand ist der UnloadRBGCommand. Dieser
teilt dem Regalbediengerät mit, aus welchem Lagerfach eine Palette ausgelagert
werden soll. Das RBG legt die Palette dann auf der Ladefläche des ATF ab und
antwortet mit einem UnloadedRBGCommand.
Die UEG Commands
Ähnlich wie das Regalbediengerät verarbeitet die Übergabestation zwei Commands, die
dieser mitteilen, entweder eine Palette von der Ladefläche des ATF zu entnehmen, bzw.
eine darauf abzulegen. Dieses wird durch die zwei Commands LoadUEGCommand und
UnloadUEGCommand bewerkstelligt. Im Unterschied zu den RBG Varianten benötigen
diese jedoch keine weiteren Parameter.
Die Antwort auf diese Commands sind wiederum, entsprechend derer des RBG, die LoadedUEGCommand bzw. UnloadedUEGCommand Commands.
Die ATF Commands
Das autonome Transportfahrzeug reagiert auf mehrere unterschiedliche GoTo Commands, die alle in ihrem Aufbau gleich sind und von der Klasse upb.hrl.comm.GoToCommand
abgeleitet sind.
Diese Commands enthalten alle drei float Werte für die x und y Koordinaten und einen
Winkel. Durch diese Werte wird dem ATF mitgeteilt, welche Position angesteuert werden soll und ich welche Richtung es dabei zeigen soll.
Abgeleitet von der Klasse GoToCommand sind GoToRBGCommand und GoToUEGCommand. Die beiden Commands werden mit einem InRBGPositionCommand bzw.
InUEGPositionCommand bestätigt, wenn das ATF die entsprechende Position erreicht
hat.
Empfängt ein ATF einen Command der Klasse GoToCommand, fährt es auch zu der
gewünschten Position, quittiert dieses aber nicht.
39
5.2. DER MASTER CONTROLLER
5.2 Der Master Controller
Der Master Controller, im Weiteren auch RC (Remote Control) gennant, ist das Lagerverwaltungssystem des Models. Dieser ist dafür zuständig die Kommunikation zwischen
alle Modulen zu verwalten, aber auch die Ein- und Auslagerungsvörgänge zu koordinieren. Somit bildet dieser NXT Baustein das Herzstück des ganzen Systems.
Bei der Implementierung des Masters sind besonders viele der Einschränkungen von
leJOS bemerkbar geworden. Am meisten Aufwand musste investiert werden, dass es
möglich wurde Bluetooth Verbindungen mit mehreren Geräten gleichzeitig aufzubauen.
leJOS NXJ ermöglicht es seit der Version 0.4, Verbindungen zwischen NXT Bausteinen
aufzubauen, allerdings immer nur eine einzige. Auch wenn diese Verbindung wieder beendet wurde, war es nicht möglich eine neue Verbindung herzustellen.
Mit Hilfe der leJOS NXJ Revisionen 1082 bis 1133 aus dem leJOS NXJ Subversion Repository1 ist es möglich Verbindungen zu mehreren NXT Bausteinen gleichzeitig aufzubauen. Leider werden dabei bestehende Verbindungen oft unterbrochen und sind daraufhin
nicht mehr weiter benutzbar. Ab Revision 1134 wurde die Möglichkeit zur Verbindung
von mehreren NXT Bausteinen, wegen des geschilderten Problems, wieder entfernt. Die
leJOS Entwickler gehen jedoch davon aus mit der leJOS NXJ Version 0.5 eine stabile
Unterstützung für mehrere gleichzeitige Bluetoothverbindungen bereitstellen zu können.
Ein weiteres, nicht ganz so einschränkendes, Problem trat bei der Implementierung
des Menüsystems auf. Da die maximale Länge einer Klasse überschritten wurde, mussten
einige Methoden in die Klasse upb.hrl.rc.RCHelper ausgelagert werden.
Bevor der Master zur Steuerung des Systems benutzt werden kann, müssen alle Bluetooth Verbindungen hergestellt werden. Dazu müssen alle NXT Bausteine eingeschaltet
und das, der Funktion entsprechende, Programm gestartet werden. Alle Clients (ATF,
RBG und UEG) sollten
Warten auf RC...
auf dem Display anzeigen. Nun lässt sich über den Menüpunkt Verbindung auf dem
Master eine Verbindung mit den einzelnen Komponenten herstellen. Der genaue Ablauf
dazu ist in Abschnitt 5.2.1 beschrieben.
Der Verbindungsaufbau auf der Master Seite ist in der Klasse MasterKommunikation umgesetzt. Diese bietet die benötigten Funktionen an, um die Verbindung mit den
Clients herzustellen. Dazu benutzt der Master, je nach Modul mit dem eine Verbindung
aufgebaut werden soll, eine der Klassen ATFKommunikation, RBGKommunikation bzw.
UEGKommunikation (siehe Klasendiagramm A.1), die alle von MasterKommunikation
abgeleitet sind und für jedes der drei Module spezifische zusätzliche Methoden implementieren.
1
http://lejos.svn.sourceforge.net/viewvc/lejos/
40
Da der Master Controller auch die Funktion des Lagerverwaltungssystems übernimmt,
benötigt dieser Angaben über die Anzahl der im Hochregal verfügbaren Lagerplätze.
Die Anzahl der Zeilen und Spalten wird durch die Konstanten RACK ROWS und
RACK COLUMNS in der Klasse upb.hrl.rc.RC (siehe Klassendiagramm 5.3) festgelegt.
5.2.1 Das Menüsystem
Der Master Controller verfügt über ein simples Menüsystem über welches sich das Hochregallager steuern lässt. Die Steuerung funktioniert über die vier Tasten unterhalb des
Displays der NXT Bausteine. Mit den beiden hellgrauen Pfeiltasten lässt sich in dem
Menü auf- und ab navigieren. Mit der großen, quadratischen, orangenen Taste bestätigt
man die aktuelle Auswahl und mit der rechteckigen, dunkelgrauen Taste kehrt man in
das vorherige Menü zurück bzw. beendet das Programm.
Dieses Menüsystem ist in drei Punkte unterteilt:
• Verbindung - Unter diesem Menüpunkt lassen sich Verbindungen zu den drei
Modulen herstellen. Dazu müssen diese zuvor eingeschaltet werden. Daraufhin
warten diese auf eine eingehende Verbindung. In dem Menü Verbindungen lässt
sich auswählen, zu welchem Modul eine Verbindung aufgebaut werden soll. Nach
der Auswahl einer der Punkte ATF, RBG, oder UEG wird nach anderen NXT
Bausteinen gesucht und die Liste der gefundenen Ergebnisse angezeigt. Aus dieser
Liste kann die entsprechende Auswahl getroffen werden, woraufhin die Verbindung
aufgebaut wird. Dieser Schritt muss für alle drei Module durchgeführt werden, um
mit diesen kommunizieren zu können.
• Test - Der Test-Menüpunkt ist dazu gedacht, einzelne Aktionen der Objekte auszuführen. Dazu muss erst eine Verbindung zu dem gewünschten Modul (über das
Verbindungs-Menü) aufgebaut werden. Daraufhin können über das Test-Menü einzelne Befehle gesendet werden. So lässt sich hierüber z.B. das ATF an eine der drei
Haltestellen navigieren oder mit Paletten beladen.
• Betrieb - Das Betrieb-Menü bietet die Möglichkeit Paletten ein- und auszulagern.
Bei Auswahl des Menüpunktes einlagern wird eine, sich auf der Gabel des UEG
befindlichen, Palette eingelagert. Hierfür sind keine weiteren Eingaben notwendig,
da automatisch ein verfügbarer Lagerplatz, mit Hilfe des LVS, ermittelt wird.
Bei Auswahl des Punktes auslagern, wird eine Liste aller sich im Lager befindlichen Paletten angezeigt und es kann eine Gewünschte ausgewählt werden, welche
daraufhin ausgelagert wird.
41
5.2.2 Das Lagerverwaltungssystem
Das eigentliche Lagerverwaltungssystem ist in der Klasse upb.hrl.rbg.LVS umgesetzt.
Diese Klasse behält den Überblick über die im Hochregallager gelagerten Paletten und
weist einzulagernden Paletten, nach dem Prinzip der chaotischen Lagerhaltung, Lagerplätze zu.
Umgesetzt wird dieses, da alle Paletten als einheitlich gelten und nicht voneinander
unterschieden werden können, durch ein zweidimensionales boolean Array.
Während der Initialisierung des LVS werden alle Elemente des Arrays auf false gesetzt,
da davon ausgegangen wird, dass das Regal komplett leer ist.
Wird die Methode einlagern über das Menüsystem aufgerufen, so ermittelt das LVS die
erste freie Position in dem Hochregal und stößt den Ablauf aus Sequenzdiagramm 5.1
an.
Entsprechend wird der Ablauf aus Sequenzdiagramm A.3 von dem LVS durchgeführt,
wobei zuvor eine Liste der verfügbaren Paletten zur Auswahl angeboten wird.
RC
upb::hrl::comm::RBGKommunikation
- BACK_COMMAND
- CMDID_BACK_TO_MAIN
- CMDID_EXIT_APP
- EXIT_COMMAND
- RACK_COLUMNS
- RACK_ROWS
- rbg
+ RBGKommunikation()
1
- atf
- connectMenu
- display
- exitAlert
- helper
- lvs
- menu
+ load()
+ unload()
upb::hrl::comm::ATFKommunikation
upb::hrl::comm::MasterKommunikation
+ ATFKommunikation()
- atf
1
- rbg
- testMenu
- ueg
- workMenu
+ goTo()
+ goToRBG()
+ goToUEG()
- FRIENDLY_NAME
+ MasterKommunikation()
+ RC()
upb::hrl::comm::UEGKommunikation
+ commandAction()
+ connectMenuAction()
+ main()
- ueg
1
+ startMenu()
+ workMenuAction()
LVS
1
- lvs
1
+ UEGKommunikation()
- helper
+ load()
+ unload()
- columns
- helper
- rows
- space
+
+
+
+
+
RCHelper
1
+ buildMenu()
+ displayString()
+ displayString()
+ findDevices()
- helper
LVS()
auslagern()
countStock()
einlagern()
freeSpace()
+ setInUse()
+ testMenuAction()
Abbildung 5.3: Klassendiagramm des Master Controllers
42
5.3 Das Regalbediengerät
Das Regalbediengerät ist mit drei Motoren und drei Drucktastern ausgestattet. Für jede
der drei Bewegungsrichtungen ist jeweils ein Paar aus Motor und Drucktaster zuständig.
Solch ein Paar wurde in der Klasse upb.hrl.rbg.Antriebseinheit zusammengefasst, welche
die Methoden isMoving() und goToInitialPosition() implementiert. isMoving() erlaubt
es zu überprüfen, ob eine Bewegung durchgeführt wird und mit goToInitialPosition()
kann zu einer initialen Ausgangsposition gefahren werden. Dazu wird die entsprechende Antriebseinheit so lange bewegt, bis der Drucktaster aktiviert ist. Ist diese Position
erreicht wird der Zähler für die durchgeführten Umdrehungen des Motors auf 0 zurück
gesetzt.
Von der Klasse Antriebseinheit sind die drei Klassen Fahreinheit, Hubeinheit und Lastaufnahmeeinheit abgeleitet. Diese setzen für die in der jeweiligen Richtung notwendigen
Funktionen zur Positionierung um. Damit die Positionierung leicht an Änderungen der
Lagerpositionen und anderer Änderungen in der Konstruktion angepasst werden kann,
wurden diese über Konstanten anpassbar gemacht.
Für jede der Klassen ist es möglich über die Konstante SPEED die Bewegungsgeschwindigkeit anzupassen. Dadurch können die unterschiedlichen Übersetzungsverhältnisse ausgeglichen werden.
Die Klasse Fahreinheit hat eine Methode goToPosition(int x), welche es ermöglicht
jede Spalte des Hochregals anzufahren. Über die geerbte Funktion goToInitialPosition()
wird die Position zur Bedienung des ATF angefahren.
Um die Spalten des Regals genau anfahren zu können, sind zwei Werte notwendig:
RACK START und BOX WIDTH. RACK START ist die Anzahl der gemessenen Pulse des Tachometers des Motors bis, von der initialen Position aus, die Mitte der ersten
Spalte des Hochregals erreicht ist. BOX WIDTH ist die Anzahl der Impulse, die der
Tachometer von der Mitte einer Spalte zu der Mitter der benachbarten Spalte misst.
Die für die Bewegung in y-Richtung zuständige Klasse Hubeinheit hat die Methoden
goToPosition(int y), so wie box up() box down(), up() und down().
Die Funktion goToPosition(int y) ist zum Anfahren der einzelnen Zeilen des Hochregals zuständig. Ähnlich wie bei der Fahreinheit wird dieses durch zwei Konstanten
RACK BOTTOM und BOX HEIGHT konfiguriert.
Die Funktionen up() und down() sind nötig, um eine Palette auf dem ATF ablegen zu
können, die Funktionen box up() und box down() sind nötig, um eine Palette in einem
Lagerfach ablegen zu können. Dazu muss sich die Hubeinheit jeweils um ein kleines
Stück anheben bzw. absenken können. Die Höhe um die dieses geschieht wird durch die
Konstante LIFT bzw. BOX LIFT definiert.
Etwas einfacher ist die Positionierung der Klasse Lastaufnahmeeinheit. Diese muss
nur drei Positionen kennen. Die initiale Position, die Position der Hochregals und die
des ATF. Die initiale Position wird mit Hilfe des Drucktasters angefahren. Nur in dieser
43
Position kann sich das Regalbediengerät frei bewegen, ohne mit der Lastaufnahmeeinheit
an dem Regal hängen zu bleiben.
Die anzufahrenden Positionen des Hochregals und des ATF werden durch die Konstanten RACK POSITION, so wie ATF POSITION festgelegt und können durch Aufrufe
der Funktionen goToRack() bzw. goToATF() angefahren werden.
Die gerade beschriebenen Klassen können somit jede benötigte Position in jeweils einer
Richtung anfahren. Die, um Ein- und Auslagerungen durchführen zu können, benötigten
Abläufe sind in der Klasse Steuerung umgesetzt. Genauer gesagt wird dieses von den
Funktionen einlagern(int x, int y) und auslagern(int x, int y) durchgeführt. Die Parameter x und y geben jeweils das Lagerfach an in dem eine Palette eingelagert, bzw. aus
dem eine Palette entnommen werden soll.
Die Klasse RBG enthält die main Methode für das Regalbediengerät. In dieser wird
eine Initialisierung durchgeführt und daraufhin auf eine Verbindung zu dem Master
gewartet. Ist die Verbindung aufgebaut, werden mit Hilfe der ClientKommunikation Befehle empfangen, welche an die Steuerung weitergeleitet werden.
Ein kompletter Überblick über das Packet upb.hrl.rbg ist in dem Klassendiagramm
5.4 dargestellt.
RBG
Hubeinheit
- FRIENDLY_NAME
- kommunikation
upb::hrl::comm::ClientKommunikation
- kommunikation
- steuerung
1
- BOX_HEIGHT
- BOX_LIFT
- LIFT
- RACK_BOTTOM
- SPEED
+ ClientKommunikation()
- connectToMaster()
+ RBG()
- main()
- steuerung
+ Hubeinheit()
Fahreinheit
+
+
+
+
+
- BOX_WIDTH
- RACK_START
- SPEED
- Fahreinheit()
+ goToPosition()
+ goToPosition()
1
- fahreinheit
Steuerung
- fahreinheit
- hubeinheit
- lastaufnahmeeinheit
box_down()
box_up()
down()
goToPosition()
goToPosition()
+ up()
1
- hubeinheit
+
+
+
+
Steuerung()
auslagern()
einlagern()
goToInitialPosition()
goToPosition()
+
+
+
-
isMoving()
placeOnATF()
placeOnRack()
takeFromATF()
takeFromRack()
Lastaufnahmeeinheit
1
- lastaufnahmeeinheit
Antriebseinheit
- ATF_POSITION
- RACK_POSITION
- SPEED
# motor
+ Lastaufnahmeeinheit()
+ goToATF()
+ goToInitialPosition()
+ Antriebseinheit()
# sensor
+ goToRack()
+ isMoving()
1
Abbildung 5.4: Klassendiagramm des Regalbediengerätes
44
5.4. DIE ÜBERGABESTATION
5.4 Die Übergabestation
Die Übergabestation ist in dem Packet upb.hrl.ueg (siehe Abbildung 5.5) umgesetzt und
ähnlich aufgebaut wie das Regalbediengerät. Die Klasse UEG enthält wiederum die main
Methode und ist für die Initialisierung, Verbindungsaufbau und den Empfang der Befehle zuständig.
Die Aufgabe der Klasse Steuerung ist das in den Funktionen laden() und entladen()
umgesetzte Be- und Entladen des ATF.
Um die beiden Vorgänge durchzuführen, wird, wie bei dem Regalbediengerät, auf eine
Hubeinheit so wie eine Lastaufnahmeeinheit zurückgriffen, welche auch von der Klasse
upb.hrl.rbg.Antriebseinheit abgeleitet sind. Analog zu dem RBG, lassen sich für die Klassen Hubeinheit und Lastaufnahmeeinheit die Drehgeschwindigkeiten des Motors über die
Konstante SPEED regeln.
Die anzufahrenden Positionen der Hubeinheit können durch die beiden Konstanten
ATF HEIGHT und LIFT bestimmt werden. ATF HEIGHT ist die Höhe der Ladefläche
des ATF. LIFT hat die selbe Funktion wie bei dem RBG. Die Lastaufnahmeeinheit
funktioniert analog zu der des RBG, hier ist jedoch nur die durch ATF POSITION festzulegende Position des ATF notwendig.
UEG
- FRIENDLY_NAME
- kommunikation
- kommunikation
- steuerung
1
- connectToMaster()
+ UEG()
+ main()
Lastaufnahmeeinheit
- steuerung
- ATF_POSITION
- SPEED
+ Lastaufnahmeeinheit()
+ goToATF()
1
1
Steuerung
- hubeinheit
- teleskopgabel
- Steuerung()
+ entladen()
+ laden()
upb::hrl::rbg::Antriebseinheit
- teleskopgabel
# motor
# sensor
Hubeinheit
+ Antriebseinheit()
- hubeinheit
1
- ATF_HEIGHT
- LIFT
- SPEED
+ isMoving()
+ Hubeinheit()
+ down()
+ goToATF()
+ up()
Abbildung 5.5: Klassendiagramm der Übergabestation
45
5.5. DAS TRANSPORTFAHRZEUG
5.5 Das Transportfahrzeug
Das Autonome Transportfahrzeug besitzt zwei Motoren die zur Fortbewegung verwendet werden. Jeder der Motoren treibt eines der beiden Vorderräder an, welche dadurch
unabhängig voneinander steuerbar sind. Für derartig aufgebaute Roboter bietet die leJOS NXJ Bibliothek in dem Packet lejos.navigaton vorgefertigte Klassen an, die die
Steuerung solcher Roboter vereinfachen.
Die einfachste dieser Klassen ist die Pilot Klasse. Diese bietet Funktionen an um, einen
solchen Roboter vorwärts und rückwärts fahren zu lassen, sich um einen bestimmten
Winkel zu drehen und anzuhalten. Darauf aufbauend gibt es weitere Klassen, die teilweise mit Hilfe weiterer Sensoren, wie z.B. einem Kompass, die Navigation des Roboters
ermöglichen und die aktuelle Position, relativ zu der Startposition, bestimmen können.
Für das autonome Transportfahrzeug wurde der TachoNavigator, der zur Positionsbestimmung die Odometrie verwendet, benutzt. Diese wurde mit einer Linienerkennung
und einer Markererkennung, für welche die beiden auf den Boden gerichteten Lichtsensoren verwendet werden, kombiniert, um möglichst genaue Positionsdaten zu erhalten.
Zusätzlich wird der Ultraschallsensor an der Front genutzt um nicht auf Hindernisse
aufzufahren. Umgesetzt wurde dieses in der Klasse upb.hrl.atf.TrackNavigator.
Für die Steuerung mit Hilfe dieser Klassen werden zusätzliche Parameter benötigt, die
die physikalischen Eigenschaften des ATF beschreiben. Dieses sind, die in der Klasse
TrackNavigator definierten Konstanten WHEEL DIAMETER und TRACK WIDTH so
wie FRONT DIFF und SIDE DIFF. Die beiden Ersten beschreiben den Raddurchmesser
und die Spurbreite des ATF in Zentimetern, während die beiden Letzteren den Abstand
des Lichtsensors zur Linienverfolgung zum Mittelpunkt der Antriebsachse des ATFs angeben.
Zusätzlich wird dort in den Konstanten SPEED und DISTANCE festgelegt wie schnell
das ATF fahren soll und wie viel Abstand, in Zentimetern, es zu Hindernissen auf der
Fahrbahn halten soll.
5.5.1 Initialisierung
Damit die beiden Lichtsensoren sicher zu Fahrbahn und Markererkennung eingesetzt
werden können, müssen diese zuvor initialisiert werden. Dieses geschieht über den in
Kapitel 4.5 beschriebenen Initialisierungsbereich auf der Fahrbahn. Die Initialisierung
ist eines der neu hinzugekommenen Features des ATF und verbessert die Positionierungsgenauigkeit enorm.
Umgesetzt ist die Initialisierung in der Methode initSensors() der Klasse TrackNavigator, deren genaues Vorgehen in Kapitel 4.5 beschrieben ist.
46
5.5.2 Linienverfolgung
Die Linienverfolgung funktioniert auf eine grundlegend andere Art und Weise, als die
für das alte ATF implementierte Version. In der alten Version des ATF wurde der von
dem Sensor für die Fahrbahn ermittelte Wert mit einem Referenzwert für die Fahrbahn
verglichen. War dieser Wert größer, und somit der aktuelle Untergrund zu hell, wurde
nur das linke Rad angetrieben und das ATF hat einen Schwenk nach rechts gemacht.
Entsprechen, wenn der eingelesene Wert zu klein war, hat das ATF einen Schwenk nach
links gemacht.
Auf diese Art und Weise hat sich das ATF, anstatt der Fahrbahnmarkierung auf einer
geraden Linie zu folgen, dieses in einer Schlangenform getan.
Die überarbeitete Implementierung ist darauf ausgerichtet der Fahrbahnmarkierung
flüssiger zu folgen. Dazu wurde der vorhandene Farbverlauf der Fahrbahn und die Tatsache, dass der genaue Helligkeitswert der Mitte der Fahrbahn von der Initialisierung
her bekannt ist, ausgenutzt.
Das ATF geht jetzt davon aus, dass es genau in Richtung der Fahrbahn ausgerichtet ist
und fängt dementsprechend an geradeaus zu fahren. Der von der Fahrbahnmarkierung
ausgelesene Helligkeitswert wird wiederum mit dem Sollwert der Fahrbahn verglichen.
Ist die Differenz der beiden Werte unterhalb eines gewissen Schwellwertes, fährt das ATF
weiterhin geradeaus und verlangsamt nur einen der beiden Motoren etwas, abhängig davon, auf welcher Seite der Ideallinie sich das ATF befindet.
Überschreitet die Differenz zwischen dem Sollwert und dem aktuell ausgelesenen Wert
den Schwellwert, so fängt das ATF an, sich in die benötigte Richtung zu drehen. Der
Winkel, um den sich das ATF hierbei dreht ist davon abhängig, wie groß die Differenz
der Werte ist. Der Winkel α wird mit Hilfe der Gleichung 5.1 berechnet.
α=
lineColor − trackColor
10
(5.1)
Geht man davon aus, dass die gewünschte Helligkeit der Fahrbahn (lineColor ) in etwa
60 entspricht und die ermittelten Helligkeiten zwischen 202 und 100 liegt, so entspricht α
einem Wert zwischen −4 und 4. Dementsprechend würde sich das ATF um einen Winkel
von maximal 4◦ in die benötigte Richtung drehen.
Es hat sich herausgestellt, dass dieses Verfahren eine sehr stabile Geradeausfahrt
ermöglicht und auch in engen Kurven das ATF sicher auf der Fahrbahn hält. Zudem
erhöht sich die Genauigkeit der von der Odometrie ermittelten Position bei diesem Ansatz deutlich gegenüber dem einfachen Anhalten eines der beiden Antriebsräder. Dieses
ist darauf zurückzuführen, das der Schlupf bei der Drehung deutlich geringer ist, da sich
hierbei beide Räder drehen können.
2
Es werden im Normalfall keine Helligkeiten unter 20 ermittelt, da der schwarze Streifen der Fahrbahn
schmaler ist als der Messbereich des Lichtsensors.
47
5.5.3 Positionsbestimmung
Das ATF benutzt zur Positionsbestimmung zwei unterschiedliche Methoden, die sich
gegenseitig unterstützten. Zum Einen wird die Odometrie benutzt, um vorallem Kurvenfahrten zu erkennen, zum Anderen die Marker auf der Fahrbahn. Dadurch lässt sich
relativ robust eine genaue Position und die Fahrtrichtung des ATF bestimmen. Die Positionsbestimmung ist in der Klasse T rackN avigator implementiert.
Im Folgenden ist beschrieben, wie die beiden Methoden funktionieren und wie sie sich
gegenseitig unterstützen
Odometrie
Die Odometrie ermöglicht es, aus den Radumdrehungen die aktuelle Position und die
Fahrtrichtung des Roboters in Relation zu dem Startpunkt zu berechnen. Diese Werte
sind allerdings ungenau und die Fehler summieren sich, je länger die Position nicht anderweitig korrigiert wird.
Die Fehler können in zwei Klassen aufgeteilt werden. Zum Einen gibt es die systematischen und zum Anderen die nicht systematischen Fehler. Bei den systematischen Fehlern
handelt es sich um Berechnungsungenauigkeiten (Rundungsfehler und Ungenauigkeit bei
der Bestimmung des Radumfangs und Radabstand). Nicht systematische Fehler entstehen etwa durch Durchdrehen (Schlupf) der Räder auf dem Untergrund oder Unebenheiten auf dem Untergrund.[TBF05, Har03]
In der leJOS Bibliothek ist bereits ein Navigator implementiert, der zur Positionsbestimmung auf der Odometrie basiert. Dieser T achoN avigator nutzt die neue Fähigkeit
der NXT Motoren aus, dass diese die durchgeführten Umdrehungen direkt mitzählen
können.
Leider besitzt diese Klasse in der leJOS Version 0.4 einige Bugs, die dazu führen, dass
oft völlig falsche Positionen berechnet werden. Außerdem müssen für die Neuberechnung
der Position die Motoren angehalten werden. Seit der Revision 1143 sind die Bugs behoben und es ist sogar möglich, während die Motoren sich bewegen die Positionsdaten
zu aktualisieren.
In Abbildung 5.6 ist eine Positionsveränderung eines ATF im Koordinatensystem
schematisch dargestellt. Die Position des Roboters im Punkt P1 ist durch das Tupel
l = (x, y, a) gegeben. Das Tupel wird in bestimmten Abständen aktualisiert, dazu werden die Größenänderungen ∆x, ∆y und ∆α auf die zugehörige Tupelelemente aufaddiert.
Es werden die Werte ∆l und ∆r mit Hilfe der, in den NXT Motoren eingebauten, Inkrementalgebern gemessen. Daraus ergibt sich nach der Gleichung (5.2) mit Hilfe des
Radabstandes d der Drehwinkel ∆α.
∆α =
∆r − ∆l
d
48
(5.2)
∆l
∆α
α
y
P1
P2
∆y
∆s
∆r
∆x
d
x
Abbildung 5.6: Schema einer Positionsveränderung
49
Die Wegstrecke ∆s wird nach Gleichung (5.3) berechnet. Sie ist der Mittelwert von
∆l und ∆r.
∆s =
∆r + ∆l
2
(5.3)
Anhand der Werte ∆x, ∆y und ∆α wird das Positionstupel aktualisiert. Genaueres
dazu ist in [Pan02] zu entnehmen.
Die Berechnung der neuen Position findet in der Methode updatePosition() der Klasse
TachoNavigator statt.
Markererkennung
Die Marker werden von dem rechten Lichtsensor des ATF erkannt und dazu benutzt die
von der Odometrie berechnete Position zu korrigieren. Die Markererkenung an sich ist
sehr einfach, es muss nur in regelmäßigen Abständen überprüft werden, ob der dafür
zuständige Lichtsensor einen bestimmten Schwellwert unterschreitet. Dieser Schwellwert
kann über die Konstante MARKER DIFF festgelegt werden.
Aufwendiger gestaltet sich die Korrektur der Odometriedaten durch die Markererkennung. Besonders wichtig ist es dabei die Fahrtrichtung anzupassen, da durch den Schlupf
der Räder auf dem Untergrund besonders dieser Wert zu Ungenauigkeiten neigt. Dazu
wird intensiver Gebrauch von den bekannten Merkmalen der Fahrbahn und des ATF
gemacht:
• Die Position, an der das ATF vor dem Initialisierungsbereich platziert wird ist
genau bekannt. Über einen Aufruf von setPosition(flot x, float y, float angle) in
der Methode initSensors() wird dieser Startpunkt festgelegt.
• Die beiden engen 180◦ Kurven auf den beidem schmalen Seiten der Fahrbahn
werden dazu genutzt, die genaue Position so wie den Winkel erneut festzulegen.
Dieses ist möglich, da nur an diesen beiden Stellen ein Marker überfahren wird,
bei dem die Fahrtrichtung des ATF 0◦ bzw 180◦ ist.
• Während der Fahrt entlang der langen Geraden wird das Raster der Markierung
benutzt, um die Position neu zu bestimmen. Je nach Fahrtrichtung (90◦ bzw -90◦ )
ist die x -Position des ATF bekannt, da davon ausgegangen wird, dass der Sensor
für die Fahrbahn sich ungefähr auf der Mitte der Bahn befindet.
Für die Bestimmung der y-Position wird ausgenutzt, dass das Raster regelmäßig ist
und somit kann die y-Position auf den Wert gesetzt werden, der dem von der Odometrie bestimmten am nächsten liegt. Das regelmäßige Raster über die Fahrbahn
hat einen Abstand von 50cm. Die dazwischen als Marker erkannten Fahrbahnabzweigungen liegen genau auf der Hälfte. Somit wird der y-Wert der Position auf
das am nächsten an der von der Odometrie ermittelten Position liegende, Vielfache von 25cm gesetzt. Dieses sind in der Regel nur kleine Korrekturen, da bei der
50
Geradeausfahrt die zurückgelegte Strecke von der Odometrie sehr genau berechnet
wird.
Die beschriebene Korrektur der Positionsdaten wird in der Methode correctPosition()
durchgeführt.
5.5.4 Anfahrt der Zielpositionen
Zur Anfahrt einer Zielposition auf der Fahrbahn wird ausgenutzt, dass über den gesamten Untergrund ein Koordinatensystem gelegt wurde. Somit lassen sich für alle anzufahrenden Zielpunkte genaue Koordinaten und ein Winkel festlegen, um eine genaue
Positionierung für das ATF festzulegen.
Da dem ATF die eigene Positionierung bekannt ist, kann dieses berechnen in welchem
Winkel ∆α die anzufahrende Zielposition liegt.
Wenn dem ATF angewiesen wurde eine bestimmte Zielposition anzufahren, fängt das
ATF damit an, der Fahrbahnmarkierung zu folgen. Jedes Mal wenn von dem ATF ein
Marker erkannt wurde, wird die aktuelle Position berechnet und nach dem in Abschnitt
5.5.3 beschriebenen Prinzip korrigiert. Daraufhin wird der Winkel berechnet in dem die
Zielposition zu der aktuellen Fahrtrichtung liegt. Ist dieser Winkel zwischen 25◦ und
75◦ groß und stimmt die gewünschte Drehrichtung des ATF mit der aktuellen überein,
so biegt das ATF nach rechts hin ab und folgt der Fahrbahn so lange bis der nächste
Marker erreicht ist. Das ATF befindet sich nun an der gewünschten Zielposition.
Dieses Prinzip funktioniert sehr genau, so dass sich die Paletten von der Übergabestation
und dem Regalbediengerät gut erfassen lassen.
Theoretisch könnte auf diese Weise auf die Führungslinien denen das ATF folgt komplett
verzichtet werden, leider ist dafür die Odometrie zu ungenau, um sich alleine darauf verlassen zu können.
×
Abbildung 5.7: Anfahrt der Zielposition
51
Der in Abbildung 5.7 dargestellte Ausschnitt der Fahrbahn zeigt, wie die korrekte Position zu Abbiegen des ATF gefunden wird. Das rote X stellt die anzufahrende Position
dar. Der linke rote Pfeil deutet einen Winkel von 25◦ rechts der aktuellen Fahrtrichtung
an. Somit wird das ATF, wenn der linke Marker erkannt wird nicht versuchen abzubiegen, da der Winkel zwischen der aktuellen Fahrtrichtung und der Zielposition kleiner als
25◦ ist.
Der nächste von dem ATF erkannte Marker wird die Abzweigung nach unten sein. Von
dieser Position aus ist der Winkel zwischen der aktuellen Fahrtrichtung und der Zielposition größer als 25◦ und somit biegt das ATF nach rechts ab.
52
6 Erweiterungsmölichkeiten
Das in den vorhergehenden Kapiteln dargestellte und entwickelte System bietet sich dazu an in einigen Punkten noch deutlich in der Funktionalität erweitert zu werden.
Im Folgenden werden noch einige Ideen zu einzelnen Komponenten des Hochregallagers betrachtet, die das System teilweise stabiler funktionieren lassen würden, bzw.
versuchen sollen, weitere Komponenten reeller Hochregallager in das Model einzubinden. Einige dieser Erweiterungen basieren auf Sensoren von Drittherstellern, die nicht
in den normalen LEGO Mindstorms Bausätzen enthalten sind.
Eine relativ offensichtliche Erweiterung des Hochregallagersystemes wäre es, dieses mit
weiteren Regalbediengeräten und den dazugehörigen Hochregalen, Übergabestationen
und autonomen Transportfahrzeugen auszustatten.
In der aktuellen Ausbaustufe besteht von jedem der angesprochenen Komponenten nur
ein Exemplar. Dieses ist zum Einen darauf zurückzuführen, dass einige benötigte Bauteile in zu geringer Zahl vorhanden sind, bzw. noch in dem RCX Hochregallager verbaut
sind. Zum Anderen darauf, dass die Bluetooth-Kommunikation zum momentanen Zeitpunkt mir der aktuellen leJOS Version noch sehr problematisch ist.
Sind diese Probleme in neueren leJOS Versionen erst einmal behoben, ist es ohne
größeren Aufwand möglich das System, und vor allem die Kommunikation, auf Grundlage dieser Bachelorarbeit so zu erweitern, dass eine Vielzahl von Übergabestationen,
Regalbediengeräten und autonomen Transportfahrzeugen unterstützt werden. Solch ein
komplexerer Aufbau würde einem reellen Hochregallager deutlich näher kommen und
viele interessante Anwendungen zulassen.
Um die Kommunikation mit mehreren Komponenten umzusetzen, wird es nötigt sein
die Commands um einige Parameter zu erweitern, um Informationen darüber zu verwalten, welche Komponenten für einen Vorgang benutzt werden sollen. Zusätzlich müsste
die Klasse upb.hrl.rc.RC dahingehend angepasst werden, dass mehrere Verbindungen als
jeweils nur eine für Übergabestationen, Regalbediengeräte und Transportfahrzeuge aufgebaut werden können und für jedes Hochregal eine Instanz der Klasse upb.hrl.rc.LVS
zur Verfügung steht.
53
6.1. ATF ERWEITERUNG
KAPITEL 6. ERWEITERUNGSMÖLICHKEITEN
6.1 ATF Erweiterung
Die Positionsbestimmung des autonomen Transportfahrzeuges funktioniert zur Zeit auf
Basis der Odometrie und der Markererkennung (siehe Kapitel 5.5), welche zusammen
ein gutes Ergebnis liefern. Es gibt jedoch eine relativ einfache Möglichkeit die Güte der
Positionsbestimmung, auf einfache Art und Weise, noch deutlich zu erhöhen.
Der NXT Baustein des ATF hat noch einen Sensoreingang übrig der unbenutzt ist.
Es würde sich anbieten dort einen Kompasssensor von HiTechnic (siehe Kapitel 3.3.6)
anzuschließen und diesen mit der bestehenden Steuerung zu kombinieren.
In dem Packet lejos.navigation gibt es bereits die Klasse CompassNavigator, die die
Positionsbestimmung auf Basis der Odometrie und des Kompasssensors ermöglicht. Die
Steuerung des ATF müsste nun dahingehend angepasst werden, dass der TrackNavigator
anstatt dem TachoNavigator den CompassNavigator benutzt.
Der Kompasssensor müsste, parallel zu den Lichtsensoren, während der Initialisierung
des ATF mit initialisiert werden. Durch diesen Schritt ist zu jeder Zeit die genaue Richtung in die das ATF zeigt, bekannt und muss nicht mit Hilfe der Marker approximiert
werden. Besonders während der Kurvenfahrt ist dieses von Vorteil, da der Schlupf der
Räder während dieser Phase besonders hoch ist und sich in einem relativ hohen Fehler
in der Ausrichtung bemerkbar macht.
Mit Hilfe des Kompasses sollte es auf jeden Fall möglich sein, wenn nicht sogar auf
die Führungslinien, zumindest auf die zusätzlichen Marker, in Form des Rasters auf der
Fahrbahn, verzichten zu können.
Möglicherweise ließe sich die Wegfindung der Transportfahrzeuge so abändern, dass auf
durchgängige Führungslinien verzichtet werden könnte und diese nur in der Umgebung
von Übergabestationen oder Regalbediengeräten zum Einsatz kommen, um sich dort
nicht nur auf die Odometrie verlassen zu müssen. Um jedoch die Transportfahrzeuge in
die Nähe dieser Elemente zu navigieren, ist die Odometrie auf jeden Fall ausreichend
und um Kollisionen mit anderen Transportfahrzeugen zu vermeiden, kann auf den, in
Benutzung befindlichen, Ultraschall Sensor vertraut werden.
54
6.2. UEG ERWEITERUNG
6.2 UEG Erweiterung
Die aktuelle Version der Übergabestation ist im Prinzip nur eine einfachere Version eines
Regalbediengerätes und hat nur die Möglichkeit eine Palette von einem ATF zu entnehmen oder darauf abzulegen. Um eine neue Palette einzulagern, muss diese also zuvor
manuell auf der Lastaufnahmeeinheit der Übergabestation platziert werden.
Um dieses zu umgehen, wäre es gut die Übergabestation mit einer automatischen Warenanlieferung zu verknüpfen. Dazu müsste der aktuelle Aufbau um ein weiteres Transportsystem, wie etwa Förderbändern, erweitert werden. Diese würden Paletten zu der
Übergabestation transportieren, von wo die Übergabestation die Paletten wiederum entnimmt und auf einem ATF ablegt. Die Auslagerung könnte entsprechend umgekehrt
funktionieren.
Grundsätzlich gibt es mehrere Möglichkeiten dieses umzusetzen. Es ist zum Beispiel
möglich die Übergabestation auf einer, durch einen weiteren Motor angetriebenen, drehbaren Bodenplatte zu montieren. Dadurch könnte die UEG eine Palette durch einen 90◦
Dreh nach rechts oder links auf unterschiedlichen Förderbändern ablegen.
Alternativ könnte für die Auslagerung auch eine weitere Übergabestation aufgebaut werden, so dass für die Ein- und Auslagerung jeweils unterschiedliche Übergabestationen
verantwortlich sind.
Durch solch einen Aufbau könnten auf dem Förderband ankommende Paletten automatisch eingelagert werden, ohne, dass für jede Palette einzelnd über die Steuerung ein
Auftrag zur Einlagerung angestoßen werden müsste.
55
6.3. LAGERVERWALTUNG
6.3 Lagerverwaltung
In einem reellen Hochregallager werden zur Verfolgung und Identifizierung von Ladeeinheiten Barcodes oder, in neueren Anlagen, auch die berührungslos auslesbaren RFID
(Radio Frequency Identification) Tags benutzt. An geeigneten Punkten im System kann
so überprüft werden, welche Palette diesen passieren [rfi03].
Um etwas ähnliches in dem LEGO Hochregallager umzusetzen, bietet es sich an
z.B den Color Sensor von HiTechnic (siehe Kapitel 3.3.6) zu benutzen. Dieser hat die
Möglichkeit 16 Farben eindeutig zu identifizieren. Auf diese Weise wäre es möglich zumindest 16, entsprechend farbig markierte, Paletten identifizieren und damit verfolgen
zu können. Entsprechende Punkte für den Einsatz eines solchen Sensors wären z.B. an
den Übergabestationen und/oder den Regalbediengeräten.
In dem aktuellen Ausbau bietet das Lagerverwaltungssystem nur die Möglichkeit Paletten, die ausgelagert werden sollen, anhand ihrer Lagerposition zu wählen. Mit Hilfe
eines Farbsensors wäre es möglich, die an der Übergabestation erkannte Farbe der Palette
an das Lagerverwaltungssystem weiterzugeben. Dieses könnte nun in dem Menüsystem
die Möglichkeit anbieten die Farbe der auszulagernden Palette auszuwählen, wobei die
Lagerposition dabei für den Bediener uninteressant wäre.
Den farbigen Paletten könnten auch bestimmte weitere Merkmale zugeordnet werden.
So könnte etwa eine schwarze Palette deutlich höher oder breiter sein als eine rote und
dürfte dementsprechend nur in bestimmten Lagerplätzen, oder Hochregalen, einsortiert
werden, bzw. müsste anders behandelt werden.
Auf diese Weise können auch komplexe Lagerverwaltungssysteme umgesetzt werden,
die darauf ausgerichtet sind, die Umschlagleistung des Lagers zu erhöhen. Erkennt das
Lagerverwaltungssystem beispielsweise, dass eine bestimmte Sorte Paletten sehr häufig
angefordert wird, so könnten diese an einer schneller erreichbaren Position gelagert werden, als eine die weniger oft ein- und ausgelagert wird.
56
7 Fazit und Ausblick
Im Rahmen dieser Bachelorarbeit wurde die Konstruktion so wie Steuerung des RCX
Hochregallagers, so weit dieses zum aktuellen Zeitpunkt möglich ist, mit Hilfe der LEGO
Mindstorms NXT umgesetzt.
Es konnten dabei alle Komponenten des Systems in ähnlicher Form mit den NXT
Bausteinen in der neuen Konstruktionsweise aufgebaut, und zusätzlich, in zeitaufwendiger Detailarbeit, mit entsprechenden CAD Programmen umgesetzt werden. Dabei wurde
versucht die Funktionalität der RCX Modelle zu übernehmen und mit Hilfe der neuen
Sensoren und Aktoren zu erweitern. Dieses ist besonders bei dem autonomen Transportfahrzeug, in Bezug auf die Wegfindung und Kollisionsvermeidung, und den übrigen
Elementen bei der Initialisierung, bemerkbar.
Die umgesetzte Steuerung der einzelnen Komponenten ist in sich komplett und erfüllt
die benötigten Aufgaben. Dabei werden alle durch die Sensoren gegebenen Möglichkeiten
ausgeschöpft, um eine möglichst präzise Arbeitsweise zu gewähren.
Über das eingebaute Menüsystem des Lagerverwaltungssystems lassen sich die einzelnen
Aktionen und komplette Ein- und Auslagerungsvorgänge initiieren.
Allerdings muss berücksichtigt werden, dass die Kommunikation zwischen den einzelnen Komponenten wegen des frühen Entwicklungsstadiums von leJOS NXJ noch eingeschränkt ist. Mit Erscheinen neuerer Versionen von leJOS NXJ sollte die erstellte
Software jedoch ohne Änderungen eine stabile Kommunikation ermöglichen.
Trotzt dieser Umstände ist die Kommunikation in den Grundzügen einsatzbereit und
leicht für zusätzliche Aufgaben erweiterbar.
Das Hochregallager bietet an einigen Stellen weiteren Raum für Ausbau und mögliche
Verbesserungen. Besonders die in Kapitel 6 dargestellten Möglichkeiten bieten einigen Anreiz dafür. Alle der vorgestellten Erweiterungen lassen sich dabei auf Basis der
während dieser Arbeit entwickelten Steuerung und Konstruktion umsetzten.
Im Bezug auf das Ziel dieser Bachelorarbeit bleibt festzuhalten, dass ein komplettes
Hochregallagersystem und dessen Steuerung auf Basis der LEGO Mindstorms NXT in
Verbindung mit leJOS NXJ umgesetzt werden konnte.
57
A UML Diagramme
A.1 Klassendiagramme
«interface »
Protocol
Kommunikation
+ GO_TO
+ GO_TO_RBG
+ GO_TO_UEG
+ IN_RBG_POSITION
+ IN_UEG_POSITION
+ LOADED_RBG
+ LOADED_UEG
+ LOAD_RBG
+ LOAD_UEG
+ UNLOADED_RBG
+ UNLOADED_UEG
+ UNLOAD_RBG
# btc
# btrd
# dis
# dos
# friendlyName
+ Kommunikation()
+ close()
+ getBTConnection()
- «multidimensionalArray» getBytes()
+ getFriendlyName()
+ UNLOAD_UEG
+ receive()
+ send()
+ close()
+ receive()
+ send()
ClientKommunikation
MasterKommunikation
- FRIENDLY_NAME
+ MasterKommunikation()
- connectToMaster()
RBGKommunikation
UEGKommunikation
+ RBGKommunikation()
+ UEGKommunikation()
+ load()
+ load()
+ unload()
+ unload()
ATFKommunikation
+ ATFKommunikation()
+ goTo()
+ goToRBG()
+ goToUEG()
Abbildung A.1: Klassendiagramm upb.hrl.comm
58
A.1. KLASSENDIAGRAMME
ANHANG A. UML DIAGRAMME
ATF
TrackNavigator
- FRIENDLY_NAME
- display
- kommunikation
- navigator
1
- navigator
+ ATF()
+ main()
- kommunikation
- display
1
- DISTANCE
- FRONT_DIFF
- MAP_UNITS
- MARKER_DIFF
- MAX_TURN_ANGLE
- MIN_TURN_ANGLE
- SIDE_DIFF
- SPEED
- TRACK_DIFF
- TRACK_WIDTH
- WHEEL_DIAMETER
- distanceSensor
- lineColor
- markerSensor
- trackSensor
- connectToMaster()
1
+
+
+
+
+
+
+
1
Display
- kommunikation
~ kommunikation
~ navigator
- navigator
1
+ Display()
+ run()
TrackNavigator()
correctPosition()
followLine()
goTo()
initSensors()
markerValue()
onMarker()
onTrack()
roundAngle()
trackValue()
Abbildung A.2: Klassendiagramm des Autonomen Transportfahrzeuges
59
A.2. SEQUENZDIAGRAMME
ANHANG A. UML DIAGRAMME
A.2 Sequenzdiagramme
RC : RC
ATF1 : ATF
RBG1 : RBG
Benutzer
Auslagern
GoToRBGCommand
UnloadRBGCommand
UnloadedRBGCommand
GoToUEGPosition
LoadUEGCommand
LoadedUEGCommand
Abbildung A.3: Sequenzdiagramm Auslagern
60
UEG1 : UEG
B Konstruktionsabbildungen
Abbildung B.1: Das Regalbediengerät mit Hochregal
61
ANHANG B. KONSTRUKTIONSABBILDUNGEN
Abbildung B.2: Das Regalbediengerät
62
ANHANG B. KONSTRUKTIONSABBILDUNGEN
Abbildung B.3: Die Lastaufnahmeeinheit
63
B.1. ANSCHLUSSBELEGUNG ANHANG B. KONSTRUKTIONSABBILDUNGEN
B.1 Anschlussbelegung
Anschluss
Motor A
Motor B
Motor C
Sensor 1
Sensor 2
Sensor 3
Sensor 4
Regalbediengerät
Motor Fahreinheit
Motor Hubeinheit
Motor Lastaufnahme
Taster Fahreinheit
Taster Hubeinheit
Taster Lastaufnahme
-
Übergabestation
Motor Hubeinheit
Motor Lastaufnahme
Taster Hubeinheit
Taster Lastaufnahme
-
Transportfahrzeug
Antrieb links
Antrieb recht
Lichtsensor links
Lichtsensor recht
Abstandssensor
-
Tabelle B.1: Anschlussbelegung der Modelle
64
C Inhalt der beiliegenden CD
Verzeichnis
Beschreibung
bin
Der bin-Ordner enthält die, mit der leJOS NXJ Version auf
dieser CD, kompilierten und gelinkten Binaries. Diese lassen
sich auf, mit der entsprechenden Version der leJOS Firmware
bespielte, NXT Bausteine übertragen. Es ist jedoch empfohlen die Java Sourcen mit einer aktuellen Version von leJOS
erneut zu kompilieren.
ldraw
Dieses Verzeichnis enthält die, mit Hilfe von MLCad und
Bricksmith, umgesetzten Konstruktionsanleitungen und die
entsprechenden Stücklisten. Die Konstruktionsanleitungen
und Stücklisten sind in Form von ldraw und pdf -Dateien
vorhanden.
lejos nxj
Dieser Ordner enthält die, zum kompilieren und linken, benutzte leJOS NXJ Version. Es ist jedoch empfehlenswert
eine aktuelle Version von der leJOS Homepage zu beziehen.
src
In diesem Verzeichnis ist der gesamte Quelltext der umgesetzten Steuerung für die NXT Bausteine gesammelt.
thesis
In diesem Ordner ist diese Bachelorarbeit in Form einer pdf Datei zu finden.
track
Dieser Ordner enthält den benutzten Fahrbahnuntergrund
in Form einer pdf -Datei, so wie die zum Erstellen benutzten
LATEX Sourcen.
Tabelle C.1: Verzeichnisstruktur der beiliegenden CD
65
D Inbetriebnahme
Im Folgenden ist die Inbetriebnahme und Bedienung des Hochregallagers in stichpunktartiger Form dargestellt. Dabei wird nur auf die prinzipiell durchzuführenden Vorgänge
eingegangen, nicht aber alle Einzelschritte erklärt. Es wird davon ausgegangen, dass eine
komplett eingerichtete leJOS NXJ Entwicklungsumgebung zur Verfügung steht.
1. Den Quelltext aus dem src Verzeichnis der CD mit der aktuellen leJOS NXJ Version
kompilieren und linken.
2. Die erhaltenen nxj-Dateien auf auf vier NXT Bausteine übertragen.
3. Über den Menüpunkt Bluetooth der leJOS Firmware sicherstellen, dass die NXT
Bausteine sich untereinander erkennen.
4. Die NXT Bausteine nach der, in Tabelle B.1 gegebenen Anschlussbelegung, mit
den Komponenten des Hochregallagers verbinden.
5. Die Programme auf den NXT Bausteinen starten. Dabei ist zu beachten, dass das
Transportfahrzeug direkt vor dem Initialisierungsbereich positioniert ist, da dieses
sofort damit anfängt zu dem Parkplatz zu fahren.
6. Über das Verbindungsmenü auf dem Controller Baustein die Bluetooth Verbindungen zu allen Komponenten aufbauen.
7. Es lässt sich nun über den Menüpunkt Betrieb auf dem Controller Baustein eine
Einlagerung anstoßen. Dazu sollte sich eine Palette auf der Lastaufnahmeeinheit
der Übergabestation befinden.
66
[Bag02]
Bagnall, Brian: Core Lego Mindstorms Programming: Programming the
RCX in Java. Prentice Hall International, 2002. – ISBN 978–0130093646
[Bag07]
Bagnall, Brian: Maximum LEGO NXT: Building Robots with Java Brains.
Variant Press, 2007. – ISBN 978–0973864915
[BDD+ 07] Boogaarts, Martijn ; Daudelin, Jonathan A. ; Davis, Brian L. ; Kelly,
Jim ; Morris, Lou ; Rhodes, Fay ; Rhodes, Rick ; Scholz, Matthias P.
; Smith, Christopher R. ; Torok, Rob: The LEGO MINDSTORMS NXT
Idea Book. Design, Invent, and Build: Design, Invent and Build. No Starch
Press, 2007. – ISBN 978–1593271503
[Har03]
Harder, Anatolij: Adaptive Antriebsregelung mit Positionsbestimmung für
Roboterfußball – Anwendungen, Universität Paderborn, Diplomarbeit, 2003
[hrl01]
Hochregallager Schmalgangsystem. http://www.ssi-schaefer.at/service/pdf/
Hochregallager.pdf. Version: 2001
[Hur06]
Hurbain, Philippe E.: LEGO Rotation Sensor Internals.
philohome.com/sensors/legorot.htm. Version: 2006
[lag83]
Fachhandbuch Lagertechnik und Betriebseinrichtung. Verband für Lagertechnik und Betriebseinrichtungen, 1983
[lvs07]
Leistungsbeschreibung Lagerverwaltungssystem.
Lagerverwaltungssystem.pdf. Version: 2007
[Mar95]
Martin, Fred G.: The Art of LEGO Design. In: The Robotics Practitioner:
The Journal for Robot Builders 1 (1995), Nr. 2
[Pan02]
Pantzer, Thomas: Echtzeit-Lernverfahren zur Fehlerbegrenzung und Driftkorrektur für Odometrie-basierte Lokalisierungsverfahren.
http://www.
∼
informatik.uni-leipzig.de/ pantec/khepera/diffeq/. Version: 2002
[rcx07]
LEGO MINDSTORMS Internals. http://www.crynwr.com/lego-robotics/.
Version: 2007
[rfi03]
RFID – Optimierung der Value Chain. http://www.gs1austria.at/epc/
downloads/MIP deutsch030505.pdf. Version: 2003
67
http://www.
http://www.tw-online.de/
[SJ91]
Schmidt, Rolf ; Jünemann, Reinhardt: Satellitenlagersysteme. Leistungsbestimmung und Betriebsstrategien. TÜV Media GmbH, 1991. – ISBN 978–
3824900367
[TBF05]
Thrun, Sebastian ; Burgard, Wolfram ; Fox, Dieter: Probabilistic Robotics
(Intelligent Robotics and Autonomous Agents). The MIT Press, 2005. – ISBN
978–0262201629
68

Studienarbeit von Jendrik Bertram

Transcrição

Documentos relacionados

Einführung in die Programmierung von LEGO-Mindstorms

Interview mit Franz Saller, Geschäftsführer Kran

digitales schutznetz ovella digital protection net

Anleitung zur Demontage der

Klausur Sensortechnik WS 09/10 1. Aufgabe 2P 2. Aufgabe 5P 3

Aktueller Kursflyer - Food

Smartphone im Physikunterrichts: Programm des Blockkurses

MONTAGEANLEITUNG

Werkzeuginnendruck-Sensor Mold Pressure Sen

Robot Kit NIBO burger