Callooh Wiki - Benutzerbeiträge [de]

MaDeCo

2011-06-26T23:20:51Z

Alois: /* MaDeCo - Protokoll zur Kommunikation im RoLoMa Projekt */

MaDeCo ist ein sehr einfaches textbasiertes Protokoll für die Kommunikation zwischen den Beteiligten im [[RoLoMa]] Projekt, den [[NIBObee]] Einheiten und der Basisstation, dem [[LPC2478]].

== Rollen ==
Es gibt unter den Beteiligten zwei festgelegte Rollen, Sender und Empfänger. Der Sender überträgt Information, der Empfänger hingegen hat eine überwiegend passive Funktion, er quittiert Nachrichten und übermittelt einen Acknowledge Code.
Während der Kommunikation werden diese Rollen nicht gewechselt.

== Format ==
Eine Nachricht besteht aus genau zwei Datensätzen, ein Datensatz besteht jeweils aus einem 3 Zeichen breiten Header Teil, einem 2 Zeichen breiten Datenteil (je nach Kommando optional oder mandatory) und einem Zeilenende ("\n"), das als einzelnes Zeichen CR (0x0d) realisiert ist.

Beide Teile der Nachricht werden unmittelbar hintereinander gesendet, also z.B. als ''SEQ13\nOPMSM\n''.

Eine Nachricht, wie sie ein Sender erstellt, besteht aus:
<Sequence>
<Command>

;<Sequence>
: besteht aus dem Header ''SEQ'', der Datenteil aus einer Nummer zwischen 1 und 99.
;<Command>
: besteht aus dem 3 Zeichen langen [[MaDeCo#Commands|Command-Code]], und einem entsprechenden Datenteil.

Eine Nachricht muss mit einer Antwort quittiert werden. Diese besteht aus:
<Acknowledge>
<Acknowledge Code>

;<Acknowledge>
: besteht aus dem Header ''ACK'' und der zu bestätigenden Sequence Number.
;<Acknowledge Code>
: besteht aus den Header ''ACC'' und dem [[MaDeCo#Acknowledge Codes|Code]].

Beispiel sind be den jeweiligen [[MaDeCo#Use Cases|Use Cases]] zu finden.

=== Commands ===
EOC ... end of communication, signalisiert das Ende einer Kommunikation
OPM ... Operation Mode (siehe [[MaDeCo#Betriebsmodus|Betriebsmodus]])
WAP ... Waypoint (siehe [[MaDeCo#Wegpunkte|Wegpunkte]])
DIR ... Angabe der Richtung im GO Betriebsmodus (siehe Kürzester Weg)

=== Acknowledge Codes ===
00 .. OK, Command acknowledged
01 .. unknown Command
02 .. invalid data
03 .. overflow (kann z.B. derzeit keine weiteren Richtungsanweisungen entgegennehmen)
11 .. unbekannter Betriebsmodus (e.g. OPMXX)
21 .. command refused, Labyrinth erkunden (OPMSM) vor [[NIBObee#Kalibrierung]] (OPMGA)

=== Betriebsmodus ===
GA ... Kalibrieren (siehe [[NIBObee#Kalibrierung]])
SM ... Labyrinth erkunden
GO ... kürzesten Weg nehmen (siehe Kürzester Weg)

=== Wegpunkte ===
Die Übertragung eines Wegpunkts erfolgt durch Angabe der Richtung (S,W,N,E), gefolgt von der Anzahl der Streckenteile.
Beispiel: WAPS4 der Wegpunkt befindet sich 4 Streckenteile südlich des zuletzt übertragenen Wegpunkts

== Ablauf ==
Im [[RoLoMa]] Projekt muss die Kommunikation aus Nachricht-Antwort Sequenzen bestehen. Wird eine gesendete Nachricht nicht bestätigt, erfolgt eine Neuübertragung nach dem RETRANSMISSION_TIMEOUT Interval.
Erfolgt auch nach RETRANSMISSION_COUNT Wiederholungen keine Antwort, wird die Übertragung abgebrochen und ein Fehler signalisiert.

Kommunikationen überschneiden sich nicht, das bedeutet, es findet zu jedem Zeitpunkt nur eine Kommunikation zwischen den Beteiligten statt. Daher ist auch zu jedem Zeitpunkt genau ein Teilnehmer der Sender, und ein Teilnehmer der Empfänger.

== Use Cases ==
Im folgenden werden Beispiele für die Kommunikation der unterschiedlichen Betriebsarten dargestellt. Daten vom Board werden normal, die von der NIBObee '''fett''' dargestellt.

=== Kalibrieren ===
Beim Kalibrieren wird das Kommando vom Board an die NIBObee geschickt und auch bei Erhalt sofort quittiert (sonst würde es zu einem Timeout kommen). Nachdem die Kalibrierung abgeschlossen ist wird die Verbindung getrennt.

''Beispiel:''
SEQ1
OPMGA

'''ACK1'''
'''ACC00'''

'''SEQ2'''
'''EOC'''

ACK2
ACC00

=== Labyrinth erkunden===
Das Kommando wird vom Board an die NIBObee geschickt und auch bei Erhalt sofort quittiert (es muss vorher allerdings eine Kalibrierung durchgeführt worden sein). Danach werden laufend die Punkte geschickt die abgefahren werden. Wenn das ganze Labyrinth erfasst wurde wir die Kommunikation wieder beendet.

''Beispiel:''
SEQ1
OPMSM

'''ACK1'''
'''ACC00'''

'''SEQ2'''
'''WAPN3'''

ACK2
ACC00

'''SEQ3'''
'''WAPE1'''

...

'''SEQ32'''
'''EOC'''

ACK32
ACC00

=== Kürzester Weg ===
Hier werden Richtungsanweisungen übertragen, die es der [[NIBObee]] ermöglichen, in einem Labyrinth den kürzesten Weg zu nehmen. Die Richtungen werden wieder mit Himmelsrichtungen beschrieben, diesmal allerdings ohne Längenangabe da immer bis zur nächsten Kreuzung gefahren wird.
In dem Beispiel wird der kürzeste Weg als S(üd)-W(est)-N(ord)-W(est) angegeben:
SEQ1
OPMGO

'''ACK1'''
'''ACC00'''

SEQ2
DIRS

'''ACK2'''
'''ACC00'''

SEQ3
DIRW

'''ACK3'''
'''ACC00'''

SEQ4
DIRN

'''ACK4'''
'''ACC00'''

SEQ5
DIRW

'''ACK5'''
'''ACC00'''

SEQ6
EOC

'''ACK6'''
'''ACC00'''

[[Kategorie:FH]]

MaDeCo

2011-06-26T23:04:52Z

Alois: /* Format */

= MaDeCo - Protokoll zur Kommunikation im [[RoLoMa]] Projekt =

MaDeCo ist ein sehr einfaches textbasiertes Protokoll für die Kommunikation zwischen den Beteiligten im [[RoLoMa]] Projekt, den [[NIBObee]] Einheiten und der Basisstation, dem [[LPC2478]].

== Rollen ==
Es gibt unter den Beteiligten zwei festgelegte Rollen, Sender und Empfänger. Der Sender überträgt Information, der Empfänger hingegen hat eine überwiegend passive Funktion, er quittiert Nachrichten und übermittelt einen Acknowledge Code.
Während der Kommunikation werden diese Rollen nicht gewechselt.

== Format ==
Eine Nachricht besteht aus genau zwei Datensätzen, ein Datensatz besteht jeweils aus einem 3 Zeichen breiten Header Teil, einem 2 Zeichen breiten Datenteil (je nach Kommando optional oder mandatory) und einem Zeilenende ("\n"), das als einzelnes Zeichen CR (0x0d) realisiert ist.

Beide Teile der Nachricht werden unmittelbar hintereinander gesendet, also z.B. als ''SEQ13\nOPMSM\n''.

Eine Nachricht, wie sie ein Sender erstellt, besteht aus:
<Sequence>
<Command>

;<Sequence>
: besteht aus dem Header ''SEQ'', der Datenteil aus einer Nummer zwischen 1 und 99.
;<Command>
: besteht aus dem 3 Zeichen langen [[MaDeCo#Commands|Command-Code]], und einem entsprechenden Datenteil.

Eine Nachricht muss mit einer Antwort quittiert werden. Diese besteht aus:
<Acknowledge>
<Acknowledge Code>

;<Acknowledge>
: besteht aus dem Header ''ACK'' und der zu bestätigenden Sequence Number.
;<Acknowledge Code>
: besteht aus den Header ''ACC'' und dem [[MaDeCo#Acknowledge Codes|Code]].

Beispiel sind be den jeweiligen [[MaDeCo#Use Cases|Use Cases]] zu finden.

=== Commands ===
EOC ... end of communication, signalisiert das Ende einer Kommunikation
OPM ... Operation Mode (siehe [[MaDeCo#Betriebsmodus|Betriebsmodus]])
WAP ... Waypoint (siehe [[MaDeCo#Wegpunkte|Wegpunkte]])
DIR ... Angabe der Richtung im GO Betriebsmodus (siehe Kürzester Weg)

=== Acknowledge Codes ===
00 .. OK, Command acknowledged
01 .. unknown Command
02 .. invalid data
03 .. overflow (kann z.B. derzeit keine weiteren Richtungsanweisungen entgegennehmen)
11 .. unbekannter Betriebsmodus (e.g. OPMXX)
21 .. command refused, Labyrinth erkunden (OPMSM) vor [[NIBObee#Kalibrierung]] (OPMGA)

=== Betriebsmodus ===
GA ... Kalibrieren (siehe [[NIBObee#Kalibrierung]])
SM ... Labyrinth erkunden
GO ... kürzesten Weg nehmen (siehe Kürzester Weg)

=== Wegpunkte ===
Die Übertragung eines Wegpunkts erfolgt durch Angabe der Richtung (S,W,N,E), gefolgt von der Anzahl der Streckenteile.
Beispiel: WAPS4 der Wegpunkt befindet sich 4 Streckenteile südlich des zuletzt übertragenen Wegpunkts

== Ablauf ==
Im [[RoLoMa]] Projekt muss die Kommunikation aus Nachricht-Antwort Sequenzen bestehen. Wird eine gesendete Nachricht nicht bestätigt, erfolgt eine Neuübertragung nach dem RETRANSMISSION_TIMEOUT Interval.
Erfolgt auch nach RETRANSMISSION_COUNT Wiederholungen keine Antwort, wird die Übertragung abgebrochen und ein Fehler signalisiert.

Kommunikationen überschneiden sich nicht, das bedeutet, es findet zu jedem Zeitpunkt nur eine Kommunikation zwischen den Beteiligten statt. Daher ist auch zu jedem Zeitpunkt genau ein Teilnehmer der Sender, und ein Teilnehmer der Empfänger.

== Use Cases ==
Im folgenden werden Beispiele für die Kommunikation der unterschiedlichen Betriebsarten dargestellt. Daten vom Board werden normal, die von der NIBObee '''fett''' dargestellt.

=== Kalibrieren ===
Beim Kalibrieren wird das Kommando vom Board an die NIBObee geschickt und auch bei Erhalt sofort quittiert (sonst würde es zu einem Timeout kommen). Nachdem die Kalibrierung abgeschlossen ist wird die Verbindung getrennt.

''Beispiel:''
SEQ1
OPMGA

'''ACK1'''
'''ACC00'''

'''SEQ2'''
'''EOC'''

ACK2
ACC00

=== Labyrinth erkunden===
Das Kommando wird vom Board an die NIBObee geschickt und auch bei Erhalt sofort quittiert (es muss vorher allerdings eine Kalibrierung durchgeführt worden sein). Danach werden laufend die Punkte geschickt die abgefahren werden. Wenn das ganze Labyrinth erfasst wurde wir die Kommunikation wieder beendet.

''Beispiel:''
SEQ1
OPMSM

'''ACK1'''
'''ACC00'''

'''SEQ2'''
'''WAPN3'''

ACK2
ACC00

'''SEQ3'''
'''WAPE1'''

...

'''SEQ32'''
'''EOC'''

ACK32
ACC00

=== Kürzester Weg ===
Hier werden Richtungsanweisungen übertragen, die es der [[NIBObee]] ermöglichen, in einem Labyrinth den kürzesten Weg zu nehmen. Die Richtungen werden wieder mit Himmelsrichtungen beschrieben, diesmal allerdings ohne Längenangabe da immer bis zur nächsten Kreuzung gefahren wird.
In dem Beispiel wird der kürzeste Weg als S(üd)-W(est)-N(ord)-W(est) angegeben:
SEQ1
OPMGO

'''ACK1'''
'''ACC00'''

SEQ2
DIRS

'''ACK2'''
'''ACC00'''

SEQ3
DIRW

'''ACK3'''
'''ACC00'''

SEQ4
DIRN

'''ACK4'''
'''ACC00'''

SEQ5
DIRW

'''ACK5'''
'''ACC00'''

SEQ6
EOC

'''ACK6'''
'''ACC00'''

[[Kategorie:FH]]

NIBObee

2011-06-26T18:50:29Z

Alois:

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
Hier wird nur ein kleiner Ausschnitt der technischen Daten dargestellt. Es handelt sich nur um jenen Teil der für die Bewertung oder Implementierung der gestellten Aufgaben relevant ist:

{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|RAM: 1 kB
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar.

Zwei Analoge Eingänge werden für die Fototransistoren der zusätzlichen Linienerkennung verwendet. Diese sind am NIBObee am Port X1 verfügbar.

Ein Ausgang dient zum ein- und ausschalten der zusätzlichen IR-LEDs. Dafür wird der PIN 1 des Port X4 verwendet.

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===

==== ATMega16 ====
Die Speichergröße scheint durchaus ausreichend zu sein. Nach Implementierung aller wichtigen Grundfunktionen ist erst weniger als die Hälfte des Programmspeichers belegt.

Problematisch war anfangs nur der geringe RAM der auch alle konstanten Strings enthält. Dies ist zwar nicht notwendig, ist mit dieser Entwicklungsumgebung allerdings so gelöst. Besonders die umfangreichen Debug-Informationen die über Bluetooth an den PC gesendet werden führten dabei zu massiven Problemen. Durch kurze symbolische Debugausgaben, die dann am PC im eigens entwickelten Terminalprogramm auf sprechende symbolische Ausgabe konvertiert wird, konnte das Problem behoben werden.

==== Liniensensoren ====
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
Die original NIBObee Biliothek wird nicht verwendet. Sie wurde durch eine eigene Implementierung im [[NIBObee#Line-Modul|Line-Modul]] ersetzt. Der Grund ist die Notwendigkeit die zusätzlichen Liniensensoren in der gleichen Weise wie die drei Originalsensoren zu behandeln.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen Gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

Nach einigen ersten Tests ist folgende weitere Aufgabe hinzugekommen:
* Herstellung der Hardware-Erweiterung mit zusätzlichen Liniensensoren

=== Aufgabenteilung ===
Alle Aufgaben wurden im Team gelöst wobei für manche dieser Aufgaben der Schwerpunkt bei nur einem oder zwei Teammitgliedern lag. Die folgende Tabelle gibt eine ungefähre Zuordnung der Aufgaben auf die einzelnen Personen:

{| class="wikitable"
|-
|colspan="3"|'''Dokumentation'''
|-

|rowspan="3"| 
|Projektfortschritt, Controlling
|Robert Peterfi
|-

|Hardware, Software (Wiki)
|Alois Pochmann, Reinhard Weismann
|-

|Codedokumentation
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|-
|colspan="3"|'''Hardware'''
|-

|rowspan="3"| 
|Entwurf, Design
|Alois Pochmann
|-

|Bestellung, Aufbau
|Robert Peterfi, Alois Pochmann
|-

|Test
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|-
|colspan="3"|'''Software'''
|-

|rowspan="8"| 
|Design, Funktionsaufteilung
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|Kommunikationsprotokoll
|Reinhard Weismann
|-

|Scheduler, Event Handling, zentrale Funktionen
|Alois Pochmann
|-

|Sensoren (Hardwareanbindung)
|Robert Peterfi
|-

|Kalibrierung
|Robert Peterfi
|-

|Odometrie
|Reinhard Weismann
|-

|Bewegungssteuerung
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|Testapplikation (Windows)
|Alois Pochmann
|-

|}

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem Folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusatzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das Einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt über Events und, wenn nur eine spezielle Funktionalität eines anderen Moduls verwendet werden soll ohne dessen Zustand zu beeinflussen, über Funktionsaufrufe (z.B. senden einer MaDeCo-Meldung zum reporten eines Wegpunktes direkt vom drive Modul). Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 1 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. überprüfen des Status der "Fühler"). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird direkt vom Scheduler mit dem aktuell zu verarbeitenden Event aufgerufen. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und eventuell die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul optional verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog-Modul ====
Digitalisieren der Analogeingänge
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Der Austausch war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet, dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16, die Behandlung der Messung der Batteriespannung verbessert. Da hier die Referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.
Die einzelnen Werte werden weiterhin über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt nun 13 analoge Werte (statt bisher 11) die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von ca 117 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 111 µs (statt bisher 94 µs) aktualisiert wird.

==== Line-Modul ====
Ermitteln der Werte der Liniensensoren
Dateien: line.c
line.h
Dieser Modul ersetzt die originalen Bibliotheksfunktionen der Liniensensoren. Dies war notwendig da wir zusätzliche Liniensensoren verwenden.

Die Werte der Liniensensoren können nun mit der Funktion
<code>ln_get(index)</code>
gelesen werden. Die Werte selbst werden über den [[NIBObee#Analog-Modul|Analog-Modul]] ermittelt.

==== Bluetooth-Modul ====
Wickelt die Kommunikation über den Bluetooth Modul ab. Zur Kommunikation wird allerdings nur der USART als Terminal angesprochen, der Bluetooth Stack ist im [[BTM-222]] implementiert.
Dateien: bluetooth.c
bluetooth.h

==== Common-Modul ====
Stellt gemeinsame Funktionen zurVerfügung
Dateien: common.c
common.h

==== Distance-Modul ====
Behandelt die Odometrie Sensoren
Dateien: distance.c
distance.h

==== Drive-Modul ====
Bewegt den NIBObee
Dateien: drive.c
drive.h

==== Follow-Modul ====
Ist für die Linienverfolgung zuständig
Dateien: follow.c
follow.h

==== MaDeCo-Modul ====
Behandelt das MaDeCo Protokoll
Dateien: madeco.c
madeco.h

==== Main-Modul ====
Scheduler und zentraler Taktgeber
Dateien: main.c
main.h

==== Sensor-Modul ====
Ist für die "Fühler" zuständig
Dateien: follow.c
follow.h

=== Applikationen ===
==== Labyrinth erkunden ====
Das ist die Hauptaufgabe des NIBObee. Der Anstoß kommt über einen Befehl vom Board. Ausgewertet wird das vom MaDeCo Modul der auch überprüft ob bereits eine Kalibrierung durchgeführt wurde. Wenn diese Prüfung erfolgreich ist wird der Drive Modul beauftragt das Labyrinth abzufahren. Dort wird nun von einer Kreuzung zur nächsten navigiert und jeder Punkt über den MaDeCo Modul an das Bord gemeldet. Bei jeder Kreuzung wird so weit wie möglich rechts abgebogen bis der NIBObee wieder am Ausgangspunkt angelangt ist.

==== Kürzesten Weg durch Labyrinth ====
Der MaDeCo Modul erhält vom Board die Richtungsanweisungen für den NIBObee und speichert diese in einem Buffer. Die erste Anweisung wird an den Drive Modul gesendet und der navigiert dann zum nächsten Kreuzungspunkt. Dann wird eine Anfrage an den MaDeCo Modul gesendet um den nächsten Punkt aus dem Buffer zu bekommen. Das passiert solange Daten vorhanden sind und nicht das Ende vom Board signalisiert wurde.

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können. Es werden dabei die Anzahl der Schritte der Odometrie für die Länge eines Feldes sowie für eine 90° Rotation als Referenzwerte ermittelt und im EEPROM gespeichert.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
Neben der State Machine die per Event kommuniziert ist auch noch ein Funktionsinterface vorhanden
===== Message Interface Definition =====
* Empfang der Kommandos vom Bluetooth Modul
* Start/Ende and Drive Modul
* Status und Ende vom Drive Modul
===== Function Interface Definition =====
* void ma_sendWap(uint8_t direction, uint8_t length);
** Senden eines Wegpunktes an das Board direkt vom Drive Modul

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* read_data
* send_data

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Auf explizites Einschalten, z.B. durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten, des Bluetooth Moduls wird verzichtet. Der Bluetooth Modul wird beim Systemstart aktiviert und ab diesem Zeitpunkt muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Die Status LEDs werden verwendet um Basisinformationen über das System zu signalisieren. Die LED 3 (rechte gelbe LED) dient als Heartbeat. Sie blinkt im 1 Sekunden-Takt sobald das System läuft. Die Beiden roten LEDs werden verwendet um Exception Situationen zu signalisieren wie zum Beispiel:
* Überschneidender Aufruf der Timerinterrupt Behandlungsroutine (nested Interrupt)
* Overflow des Empfangsbuffers für Bluetooth-Verbindung

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall kann das aber auch bedeuten dass wir soeben eine Kreuzung überfahren. Das kann durch die zusätzlichen Sensoren festgestellt werden und solange müssen wir diese Korrektur auch verzögern. Erst nachdem die zusätzlichen Sensoren keine querende Linie mehr erkennen können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren haben oder ob tatsächlich eine Abweichung vorliegt.

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu bekommt der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings im Falle einer Kreuzung verzögert bis diese überfahren wurde.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 1 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

: ''Mit Fortschreiten des Projekts hat sich immer mehr gezeigt dass die Anforderung die Leistungsfähigleiten des Controllers nicht überfordern. Bereits mit einem Großteil der Implementierung wurde nur ca die Hälfte des Verfügbareb Speichers verbraucht''

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

: ''Es war nicht notwendig auf PC-Kabellösungen zu setzen da der Bluetooth Modul ausreichend schnell fertiggestellt werden konnte (ohne kritische Verzögerungen im Projekt zu verursachen) und dann auch sehr schnell in Betrieb genommen werden konnte''

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
** Nachdem ein Großteil der Funktionalität implementiert war hat eine Überprüfung ausreichende Reserven gezeigt (ca 50% freier Speicher verfügbar)
* Wie kann das Verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
** Zusatzsensoren mussten gebaut werden. Die Wartezeit konnte mit anderen Tätigkeiten gefüllt werden so dass die Auswirkungen auf das Projekt in Summe gring waren.
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
** Es wurde beschlossen die Bluetooth Schnittstelle sofort zu aktivieren wenn das System gestartet wir. Das vereinfacht die Implementierung und ermöglicht ausserdem Debuginformationen über dieses Interface zu senden.
* Soll der Betriebsmodus gewählt werden können?
** Der Betriebsmodus wird vom Board per [[MaDeCo]] Kommando ausgewählt

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-06-25T08:09:33Z

Alois: /* Protokolle und deren Implementierung */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
Hier wird nur ein kleiner Ausschnitt der technischen Daten dargestellt. Es handelt sich nur um jenen Teil der für die Bewertung oder Implementierung der gestellten Aufgaben relevant ist:

{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|RAM: 1 kB
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar.

Zwei Analoge Eingänge werden für die Fototransistoren der zusätzlichen Linienerkennung verwendet. Diese sind am NIBObee am Port X1 verfügbar.

Ein Ausgang dient zum ein- und ausschalten der zusätzlichen IR-LEDs. Dafür wird der PIN 1 des Port X4 verwendet.

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===

==== ATMega16 ====
Die Speichergröße scheint durchaus ausreichend zu sein. Nach Implementierung aller wichtigen Grundfunktionen ist erst weniger als die Hälfte des Programmspeichers belegt.

Problematisch war anfangs nur der geringe RAM der auch alle konstanten Strings enthält. Dies ist zwar nicht notwendig, ist mit dieser Entwicklungsumgebung allerdings so gelöst. Besonders die umfangreichen Debug-Informationen die über Bluetooth an den PC gesendet werden führten dabei zu massiven Problemen. Durch kurze symbolische Debugausgaben, die dann am PC im eigens entwickelten Terminalprogramm auf sprechende symbolische Ausgabe konvertiert wird, konnte das Problem behoben werden.

==== Liniensensoren ====
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
Die original NIBObee Biliothek wird nicht verwendet. Sie wurde durch eine eigene Implementierung im [[NIBObee#Line-Modul|Line-Modul]] ersetzt. Der Grund ist die Notwendigkeit die zusätzlichen Liniensensoren in der gleichen Weise wie die drei Originalsensoren zu behandeln.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen Gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

Nach einigen ersten Tests ist folgende weitere Aufgabe hinzugekommen:
* Herstellung der Hardware-Erweiterung mit zusätzlichen Liniensensoren

=== Aufgabenteilung ===
Alle Aufgaben wurden im Team gelöst wobei für manche dieser Aufgaben der Schwerpunkt bei nur einem oder zwei Teammitgliedern lag. Die folgende Tabelle gibt eine ungefähre Zuordnung der Aufgaben auf die einzelnen Personen:

{| class="wikitable"
|-
|colspan="3"|'''Dokumentation'''
|-

|rowspan="3"| 
|Projektfortschritt, Controlling
|Robert Peterfi
|-

|Hardware, Software (Wiki)
|Alois Pochmann, Reinhard Weismann
|-

|Codedokumentation
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|-
|colspan="3"|'''Hardware'''
|-

|rowspan="3"| 
|Entwurf, Design
|Alois Pochmann
|-

|Bestellung, Aufbau
|Robert Peterfi, Alois Pochmann
|-

|Test
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|-
|colspan="3"|'''Software'''
|-

|rowspan="8"| 
|Design, Funktionsaufteilung
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|Kommunikationsprotokoll
|Reinhard Weismann
|-

|Scheduler, Event Handling, zentrale Funktionen
|Alois Pochmann
|-

|Sensoren (Hardwareanbindung)
|Robert Peterfi
|-

|Kalibrierung
|Robert Peterfi
|-

|Odometrie
|Reinhard Weismann
|-

|Bewegungssteuerung
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|Testapplikation (Windows)
|Alois Pochmann
|-

|}

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem Folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusatzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das Einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt über Events und, wenn nur eine spezielle Funktionalität eines anderen Moduls verwendet werden soll ohne dessen Zustand zu beeinflussen, über Funktionsaufrufe (z.B. senden einer MaDeCo-Meldung zum reporten eines Wegpunktes direkt vom drive Modul). Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 1 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. überprüfen des Status der "Fühler"). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird direkt vom Scheduler mit dem aktuell zu verarbeitenden Event aufgerufen. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und eventuell die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul optional verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog-Modul ====
Digitalisieren der Analogeingänge
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Der Austausch war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet, dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16, die Behandlung der Messung der Batteriespannung verbessert. Da hier die Referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.
Die einzelnen Werte werden weiterhin über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt nun 13 analoge Werte (statt bisher 11) die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von ca 117 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 111 µs (statt bisher 94 µs) aktualisiert wird.

==== Line-Modul ====
Ermitteln der Werte der Liniensensoren
Dateien: line.c
line.h
Dieser Modul ersetzt die originalen Bibliotheksfunktionen der Liniensensoren. Dies war notwendig da wir zusätzliche Liniensensoren verwenden.

Die Werte der Liniensensoren können nun mit der Funktion
<code>ln_get(index)</code>
gelesen werden. Die Werte selbst werden über den [[NIBObee#Analog-Modul|Analog-Modul]] ermittelt.

==== Bluetooth-Modul ====
Wickelt die Kommunikation über den Bluetooth Modul ab. Zur Kommunikation wird allerdings nur der USART als Terminal angesprochen, der Bluetooth Stack ist im [[BTM-222]] implementiert.
Dateien: bluetooth.c
bluetooth.h

==== Common-Modul ====
Stellt gemeinsame Funktionen zurVerfügung
Dateien: common.c
common.h

==== Distance-Modul ====
Behandelt die Odometrie Sensoren
Dateien: distance.c
distance.h

==== Drive-Modul ====
Bewegt den NIBObee
Dateien: drive.c
drive.h

==== Follow-Modul ====
Ist für die Linienverfolgung zuständig
Dateien: follow.c
follow.h

==== MaDeCo-Modul ====
Behandelt das MaDeCo Protokoll
Dateien: madeco.c
madeco.h

==== Main-Modul ====
Scheduler und zentraler Taktgeber
Dateien: main.c
main.h

==== Sensor-Modul ====
Ist für die "Fühler" zuständig
Dateien: follow.c
follow.h

=== Applikationen ===
==== Labyrinth erkunden ====
Das ist die Hauptaufgabe des NIBObee. Der Anstoß kommt über einen Befehl vom Board. Ausgewertet wird das vom MaDeCo Modul der auch überprüft ob bereits eine Kalibrierung durchgeführt wurde. Wenn diese Prüfung erfolgreich ist wird der Drive Modul beauftragt das Labyrinth abzufahren. Dort wird nun von einer Kreuzung zur nächsten navigiert und jeder Punkt über den MaDeCo Modul an das Bord gemeldet. Bei jeder Kreuzung wird so weit wie möglich rechts abgebogen bis der NIBObee wieder am Ausgangspunkt angelangt ist.

==== Kürzesten Weg durch Labyrinth ====
Der MaDeCo Modul erhält vom Board die Richtungsanweisungen für den NIBObee und speichert diese in einem Buffer. Die erste Anweisung wird an den Drive Modul gesendet und der navigiert dann zum nächsten Kreuzungspunkt. Dann wird eine Anfrage an den MaDeCo Modul gesendet um den nächsten Punkt aus dem Buffer zu bekommen. Das passiert solange Daten vorhanden sind und nicht das Ende vom Board signalisiert wurde.

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können. Es werden dabei die Anzahl der Schritte der Odometrie für die Länge eines Feldes sowie für eine 90° Rotation als Referenzwerte ermittelt und im EEPROM gespeichert.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
Neben der State Machine die per Event kommuniziert ist auch noch ein Funktionsinterface vorhanden
===== Message Interface Definition =====
* Empfang der Kommandos vom Bluetooth Modul
* Start/Ende and Drive Modul
* Status und Ende vom Drive Modul
===== Function Interface Definition =====
* void ma_sendWap(uint8_t direction, uint8_t length);
** Senden eines Wegpunktes an das Board direkt vom Drive Modul

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* read_data
* send_data

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-06-25T08:04:29Z

Alois: /* MaDeCo */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
Hier wird nur ein kleiner Ausschnitt der technischen Daten dargestellt. Es handelt sich nur um jenen Teil der für die Bewertung oder Implementierung der gestellten Aufgaben relevant ist:

{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|RAM: 1 kB
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar.

Zwei Analoge Eingänge werden für die Fototransistoren der zusätzlichen Linienerkennung verwendet. Diese sind am NIBObee am Port X1 verfügbar.

Ein Ausgang dient zum ein- und ausschalten der zusätzlichen IR-LEDs. Dafür wird der PIN 1 des Port X4 verwendet.

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===

==== ATMega16 ====
Die Speichergröße scheint durchaus ausreichend zu sein. Nach Implementierung aller wichtigen Grundfunktionen ist erst weniger als die Hälfte des Programmspeichers belegt.

Problematisch war anfangs nur der geringe RAM der auch alle konstanten Strings enthält. Dies ist zwar nicht notwendig, ist mit dieser Entwicklungsumgebung allerdings so gelöst. Besonders die umfangreichen Debug-Informationen die über Bluetooth an den PC gesendet werden führten dabei zu massiven Problemen. Durch kurze symbolische Debugausgaben, die dann am PC im eigens entwickelten Terminalprogramm auf sprechende symbolische Ausgabe konvertiert wird, konnte das Problem behoben werden.

==== Liniensensoren ====
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
Die original NIBObee Biliothek wird nicht verwendet. Sie wurde durch eine eigene Implementierung im [[NIBObee#Line-Modul|Line-Modul]] ersetzt. Der Grund ist die Notwendigkeit die zusätzlichen Liniensensoren in der gleichen Weise wie die drei Originalsensoren zu behandeln.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen Gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

Nach einigen ersten Tests ist folgende weitere Aufgabe hinzugekommen:
* Herstellung der Hardware-Erweiterung mit zusätzlichen Liniensensoren

=== Aufgabenteilung ===
Alle Aufgaben wurden im Team gelöst wobei für manche dieser Aufgaben der Schwerpunkt bei nur einem oder zwei Teammitgliedern lag. Die folgende Tabelle gibt eine ungefähre Zuordnung der Aufgaben auf die einzelnen Personen:

{| class="wikitable"
|-
|colspan="3"|'''Dokumentation'''
|-

|rowspan="3"| 
|Projektfortschritt, Controlling
|Robert Peterfi
|-

|Hardware, Software (Wiki)
|Alois Pochmann, Reinhard Weismann
|-

|Codedokumentation
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|-
|colspan="3"|'''Hardware'''
|-

|rowspan="3"| 
|Entwurf, Design
|Alois Pochmann
|-

|Bestellung, Aufbau
|Robert Peterfi, Alois Pochmann
|-

|Test
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|-
|colspan="3"|'''Software'''
|-

|rowspan="8"| 
|Design, Funktionsaufteilung
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|Kommunikationsprotokoll
|Reinhard Weismann
|-

|Scheduler, Event Handling, zentrale Funktionen
|Alois Pochmann
|-

|Sensoren (Hardwareanbindung)
|Robert Peterfi
|-

|Kalibrierung
|Robert Peterfi
|-

|Odometrie
|Reinhard Weismann
|-

|Bewegungssteuerung
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|Testapplikation (Windows)
|Alois Pochmann
|-

|}

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem Folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusatzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das Einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt über Events und, wenn nur eine spezielle Funktionalität eines anderen Moduls verwendet werden soll ohne dessen Zustand zu beeinflussen, über Funktionsaufrufe (z.B. senden einer MaDeCo-Meldung zum reporten eines Wegpunktes direkt vom drive Modul). Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 1 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. überprüfen des Status der "Fühler"). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird direkt vom Scheduler mit dem aktuell zu verarbeitenden Event aufgerufen. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und eventuell die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul optional verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog-Modul ====
Digitalisieren der Analogeingänge
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Der Austausch war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet, dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16, die Behandlung der Messung der Batteriespannung verbessert. Da hier die Referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.
Die einzelnen Werte werden weiterhin über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt nun 13 analoge Werte (statt bisher 11) die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von ca 117 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 111 µs (statt bisher 94 µs) aktualisiert wird.

==== Line-Modul ====
Ermitteln der Werte der Liniensensoren
Dateien: line.c
line.h
Dieser Modul ersetzt die originalen Bibliotheksfunktionen der Liniensensoren. Dies war notwendig da wir zusätzliche Liniensensoren verwenden.

Die Werte der Liniensensoren können nun mit der Funktion
<code>ln_get(index)</code>
gelesen werden. Die Werte selbst werden über den [[NIBObee#Analog-Modul|Analog-Modul]] ermittelt.

==== Bluetooth-Modul ====
Wickelt die Kommunikation über den Bluetooth Modul ab. Zur Kommunikation wird allerdings nur der USART als Terminal angesprochen, der Bluetooth Stack ist im [[BTM-222]] implementiert.
Dateien: bluetooth.c
bluetooth.h

==== Common-Modul ====
Stellt gemeinsame Funktionen zurVerfügung
Dateien: common.c
common.h

==== Distance-Modul ====
Behandelt die Odometrie Sensoren
Dateien: distance.c
distance.h

==== Drive-Modul ====
Bewegt den NIBObee
Dateien: drive.c
drive.h

==== Follow-Modul ====
Ist für die Linienverfolgung zuständig
Dateien: follow.c
follow.h

==== MaDeCo-Modul ====
Behandelt das MaDeCo Protokoll
Dateien: madeco.c
madeco.h

==== Main-Modul ====
Scheduler und zentraler Taktgeber
Dateien: main.c
main.h

==== Sensor-Modul ====
Ist für die "Fühler" zuständig
Dateien: follow.c
follow.h

=== Applikationen ===
==== Labyrinth erkunden ====
Das ist die Hauptaufgabe des NIBObee. Der Anstoß kommt über einen Befehl vom Board. Ausgewertet wird das vom MaDeCo Modul der auch überprüft ob bereits eine Kalibrierung durchgeführt wurde. Wenn diese Prüfung erfolgreich ist wird der Drive Modul beauftragt das Labyrinth abzufahren. Dort wird nun von einer Kreuzung zur nächsten navigiert und jeder Punkt über den MaDeCo Modul an das Bord gemeldet. Bei jeder Kreuzung wird so weit wie möglich rechts abgebogen bis der NIBObee wieder am Ausgangspunkt angelangt ist.

==== Kürzesten Weg durch Labyrinth ====
Der MaDeCo Modul erhält vom Board die Richtungsanweisungen für den NIBObee und speichert diese in einem Buffer. Die erste Anweisung wird an den Drive Modul gesendet und der navigiert dann zum nächsten Kreuzungspunkt. Dann wird eine Anfrage an den MaDeCo Modul gesendet um den nächsten Punkt aus dem Buffer zu bekommen. Das passiert solange Daten vorhanden sind und nicht das Ende vom Board signalisiert wurde.

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können. Es werden dabei die Anzahl der Schritte der Odometrie für die Länge eines Feldes sowie für eine 90° Rotation als Referenzwerte ermittelt und im EEPROM gespeichert.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
Neben der State Machine die per Event kommuniziert ist auch noch ein Funktionsinterface vorhanden
===== Message Interface Definition =====
Das Bild zeigt die State Machine des MaDeCo Moduls mit den unterstützten Events
===== Function Interface Definition =====
;void ma_sendWap(uint8_t direction, uint8_t length);
:Senden eines Wegpunktes an das Board direkt vom Drive Modul

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-06-25T07:55:49Z

Alois: /* Kalibrierung */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
Hier wird nur ein kleiner Ausschnitt der technischen Daten dargestellt. Es handelt sich nur um jenen Teil der für die Bewertung oder Implementierung der gestellten Aufgaben relevant ist:

{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|RAM: 1 kB
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar.

Zwei Analoge Eingänge werden für die Fototransistoren der zusätzlichen Linienerkennung verwendet. Diese sind am NIBObee am Port X1 verfügbar.

Ein Ausgang dient zum ein- und ausschalten der zusätzlichen IR-LEDs. Dafür wird der PIN 1 des Port X4 verwendet.

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===

==== ATMega16 ====
Die Speichergröße scheint durchaus ausreichend zu sein. Nach Implementierung aller wichtigen Grundfunktionen ist erst weniger als die Hälfte des Programmspeichers belegt.

Problematisch war anfangs nur der geringe RAM der auch alle konstanten Strings enthält. Dies ist zwar nicht notwendig, ist mit dieser Entwicklungsumgebung allerdings so gelöst. Besonders die umfangreichen Debug-Informationen die über Bluetooth an den PC gesendet werden führten dabei zu massiven Problemen. Durch kurze symbolische Debugausgaben, die dann am PC im eigens entwickelten Terminalprogramm auf sprechende symbolische Ausgabe konvertiert wird, konnte das Problem behoben werden.

==== Liniensensoren ====
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
Die original NIBObee Biliothek wird nicht verwendet. Sie wurde durch eine eigene Implementierung im [[NIBObee#Line-Modul|Line-Modul]] ersetzt. Der Grund ist die Notwendigkeit die zusätzlichen Liniensensoren in der gleichen Weise wie die drei Originalsensoren zu behandeln.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen Gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

Nach einigen ersten Tests ist folgende weitere Aufgabe hinzugekommen:
* Herstellung der Hardware-Erweiterung mit zusätzlichen Liniensensoren

=== Aufgabenteilung ===
Alle Aufgaben wurden im Team gelöst wobei für manche dieser Aufgaben der Schwerpunkt bei nur einem oder zwei Teammitgliedern lag. Die folgende Tabelle gibt eine ungefähre Zuordnung der Aufgaben auf die einzelnen Personen:

{| class="wikitable"
|-
|colspan="3"|'''Dokumentation'''
|-

|rowspan="3"| 
|Projektfortschritt, Controlling
|Robert Peterfi
|-

|Hardware, Software (Wiki)
|Alois Pochmann, Reinhard Weismann
|-

|Codedokumentation
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|-
|colspan="3"|'''Hardware'''
|-

|rowspan="3"| 
|Entwurf, Design
|Alois Pochmann
|-

|Bestellung, Aufbau
|Robert Peterfi, Alois Pochmann
|-

|Test
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|-
|colspan="3"|'''Software'''
|-

|rowspan="8"| 
|Design, Funktionsaufteilung
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|Kommunikationsprotokoll
|Reinhard Weismann
|-

|Scheduler, Event Handling, zentrale Funktionen
|Alois Pochmann
|-

|Sensoren (Hardwareanbindung)
|Robert Peterfi
|-

|Kalibrierung
|Robert Peterfi
|-

|Odometrie
|Reinhard Weismann
|-

|Bewegungssteuerung
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|Testapplikation (Windows)
|Alois Pochmann
|-

|}

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem Folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusatzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das Einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt über Events und, wenn nur eine spezielle Funktionalität eines anderen Moduls verwendet werden soll ohne dessen Zustand zu beeinflussen, über Funktionsaufrufe (z.B. senden einer MaDeCo-Meldung zum reporten eines Wegpunktes direkt vom drive Modul). Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 1 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. überprüfen des Status der "Fühler"). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird direkt vom Scheduler mit dem aktuell zu verarbeitenden Event aufgerufen. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und eventuell die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul optional verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog-Modul ====
Digitalisieren der Analogeingänge
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Der Austausch war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet, dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16, die Behandlung der Messung der Batteriespannung verbessert. Da hier die Referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.
Die einzelnen Werte werden weiterhin über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt nun 13 analoge Werte (statt bisher 11) die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von ca 117 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 111 µs (statt bisher 94 µs) aktualisiert wird.

==== Line-Modul ====
Ermitteln der Werte der Liniensensoren
Dateien: line.c
line.h
Dieser Modul ersetzt die originalen Bibliotheksfunktionen der Liniensensoren. Dies war notwendig da wir zusätzliche Liniensensoren verwenden.

Die Werte der Liniensensoren können nun mit der Funktion
<code>ln_get(index)</code>
gelesen werden. Die Werte selbst werden über den [[NIBObee#Analog-Modul|Analog-Modul]] ermittelt.

==== Bluetooth-Modul ====
Wickelt die Kommunikation über den Bluetooth Modul ab. Zur Kommunikation wird allerdings nur der USART als Terminal angesprochen, der Bluetooth Stack ist im [[BTM-222]] implementiert.
Dateien: bluetooth.c
bluetooth.h

==== Common-Modul ====
Stellt gemeinsame Funktionen zurVerfügung
Dateien: common.c
common.h

==== Distance-Modul ====
Behandelt die Odometrie Sensoren
Dateien: distance.c
distance.h

==== Drive-Modul ====
Bewegt den NIBObee
Dateien: drive.c
drive.h

==== Follow-Modul ====
Ist für die Linienverfolgung zuständig
Dateien: follow.c
follow.h

==== MaDeCo-Modul ====
Behandelt das MaDeCo Protokoll
Dateien: madeco.c
madeco.h

==== Main-Modul ====
Scheduler und zentraler Taktgeber
Dateien: main.c
main.h

==== Sensor-Modul ====
Ist für die "Fühler" zuständig
Dateien: follow.c
follow.h

=== Applikationen ===
==== Labyrinth erkunden ====
Das ist die Hauptaufgabe des NIBObee. Der Anstoß kommt über einen Befehl vom Board. Ausgewertet wird das vom MaDeCo Modul der auch überprüft ob bereits eine Kalibrierung durchgeführt wurde. Wenn diese Prüfung erfolgreich ist wird der Drive Modul beauftragt das Labyrinth abzufahren. Dort wird nun von einer Kreuzung zur nächsten navigiert und jeder Punkt über den MaDeCo Modul an das Bord gemeldet. Bei jeder Kreuzung wird so weit wie möglich rechts abgebogen bis der NIBObee wieder am Ausgangspunkt angelangt ist.

==== Kürzesten Weg durch Labyrinth ====
Der MaDeCo Modul erhält vom Board die Richtungsanweisungen für den NIBObee und speichert diese in einem Buffer. Die erste Anweisung wird an den Drive Modul gesendet und der navigiert dann zum nächsten Kreuzungspunkt. Dann wird eine Anfrage an den MaDeCo Modul gesendet um den nächsten Punkt aus dem Buffer zu bekommen. Das passiert solange Daten vorhanden sind und nicht das Ende vom Board signalisiert wurde.

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können. Es werden dabei die Anzahl der Schritte der Odometrie für die Länge eines Feldes sowie für eine 90° Rotation als Referenzwerte ermittelt und im EEPROM gespeichert.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-06-25T07:52:59Z

Alois: /* Kürzesten Weg durch Labyrinth */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
Hier wird nur ein kleiner Ausschnitt der technischen Daten dargestellt. Es handelt sich nur um jenen Teil der für die Bewertung oder Implementierung der gestellten Aufgaben relevant ist:

{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|RAM: 1 kB
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar.

Zwei Analoge Eingänge werden für die Fototransistoren der zusätzlichen Linienerkennung verwendet. Diese sind am NIBObee am Port X1 verfügbar.

Ein Ausgang dient zum ein- und ausschalten der zusätzlichen IR-LEDs. Dafür wird der PIN 1 des Port X4 verwendet.

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===

==== ATMega16 ====
Die Speichergröße scheint durchaus ausreichend zu sein. Nach Implementierung aller wichtigen Grundfunktionen ist erst weniger als die Hälfte des Programmspeichers belegt.

Problematisch war anfangs nur der geringe RAM der auch alle konstanten Strings enthält. Dies ist zwar nicht notwendig, ist mit dieser Entwicklungsumgebung allerdings so gelöst. Besonders die umfangreichen Debug-Informationen die über Bluetooth an den PC gesendet werden führten dabei zu massiven Problemen. Durch kurze symbolische Debugausgaben, die dann am PC im eigens entwickelten Terminalprogramm auf sprechende symbolische Ausgabe konvertiert wird, konnte das Problem behoben werden.

==== Liniensensoren ====
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
Die original NIBObee Biliothek wird nicht verwendet. Sie wurde durch eine eigene Implementierung im [[NIBObee#Line-Modul|Line-Modul]] ersetzt. Der Grund ist die Notwendigkeit die zusätzlichen Liniensensoren in der gleichen Weise wie die drei Originalsensoren zu behandeln.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen Gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

Nach einigen ersten Tests ist folgende weitere Aufgabe hinzugekommen:
* Herstellung der Hardware-Erweiterung mit zusätzlichen Liniensensoren

=== Aufgabenteilung ===
Alle Aufgaben wurden im Team gelöst wobei für manche dieser Aufgaben der Schwerpunkt bei nur einem oder zwei Teammitgliedern lag. Die folgende Tabelle gibt eine ungefähre Zuordnung der Aufgaben auf die einzelnen Personen:

{| class="wikitable"
|-
|colspan="3"|'''Dokumentation'''
|-

|rowspan="3"| 
|Projektfortschritt, Controlling
|Robert Peterfi
|-

|Hardware, Software (Wiki)
|Alois Pochmann, Reinhard Weismann
|-

|Codedokumentation
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|-
|colspan="3"|'''Hardware'''
|-

|rowspan="3"| 
|Entwurf, Design
|Alois Pochmann
|-

|Bestellung, Aufbau
|Robert Peterfi, Alois Pochmann
|-

|Test
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|-
|colspan="3"|'''Software'''
|-

|rowspan="8"| 
|Design, Funktionsaufteilung
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|Kommunikationsprotokoll
|Reinhard Weismann
|-

|Scheduler, Event Handling, zentrale Funktionen
|Alois Pochmann
|-

|Sensoren (Hardwareanbindung)
|Robert Peterfi
|-

|Kalibrierung
|Robert Peterfi
|-

|Odometrie
|Reinhard Weismann
|-

|Bewegungssteuerung
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|Testapplikation (Windows)
|Alois Pochmann
|-

|}

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem Folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusatzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das Einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt über Events und, wenn nur eine spezielle Funktionalität eines anderen Moduls verwendet werden soll ohne dessen Zustand zu beeinflussen, über Funktionsaufrufe (z.B. senden einer MaDeCo-Meldung zum reporten eines Wegpunktes direkt vom drive Modul). Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 1 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. überprüfen des Status der "Fühler"). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird direkt vom Scheduler mit dem aktuell zu verarbeitenden Event aufgerufen. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und eventuell die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul optional verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog-Modul ====
Digitalisieren der Analogeingänge
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Der Austausch war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet, dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16, die Behandlung der Messung der Batteriespannung verbessert. Da hier die Referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.
Die einzelnen Werte werden weiterhin über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt nun 13 analoge Werte (statt bisher 11) die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von ca 117 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 111 µs (statt bisher 94 µs) aktualisiert wird.

==== Line-Modul ====
Ermitteln der Werte der Liniensensoren
Dateien: line.c
line.h
Dieser Modul ersetzt die originalen Bibliotheksfunktionen der Liniensensoren. Dies war notwendig da wir zusätzliche Liniensensoren verwenden.

Die Werte der Liniensensoren können nun mit der Funktion
<code>ln_get(index)</code>
gelesen werden. Die Werte selbst werden über den [[NIBObee#Analog-Modul|Analog-Modul]] ermittelt.

==== Bluetooth-Modul ====
Wickelt die Kommunikation über den Bluetooth Modul ab. Zur Kommunikation wird allerdings nur der USART als Terminal angesprochen, der Bluetooth Stack ist im [[BTM-222]] implementiert.
Dateien: bluetooth.c
bluetooth.h

==== Common-Modul ====
Stellt gemeinsame Funktionen zurVerfügung
Dateien: common.c
common.h

==== Distance-Modul ====
Behandelt die Odometrie Sensoren
Dateien: distance.c
distance.h

==== Drive-Modul ====
Bewegt den NIBObee
Dateien: drive.c
drive.h

==== Follow-Modul ====
Ist für die Linienverfolgung zuständig
Dateien: follow.c
follow.h

==== MaDeCo-Modul ====
Behandelt das MaDeCo Protokoll
Dateien: madeco.c
madeco.h

==== Main-Modul ====
Scheduler und zentraler Taktgeber
Dateien: main.c
main.h

==== Sensor-Modul ====
Ist für die "Fühler" zuständig
Dateien: follow.c
follow.h

=== Applikationen ===
==== Labyrinth erkunden ====
Das ist die Hauptaufgabe des NIBObee. Der Anstoß kommt über einen Befehl vom Board. Ausgewertet wird das vom MaDeCo Modul der auch überprüft ob bereits eine Kalibrierung durchgeführt wurde. Wenn diese Prüfung erfolgreich ist wird der Drive Modul beauftragt das Labyrinth abzufahren. Dort wird nun von einer Kreuzung zur nächsten navigiert und jeder Punkt über den MaDeCo Modul an das Bord gemeldet. Bei jeder Kreuzung wird so weit wie möglich rechts abgebogen bis der NIBObee wieder am Ausgangspunkt angelangt ist.

==== Kürzesten Weg durch Labyrinth ====
Der MaDeCo Modul erhält vom Board die Richtungsanweisungen für den NIBObee und speichert diese in einem Buffer. Die erste Anweisung wird an den Drive Modul gesendet und der navigiert dann zum nächsten Kreuzungspunkt. Dann wird eine Anfrage an den MaDeCo Modul gesendet um den nächsten Punkt aus dem Buffer zu bekommen. Das passiert solange Daten vorhanden sind und nicht das Ende vom Board signalisiert wurde.

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-06-25T07:52:38Z

Alois: /* Kürzesten Weg durch Labyrinth */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
Hier wird nur ein kleiner Ausschnitt der technischen Daten dargestellt. Es handelt sich nur um jenen Teil der für die Bewertung oder Implementierung der gestellten Aufgaben relevant ist:

{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|RAM: 1 kB
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar.

Zwei Analoge Eingänge werden für die Fototransistoren der zusätzlichen Linienerkennung verwendet. Diese sind am NIBObee am Port X1 verfügbar.

Ein Ausgang dient zum ein- und ausschalten der zusätzlichen IR-LEDs. Dafür wird der PIN 1 des Port X4 verwendet.

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===

==== ATMega16 ====
Die Speichergröße scheint durchaus ausreichend zu sein. Nach Implementierung aller wichtigen Grundfunktionen ist erst weniger als die Hälfte des Programmspeichers belegt.

Problematisch war anfangs nur der geringe RAM der auch alle konstanten Strings enthält. Dies ist zwar nicht notwendig, ist mit dieser Entwicklungsumgebung allerdings so gelöst. Besonders die umfangreichen Debug-Informationen die über Bluetooth an den PC gesendet werden führten dabei zu massiven Problemen. Durch kurze symbolische Debugausgaben, die dann am PC im eigens entwickelten Terminalprogramm auf sprechende symbolische Ausgabe konvertiert wird, konnte das Problem behoben werden.

==== Liniensensoren ====
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
Die original NIBObee Biliothek wird nicht verwendet. Sie wurde durch eine eigene Implementierung im [[NIBObee#Line-Modul|Line-Modul]] ersetzt. Der Grund ist die Notwendigkeit die zusätzlichen Liniensensoren in der gleichen Weise wie die drei Originalsensoren zu behandeln.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen Gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

Nach einigen ersten Tests ist folgende weitere Aufgabe hinzugekommen:
* Herstellung der Hardware-Erweiterung mit zusätzlichen Liniensensoren

=== Aufgabenteilung ===
Alle Aufgaben wurden im Team gelöst wobei für manche dieser Aufgaben der Schwerpunkt bei nur einem oder zwei Teammitgliedern lag. Die folgende Tabelle gibt eine ungefähre Zuordnung der Aufgaben auf die einzelnen Personen:

{| class="wikitable"
|-
|colspan="3"|'''Dokumentation'''
|-

|rowspan="3"| 
|Projektfortschritt, Controlling
|Robert Peterfi
|-

|Hardware, Software (Wiki)
|Alois Pochmann, Reinhard Weismann
|-

|Codedokumentation
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|-
|colspan="3"|'''Hardware'''
|-

|rowspan="3"| 
|Entwurf, Design
|Alois Pochmann
|-

|Bestellung, Aufbau
|Robert Peterfi, Alois Pochmann
|-

|Test
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|-
|colspan="3"|'''Software'''
|-

|rowspan="8"| 
|Design, Funktionsaufteilung
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|Kommunikationsprotokoll
|Reinhard Weismann
|-

|Scheduler, Event Handling, zentrale Funktionen
|Alois Pochmann
|-

|Sensoren (Hardwareanbindung)
|Robert Peterfi
|-

|Kalibrierung
|Robert Peterfi
|-

|Odometrie
|Reinhard Weismann
|-

|Bewegungssteuerung
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|Testapplikation (Windows)
|Alois Pochmann
|-

|}

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem Folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusatzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das Einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt über Events und, wenn nur eine spezielle Funktionalität eines anderen Moduls verwendet werden soll ohne dessen Zustand zu beeinflussen, über Funktionsaufrufe (z.B. senden einer MaDeCo-Meldung zum reporten eines Wegpunktes direkt vom drive Modul). Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 1 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. überprüfen des Status der "Fühler"). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird direkt vom Scheduler mit dem aktuell zu verarbeitenden Event aufgerufen. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und eventuell die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul optional verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog-Modul ====
Digitalisieren der Analogeingänge
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Der Austausch war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet, dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16, die Behandlung der Messung der Batteriespannung verbessert. Da hier die Referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.
Die einzelnen Werte werden weiterhin über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt nun 13 analoge Werte (statt bisher 11) die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von ca 117 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 111 µs (statt bisher 94 µs) aktualisiert wird.

==== Line-Modul ====
Ermitteln der Werte der Liniensensoren
Dateien: line.c
line.h
Dieser Modul ersetzt die originalen Bibliotheksfunktionen der Liniensensoren. Dies war notwendig da wir zusätzliche Liniensensoren verwenden.

Die Werte der Liniensensoren können nun mit der Funktion
<code>ln_get(index)</code>
gelesen werden. Die Werte selbst werden über den [[NIBObee#Analog-Modul|Analog-Modul]] ermittelt.

==== Bluetooth-Modul ====
Wickelt die Kommunikation über den Bluetooth Modul ab. Zur Kommunikation wird allerdings nur der USART als Terminal angesprochen, der Bluetooth Stack ist im [[BTM-222]] implementiert.
Dateien: bluetooth.c
bluetooth.h

==== Common-Modul ====
Stellt gemeinsame Funktionen zurVerfügung
Dateien: common.c
common.h

==== Distance-Modul ====
Behandelt die Odometrie Sensoren
Dateien: distance.c
distance.h

==== Drive-Modul ====
Bewegt den NIBObee
Dateien: drive.c
drive.h

==== Follow-Modul ====
Ist für die Linienverfolgung zuständig
Dateien: follow.c
follow.h

==== MaDeCo-Modul ====
Behandelt das MaDeCo Protokoll
Dateien: madeco.c
madeco.h

==== Main-Modul ====
Scheduler und zentraler Taktgeber
Dateien: main.c
main.h

==== Sensor-Modul ====
Ist für die "Fühler" zuständig
Dateien: follow.c
follow.h

=== Applikationen ===
==== Labyrinth erkunden ====
Das ist die Hauptaufgabe des NIBObee. Der Anstoß kommt über einen Befehl vom Board. Ausgewertet wird das vom MaDeCo Modul der auch überprüft ob bereits eine Kalibrierung durchgeführt wurde. Wenn diese Prüfung erfolgreich ist wird der Drive Modul beauftragt das Labyrinth abzufahren. Dort wird nun von einer Kreuzung zur nächsten navigiert und jeder Punkt über den MaDeCo Modul an das Bord gemeldet. Bei jeder Kreuzung wird so weit wie möglich rechts abgebogen bis der NIBObee wieder am Ausgangspunkt angelangt ist.

==== Kürzesten Weg durch Labyrinth ====
Der MaDeCo Modul erhält vom Board die Richtungsanweisungen für den NIBObee und speichert diese in einem Buffer. Die erste Anweisung wird an den Drive Modul gesendet und der navigiert dann zum nächsten Kreuzungspunkt. Dann wird eine Anfrage an den MaDeCo Modul gesendet um den nächsten Punkt aus dem Buffer zu bekommen. Das passiert solange Daten vorhanden sind und nicht das Ende vom Borad signalisiert wurde.

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-06-25T07:49:44Z

Alois: /* Labyrinth erkunden */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
Hier wird nur ein kleiner Ausschnitt der technischen Daten dargestellt. Es handelt sich nur um jenen Teil der für die Bewertung oder Implementierung der gestellten Aufgaben relevant ist:

{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|RAM: 1 kB
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar.

Zwei Analoge Eingänge werden für die Fototransistoren der zusätzlichen Linienerkennung verwendet. Diese sind am NIBObee am Port X1 verfügbar.

Ein Ausgang dient zum ein- und ausschalten der zusätzlichen IR-LEDs. Dafür wird der PIN 1 des Port X4 verwendet.

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===

==== ATMega16 ====
Die Speichergröße scheint durchaus ausreichend zu sein. Nach Implementierung aller wichtigen Grundfunktionen ist erst weniger als die Hälfte des Programmspeichers belegt.

Problematisch war anfangs nur der geringe RAM der auch alle konstanten Strings enthält. Dies ist zwar nicht notwendig, ist mit dieser Entwicklungsumgebung allerdings so gelöst. Besonders die umfangreichen Debug-Informationen die über Bluetooth an den PC gesendet werden führten dabei zu massiven Problemen. Durch kurze symbolische Debugausgaben, die dann am PC im eigens entwickelten Terminalprogramm auf sprechende symbolische Ausgabe konvertiert wird, konnte das Problem behoben werden.

==== Liniensensoren ====
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
Die original NIBObee Biliothek wird nicht verwendet. Sie wurde durch eine eigene Implementierung im [[NIBObee#Line-Modul|Line-Modul]] ersetzt. Der Grund ist die Notwendigkeit die zusätzlichen Liniensensoren in der gleichen Weise wie die drei Originalsensoren zu behandeln.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen Gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

Nach einigen ersten Tests ist folgende weitere Aufgabe hinzugekommen:
* Herstellung der Hardware-Erweiterung mit zusätzlichen Liniensensoren

=== Aufgabenteilung ===
Alle Aufgaben wurden im Team gelöst wobei für manche dieser Aufgaben der Schwerpunkt bei nur einem oder zwei Teammitgliedern lag. Die folgende Tabelle gibt eine ungefähre Zuordnung der Aufgaben auf die einzelnen Personen:

{| class="wikitable"
|-
|colspan="3"|'''Dokumentation'''
|-

|rowspan="3"| 
|Projektfortschritt, Controlling
|Robert Peterfi
|-

|Hardware, Software (Wiki)
|Alois Pochmann, Reinhard Weismann
|-

|Codedokumentation
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|-
|colspan="3"|'''Hardware'''
|-

|rowspan="3"| 
|Entwurf, Design
|Alois Pochmann
|-

|Bestellung, Aufbau
|Robert Peterfi, Alois Pochmann
|-

|Test
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|-
|colspan="3"|'''Software'''
|-

|rowspan="8"| 
|Design, Funktionsaufteilung
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|Kommunikationsprotokoll
|Reinhard Weismann
|-

|Scheduler, Event Handling, zentrale Funktionen
|Alois Pochmann
|-

|Sensoren (Hardwareanbindung)
|Robert Peterfi
|-

|Kalibrierung
|Robert Peterfi
|-

|Odometrie
|Reinhard Weismann
|-

|Bewegungssteuerung
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|Testapplikation (Windows)
|Alois Pochmann
|-

|}

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem Folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusatzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das Einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt über Events und, wenn nur eine spezielle Funktionalität eines anderen Moduls verwendet werden soll ohne dessen Zustand zu beeinflussen, über Funktionsaufrufe (z.B. senden einer MaDeCo-Meldung zum reporten eines Wegpunktes direkt vom drive Modul). Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 1 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. überprüfen des Status der "Fühler"). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird direkt vom Scheduler mit dem aktuell zu verarbeitenden Event aufgerufen. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und eventuell die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul optional verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog-Modul ====
Digitalisieren der Analogeingänge
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Der Austausch war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet, dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16, die Behandlung der Messung der Batteriespannung verbessert. Da hier die Referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.
Die einzelnen Werte werden weiterhin über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt nun 13 analoge Werte (statt bisher 11) die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von ca 117 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 111 µs (statt bisher 94 µs) aktualisiert wird.

==== Line-Modul ====
Ermitteln der Werte der Liniensensoren
Dateien: line.c
line.h
Dieser Modul ersetzt die originalen Bibliotheksfunktionen der Liniensensoren. Dies war notwendig da wir zusätzliche Liniensensoren verwenden.

Die Werte der Liniensensoren können nun mit der Funktion
<code>ln_get(index)</code>
gelesen werden. Die Werte selbst werden über den [[NIBObee#Analog-Modul|Analog-Modul]] ermittelt.

==== Bluetooth-Modul ====
Wickelt die Kommunikation über den Bluetooth Modul ab. Zur Kommunikation wird allerdings nur der USART als Terminal angesprochen, der Bluetooth Stack ist im [[BTM-222]] implementiert.
Dateien: bluetooth.c
bluetooth.h

==== Common-Modul ====
Stellt gemeinsame Funktionen zurVerfügung
Dateien: common.c
common.h

==== Distance-Modul ====
Behandelt die Odometrie Sensoren
Dateien: distance.c
distance.h

==== Drive-Modul ====
Bewegt den NIBObee
Dateien: drive.c
drive.h

==== Follow-Modul ====
Ist für die Linienverfolgung zuständig
Dateien: follow.c
follow.h

==== MaDeCo-Modul ====
Behandelt das MaDeCo Protokoll
Dateien: madeco.c
madeco.h

==== Main-Modul ====
Scheduler und zentraler Taktgeber
Dateien: main.c
main.h

==== Sensor-Modul ====
Ist für die "Fühler" zuständig
Dateien: follow.c
follow.h

=== Applikationen ===
==== Labyrinth erkunden ====
Das ist die Hauptaufgabe des NIBObee. Der Anstoß kommt über einen Befehl vom Board. Ausgewertet wird das vom MaDeCo Modul der auch überprüft ob bereits eine Kalibrierung durchgeführt wurde. Wenn diese Prüfung erfolgreich ist wird der Drive Modul beauftragt das Labyrinth abzufahren. Dort wird nun von einer Kreuzung zur nächsten navigiert und jeder Punkt über den MaDeCo Modul an das Bord gemeldet. Bei jeder Kreuzung wird so weit wie möglich rechts abgebogen bis der NIBObee wieder am Ausgangspunkt angelangt ist.

==== Kürzesten Weg durch Labyrinth ====

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-06-25T07:40:44Z

Alois: /* Analog-Modul */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
Hier wird nur ein kleiner Ausschnitt der technischen Daten dargestellt. Es handelt sich nur um jenen Teil der für die Bewertung oder Implementierung der gestellten Aufgaben relevant ist:

{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|RAM: 1 kB
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar.

Zwei Analoge Eingänge werden für die Fototransistoren der zusätzlichen Linienerkennung verwendet. Diese sind am NIBObee am Port X1 verfügbar.

Ein Ausgang dient zum ein- und ausschalten der zusätzlichen IR-LEDs. Dafür wird der PIN 1 des Port X4 verwendet.

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===

==== ATMega16 ====
Die Speichergröße scheint durchaus ausreichend zu sein. Nach Implementierung aller wichtigen Grundfunktionen ist erst weniger als die Hälfte des Programmspeichers belegt.

Problematisch war anfangs nur der geringe RAM der auch alle konstanten Strings enthält. Dies ist zwar nicht notwendig, ist mit dieser Entwicklungsumgebung allerdings so gelöst. Besonders die umfangreichen Debug-Informationen die über Bluetooth an den PC gesendet werden führten dabei zu massiven Problemen. Durch kurze symbolische Debugausgaben, die dann am PC im eigens entwickelten Terminalprogramm auf sprechende symbolische Ausgabe konvertiert wird, konnte das Problem behoben werden.

==== Liniensensoren ====
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
Die original NIBObee Biliothek wird nicht verwendet. Sie wurde durch eine eigene Implementierung im [[NIBObee#Line-Modul|Line-Modul]] ersetzt. Der Grund ist die Notwendigkeit die zusätzlichen Liniensensoren in der gleichen Weise wie die drei Originalsensoren zu behandeln.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen Gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

Nach einigen ersten Tests ist folgende weitere Aufgabe hinzugekommen:
* Herstellung der Hardware-Erweiterung mit zusätzlichen Liniensensoren

=== Aufgabenteilung ===
Alle Aufgaben wurden im Team gelöst wobei für manche dieser Aufgaben der Schwerpunkt bei nur einem oder zwei Teammitgliedern lag. Die folgende Tabelle gibt eine ungefähre Zuordnung der Aufgaben auf die einzelnen Personen:

{| class="wikitable"
|-
|colspan="3"|'''Dokumentation'''
|-

|rowspan="3"| 
|Projektfortschritt, Controlling
|Robert Peterfi
|-

|Hardware, Software (Wiki)
|Alois Pochmann, Reinhard Weismann
|-

|Codedokumentation
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|-
|colspan="3"|'''Hardware'''
|-

|rowspan="3"| 
|Entwurf, Design
|Alois Pochmann
|-

|Bestellung, Aufbau
|Robert Peterfi, Alois Pochmann
|-

|Test
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|-
|colspan="3"|'''Software'''
|-

|rowspan="8"| 
|Design, Funktionsaufteilung
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|Kommunikationsprotokoll
|Reinhard Weismann
|-

|Scheduler, Event Handling, zentrale Funktionen
|Alois Pochmann
|-

|Sensoren (Hardwareanbindung)
|Robert Peterfi
|-

|Kalibrierung
|Robert Peterfi
|-

|Odometrie
|Reinhard Weismann
|-

|Bewegungssteuerung
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|Testapplikation (Windows)
|Alois Pochmann
|-

|}

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem Folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusatzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das Einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt über Events und, wenn nur eine spezielle Funktionalität eines anderen Moduls verwendet werden soll ohne dessen Zustand zu beeinflussen, über Funktionsaufrufe (z.B. senden einer MaDeCo-Meldung zum reporten eines Wegpunktes direkt vom drive Modul). Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 1 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. überprüfen des Status der "Fühler"). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird direkt vom Scheduler mit dem aktuell zu verarbeitenden Event aufgerufen. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und eventuell die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul optional verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog-Modul ====
Digitalisieren der Analogeingänge
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Der Austausch war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet, dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16, die Behandlung der Messung der Batteriespannung verbessert. Da hier die Referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.
Die einzelnen Werte werden weiterhin über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt nun 13 analoge Werte (statt bisher 11) die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von ca 117 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 111 µs (statt bisher 94 µs) aktualisiert wird.

==== Line-Modul ====
Ermitteln der Werte der Liniensensoren
Dateien: line.c
line.h
Dieser Modul ersetzt die originalen Bibliotheksfunktionen der Liniensensoren. Dies war notwendig da wir zusätzliche Liniensensoren verwenden.

Die Werte der Liniensensoren können nun mit der Funktion
<code>ln_get(index)</code>
gelesen werden. Die Werte selbst werden über den [[NIBObee#Analog-Modul|Analog-Modul]] ermittelt.

==== Bluetooth-Modul ====
Wickelt die Kommunikation über den Bluetooth Modul ab. Zur Kommunikation wird allerdings nur der USART als Terminal angesprochen, der Bluetooth Stack ist im [[BTM-222]] implementiert.
Dateien: bluetooth.c
bluetooth.h

==== Common-Modul ====
Stellt gemeinsame Funktionen zurVerfügung
Dateien: common.c
common.h

==== Distance-Modul ====
Behandelt die Odometrie Sensoren
Dateien: distance.c
distance.h

==== Drive-Modul ====
Bewegt den NIBObee
Dateien: drive.c
drive.h

==== Follow-Modul ====
Ist für die Linienverfolgung zuständig
Dateien: follow.c
follow.h

==== MaDeCo-Modul ====
Behandelt das MaDeCo Protokoll
Dateien: madeco.c
madeco.h

==== Main-Modul ====
Scheduler und zentraler Taktgeber
Dateien: main.c
main.h

==== Sensor-Modul ====
Ist für die "Fühler" zuständig
Dateien: follow.c
follow.h

=== Applikationen ===
==== Labyrinth erkunden ====

==== Kürzesten Weg durch Labyrinth ====

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-06-24T23:00:32Z

Alois: /* Architektur */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
Hier wird nur ein kleiner Ausschnitt der technischen Daten dargestellt. Es handelt sich nur um jenen Teil der für die Bewertung oder Implementierung der gestellten Aufgaben relevant ist:

{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|RAM: 1 kB
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar.

Zwei Analoge Eingänge werden für die Fototransistoren der zusätzlichen Linienerkennung verwendet. Diese sind am NIBObee am Port X1 verfügbar.

Ein Ausgang dient zum ein- und ausschalten der zusätzlichen IR-LEDs. Dafür wird der PIN 1 des Port X4 verwendet.

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===

==== ATMega16 ====
Die Speichergröße scheint durchaus ausreichend zu sein. Nach Implementierung aller wichtigen Grundfunktionen ist erst weniger als die Hälfte des Programmspeichers belegt.

Problematisch war anfangs nur der geringe RAM der auch alle konstanten Strings enthält. Dies ist zwar nicht notwendig, ist mit dieser Entwicklungsumgebung allerdings so gelöst. Besonders die umfangreichen Debug-Informationen die über Bluetooth an den PC gesendet werden führten dabei zu massiven Problemen. Durch kurze symbolische Debugausgaben, die dann am PC im eigens entwickelten Terminalprogramm auf sprechende symbolische Ausgabe konvertiert wird, konnte das Problem behoben werden.

==== Liniensensoren ====
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
Die original NIBObee Biliothek wird nicht verwendet. Sie wurde durch eine eigene Implementierung im [[NIBObee#Line-Modul|Line-Modul]] ersetzt. Der Grund ist die Notwendigkeit die zusätzlichen Liniensensoren in der gleichen Weise wie die drei Originalsensoren zu behandeln.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen Gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

Nach einigen ersten Tests ist folgende weitere Aufgabe hinzugekommen:
* Herstellung der Hardware-Erweiterung mit zusätzlichen Liniensensoren

=== Aufgabenteilung ===
Alle Aufgaben wurden im Team gelöst wobei für manche dieser Aufgaben der Schwerpunkt bei nur einem oder zwei Teammitgliedern lag. Die folgende Tabelle gibt eine ungefähre Zuordnung der Aufgaben auf die einzelnen Personen:

{| class="wikitable"
|-
|colspan="3"|'''Dokumentation'''
|-

|rowspan="3"| 
|Projektfortschritt, Controlling
|Robert Peterfi
|-

|Hardware, Software (Wiki)
|Alois Pochmann, Reinhard Weismann
|-

|Codedokumentation
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|-
|colspan="3"|'''Hardware'''
|-

|rowspan="3"| 
|Entwurf, Design
|Alois Pochmann
|-

|Bestellung, Aufbau
|Robert Peterfi, Alois Pochmann
|-

|Test
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|-
|colspan="3"|'''Software'''
|-

|rowspan="8"| 
|Design, Funktionsaufteilung
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|Kommunikationsprotokoll
|Reinhard Weismann
|-

|Scheduler, Event Handling, zentrale Funktionen
|Alois Pochmann
|-

|Sensoren (Hardwareanbindung)
|Robert Peterfi
|-

|Kalibrierung
|Robert Peterfi
|-

|Odometrie
|Reinhard Weismann
|-

|Bewegungssteuerung
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|Testapplikation (Windows)
|Alois Pochmann
|-

|}

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem Folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusatzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das Einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt über Events und, wenn nur eine spezielle Funktionalität eines anderen Moduls verwendet werden soll ohne dessen Zustand zu beeinflussen, über Funktionsaufrufe (z.B. senden einer MaDeCo-Meldung zum reporten eines Wegpunktes direkt vom drive Modul). Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 1 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. überprüfen des Status der "Fühler"). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird direkt vom Scheduler mit dem aktuell zu verarbeitenden Event aufgerufen. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und eventuell die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul optional verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog-Modul ====
Digitalisieren der Analogeingänge
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Dies war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16 die Behandlung der Messung der Batteriespannung verbessert. Da hier die Referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.
Die einzelnen Werte werden weiterhin über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt nun 13 analoge Werte (statt bisher 11) die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von ca 117 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 111 µs (statt bisher 94 µs) aktualisiert wird.

==== Line-Modul ====
Ermitteln der Werte der Liniensensoren
Dateien: line.c
line.h
Dieser Modul ersetzt die originalen Bibliotheksfunktionen der Liniensensoren. Dies war notwendig da wir zusätzliche Liniensensoren verwenden.

Die Werte der Liniensensoren können nun mit der Funktion
<code>ln_get(index)</code>
gelesen werden. Die Werte selbst werden über den [[NIBObee#Analog-Modul|Analog-Modul]] ermittelt.

==== Bluetooth-Modul ====
Wickelt die Kommunikation über den Bluetooth Modul ab. Zur Kommunikation wird allerdings nur der USART als Terminal angesprochen, der Bluetooth Stack ist im [[BTM-222]] implementiert.
Dateien: bluetooth.c
bluetooth.h

==== Common-Modul ====
Stellt gemeinsame Funktionen zurVerfügung
Dateien: common.c
common.h

==== Distance-Modul ====
Behandelt die Odometrie Sensoren
Dateien: distance.c
distance.h

==== Drive-Modul ====
Bewegt den NIBObee
Dateien: drive.c
drive.h

==== Follow-Modul ====
Ist für die Linienverfolgung zuständig
Dateien: follow.c
follow.h

==== MaDeCo-Modul ====
Behandelt das MaDeCo Protokoll
Dateien: madeco.c
madeco.h

==== Main-Modul ====
Scheduler und zentraler Taktgeber
Dateien: main.c
main.h

==== Sensor-Modul ====
Ist für die "Fühler" zuständig
Dateien: follow.c
follow.h

=== Applikationen ===
==== Labyrinth erkunden ====

==== Kürzesten Weg durch Labyrinth ====

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-06-24T22:53:21Z

Alois: /* Liniensensoren */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
Hier wird nur ein kleiner Ausschnitt der technischen Daten dargestellt. Es handelt sich nur um jenen Teil der für die Bewertung oder Implementierung der gestellten Aufgaben relevant ist:

{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|RAM: 1 kB
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar.

Zwei Analoge Eingänge werden für die Fototransistoren der zusätzlichen Linienerkennung verwendet. Diese sind am NIBObee am Port X1 verfügbar.

Ein Ausgang dient zum ein- und ausschalten der zusätzlichen IR-LEDs. Dafür wird der PIN 1 des Port X4 verwendet.

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===

==== ATMega16 ====
Die Speichergröße scheint durchaus ausreichend zu sein. Nach Implementierung aller wichtigen Grundfunktionen ist erst weniger als die Hälfte des Programmspeichers belegt.

Problematisch war anfangs nur der geringe RAM der auch alle konstanten Strings enthält. Dies ist zwar nicht notwendig, ist mit dieser Entwicklungsumgebung allerdings so gelöst. Besonders die umfangreichen Debug-Informationen die über Bluetooth an den PC gesendet werden führten dabei zu massiven Problemen. Durch kurze symbolische Debugausgaben, die dann am PC im eigens entwickelten Terminalprogramm auf sprechende symbolische Ausgabe konvertiert wird, konnte das Problem behoben werden.

==== Liniensensoren ====
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
Die original NIBObee Biliothek wird nicht verwendet. Sie wurde durch eine eigene Implementierung im [[NIBObee#Line-Modul|Line-Modul]] ersetzt. Der Grund ist die Notwendigkeit die zusätzlichen Liniensensoren in der gleichen Weise wie die drei Originalsensoren zu behandeln.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen Gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

Nach einigen ersten Tests ist folgende weitere Aufgabe hinzugekommen:
* Herstellung der Hardware-Erweiterung mit zusätzlichen Liniensensoren

=== Aufgabenteilung ===
Alle Aufgaben wurden im Team gelöst wobei für manche dieser Aufgaben der Schwerpunkt bei nur einem oder zwei Teammitgliedern lag. Die folgende Tabelle gibt eine ungefähre Zuordnung der Aufgaben auf die einzelnen Personen:

{| class="wikitable"
|-
|colspan="3"|'''Dokumentation'''
|-

|rowspan="3"| 
|Projektfortschritt, Controlling
|Robert Peterfi
|-

|Hardware, Software (Wiki)
|Alois Pochmann, Reinhard Weismann
|-

|Codedokumentation
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|-
|colspan="3"|'''Hardware'''
|-

|rowspan="3"| 
|Entwurf, Design
|Alois Pochmann
|-

|Bestellung, Aufbau
|Robert Peterfi, Alois Pochmann
|-

|Test
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|-
|colspan="3"|'''Software'''
|-

|rowspan="8"| 
|Design, Funktionsaufteilung
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|Kommunikationsprotokoll
|Reinhard Weismann
|-

|Scheduler, Event Handling, zentrale Funktionen
|Alois Pochmann
|-

|Sensoren (Hardwareanbindung)
|Robert Peterfi
|-

|Kalibrierung
|Robert Peterfi
|-

|Odometrie
|Reinhard Weismann
|-

|Bewegungssteuerung
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|Testapplikation (Windows)
|Alois Pochmann
|-

|}

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem Folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusatzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das Einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt ausschließlich über Events. Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 2 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. lesen der Liniensensoren). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird nicht direkt vom Scheduler aufgerufen sondern über die Funktion <xx>_eventHandler. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; eine Funktion mit dem Namen <xx>_eventHandler (extern)
: Ist die Funktion die vom Scheduler aufgerufen wird damit die Statemaschine mit dem aktuellen Event, sofern vorhanden, durchlaufen wird.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.
; eine Funktion mit dem Namen <xx>_receiveEvent (intern)
: ReceiveEvent ist eigentlich eine interne Funktion (wird also nicht im Header File deklariert), der Pointer auf diese Funktion wird allerdings als Callback beim Subscribe übergeben damit der Event dem Modul zugestellt werden kann.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog-Modul ====
Digitalisieren der Analogeingänge
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Dies war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16 die Behandlung der Messung der Batteriespannung verbessert. Da hier die Referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.
Die einzelnen Werte werden weiterhin über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt nun 13 analoge Werte (statt bisher 11) die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von ca 117 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 111 µs (statt bisher 94 µs) aktualisiert wird.

==== Line-Modul ====
Ermitteln der Werte der Liniensensoren
Dateien: line.c
line.h
Dieser Modul ersetzt die originalen Bibliotheksfunktionen der Liniensensoren. Dies war notwendig da wir zusätzliche Liniensensoren verwenden.

Die Werte der Liniensensoren können nun mit der Funktion
<code>ln_get(index)</code>
gelesen werden. Die Werte selbst werden über den [[NIBObee#Analog-Modul|Analog-Modul]] ermittelt.

==== Bluetooth-Modul ====
Wickelt die Kommunikation über den Bluetooth Modul ab. Zur Kommunikation wird allerdings nur der USART als Terminal angesprochen, der Bluetooth Stack ist im [[BTM-222]] implementiert.
Dateien: bluetooth.c
bluetooth.h

==== Common-Modul ====
Stellt gemeinsame Funktionen zurVerfügung
Dateien: common.c
common.h

==== Distance-Modul ====
Behandelt die Odometrie Sensoren
Dateien: distance.c
distance.h

==== Drive-Modul ====
Bewegt den NIBObee
Dateien: drive.c
drive.h

==== Follow-Modul ====
Ist für die Linienverfolgung zuständig
Dateien: follow.c
follow.h

==== MaDeCo-Modul ====
Behandelt das MaDeCo Protokoll
Dateien: madeco.c
madeco.h

==== Main-Modul ====
Scheduler und zentraler Taktgeber
Dateien: main.c
main.h

==== Sensor-Modul ====
Ist für die "Fühler" zuständig
Dateien: follow.c
follow.h

=== Applikationen ===
==== Labyrinth erkunden ====

==== Kürzesten Weg durch Labyrinth ====

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-06-24T22:52:20Z

Alois: /* Liniensensoren */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
Hier wird nur ein kleiner Ausschnitt der technischen Daten dargestellt. Es handelt sich nur um jenen Teil der für die Bewertung oder Implementierung der gestellten Aufgaben relevant ist:

{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|RAM: 1 kB
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar.

Zwei Analoge Eingänge werden für die Fototransistoren der zusätzlichen Linienerkennung verwendet. Diese sind am NIBObee am Port X1 verfügbar.

Ein Ausgang dient zum ein- und ausschalten der zusätzlichen IR-LEDs. Dafür wird der PIN 1 des Port X4 verwendet.

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===

==== ATMega16 ====
Die Speichergröße scheint durchaus ausreichend zu sein. Nach Implementierung aller wichtigen Grundfunktionen ist erst weniger als die Hälfte des Programmspeichers belegt.

Problematisch war anfangs nur der geringe RAM der auch alle konstanten Strings enthält. Dies ist zwar nicht notwendig, ist mit dieser Entwicklungsumgebung allerdings so gelöst. Besonders die umfangreichen Debug-Informationen die über Bluetooth an den PC gesendet werden führten dabei zu massiven Problemen. Durch kurze symbolische Debugausgaben, die dann am PC im eigens entwickelten Terminalprogramm auf sprechende symbolische Ausgabe konvertiert wird, konnte das Problem behoben werden.

==== Liniensensoren ====
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
Die original NIBObee Biliothek wird nicht verwendet. Sie wurde durch eine eigene Implementierung im [[NIBObee#Line-Modul|Line-Modul]] ersetzt. Der Grund ist die Notwendigkeit die zusätzlichen Liniensensoren in der gleichen Weise wie die drei Originalsensoren zu behandeln.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen Gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

Nach einigen ersten Tests ist folgende weitere Aufgabe hinzugekommen:
* Herstellung der Hardware-Erweiterung mit zusätzlichen Liniensensoren

=== Aufgabenteilung ===
Alle Aufgaben wurden im Team gelöst wobei für manche dieser Aufgaben der Schwerpunkt bei nur einem oder zwei Teammitgliedern lag. Die folgende Tabelle gibt eine ungefähre Zuordnung der Aufgaben auf die einzelnen Personen:

{| class="wikitable"
|-
|colspan="3"|'''Dokumentation'''
|-

|rowspan="3"| 
|Projektfortschritt, Controlling
|Robert Peterfi
|-

|Hardware, Software (Wiki)
|Alois Pochmann, Reinhard Weismann
|-

|Codedokumentation
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|-
|colspan="3"|'''Hardware'''
|-

|rowspan="3"| 
|Entwurf, Design
|Alois Pochmann
|-

|Bestellung, Aufbau
|Robert Peterfi, Alois Pochmann
|-

|Test
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|-
|colspan="3"|'''Software'''
|-

|rowspan="8"| 
|Design, Funktionsaufteilung
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|Kommunikationsprotokoll
|Reinhard Weismann
|-

|Scheduler, Event Handling, zentrale Funktionen
|Alois Pochmann
|-

|Sensoren (Hardwareanbindung)
|Robert Peterfi
|-

|Kalibrierung
|Robert Peterfi
|-

|Odometrie
|Reinhard Weismann
|-

|Bewegungssteuerung
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|Testapplikation (Windows)
|Alois Pochmann
|-

|}

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem Folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusätzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt ausschließlich über Events. Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 2 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. lesen der Liniensensoren). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird nicht direkt vom Scheduler aufgerufen sondern über die Funktion <xx>_eventHandler. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; eine Funktion mit dem Namen <xx>_eventHandler (extern)
: Ist die Funktion die vom Scheduler aufgerufen wird damit die Statemaschine mit dem aktuellen Event, sofern vorhanden, durchlaufen wird.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.
; eine Funktion mit dem Namen <xx>_receiveEvent (intern)
: ReceiveEvent ist eigentlich eine interne Funktion (wird also nicht im Header File deklariert), der Pointer auf diese Funktion wird allerdings als Callback beim Subscribe übergeben damit der Event dem Modul zugestellt werden kann.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog-Modul ====
Digitalisieren der Analogeingänge
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Dies war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16 die Behandlung der Messung der Batteriespannung verbessert. Da hier die Referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.
Die einzelnen Werte werden weiterhin über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt nun 13 analoge Werte (statt bisher 11) die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von ca 117 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 111 µs (statt bisher 94 µs) aktualisiert wird.

==== Line-Modul ====
Ermitteln der Werte der Liniensensoren
Dateien: line.c
line.h
Dieser Modul ersetzt die originalen Bibliotheksfunktionen der Liniensensoren. Dies war notwendig da wir zusätzliche Liniensensoren verwenden.

Die Werte der Liniensensoren können nun mit der Funktion
<code>ln_get(index)</code>
gelesen werden. Die Werte selbst werden über den [[NIBObee#Analog-Modul|Analog-Modul]] ermittelt.

==== Bluetooth-Modul ====
Wickelt die Kommunikation über den Bluetooth Modul ab. Zur Kommunikation wird allerdings nur der USART als Terminal angesprochen, der Bluetooth Stack ist im [[BTM-222]] implementiert.
Dateien: bluetooth.c
bluetooth.h

==== Common-Modul ====
Stellt gemeinsame Funktionen zurVerfügung
Dateien: common.c
common.h

==== Distance-Modul ====
Behandelt die Odometrie Sensoren
Dateien: distance.c
distance.h

==== Drive-Modul ====
Bewegt den NIBObee
Dateien: drive.c
drive.h

==== Follow-Modul ====
Ist für die Linienverfolgung zuständig
Dateien: follow.c
follow.h

==== MaDeCo-Modul ====
Behandelt das MaDeCo Protokoll
Dateien: madeco.c
madeco.h

==== Main-Modul ====
Scheduler und zentraler Taktgeber
Dateien: main.c
main.h

==== Sensor-Modul ====
Ist für die "Fühler" zuständig
Dateien: follow.c
follow.h

=== Applikationen ===
==== Labyrinth erkunden ====

==== Kürzesten Weg durch Labyrinth ====

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-06-24T22:51:41Z

Alois: /* Aufgaben */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
Hier wird nur ein kleiner Ausschnitt der technischen Daten dargestellt. Es handelt sich nur um jenen Teil der für die Bewertung oder Implementierung der gestellten Aufgaben relevant ist:

{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|RAM: 1 kB
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar.

Zwei Analoge Eingänge werden für die Fototransistoren der zusätzlichen Linienerkennung verwendet. Diese sind am NIBObee am Port X1 verfügbar.

Ein Ausgang dient zum ein- und ausschalten der zusätzlichen IR-LEDs. Dafür wird der PIN 1 des Port X4 verwendet.

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===

==== ATMega16 ====
Die Speichergröße scheint durchaus ausreichend zu sein. Nach Implementierung aller wichtigen Grundfunktionen ist erst weniger als die Hälfte des Programmspeichers belegt.

Problematisch war anfangs nur der geringe RAM der auch alle konstanten Strings enthält. Dies ist zwar nicht notwendig, ist mit dieser Entwicklungsumgebung allerdings so gelöst. Besonders die umfangreichen Debug-Informationen die über Bluetooth an den PC gesendet werden führten dabei zu massiven Problemen. Durch kurze symbolische Debugausgaben, die dann am PC im eigens entwickelten Terminalprogramm auf sprechende symbolische Ausgabe konvertiert wird, konnte das Problem behoben werden.

==== Liniensensoren ====
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
Die original NIBObee Biliothek wird nicht verwendet. Sie wurde durch eine eigene Implementierung im [[NIBObee#Line-Modul|Line-Modul]] ersetzt. Der Grund ist die Notwendigkeit die zusätzlichen Liniensensoren in der gleichen Weise wie die drei Originalsensoren zu behandeln.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen Gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

Nach einigen ersten Tests ist folgende weitere Aufgabe hinzugekommen:
* Herstellung der Hardware-Erweiterung mit zusätzlichen Liniensensoren

=== Aufgabenteilung ===
Alle Aufgaben wurden im Team gelöst wobei für manche dieser Aufgaben der Schwerpunkt bei nur einem oder zwei Teammitgliedern lag. Die folgende Tabelle gibt eine ungefähre Zuordnung der Aufgaben auf die einzelnen Personen:

{| class="wikitable"
|-
|colspan="3"|'''Dokumentation'''
|-

|rowspan="3"| 
|Projektfortschritt, Controlling
|Robert Peterfi
|-

|Hardware, Software (Wiki)
|Alois Pochmann, Reinhard Weismann
|-

|Codedokumentation
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|-
|colspan="3"|'''Hardware'''
|-

|rowspan="3"| 
|Entwurf, Design
|Alois Pochmann
|-

|Bestellung, Aufbau
|Robert Peterfi, Alois Pochmann
|-

|Test
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|-
|colspan="3"|'''Software'''
|-

|rowspan="8"| 
|Design, Funktionsaufteilung
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|Kommunikationsprotokoll
|Reinhard Weismann
|-

|Scheduler, Event Handling, zentrale Funktionen
|Alois Pochmann
|-

|Sensoren (Hardwareanbindung)
|Robert Peterfi
|-

|Kalibrierung
|Robert Peterfi
|-

|Odometrie
|Reinhard Weismann
|-

|Bewegungssteuerung
|Robert Peterfi, Alois Pochmann, Reinhard Weismann
|-

|Testapplikation (Windows)
|Alois Pochmann
|-

|}

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusätzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt ausschließlich über Events. Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 2 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. lesen der Liniensensoren). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird nicht direkt vom Scheduler aufgerufen sondern über die Funktion <xx>_eventHandler. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; eine Funktion mit dem Namen <xx>_eventHandler (extern)
: Ist die Funktion die vom Scheduler aufgerufen wird damit die Statemaschine mit dem aktuellen Event, sofern vorhanden, durchlaufen wird.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.
; eine Funktion mit dem Namen <xx>_receiveEvent (intern)
: ReceiveEvent ist eigentlich eine interne Funktion (wird also nicht im Header File deklariert), der Pointer auf diese Funktion wird allerdings als Callback beim Subscribe übergeben damit der Event dem Modul zugestellt werden kann.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog-Modul ====
Digitalisieren der Analogeingänge
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Dies war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16 die Behandlung der Messung der Batteriespannung verbessert. Da hier die Referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.
Die einzelnen Werte werden weiterhin über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt nun 13 analoge Werte (statt bisher 11) die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von ca 117 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 111 µs (statt bisher 94 µs) aktualisiert wird.

==== Line-Modul ====
Ermitteln der Werte der Liniensensoren
Dateien: line.c
line.h
Dieser Modul ersetzt die originalen Bibliotheksfunktionen der Liniensensoren. Dies war notwendig da wir zusätzliche Liniensensoren verwenden.

Die Werte der Liniensensoren können nun mit der Funktion
<code>ln_get(index)</code>
gelesen werden. Die Werte selbst werden über den [[NIBObee#Analog-Modul|Analog-Modul]] ermittelt.

==== Bluetooth-Modul ====
Wickelt die Kommunikation über den Bluetooth Modul ab. Zur Kommunikation wird allerdings nur der USART als Terminal angesprochen, der Bluetooth Stack ist im [[BTM-222]] implementiert.
Dateien: bluetooth.c
bluetooth.h

==== Common-Modul ====
Stellt gemeinsame Funktionen zurVerfügung
Dateien: common.c
common.h

==== Distance-Modul ====
Behandelt die Odometrie Sensoren
Dateien: distance.c
distance.h

==== Drive-Modul ====
Bewegt den NIBObee
Dateien: drive.c
drive.h

==== Follow-Modul ====
Ist für die Linienverfolgung zuständig
Dateien: follow.c
follow.h

==== MaDeCo-Modul ====
Behandelt das MaDeCo Protokoll
Dateien: madeco.c
madeco.h

==== Main-Modul ====
Scheduler und zentraler Taktgeber
Dateien: main.c
main.h

==== Sensor-Modul ====
Ist für die "Fühler" zuständig
Dateien: follow.c
follow.h

=== Applikationen ===
==== Labyrinth erkunden ====

==== Kürzesten Weg durch Labyrinth ====

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-06-24T22:36:45Z

Alois: /* Liniensensoren */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
Hier wird nur ein kleiner Ausschnitt der technischen Daten dargestellt. Es handelt sich nur um jenen Teil der für die Bewertung oder Implementierung der gestellten Aufgaben relevant ist:

{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|RAM: 1 kB
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar.

Zwei Analoge Eingänge werden für die Fototransistoren der zusätzlichen Linienerkennung verwendet. Diese sind am NIBObee am Port X1 verfügbar.

Ein Ausgang dient zum ein- und ausschalten der zusätzlichen IR-LEDs. Dafür wird der PIN 1 des Port X4 verwendet.

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===

==== ATMega16 ====
Die Speichergröße scheint durchaus ausreichend zu sein. Nach Implementierung aller wichtigen Grundfunktionen ist erst weniger als die Hälfte des Programmspeichers belegt.

Problematisch war anfangs nur der geringe RAM der auch alle konstanten Strings enthält. Dies ist zwar nicht notwendig, ist mit dieser Entwicklungsumgebung allerdings so gelöst. Besonders die umfangreichen Debug-Informationen die über Bluetooth an den PC gesendet werden führten dabei zu massiven Problemen. Durch kurze symbolische Debugausgaben, die dann am PC im eigens entwickelten Terminalprogramm auf sprechende symbolische Ausgabe konvertiert wird, konnte das Problem behoben werden.

==== Liniensensoren ====
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
Die original NIBObee Biliothek wird nicht verwendet. Sie wurde durch eine eigene Implementierung im [[NIBObee#Line-Modul|Line-Modul]] ersetzt. Der Grund ist die Notwendigkeit die zusätzlichen Liniensensoren in der gleichen Weise wie die drei Originalsensoren zu behandeln.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen Gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

Nach einigen ersten Tests ist folgende weitere Aufgabe hinzugekommen:
* Herstellung der Hardware-Erweiterung mit zusätzlichen Liniensensoren

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusätzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt ausschließlich über Events. Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 2 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. lesen der Liniensensoren). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird nicht direkt vom Scheduler aufgerufen sondern über die Funktion <xx>_eventHandler. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; eine Funktion mit dem Namen <xx>_eventHandler (extern)
: Ist die Funktion die vom Scheduler aufgerufen wird damit die Statemaschine mit dem aktuellen Event, sofern vorhanden, durchlaufen wird.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.
; eine Funktion mit dem Namen <xx>_receiveEvent (intern)
: ReceiveEvent ist eigentlich eine interne Funktion (wird also nicht im Header File deklariert), der Pointer auf diese Funktion wird allerdings als Callback beim Subscribe übergeben damit der Event dem Modul zugestellt werden kann.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog-Modul ====
Digitalisieren der Analogeingänge
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Dies war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16 die Behandlung der Messung der Batteriespannung verbessert. Da hier die Referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.
Die einzelnen Werte werden weiterhin über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt nun 13 analoge Werte (statt bisher 11) die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von ca 117 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 111 µs (statt bisher 94 µs) aktualisiert wird.

==== Line-Modul ====
Ermitteln der Werte der Liniensensoren
Dateien: line.c
line.h
Dieser Modul ersetzt die originalen Bibliotheksfunktionen der Liniensensoren. Dies war notwendig da wir zusätzliche Liniensensoren verwenden.

Die Werte der Liniensensoren können nun mit der Funktion
<code>ln_get(index)</code>
gelesen werden. Die Werte selbst werden über den [[NIBObee#Analog-Modul|Analog-Modul]] ermittelt.

==== Bluetooth-Modul ====
Wickelt die Kommunikation über den Bluetooth Modul ab. Zur Kommunikation wird allerdings nur der USART als Terminal angesprochen, der Bluetooth Stack ist im [[BTM-222]] implementiert.
Dateien: bluetooth.c
bluetooth.h

==== Common-Modul ====
Stellt gemeinsame Funktionen zurVerfügung
Dateien: common.c
common.h

==== Distance-Modul ====
Behandelt die Odometrie Sensoren
Dateien: distance.c
distance.h

==== Drive-Modul ====
Bewegt den NIBObee
Dateien: drive.c
drive.h

==== Follow-Modul ====
Ist für die Linienverfolgung zuständig
Dateien: follow.c
follow.h

==== MaDeCo-Modul ====
Behandelt das MaDeCo Protokoll
Dateien: madeco.c
madeco.h

==== Main-Modul ====
Scheduler und zentraler Taktgeber
Dateien: main.c
main.h

==== Sensor-Modul ====
Ist für die "Fühler" zuständig
Dateien: follow.c
follow.h

=== Applikationen ===
==== Labyrinth erkunden ====

==== Kürzesten Weg durch Labyrinth ====

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-06-24T22:35:53Z

Alois: /* ATMega16 */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
Hier wird nur ein kleiner Ausschnitt der technischen Daten dargestellt. Es handelt sich nur um jenen Teil der für die Bewertung oder Implementierung der gestellten Aufgaben relevant ist:

{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|RAM: 1 kB
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar.

Zwei Analoge Eingänge werden für die Fototransistoren der zusätzlichen Linienerkennung verwendet. Diese sind am NIBObee am Port X1 verfügbar.

Ein Ausgang dient zum ein- und ausschalten der zusätzlichen IR-LEDs. Dafür wird der PIN 1 des Port X4 verwendet.

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===

==== ATMega16 ====
Die Speichergröße scheint durchaus ausreichend zu sein. Nach Implementierung aller wichtigen Grundfunktionen ist erst weniger als die Hälfte des Programmspeichers belegt.

Problematisch war anfangs nur der geringe RAM der auch alle konstanten Strings enthält. Dies ist zwar nicht notwendig, ist mit dieser Entwicklungsumgebung allerdings so gelöst. Besonders die umfangreichen Debug-Informationen die über Bluetooth an den PC gesendet werden führten dabei zu massiven Problemen. Durch kurze symbolische Debugausgaben, die dann am PC im eigens entwickelten Terminalprogramm auf sprechende symbolische Ausgabe konvertiert wird, konnte das Problem behoben werden.

==== Liniensensoren ====
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
Die original NIBObee Biliothek wird nicht verwendet. Sie wurde durch eine eigene Implementierung im [[NIBObee#Line-Modul|Line-Modul]] ersetzt. Der Grund ist die Notwendigkeit die zusätzlichen Liniensensoren in der gleichen weise wie die drei Originalsensoren zu behandeln.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen Gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

Nach einigen ersten Tests ist folgende weitere Aufgabe hinzugekommen:
* Herstellung der Hardware-Erweiterung mit zusätzlichen Liniensensoren

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusätzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt ausschließlich über Events. Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 2 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. lesen der Liniensensoren). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird nicht direkt vom Scheduler aufgerufen sondern über die Funktion <xx>_eventHandler. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; eine Funktion mit dem Namen <xx>_eventHandler (extern)
: Ist die Funktion die vom Scheduler aufgerufen wird damit die Statemaschine mit dem aktuellen Event, sofern vorhanden, durchlaufen wird.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.
; eine Funktion mit dem Namen <xx>_receiveEvent (intern)
: ReceiveEvent ist eigentlich eine interne Funktion (wird also nicht im Header File deklariert), der Pointer auf diese Funktion wird allerdings als Callback beim Subscribe übergeben damit der Event dem Modul zugestellt werden kann.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog-Modul ====
Digitalisieren der Analogeingänge
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Dies war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16 die Behandlung der Messung der Batteriespannung verbessert. Da hier die Referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.
Die einzelnen Werte werden weiterhin über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt nun 13 analoge Werte (statt bisher 11) die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von ca 117 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 111 µs (statt bisher 94 µs) aktualisiert wird.

==== Line-Modul ====
Ermitteln der Werte der Liniensensoren
Dateien: line.c
line.h
Dieser Modul ersetzt die originalen Bibliotheksfunktionen der Liniensensoren. Dies war notwendig da wir zusätzliche Liniensensoren verwenden.

Die Werte der Liniensensoren können nun mit der Funktion
<code>ln_get(index)</code>
gelesen werden. Die Werte selbst werden über den [[NIBObee#Analog-Modul|Analog-Modul]] ermittelt.

==== Bluetooth-Modul ====
Wickelt die Kommunikation über den Bluetooth Modul ab. Zur Kommunikation wird allerdings nur der USART als Terminal angesprochen, der Bluetooth Stack ist im [[BTM-222]] implementiert.
Dateien: bluetooth.c
bluetooth.h

==== Common-Modul ====
Stellt gemeinsame Funktionen zurVerfügung
Dateien: common.c
common.h

==== Distance-Modul ====
Behandelt die Odometrie Sensoren
Dateien: distance.c
distance.h

==== Drive-Modul ====
Bewegt den NIBObee
Dateien: drive.c
drive.h

==== Follow-Modul ====
Ist für die Linienverfolgung zuständig
Dateien: follow.c
follow.h

==== MaDeCo-Modul ====
Behandelt das MaDeCo Protokoll
Dateien: madeco.c
madeco.h

==== Main-Modul ====
Scheduler und zentraler Taktgeber
Dateien: main.c
main.h

==== Sensor-Modul ====
Ist für die "Fühler" zuständig
Dateien: follow.c
follow.h

=== Applikationen ===
==== Labyrinth erkunden ====

==== Kürzesten Weg durch Labyrinth ====

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

RoLoMa

2011-06-24T22:30:08Z

Alois: /* Projektfortschritt */

RoLoMa ist der, vielleicht wenig einfallsreiche, Name des ESE-Projekts im 4. Semester. Es ist die Abkürzung für "Robots Lost in Maze".
== Projektbeschreibung ==
=== Aufgabe ===
Bei diesem Projekt soll ein autonomer Roboter ein Labyrinth analysieren, alle vorhandenen Abzweigungen protokollieren und diese Daten an eine zentrale Einheit senden. Die zentrale Einheit soll einen zweiten autonomen Roboter mit diesen Daten auf dem berechneten kürzesten Weg durch das Labyrinth lotsen können. Dazu muss eine Kommunikation zwischen dem Roboter und der zentralen Einheit hergestellt werden.
Die oben erwähnte zentrale Einheit wird im weiteren Dokument als „Board“ bezeichnet und der autonome Roboter, aufgrund des gewählten Produkts „[[NIBObee]]“.
=== Details ===
[[File:ExampleMaze.png|thumb|120px|Beispiellabyrinth]]
Das Labyrinth wird eine Matrix mit vordefinierter Größe sein (z.B. 8x8) bei dem die möglichen Wege als schwarze Linie dargestellt sind. Auf dieser Linie wird sich der [[NIBObee]] bewegen. Die Aufgabe des ersten [[NIBObee]] besteht nun darin das gesamt Labyrinth abzufahren und eine Karte zu erstellen.

Diese gesammelte Information wird dann an das Board übertragen. Dort wird das Labyrinth auf einer grafischen Ausgabe dargestellt und der Benutzer kann einen beliebigen Zielpunkt für den zweiten [[NIBObee]] festlegen. Der optimale Weg wird berechnet und der zweite [[NIBObee]] über diesen Weg an das definierte Ziel geleitet.


 

=== Aufgabenteilung ===
An dem Projekt sind zwei Gruppen beteiligt, eine die sich um die Roboter kümmert (Gruppe NIBObee), eine zweite die die Implementierung der zentralen Einheit (Gruppe Board) vornimmt. Gemeinsam muss die Übertragungstechnik (Hardware und Protokoll) erarbeitet werden. Die Implementierung kann dann getrennt erfolgen und am Ende des Projekts ist eine gemeinsame Testphase notwendig.

Da noch einige Festlegungen bezüglich der verwendeten Hardware und der Übertragungstechnik ausständig sind können sich im Zuge des weiteren Projektfortschritts durchaus noch Änderungen ergeben. Für alle kritischen Elemente wird so früh wie möglich auch eine alternative Lösung als Fallback vorgesehen. Das ist notwendig für den Fall, dass sich für ein Problem keine, zumindest im Rahmen dieses Semesters, realisierbare Implementierung ergibt.

==== Team Board ====
Teammitglieder dieser Gruppe sind:
* Michaela Escuyer
* Thomas Neuber
* Robert Pavljuk
==== Team NIBObee ====
Teammitglieder dieser Gruppe sind:
* Robert Peterfi
* Alois Pochmann
* Reinhard Weismann

== Realisierung ==

=== Plattformen / Hardware ===
Die Plattformen der Roboter und der Kontrolleinheit sind im Folgenden aufgelistet und stehen (wenn auch teilweise nur als Bausatz) fertig zur Verfügung. Die Hardware der Kommunikationseinrichtung wird im Zuge dieses Projekts erstellt.

==== Roboter ====
Der eingesetzte Roboter ist eine [[NIBObee]] von [http://www.nicai-systems.com/de/nibobee.html Nicai-Systems]. Dieser Roboter verfügt über einen Liniensensor der es prinzipiell ermöglicht einer kontrastreichen Linie, vorzugsweise schwarze Linie auf weißem Boden, zu folgen.

Weitere Dateils können der [[NIBObee]]-Seite entnommen werden.

==== Kontrolleinheit ====
Die Zentrale Kontrolleinheit wird auf dem vom 3. Semester bekannten [[LPC2478]] realisiert.

==== Kommunikation ====
Die Kommunikation der [[NIBObee]]-Roboter mit der zentralen Steuerung erfolgt über Bluetooth. Dazu wird über den auf beiden Plattformen bestehenden UART Anschluss ein Modul mit RS232-BT Umsetzung verwendet.
Die im Folgenden aufgelisteten Module kommen für die Umsetzung in Frage:
* BTM-112
* [[BTM-222]]
Die Entscheidung ist zugunsten des [[BTM-222]] gefallen. Details dazu können der [[BTM-222]]-Seite entnommen werden.

=== Software ===
Details zur Software sind auf den Seiten von [[NIBObee#Software|NIBObee]] und [[LPC2478#Software|LPC2478]] zu finden.

=== Protokolle ===
==== Bluetooth ====
Der gesamte Bluetooth Stack ist im [[BTM-222]] realsiert und muss daher im Projekt nicht betrachtet werden.
==== [[MaDeCo]] ====
Das projektspezifische Protokol zur Übertragung der Labyrinthdaten nach / bei der Erkundung und dann zu Steuerung durch das Labyrinth ('''Ma'''ze '''De'''tection and '''Co'''ntrol) ist zu definieren.

=== Testumgebung ===
==== Labyrinth ====
Wie schon in der Angabe zu sehen ist gelten für das Labyrinth einige Annahmen die als Voraussetzungen für die Implementierung festgelegt werden:
* Es gibt nur gerade Linien
* Alle Kreuzungen sind rechtwinkelig
* Alle Abstände sind genau ein Vielfaches der kürzesten Verbindung der Mittelpunkte zweier Felder
* Alle (nicht sichtbaren) Felder sind gleich groß
* Das gesamte Labyrinth entspricht einer Baumstruktur, d.h. es gibt niemals zwei paralelle Wege von einem Punkt zu einem Anderen, also keine geschlossenen Schleifen.
* Da die Steuerung ausschließlich über die Liniensensoren implementiert wird ist die Strecke kollisionsfrei zu halten, d.h. der [[NIBObee]] wird nicht auf Kontakt mit den Fühlern durch Ausweichmanöver reagieren.

==== Simulationen ====
Damit ein unabhängiges Testen der einzelnen Teile des Projekts möglich ist werden in einigen Bereichen Simulationen eingesetzt:
* Bluetooth-Verbindung kann mit einem PC und Terminalprogramm getestet werden
* [[MaDeCo]]-Protokoll wird textbasiert entworfen um mit einfachen Textfiles auf beiden Seiten testen zu können

== Projektfortschritt ==
Der Projektfortschritt wird im gleichen Intervall verfolgt in dem die Lehrveranstaltung abgehalten wird

{| class="wikitable"
|-
!Woche
!Block
!Tätigkeiten / Erkenntnisse
|-

|14.02.2011 - 20.02.2011
|Gemeinsam
|
* Projektdefinition: Festlegen des Projektinhalts und grobe Abstimmung der einzelnen beteiligten Komponenten.
* Erstellung eines Dokuments zur Projektbeschreibung
* Erstellen eines Projektplans

|-

|'''21.02.2011'''
|colspan="2"|'''Projekt akzeptiert -> Projektstart'''
|-

|rowspan="3"|21.02.2011 - 27.02.2011
|Gemeinsam
|
* Bestellungen besprochen.
* Wiki eingerichtet.
* Bestelliste für Bluetooth Module erstellt
** Auflistung siehe [[BTM-222#Hardware|BTM-222 Stückliste]]
* Gesamte Hardware bestellt:
** 2 NIBObee - Programmierbarer Roboter-Bausatz
** 5 x [[BTM-222#Hardware|BTM-222 Stückliste]] (3 x für das Nibobee und 2 x für das board) erstellt.

|-
|Board
|
* Display Erfahrungsberichte recherchiert.
* Grafik Konzept (Blöcke) besprochen
* Beispiel Implementierungen für Touchscreen und Grafik von [[LPC2478|LPC 2478]] gesucht

|-
|NIBObee
|
* Bestellungen besprochen.
* nach Bauanleitungen und Datenblätter recherchiert.
* Printlayout des BT-Modul für NIBObee erstellt
* Recherche der BTM-222 Konfigurationsmöglichkeiten.
* Sammeln offener Punkte, auflisten von Risiken und möglicher Massnahmen

|-

|rowspan="3"|28.02.2011 - 06.03.2011
|Gemeinsam
|
* Definition des proprietären Kommunikationsprotokolls [[MaDeCo| MaDeCo ('''Ma'''ze '''De'''tection and '''Co'''ntrol)]]

|-
|Board
|
* Weitere Analyse für Touchscreen und Grafikausgabe
* Demo Implementierung von Hr. Kramer angefordert und eingelesen
* Sourcen Demo Projekt in Eclipse Ganymed geladen und Debug Optionen ergänzt
* Debuggingversuche, Ursachensuche für fehlende Anzeige

|-
|NIBObee
|
* Bestellung eingetroffen. Zusammenbau der Roboter durchgeführt
* Detailabsprache der benötigten Roboterfunktionen
* Analyse der Probleme beim Befahren des Labyrinths und Abbildung auf notwendige Funktionen.

|-

|rowspan="3"|07.03.2011 - 13.03.2011
|Gemeinsam
|
* Recherche Ergebnisse besprochen
* Bauteile für Bluetooth Modul sind teilweise nicht optimal (vor allem wegen der Größe). Es werden noch Alternativen gesucht und das Layout und der Bestückungspan wurden geändert.

|-
|Board
|
* Mehrstündiger Versuch, das Display mit Demo Applikationen zu testen
* daraus resultierende Tests haben ergeben dass das Display defekt war. Das Board wurde gegen ein neues getauscht
* neuerliche Inbetriebnahme mit Demo Applikationen

|-
|NIBObee
|
* Installation der Entwicklungsumbegung
* Testen der Beispielprogramme
* Kalibrierung der Liniensensoren
* Erstellen eines Testprogramms für die Liniensensoren um die optimale Linienbreite für das Labyrinth ermitteln zu können (2 cm scheint zu breit, Kontrastwert nicht über 128).

|-

|rowspan="3"|14.03.2011 - 20.03.2011
|Gemeinsam
|
* Besprechung der jeweiligen Ergebnisse
* neue Bestückungsliste besprechen und fehlende Teile organisieren

|-
|Board
|
* weitere Recherche nach lauffähigen Demoapplikationen
* Für speziell dieses Board frustrierend wenige bis keine Ergebnisse

|-
|NIBObee
|
* Versuche mit zwei unterschiedlichen Ansätzen des Geradeauslaufs des NIBObee:
** Korrektur mittles Regelkreis unter Berücksichtigung der Odometriesensoren
** Korrektur nur mttels der Werte von den Liniensensoren
* Obwohl der Regelkreis eine gradeausfahrt auch ohne Linie schafft ist der Start problematisch und daher für unsere Zwecke ungeeignet

|-

|rowspan="3"|21.03.2011 - 27.03.2011
|Gemeinsam
|
* gegenseitiges Update
* fast alle Bauteile eingetroffen bzw. vorhanden, Ausnahme: Printplatte
** voraussichtlicher Liefertermin der Printplatte kommende Woche

|-
|Board
|
* vergebliche Versuche, den UART in Betrieb zu nehmen
* gemeinsam mit Hrn. Wenzl nochmals versucht, auch ergebnislos
* Entschluss, das Vorgehen zu ändern
* neues Projekt auf Basis Interrupt Template vom 3. Semester
* Anpassung auf unsere Umgebung

|-
|NIBObee
|
* Implementierung gestartet mit folgenden Funktionen:
* Systemtimer mit 100Hz Taktfrequenz
* Statemachine für folgende Module:
** Drive, zuständig für das fahren entlang der Linie des Labyrinths
** Sensor, zuständig für die Fühler. Entprellen und melden von Änderungen.
** Line, zuständig für das erkennen der Linie und melden von Abweichungen
* Scheduler, der alle Module die einen Event bearbeiten müssen aufruft.

|-

|rowspan="3"|28.03.2011 - 03.04.2011
|Gemeinsam
|
*Leiterplatten eingetroffen, Beginn des Aufbaus der Bluetooth Module

|-
|Board
|

|-
|NIBObee
|
*Implementieren der Linienverfolgung mit den Statemachines
*Neuer Modul für Distanzmessung. Wurde von der Implementierung der Odometrie-Bibliothek abgeleitet.
*Erfolgreiches Ausrichten des NIBObee im Zentrum eines Felds des Labyrinths
*Probleme beim Unterscheiden von Spurabweichung und Kreuzung. Kann mit den vorhandenen Sensoren nicht gelöst werden. Es wird eine Erweiterung des NIBObee geplant.
*Zusätzliche 6 LEDs für Debugzwecke über Erweiterungsports angeschlossen und Ansteuerung implementiert

|-

|rowspan="3"|04.04.2011 - 10.04.2011
|Gemeinsam
|
*Nochmals Bauteile für BT-Modul getauscht da ein leistungfähiger Low-Drop-Out Spannungsregeler verwendet werden soll um auch mit abgesunkener Akkuspannung noch eine konstante Spannung am BTM-222 zu haben.
*Das machte allerdings eine Korrektur an den fertigen Leiterplatten notwendig :-(

|-
|Board
|

|-
|NIBObee
|
*Fertigstellen des ersten Bluetooth Moduls
*Verbindung von NIBObee mit PC hergestellt
*Neue Funktionen zur Kommunikation. Senden und Empfangen mittels Interrupts implementiert
*Start Implementierung der State Maschine für das MaDeCo Protokoll
*Debug Möglichkeit mittels BT-Verbindung zum PC implementiert
*PC Testapplikation für die Bluetooth Verbindung mit spezieller Unterstützung des MaDeCo Protokolls implementiert.
*Erzeugen von DoxyGen Dokumentation

|-

|rowspan="3"|11.04.2011 - 01.05.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Überarbeiten des Event-Machanismus
*Optimieren der Debug-Protokollierung über Bluetooth. Strings belegten zu viel Speicher. Das führte zu undefinierbarem Verhalten wegen Überschreiben von Stack und Daten.
*Erweitern der PC Applikation zum bedienen der NIBObee BT-Schnittstelle. Die optimierte Debug-Ausgabe kann auf Basis von speziellen Kommentaren der NIBObee-Source (debug.h) symbolisch aufbereitet werden.
*Erweiterung mit zusätliche Liniensensoren angefertigt
*Wegen zusätzlicher Liniensensoren neue Applikation zum Kalibrieren der Liniensensoren (jetzt 5 Sück) erstellt.
*Wegen zusätzlicher Liniensensoren ersetzen des original Moduls zum Einlesen der Analogwerte.
*Wegen zusätzlicher Liniensensoren ersetzen des original Moduls zum ermitteln der Werte der Liniensensoren.
*Kreuzungserkennung und Linienverfolgung funktionieren nun parallel, NIBObee fährt kleines Testlabyrinth gezielt ab.
*Waagrechte Ausrichtung des NIBObee korrigiert da der Abstand der Liniensensoren zum Boden von essentieller Bedeutung ist.
*Doxygen Kommentare in Code eingefügt
*Doxygen in Entwicklungsumgebung eingebunden

|-

|rowspan="3"|02.05.2011 - 08.05.2011
|Gemeinsam
|

|-
|Board
|
* verschiedene UART sourcecodes aus fremden Demoapplikationen versucht auf das board zu portieren

|-
|NIBObee
|
*Tests mit neuen, zusätzlichen Liniensensoren.
*Probleme mit Hardwareausfällen der neuen Erweiterung. Die Phototransistoren reagieren nicht so gut wie erwartet. Ausserdem scheinen sie sehr leicht bei den Lötarbeiten defekt zu werden. Austausch notwendig
*Weitere Optimierungender Debugausgaben notwendig. Zusätzliche Funktionen in Testapplikation implementiert um nicht nur die Testpunkte, sondern auch die unterschiedlichen dezimalen Werte in symbolische Ausgaben umrechnen zu können.
*Fehlerhafte Linienendeerkennung, optimieren des Algorithmus.

|-

|rowspan="3"|09.05.2011 - 15.05.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Fertigstellen der MaDeCo State Machine für die unterschiedlichen Betriebsmodi und der Kommunikation mit dem drive Modul
*Implementieren der unterschiedlichen Betriebsmodi im drive Modul
*Test des Calibrate Modus zeigt Probleme beim Geradeauslauf nach Linienende, Kalibrierungsvorlage muss überarbeitet werden.

|-

|rowspan="3"|16.05.2011 - 22.05.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Zusätzliche MaDeCo Funktionen für den Testbetrieb
*Erweiterung des MaDeCo Protokolls für einfachere Implementierung
*Überarbeiten der Inlinedokumentation

|-

|rowspan="3"|23.05.2011 - 29.05.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Aktualisieren der Wiki Dokumentation
*Modus Calibration erfolgreich abgeschlossen, EEPROM wird mit korrekten Werten versorgt
*Linienverfolgung funktioniert nicht zufriedenstellend, Analyse aufwendig da beim Fehlersuchen sehr viele Daten der Liniensensoren anfallen, übertragen und ausgewertet müssen. Dabei stossen wir immer wieder an die Leistungsgrenzen des Systems.

|-

|rowspan="3"|30.05.2011 - 05.06.2011
|Gemeinsam
|

|-
|Board
|
* PLL Initialisierung kontrolliert, marginaler Fehler korrigiert
* UART Initialisierung kontrolliert, nichts gefunden. UART0 Senden OK, UART1 NOK
* UART1 Initialisierung auf P3.16 und P3.17 führt zum Erfolg
* Die nötigen UART Funktionen identifiziert und modular implementiert.
* UART Funktionen Interrupt getrieben implementiert
* bluetooth Modul aufgebaut

|-
|NIBObee
|
*Weiter massive Probleme bei der Linienverfolgung
*Nach Rotation entstehen üblicherweise Positionierungsfehler die sich danach aufschaukeln
*Follow und Drive Modul werden überarbeitet um "weichere" korrektur zu imlpementieren

|-

|rowspan="3"|06.06.2011 - 19.06.2011
|Gemeinsam
|
* Funktionstest für bluetooth Modul am board und interruptgetriebene UART Funktionen

|-
|Board
|
* Interrupt Handler erweitert: signalisiert wenn message komplett (CR) empfangen
* Handling für Sequenz- und Acknowledge-Nummern
* state machine für MaDeCo Protokoll
* Interface zu PC-Applikation

|-
|NIBObee
|
*Überarbeiten des Scheduling um Linienverfolgung mit mehr Priorität zu versehen
*Weitere Überarbeitung der Linienerkennung
*Verbesserung der Schnittstelle zum Board (ACK strikt nach Protokoll, keine unnötigen Ausgaben)
*Korrigieren des problematischen Verhaltens wegen der Meldungen des BTM-222 in der Initialisierungsphase

|-

|'''20.06.2011'''
|colspan="2"|'''Projekt präsentiert -> Projektende'''
|-

|}

[[Kategorie:FH]]

RoLoMa

2011-06-24T20:04:44Z

Alois: /* Projektfortschritt */

RoLoMa ist der, vielleicht wenig einfallsreiche, Name des ESE-Projekts im 4. Semester. Es ist die Abkürzung für "Robots Lost in Maze".
== Projektbeschreibung ==
=== Aufgabe ===
Bei diesem Projekt soll ein autonomer Roboter ein Labyrinth analysieren, alle vorhandenen Abzweigungen protokollieren und diese Daten an eine zentrale Einheit senden. Die zentrale Einheit soll einen zweiten autonomen Roboter mit diesen Daten auf dem berechneten kürzesten Weg durch das Labyrinth lotsen können. Dazu muss eine Kommunikation zwischen dem Roboter und der zentralen Einheit hergestellt werden.
Die oben erwähnte zentrale Einheit wird im weiteren Dokument als „Board“ bezeichnet und der autonome Roboter, aufgrund des gewählten Produkts „[[NIBObee]]“.
=== Details ===
[[File:ExampleMaze.png|thumb|120px|Beispiellabyrinth]]
Das Labyrinth wird eine Matrix mit vordefinierter Größe sein (z.B. 8x8) bei dem die möglichen Wege als schwarze Linie dargestellt sind. Auf dieser Linie wird sich der [[NIBObee]] bewegen. Die Aufgabe des ersten [[NIBObee]] besteht nun darin das gesamt Labyrinth abzufahren und eine Karte zu erstellen.

Diese gesammelte Information wird dann an das Board übertragen. Dort wird das Labyrinth auf einer grafischen Ausgabe dargestellt und der Benutzer kann einen beliebigen Zielpunkt für den zweiten [[NIBObee]] festlegen. Der optimale Weg wird berechnet und der zweite [[NIBObee]] über diesen Weg an das definierte Ziel geleitet.


 

=== Aufgabenteilung ===
An dem Projekt sind zwei Gruppen beteiligt, eine die sich um die Roboter kümmert (Gruppe NIBObee), eine zweite die die Implementierung der zentralen Einheit (Gruppe Board) vornimmt. Gemeinsam muss die Übertragungstechnik (Hardware und Protokoll) erarbeitet werden. Die Implementierung kann dann getrennt erfolgen und am Ende des Projekts ist eine gemeinsame Testphase notwendig.

Da noch einige Festlegungen bezüglich der verwendeten Hardware und der Übertragungstechnik ausständig sind können sich im Zuge des weiteren Projektfortschritts durchaus noch Änderungen ergeben. Für alle kritischen Elemente wird so früh wie möglich auch eine alternative Lösung als Fallback vorgesehen. Das ist notwendig für den Fall, dass sich für ein Problem keine, zumindest im Rahmen dieses Semesters, realisierbare Implementierung ergibt.

==== Team Board ====
Teammitglieder dieser Gruppe sind:
* Michaela Escuyer
* Thomas Neuber
* Robert Pavljuk
==== Team NIBObee ====
Teammitglieder dieser Gruppe sind:
* Robert Peterfi
* Alois Pochmann
* Reinhard Weismann

== Realisierung ==

=== Plattformen / Hardware ===
Die Plattformen der Roboter und der Kontrolleinheit sind im Folgenden aufgelistet und stehen (wenn auch teilweise nur als Bausatz) fertig zur Verfügung. Die Hardware der Kommunikationseinrichtung wird im Zuge dieses Projekts erstellt.

==== Roboter ====
Der eingesetzte Roboter ist eine [[NIBObee]] von [http://www.nicai-systems.com/de/nibobee.html Nicai-Systems]. Dieser Roboter verfügt über einen Liniensensor der es prinzipiell ermöglicht einer kontrastreichen Linie, vorzugsweise schwarze Linie auf weißem Boden, zu folgen.

Weitere Dateils können der [[NIBObee]]-Seite entnommen werden.

==== Kontrolleinheit ====
Die Zentrale Kontrolleinheit wird auf dem vom 3. Semester bekannten [[LPC2478]] realisiert.

==== Kommunikation ====
Die Kommunikation der [[NIBObee]]-Roboter mit der zentralen Steuerung erfolgt über Bluetooth. Dazu wird über den auf beiden Plattformen bestehenden UART Anschluss ein Modul mit RS232-BT Umsetzung verwendet.
Die im Folgenden aufgelisteten Module kommen für die Umsetzung in Frage:
* BTM-112
* [[BTM-222]]
Die Entscheidung ist zugunsten des [[BTM-222]] gefallen. Details dazu können der [[BTM-222]]-Seite entnommen werden.

=== Software ===
Details zur Software sind auf den Seiten von [[NIBObee#Software|NIBObee]] und [[LPC2478#Software|LPC2478]] zu finden.

=== Protokolle ===
==== Bluetooth ====
Der gesamte Bluetooth Stack ist im [[BTM-222]] realsiert und muss daher im Projekt nicht betrachtet werden.
==== [[MaDeCo]] ====
Das projektspezifische Protokol zur Übertragung der Labyrinthdaten nach / bei der Erkundung und dann zu Steuerung durch das Labyrinth ('''Ma'''ze '''De'''tection and '''Co'''ntrol) ist zu definieren.

=== Testumgebung ===
==== Labyrinth ====
Wie schon in der Angabe zu sehen ist gelten für das Labyrinth einige Annahmen die als Voraussetzungen für die Implementierung festgelegt werden:
* Es gibt nur gerade Linien
* Alle Kreuzungen sind rechtwinkelig
* Alle Abstände sind genau ein Vielfaches der kürzesten Verbindung der Mittelpunkte zweier Felder
* Alle (nicht sichtbaren) Felder sind gleich groß
* Das gesamte Labyrinth entspricht einer Baumstruktur, d.h. es gibt niemals zwei paralelle Wege von einem Punkt zu einem Anderen, also keine geschlossenen Schleifen.
* Da die Steuerung ausschließlich über die Liniensensoren implementiert wird ist die Strecke kollisionsfrei zu halten, d.h. der [[NIBObee]] wird nicht auf Kontakt mit den Fühlern durch Ausweichmanöver reagieren.

==== Simulationen ====
Damit ein unabhängiges Testen der einzelnen Teile des Projekts möglich ist werden in einigen Bereichen Simulationen eingesetzt:
* Bluetooth-Verbindung kann mit einem PC und Terminalprogramm getestet werden
* [[MaDeCo]]-Protokoll wird textbasiert entworfen um mit einfachen Textfiles auf beiden Seiten testen zu können

== Projektfortschritt ==
Der Projektfortschritt wird im gleichen Intervall verfolgt in dem die Lehrveranstaltung abgehalten wird

{| class="wikitable"
|-
!Woche
!Block
!Tätigkeiten / Erkenntnisse
|-

|14.02.2011 - 20.02.2011
|Gemeinsam
|
* Projektdefinition: Festlegen des Projektinhalts und grobe Abstimmung der einzelnen beteiligten Komponenten.
* Erstellung eines Dokuments zur Projektbeschreibung
* Erstellen eines Projektplans

|-

|'''21.02.2011'''
|colspan="2"|'''Projekt akzeptiert -> Projektstart'''
|-

|rowspan="3"|21.02.2011 - 27.02.2011
|Gemeinsam
|
* Bestellungen besprochen.
* Wiki eingerichtet.
* Bestelliste für Bluetooth Module erstellt
** Auflistung siehe [[BTM-222#Hardware|BTM-222 Stückliste]]
* Gesamte Hardware bestellt:
** 2 NIBObee - Programmierbarer Roboter-Bausatz
** 5 x [[BTM-222#Hardware|BTM-222 Stückliste]] (3 x für das Nibobee und 2 x für das board) erstellt.

|-
|Board
|
* Display Erfahrungsberichte recherchiert.
* Grafik Konzept (Blöcke) besprochen
* Beispiel Implementierungen für Touchscreen und Grafik von [[LPC2478|LPC 2478]] gesucht

|-
|NIBObee
|
* Bestellungen besprochen.
* nach Bauanleitungen und Datenblätter recherchiert.
* Printlayout des BT-Modul für NIBObee erstellt
* Recherche der BTM-222 Konfigurationsmöglichkeiten.
* Sammeln offener Punkte, auflisten von Risiken und möglicher Massnahmen

|-

|rowspan="3"|28.02.2011 - 06.03.2011
|Gemeinsam
|
* Definition des proprietären Kommunikationsprotokolls [[MaDeCo| MaDeCo ('''Ma'''ze '''De'''tection and '''Co'''ntrol)]]

|-
|Board
|
* Weitere Analyse für Touchscreen und Grafikausgabe
* Demo Implementierung von Hr. Kramer angefordert und eingelesen
* Sourcen Demo Projekt in Eclipse Ganymed geladen und Debug Optionen ergänzt
* Debuggingversuche, Ursachensuche für fehlende Anzeige

|-
|NIBObee
|
* Bestellung eingetroffen. Zusammenbau der Roboter durchgeführt
* Detailabsprache der benötigten Roboterfunktionen
* Analyse der Probleme beim Befahren des Labyrinths und Abbildung auf notwendige Funktionen.

|-

|rowspan="3"|7.3.2011-13.3.2011
|Gemeinsam
|
* Recherche Ergebnisse besprochen
* Bauteile für Bluetooth Modul sind teilweise nicht optimal (vor allem wegen der Größe). Es werden noch Alternativen gesucht und das Layout und der Bestückungspan wurden geändert.

|-
|Board
|
* Mehrstündiger Versuch, das Display mit Demo Applikationen zu testen
* daraus resultierende Tests haben ergeben dass das Display defekt war. Das Board wurde gegen ein neues getauscht
* neuerliche Inbetriebnahme mit Demo Applikationen

|-
|NIBObee
|
* Installation der Entwicklungsumbegung
* Testen der Beispielprogramme
* Kalibrierung der Liniensensoren
* Erstellen eines Testprogramms für die Liniensensoren um die optimale Linienbreite für das Labyrinth ermitteln zu können (2 cm scheint zu breit, Kontrastwert nicht über 128).

|-

|rowspan="3"|14.3.2011-20.3.2011
|Gemeinsam
|
* Besprechung der jeweiligen Ergebnisse
* neue Bestückungsliste besprechen und fehlende Teile organisieren

|-
|Board
|
* weitere Recherche nach lauffähigen Demoapplikationen
* Für speziell dieses Board frustrierend wenige bis keine Ergebnisse

|-
|NIBObee
|
* Versuche mit zwei unterschiedlichen Ansätzen des Geradeauslaufs des NIBObee:
** Korrektur mittles Regelkreis unter Berücksichtigung der Odometriesensoren
** Korrektur nur mttels der Werte von den Liniensensoren
* Obwohl der Regelkreis eine gradeausfahrt auch ohne Linie schafft ist der Start problematisch und daher für unsere Zwecke ungeeignet

|-

|rowspan="3"|21.3.2011-27.3.2011
|Gemeinsam
|
* gegenseitiges Update
* fast alle Bauteile eingetroffen bzw. vorhanden, Ausnahme: Printplatte
** voraussichtlicher Liefertermin der Printplatte kommende Woche

|-
|Board
|
* vergebliche Versuche, den UART in Betrieb zu nehmen
* gemeinsam mit Hrn. Wenzl nochmals versucht, auch ergebnislos
* Entschluss, das Vorgehen zu ändern
* neues Projekt auf Basis Interrupt Template vom 3. Semester
* Anpassung auf unsere Umgebung

|-
|NIBObee
|
* Implementierung gestartet mit folgenden Funktionen:
* Systemtimer mit 100Hz Taktfrequenz
* Statemachine für folgende Module:
** Drive, zuständig für das fahren entlang der Linie des Labyrinths
** Sensor, zuständig für die Fühler. Entprellen und melden von Änderungen.
** Line, zuständig für das erkennen der Linie und melden von Abweichungen
* Scheduler, der alle Module die einen Event bearbeiten müssen aufruft.

|-

|rowspan="3"|28.3.2011-3.4.2011
|Gemeinsam
|
*Leiterplatten eingetroffen, Beginn des Aufbaus der Bluetooth Module

|-
|Board
|

|-
|NIBObee
|
*Implementieren der Linienverfolgung mit den Statemachines
*Neuer Modul für Distanzmessung. Wurde von der Implementierung der Odometrie-Bibliothek abgeleitet.
*Erfolgreiches Ausrichten des NIBObee im Zentrum eines Felds des Labyrinths
*Probleme beim Unterscheiden von Spurabweichung und Kreuzung. Kann mit den vorhandenen Sensoren nicht gelöst werden. Es wird eine Erweiterung des NIBObee geplant.
*Zusätzliche 6 LEDs für Debugzwecke über Erweiterungsports angeschlossen und Ansteuerung implementiert

|-

|rowspan="3"|4.4.2011-10.4.2011
|Gemeinsam
|
*Nochmals Bauteile für BT-Modul getauscht da ein leistungfähiger Low-Drop-Out Spannungsregeler verwendet werden soll um auch mit abgesunkener Akkuspannung noch eine konstante Spannung am BTM-222 zu haben.
*Das machte allerdings eine Korrektur an den fertigen Leiterplatten notwendig :-(

|-
|Board
|

|-
|NIBObee
|
*Fertigstellen des ersten Bluetooth Moduls
*Verbindung von NIBObee mit PC hergestellt
*Neue Funktionen zur Kommunikation. Senden und Empfangen mittels Interrupts implementiert
*Start Implementierung der State Maschine für das MaDeCo Protokoll
*Debug Möglichkeit mittels BT-Verbindung zum PC implementiert
*PC Testapplikation für die Bluetooth Verbindung mit spezieller Unterstützung des MaDeCo Protokolls implementiert.
*Erzeugen von DoxyGen Dokumentation

|-

|rowspan="3"|11.4.2011-1.5.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Überarbeiten des Event-Machanismus
*Optimieren der Debug-Protokollierung über Bluetooth. Strings belegten zu viel Speicher. Das führte zu undefinierbarem Verhalten wegen Überschreiben von Stack und Daten.
*Erweitern der PC Applikation zum bedienen der NIBObee BT-Schnittstelle. Die optimierte Debug-Ausgabe kann auf Basis von speziellen Kommentaren der NIBObee-Source (debug.h) symbolisch aufbereitet werden.
*Erweiterung mit zusätliche Liniensensoren angefertigt
*Wegen zusätzlicher Liniensensoren neue Applikation zum Kalibrieren der Liniensensoren (jetzt 5 Sück) erstellt.
*Wegen zusätzlicher Liniensensoren ersetzen des original Moduls zum Einlesen der Analogwerte.
*Wegen zusätzlicher Liniensensoren ersetzen des original Moduls zum ermitteln der Werte der Liniensensoren.
*Kreuzungserkennung und Linienverfolgung funktionieren nun parallel, NIBObee fährt kleines Testlabyrinth gezielt ab.
*Waagrechte Ausrichtung des NIBObee korrigiert da der Abstand der Liniensensoren zum Boden von essentieller Bedeutung ist.
*Doxygen Kommentare in Code eingefügt
*Doxygen in Entwicklungsumgebung eingebunden

|-

|rowspan="3"|2.5.2011-8.5.2011
|Gemeinsam
|

|-
|Board
|
* verschiedene UART sourcecodes aus fremden Demoapplikationen versucht auf das board zu portieren

|-
|NIBObee
|
*Tests mit neuen, zusätzlichen Liniensensoren.
*Probleme mit Hardwareausfällen der neuen Erweiterung. Die Phototransistoren reagieren nicht so gut wie erwartet. Ausserdem scheinen sie sehr leicht bei den Lötarbeiten defekt zu werden. Austausch notwendig
*Weitere Optimierungender Debugausgaben notwendig. Zusätzliche Funktionen in Testapplikation implementiert um nicht nur die Testpunkte, sondern auch die unterschiedlichen dezimalen Werte in symbolische Ausgaben umrechnen zu können.
*Fehlerhafte Linienendeerkennung, optimieren des Algorithmus.

|-

|rowspan="3"|9.5.2011-15.5.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Fertigstellen der MaDeCo State Machine für die unterschiedlichen Betriebsmodi und der Kommunikation mit dem drive Modul
*Implementieren der unterschiedlichen Betriebsmodi im drive Modul
*Test des Calibrate Modus zeigt Probleme beim Geradeauslauf nach Linienende, Kalibrierungsvorlage muss überarbeitet werden.

|-

|rowspan="3"|16.5.2011-22.5.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Zusätzliche MaDeCo Funktionen für den Testbetrieb
*Erweiterung des MaDeCo Protokolls für einfachere Implementierung
*Überarbeiten der Inlinedokumentation

|-

|rowspan="3"|23.5.2011-29.5.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Aktualisieren der Wiki Dokumentation
*Modus Calibration erfolgreich abgeschlossen, EEPROM wird mit korrekten Werten versorgt
*Linienverfolgung funktioniert nicht zufriedenstellend, Analyse aufwendig da beim Fehlersuchen sehr viele Daten der Liniensensoren anfallen, übertragen und ausgewertet müssen. Dabei stossen wir immer wieder an die Leistungsgrenzen des Systems.

|-

|rowspan="3"|30.5.2011-5.6.2011
|Gemeinsam
|

|-
|Board
|
* PLL Initialisierung kontrolliert, marginaler Fehler korrigiert
* UART Initialisierung kontrolliert, nichts gefunden. UART0 Senden OK, UART1 NOK
* UART1 Initialisierung auf P3.16 und P3.17 führt zum Erfolg
* Die nötigen UART Funktionen identifiziert und modular implementiert.
* UART Funktionen Interrupt getrieben implementiert
* bluetooth Modul aufgebaut

|-
|NIBObee
|
*Weiter massive Probleme bei der Linienverfolgung
*Nach Rotation entstehen üblicherweise Positionierungsfehler die sich danach aufschaukeln
*Follow und Drive Modul werden überarbeitet um "weichere" korrektur zu imlpementieren

|-

|rowspan="3"|6.6.2011-19.6.2011
|Gemeinsam
|
* Funktionstest für bluetooth Modul am board und interruptgetriebene UART Funktionen

|-
|Board
|
* Interrupt Handler erweitert: signalisiert wenn message komplett (CR) empfangen
* Handling für Sequenz- und Acknowledge-Nummern
* state machine für MaDeCo Protokoll
* Interface zu PC-Applikation

|-
|NIBObee
|
*Überarbeiten des Scheduling um Linienverfolgung mit mehr Priorität zu versehen
*Weitere Überarbeitung der Linienerkennung
*Verbesserung der Schnittstelle zum Board (ACK strikt nach Protokoll, keine unnötigen Ausgaben)
*Korrigieren des problematischen Verhaltens wegen der Meldungen des BTM-222 in der Initialisierungsphase

|-

|'''20.06.2011'''
|colspan="2"|'''Projekt präsentiert -> Projektende'''
|-

|}

[[Kategorie:FH]]

RoLoMa

2011-06-24T19:53:39Z

Alois: /* Projektfortschritt */

RoLoMa ist der, vielleicht wenig einfallsreiche, Name des ESE-Projekts im 4. Semester. Es ist die Abkürzung für "Robots Lost in Maze".
== Projektbeschreibung ==
=== Aufgabe ===
Bei diesem Projekt soll ein autonomer Roboter ein Labyrinth analysieren, alle vorhandenen Abzweigungen protokollieren und diese Daten an eine zentrale Einheit senden. Die zentrale Einheit soll einen zweiten autonomen Roboter mit diesen Daten auf dem berechneten kürzesten Weg durch das Labyrinth lotsen können. Dazu muss eine Kommunikation zwischen dem Roboter und der zentralen Einheit hergestellt werden.
Die oben erwähnte zentrale Einheit wird im weiteren Dokument als „Board“ bezeichnet und der autonome Roboter, aufgrund des gewählten Produkts „[[NIBObee]]“.
=== Details ===
[[File:ExampleMaze.png|thumb|120px|Beispiellabyrinth]]
Das Labyrinth wird eine Matrix mit vordefinierter Größe sein (z.B. 8x8) bei dem die möglichen Wege als schwarze Linie dargestellt sind. Auf dieser Linie wird sich der [[NIBObee]] bewegen. Die Aufgabe des ersten [[NIBObee]] besteht nun darin das gesamt Labyrinth abzufahren und eine Karte zu erstellen.

Diese gesammelte Information wird dann an das Board übertragen. Dort wird das Labyrinth auf einer grafischen Ausgabe dargestellt und der Benutzer kann einen beliebigen Zielpunkt für den zweiten [[NIBObee]] festlegen. Der optimale Weg wird berechnet und der zweite [[NIBObee]] über diesen Weg an das definierte Ziel geleitet.


 

=== Aufgabenteilung ===
An dem Projekt sind zwei Gruppen beteiligt, eine die sich um die Roboter kümmert (Gruppe NIBObee), eine zweite die die Implementierung der zentralen Einheit (Gruppe Board) vornimmt. Gemeinsam muss die Übertragungstechnik (Hardware und Protokoll) erarbeitet werden. Die Implementierung kann dann getrennt erfolgen und am Ende des Projekts ist eine gemeinsame Testphase notwendig.

Da noch einige Festlegungen bezüglich der verwendeten Hardware und der Übertragungstechnik ausständig sind können sich im Zuge des weiteren Projektfortschritts durchaus noch Änderungen ergeben. Für alle kritischen Elemente wird so früh wie möglich auch eine alternative Lösung als Fallback vorgesehen. Das ist notwendig für den Fall, dass sich für ein Problem keine, zumindest im Rahmen dieses Semesters, realisierbare Implementierung ergibt.

==== Team Board ====
Teammitglieder dieser Gruppe sind:
* Michaela Escuyer
* Thomas Neuber
* Robert Pavljuk
==== Team NIBObee ====
Teammitglieder dieser Gruppe sind:
* Robert Peterfi
* Alois Pochmann
* Reinhard Weismann

== Realisierung ==

=== Plattformen / Hardware ===
Die Plattformen der Roboter und der Kontrolleinheit sind im Folgenden aufgelistet und stehen (wenn auch teilweise nur als Bausatz) fertig zur Verfügung. Die Hardware der Kommunikationseinrichtung wird im Zuge dieses Projekts erstellt.

==== Roboter ====
Der eingesetzte Roboter ist eine [[NIBObee]] von [http://www.nicai-systems.com/de/nibobee.html Nicai-Systems]. Dieser Roboter verfügt über einen Liniensensor der es prinzipiell ermöglicht einer kontrastreichen Linie, vorzugsweise schwarze Linie auf weißem Boden, zu folgen.

Weitere Dateils können der [[NIBObee]]-Seite entnommen werden.

==== Kontrolleinheit ====
Die Zentrale Kontrolleinheit wird auf dem vom 3. Semester bekannten [[LPC2478]] realisiert.

==== Kommunikation ====
Die Kommunikation der [[NIBObee]]-Roboter mit der zentralen Steuerung erfolgt über Bluetooth. Dazu wird über den auf beiden Plattformen bestehenden UART Anschluss ein Modul mit RS232-BT Umsetzung verwendet.
Die im Folgenden aufgelisteten Module kommen für die Umsetzung in Frage:
* BTM-112
* [[BTM-222]]
Die Entscheidung ist zugunsten des [[BTM-222]] gefallen. Details dazu können der [[BTM-222]]-Seite entnommen werden.

=== Software ===
Details zur Software sind auf den Seiten von [[NIBObee#Software|NIBObee]] und [[LPC2478#Software|LPC2478]] zu finden.

=== Protokolle ===
==== Bluetooth ====
Der gesamte Bluetooth Stack ist im [[BTM-222]] realsiert und muss daher im Projekt nicht betrachtet werden.
==== [[MaDeCo]] ====
Das projektspezifische Protokol zur Übertragung der Labyrinthdaten nach / bei der Erkundung und dann zu Steuerung durch das Labyrinth ('''Ma'''ze '''De'''tection and '''Co'''ntrol) ist zu definieren.

=== Testumgebung ===
==== Labyrinth ====
Wie schon in der Angabe zu sehen ist gelten für das Labyrinth einige Annahmen die als Voraussetzungen für die Implementierung festgelegt werden:
* Es gibt nur gerade Linien
* Alle Kreuzungen sind rechtwinkelig
* Alle Abstände sind genau ein Vielfaches der kürzesten Verbindung der Mittelpunkte zweier Felder
* Alle (nicht sichtbaren) Felder sind gleich groß
* Das gesamte Labyrinth entspricht einer Baumstruktur, d.h. es gibt niemals zwei paralelle Wege von einem Punkt zu einem Anderen, also keine geschlossenen Schleifen.
* Da die Steuerung ausschließlich über die Liniensensoren implementiert wird ist die Strecke kollisionsfrei zu halten, d.h. der [[NIBObee]] wird nicht auf Kontakt mit den Fühlern durch Ausweichmanöver reagieren.

==== Simulationen ====
Damit ein unabhängiges Testen der einzelnen Teile des Projekts möglich ist werden in einigen Bereichen Simulationen eingesetzt:
* Bluetooth-Verbindung kann mit einem PC und Terminalprogramm getestet werden
* [[MaDeCo]]-Protokoll wird textbasiert entworfen um mit einfachen Textfiles auf beiden Seiten testen zu können

== Projektfortschritt ==
Der Projektfortschritt wird im gleichen Intervall verfolgt in dem die Lehrveranstaltung abgehalten wird

{| class="wikitable"
|-
!Woche
!Block
!Tätigkeiten / Erkenntnisse
|-

|14.02.2011 - 20.02.2011
|Gemeinsam
|
* Projektdefinition: Festlegen des Projektinhalts und grobe Abstimmung der einzelnen beteiligten Komponenten.
* Erstellung eines Dokuments zur Projektbeschreibung
* Erstellen eines Projektplans

|-

|'''21.02.2011'''
|colspan="2"|'''Projekt akzeptiert -> Projektstart'''
|-

|rowspan="3"|21.02.2011 - 27.02.2011
|Gemeinsam
|
* Bestellungen besprochen.
* Wiki eingerichtet.
* Bestelliste für Bluetooth Module erstellt
** Auflistung siehe [[BTM-222#Hardware|BTM-222 Stückliste]]
* Gesamte Hardware bestellt:
** 2 NIBObee - Programmierbarer Roboter-Bausatz
** 5 x [[BTM-222#Hardware|BTM-222 Stückliste]] (3 x für das Nibobee und 2 x für das board) erstellt.

|-
|Board
|
* Display Erfahrungsberichte recherchiert.
* Grafik Konzept (Blöcke) besprochen
* Beispiel Implementierungen für Touchscreen und Grafik von [[LPC2478|LPC 2478]] gesucht

|-
|NIBObee
|
* Bestellungen besprochen.
* nach Bauanleitungen und Datenblätter recherchiert.
* Printlayout des BT-Modul für NIBObee erstellt
* Recherche der BTM-222 Konfigurationsmöglichkeiten.
* Sammeln offener Punkte, auflisten von Risiken und möglicher Massnahmen

|-

|rowspan="3"|28.02.2011 - 06.03.2011
|Gemeinsam
|
* Definition des proprietären Kommunikationsprotokolls [[MaDeCo| MaDeCo ('''Ma'''ze '''De'''tection and '''Co'''ntrol)]]

|-
|Board
|
* Weitere Analyse für Touchscreen und Grafikausgabe
* Demo Implementierung von Hr. Kramer angefordert und eingelesen
* Sourcen Demo Projekt in Eclipse Ganymed geladen und Debug Optionen ergänzt
* Debuggingversuche, Ursachensuche für fehlende Anzeige

|-
|NIBObee
|
* Bestellung eingetroffen. Zusammenbau der Roboter durchgeführt
* Detailabsprache der benötigten Roboterfunktionen
* Analyse der Probleme beim Befahren des Labyrinths und Abbildung auf notwendige Funktionen.

|-

|rowspan="3"|7.3.2011-13.3.2011
|Gemeinsam
|
* Recherche Ergebnisse besprochen
* Bauteile für Bluetooth Modul sind teilweise nicht optimal (vor allem wegen der Größe). Es werden noch Alternativen gesucht und das Layout und der Bestückungspan wurden geändert.

|-
|Board
|
* Mehrstündiger Versuch, das Display mit Demo Applikationen zu testen
* daraus resultierende Tests haben ergeben dass das Display defekt war. Das Board wurde gegen ein neues getauscht
* neuerliche Inbetriebnahme mit Demo Applikationen

|-
|NIBObee
|
* Installation der Entwicklungsumbegung
* Testen der Beispielprogramme
* Kalibrierung der Liniensensoren
* Erstellen eines Testprogramms für die Liniensensoren um die optimale Linienbreite für das Labyrinth ermitteln zu können (2 cm scheint zu breit, Kontrastwert nicht über 128).

|-

|rowspan="3"|14.3.2011-20.3.2011
|Gemeinsam
|
* Besprechung der jeweiligen Ergebnisse
* neue Bestückungsliste besprechen und fehlende Teile organisieren

|-
|Board
|
* weitere Recherche nach lauffähigen Demoapplikationen
* Für speziell dieses Board frustrierend wenige bis keine Ergebnisse

|-
|NIBObee
|
* Versuche mit zwei unterschiedlichen Ansätzen des Geradeauslaufs des NIBObee:
** Korrektur mittles Regelkreis unter Berücksichtigung der Odometriesensoren
** Korrektur nur mttels der Werte von den Liniensensoren
* Obwohl der Regelkreis eine gradeausfahrt auch ohne Linie schafft ist der Start problematisch und daher für unsere Zwecke ungeeignet

|-

|rowspan="3"|21.3.2011-27.3.2011
|Gemeinsam
|
* gegenseitiges Update
* fast alle Bauteile eingetroffen bzw. vorhanden, Ausnahme: Printplatte
** voraussichtlicher Liefertermin der Printplatte kommende Woche

|-
|Board
|
* vergebliche Versuche, den UART in Betrieb zu nehmen
* gemeinsam mit Hrn. Wenzl nochmals versucht, auch ergebnislos
* Entschluss, das Vorgehen zu ändern
* neues Projekt auf Basis Interrupt Template vom 3. Semester
* Anpassung auf unsere Umgebung

|-
|NIBObee
|
* Implementierung gestartet mit folgenden Funktionen:
* Systemtimer mit 100Hz Taktfrequenz
* Statemachine für folgende Module:
** Drive, zuständig für das fahren entlang der Linie des Labyrinths
** Sensor, zuständig für die Fühler. Entprellen und melden von Änderungen.
** Line, zuständig für das erkennen der Linie und melden von Abweichungen
* Scheduler, der alle Module die einen Event bearbeiten müssen aufruft.

|-

|rowspan="3"|28.3.2011-3.4.2011
|Gemeinsam
|
*Leiterplatten eingetroffen, Beginn des Aufbaus der Bluetooth Module

|-
|Board
|

|-
|NIBObee
|
*Implementieren der Linienverfolgung mit den Statemachines
*Neuer Modul für Distanzmessung. Wurde von der Implementierung der Odometrie-Bibliothek abgeleitet.
*Erfolgreiches Ausrichten des NIBObee im Zentrum eines Felds des Labyrinths
*Probleme beim Unterscheiden von Spurabweichung und Kreuzung. Kann mit den vorhandenen Sensoren nicht gelöst werden. Es wird eine Erweiterung des NIBObee geplant.
*Zusätzliche 6 LEDs für Debugzwecke über Erweiterungsports angeschlossen und Ansteuerung implementiert

|-

|rowspan="3"|4.4.2011-10.4.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Fertigstellen des ersten Bluetooth Moduls
*Verbindung von NIBObee mit PC hergestellt
*Neue Funktionen zur Kommunikation. Senden und Empfangen mittels Interrupts implementiert
*Start Implementierung der State Maschine für das MaDeCo Protokoll
*Debug Möglichkeit mittels BT-Verbindung zum PC implementiert
*PC Testapplikation für die Bluetooth Verbindung mit spezieller Unterstützung des MaDeCo Protokolls implementiert.
*Erzeugen von DoxyGen Dokumentation

|-

|rowspan="3"|11.4.2011-1.5.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Überarbeiten des Event-Machanismus
*Optimieren der Debug-Protokollierung über Bluetooth. Strings belegten zu viel Speicher. Das führte zu undefinierbarem Verhalten wegen Überschreiben von Stack und Daten.
*Erweitern der PC Applikation zum bedienen der NIBObee BT-Schnittstelle. Die optimierte Debug-Ausgabe kann auf Basis von speziellen Kommentaren der NIBObee-Source (debug.h) symbolisch aufbereitet werden.
*Erweiterung mit zusätliche Liniensensoren angefertigt
*Wegen zusätzlicher Liniensensoren neue Applikation zum Kalibrieren der Liniensensoren (jetzt 5 Sück) erstellt.
*Wegen zusätzlicher Liniensensoren ersetzen des original Moduls zum Einlesen der Analogwerte.
*Wegen zusätzlicher Liniensensoren ersetzen des original Moduls zum ermitteln der Werte der Liniensensoren.
*Kreuzungserkennung und Linienverfolgung funktionieren nun parallel, NIBObee fährt kleines Testlabyrinth gezielt ab.
*Waagrechte Ausrichtung des NIBObee korrigiert da der Abstand der Liniensensoren zum Boden von essentieller Bedeutung ist.
*Doxygen Kommentare in Code eingefügt
*Doxygen in Entwicklungsumgebung eingebunden

|-

|rowspan="3"|2.5.2011-8.5.2011
|Gemeinsam
|

|-
|Board
|
* verschiedene UART sourcecodes aus fremden Demoapplikationen versucht auf das board zu portieren

|-
|NIBObee
|
*Tests mit neuen, zusätzlichen Liniensensoren.
*Probleme mit Hardwareausfällen der neuen Erweiterung. Die Phototransistoren reagieren nicht so gut wie erwartet. Ausserdem scheinen sie sehr leicht bei den Lötarbeiten defekt zu werden. Austausch notwendig
*Weitere Optimierungender Debugausgaben notwendig. Zusätzliche Funktionen in Testapplikation implementiert um nicht nur die Testpunkte, sondern auch die unterschiedlichen dezimalen Werte in symbolische Ausgaben umrechnen zu können.
*Fehlerhafte Linienendeerkennung, optimieren des Algorithmus.

|-

|rowspan="3"|9.5.2011-15.5.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Fertigstellen der MaDeCo State Machine für die unterschiedlichen Betriebsmodi und der Kommunikation mit dem drive Modul
*Implementieren der unterschiedlichen Betriebsmodi im drive Modul
*Test des Calibrate Modus zeigt Probleme beim Geradeauslauf nach Linienende, Kalibrierungsvorlage muss überarbeitet werden.

|-

|rowspan="3"|16.5.2011-22.5.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Zusätzliche MaDeCo Funktionen für den Testbetrieb
*Erweiterung des MaDeCo Protokolls für einfachere Implementierung
*Überarbeiten der Inlinedokumentation

|-

|rowspan="3"|23.5.2011-29.5.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Aktualisieren der Wiki Dokumentation
*Modus Calibration erfolgreich abgeschlossen, EEPROM wird mit korrekten Werten versorgt
*Linienverfolgung funktioniert nicht zufriedenstellend, Analyse aufwendig da beim Fehlersuchen sehr viele Daten der Liniensensoren anfallen, übertragen und ausgewertet müssen. Dabei stossen wir immer wieder an die Leistungsgrenzen des Systems.

|-

|rowspan="3"|30.5.2011-5.6.2011
|Gemeinsam
|

|-
|Board
|
* PLL Initialisierung kontrolliert, marginaler Fehler korrigiert
* UART Initialisierung kontrolliert, nichts gefunden. UART0 Senden OK, UART1 NOK
* UART1 Initialisierung auf P3.16 und P3.17 führt zum Erfolg
* Die nötigen UART Funktionen identifiziert und modular implementiert.
* UART Funktionen Interrupt getrieben implementiert
* bluetooth Modul aufgebaut

|-
|NIBObee
|
*Weiter massive Probleme bei der Linienverfolgung
*Nach Rotation entstehen üblicherweise Positionierungsfehler die sich danach aufschaukeln
*Follow und Drive Modul werden überarbeitet um "weichere" korrektur zu imlpementieren

|-

|rowspan="3"|6.6.2011-19.6.2011
|Gemeinsam
|
* Funktionstest für bluetooth Modul am board und interruptgetriebene UART Funktionen

|-
|Board
|
* Interrupt Handler erweitert: signalisiert wenn message komplett (CR) empfangen
* Handling für Sequenz- und Acknowledge-Nummern
* state machine für MaDeCo Protokoll
* Interface zu PC-Applikation

|-
|NIBObee
|
*Überarbeiten des Scheduling um Linienverfolgung mit mehr Priorität zu versehen
*Weitere Überarbeitung der Linienerkennung
*Verbesserung der Schnittstelle zum Board (ACK strikt nach Protokoll, keine unnötigen Ausgaben)
*Korrigieren des problematischen Verhaltens wegen der Meldungen des BTM-222 in der Initialisierungsphase

|-

|'''20.06.2011'''
|colspan="2"|'''Projekt präsentiert -> Projektende'''
|-

|}

[[Kategorie:FH]]

RoLoMa

2011-06-24T19:47:28Z

Alois: /* Projektfortschritt */

RoLoMa ist der, vielleicht wenig einfallsreiche, Name des ESE-Projekts im 4. Semester. Es ist die Abkürzung für "Robots Lost in Maze".
== Projektbeschreibung ==
=== Aufgabe ===
Bei diesem Projekt soll ein autonomer Roboter ein Labyrinth analysieren, alle vorhandenen Abzweigungen protokollieren und diese Daten an eine zentrale Einheit senden. Die zentrale Einheit soll einen zweiten autonomen Roboter mit diesen Daten auf dem berechneten kürzesten Weg durch das Labyrinth lotsen können. Dazu muss eine Kommunikation zwischen dem Roboter und der zentralen Einheit hergestellt werden.
Die oben erwähnte zentrale Einheit wird im weiteren Dokument als „Board“ bezeichnet und der autonome Roboter, aufgrund des gewählten Produkts „[[NIBObee]]“.
=== Details ===
[[File:ExampleMaze.png|thumb|120px|Beispiellabyrinth]]
Das Labyrinth wird eine Matrix mit vordefinierter Größe sein (z.B. 8x8) bei dem die möglichen Wege als schwarze Linie dargestellt sind. Auf dieser Linie wird sich der [[NIBObee]] bewegen. Die Aufgabe des ersten [[NIBObee]] besteht nun darin das gesamt Labyrinth abzufahren und eine Karte zu erstellen.

Diese gesammelte Information wird dann an das Board übertragen. Dort wird das Labyrinth auf einer grafischen Ausgabe dargestellt und der Benutzer kann einen beliebigen Zielpunkt für den zweiten [[NIBObee]] festlegen. Der optimale Weg wird berechnet und der zweite [[NIBObee]] über diesen Weg an das definierte Ziel geleitet.


 

=== Aufgabenteilung ===
An dem Projekt sind zwei Gruppen beteiligt, eine die sich um die Roboter kümmert (Gruppe NIBObee), eine zweite die die Implementierung der zentralen Einheit (Gruppe Board) vornimmt. Gemeinsam muss die Übertragungstechnik (Hardware und Protokoll) erarbeitet werden. Die Implementierung kann dann getrennt erfolgen und am Ende des Projekts ist eine gemeinsame Testphase notwendig.

Da noch einige Festlegungen bezüglich der verwendeten Hardware und der Übertragungstechnik ausständig sind können sich im Zuge des weiteren Projektfortschritts durchaus noch Änderungen ergeben. Für alle kritischen Elemente wird so früh wie möglich auch eine alternative Lösung als Fallback vorgesehen. Das ist notwendig für den Fall, dass sich für ein Problem keine, zumindest im Rahmen dieses Semesters, realisierbare Implementierung ergibt.

==== Team Board ====
Teammitglieder dieser Gruppe sind:
* Michaela Escuyer
* Thomas Neuber
* Robert Pavljuk
==== Team NIBObee ====
Teammitglieder dieser Gruppe sind:
* Robert Peterfi
* Alois Pochmann
* Reinhard Weismann

== Realisierung ==

=== Plattformen / Hardware ===
Die Plattformen der Roboter und der Kontrolleinheit sind im Folgenden aufgelistet und stehen (wenn auch teilweise nur als Bausatz) fertig zur Verfügung. Die Hardware der Kommunikationseinrichtung wird im Zuge dieses Projekts erstellt.

==== Roboter ====
Der eingesetzte Roboter ist eine [[NIBObee]] von [http://www.nicai-systems.com/de/nibobee.html Nicai-Systems]. Dieser Roboter verfügt über einen Liniensensor der es prinzipiell ermöglicht einer kontrastreichen Linie, vorzugsweise schwarze Linie auf weißem Boden, zu folgen.

Weitere Dateils können der [[NIBObee]]-Seite entnommen werden.

==== Kontrolleinheit ====
Die Zentrale Kontrolleinheit wird auf dem vom 3. Semester bekannten [[LPC2478]] realisiert.

==== Kommunikation ====
Die Kommunikation der [[NIBObee]]-Roboter mit der zentralen Steuerung erfolgt über Bluetooth. Dazu wird über den auf beiden Plattformen bestehenden UART Anschluss ein Modul mit RS232-BT Umsetzung verwendet.
Die im Folgenden aufgelisteten Module kommen für die Umsetzung in Frage:
* BTM-112
* [[BTM-222]]
Die Entscheidung ist zugunsten des [[BTM-222]] gefallen. Details dazu können der [[BTM-222]]-Seite entnommen werden.

=== Software ===
Details zur Software sind auf den Seiten von [[NIBObee#Software|NIBObee]] und [[LPC2478#Software|LPC2478]] zu finden.

=== Protokolle ===
==== Bluetooth ====
Der gesamte Bluetooth Stack ist im [[BTM-222]] realsiert und muss daher im Projekt nicht betrachtet werden.
==== [[MaDeCo]] ====
Das projektspezifische Protokol zur Übertragung der Labyrinthdaten nach / bei der Erkundung und dann zu Steuerung durch das Labyrinth ('''Ma'''ze '''De'''tection and '''Co'''ntrol) ist zu definieren.

=== Testumgebung ===
==== Labyrinth ====
Wie schon in der Angabe zu sehen ist gelten für das Labyrinth einige Annahmen die als Voraussetzungen für die Implementierung festgelegt werden:
* Es gibt nur gerade Linien
* Alle Kreuzungen sind rechtwinkelig
* Alle Abstände sind genau ein Vielfaches der kürzesten Verbindung der Mittelpunkte zweier Felder
* Alle (nicht sichtbaren) Felder sind gleich groß
* Das gesamte Labyrinth entspricht einer Baumstruktur, d.h. es gibt niemals zwei paralelle Wege von einem Punkt zu einem Anderen, also keine geschlossenen Schleifen.
* Da die Steuerung ausschließlich über die Liniensensoren implementiert wird ist die Strecke kollisionsfrei zu halten, d.h. der [[NIBObee]] wird nicht auf Kontakt mit den Fühlern durch Ausweichmanöver reagieren.

==== Simulationen ====
Damit ein unabhängiges Testen der einzelnen Teile des Projekts möglich ist werden in einigen Bereichen Simulationen eingesetzt:
* Bluetooth-Verbindung kann mit einem PC und Terminalprogramm getestet werden
* [[MaDeCo]]-Protokoll wird textbasiert entworfen um mit einfachen Textfiles auf beiden Seiten testen zu können

== Projektfortschritt ==
Der Projektfortschritt wird im gleichen Intervall verfolgt in dem die Lehrveranstaltung abgehalten wird

{| class="wikitable"
|-
!Woche
!Block
!Tätigkeiten / Erkenntnisse
|-

|14.02.2011 - 20.02.2011
|Gemeinsam
|
* Projektdefinition: Festlegen des Projektinhalts und grobe Abstimmung der einzelnen beteiligten Komponenten.
* Erstellung eines Dokuments zur Projektbeschreibung
* Erstellen eines Projektplans

|-

|'''21.02.2011'''
|colspan="2"|'''Projekt akzeptiert -> Projektstart'''
|-

|rowspan="3"|21.02.2011 - 27.02.2011
|Gemeinsam
|
* Bestellungen besprochen.
* Wiki eingerichtet.
* Bestelliste für Bluetooth Module erstellt
** Auflistung siehe [[BTM-222#Hardware|BTM-222 Stückliste]]
* Gesamte Hardware bestellt:
** 2 NIBObee - Programmierbarer Roboter-Bausatz
** 5 x [[BTM-222#Hardware|BTM-222 Stückliste]] (3 x für das Nibobee und 2 x für das board) erstellt.

|-
|Board
|
* Display Erfahrungsberichte recherchiert.
* Grafik Konzept (Blöcke) besprochen
* Beispiel Implementierungen für Touchscreen und Grafik von [[LPC2478|LPC 2478]] gesucht

|-
|NIBObee
|
* Bestellungen besprochen.
* nach Bauanleitungen und Datenblätter recherchiert.
* Printlayout des BT-Modul für NIBObee erstellt
* Recherche der BTM-222 Konfigurationsmöglichkeiten.
* Sammeln offener Punkte, auflisten von Risiken und möglicher Massnahmen

|-

|rowspan="3"|28.02.2011 - 06.03.2011
|Gemeinsam
|
* Definition des proprietären Kommunikationsprotokolls [[MaDeCo| MaDeCo ('''Ma'''ze '''De'''tection and '''Co'''ntrol)]]

|-
|Board
|
* Weitere Analyse für Touchscreen und Grafikausgabe
* Demo Implementierung von Hr. Kramer angefordert und eingelesen
* Sourcen Demo Projekt in Eclipse Ganymed geladen und Debug Optionen ergänzt
* Debuggingversuche, Ursachensuche für fehlende Anzeige

|-
|NIBObee
|
* Bestellung eingetroffen. Zusammenbau der Roboter durchgeführt
* Detailabsprache der benötigten Roboterfunktionen
* Analyse der Probleme beim Befahren des Labyrinths und Abbildung auf notwendige Funktionen.

|-

|rowspan="3"|7.3.2011-13.3.2011
|Gemeinsam
|
* Recherche Ergebnisse besprochen
* Bauteile für Bluetooth Modul sind teilweise nicht optimal (vor allem wegen der Größe). Es werden noch Alternativen gesucht und das Layout und der Bestückungspan wurden geändert.

|-
|Board
|
* Mehrstündiger Versuch, das Display mit Demo Applikationen zu testen
* daraus resultierende Tests haben ergeben dass das Display defekt war. Das Board wurde gegen ein neues getauscht
* neuerliche Inbetriebnahme mit Demo Applikationen

|-
|NIBObee
|
* Installation der Entwicklungsumbegung
* Testen der Beispielprogramme
* Kalibrierung der Liniensensoren
* Erstellen eines Testprogramms für die Liniensensoren um die optimale Linienbreite für das Labyrinth ermitteln zu können (2 cm scheint zu breit, Kontrastwert nicht über 128).

|-

|rowspan="3"|14.3.2011-20.3.2011
|Gemeinsam
|
* Besprechung der jeweiligen Ergebnisse
* neue Bestückungsliste besprechen und fehlende Teile organisieren

|-
|Board
|
* weitere Recherche nach lauffähigen Demoapplikationen
* Für speziell dieses Board frustrierend wenige bis keine Ergebnisse

|-
|NIBObee
|
* Versuche mit zwei unterschiedlichen Ansätzen des Geradeauslaufs des NIBObee:
** Korrektur mittles Regelkreis unter Berücksichtigung der Odometriesensoren
** Korrektur nur mttels der Werte von den Liniensensoren
* Obwohl der Regelkreis eine gradeausfahrt auch ohne Linie schafft ist der Start problematisch und daher für unsere Zwecke ungeeignet

|-

|rowspan="3"|21.3.2011-27.3.2011
|Gemeinsam
|
* gegenseitiges Update
* fast alle Bauteile eingetroffen bzw. vorhanden, Ausnahme: Printplatte
** voraussichtlicher Liefertermin der Printplatte kommende Woche

|-
|Board
|
* vergebliche Versuche, den UART in Betrieb zu nehmen
* gemeinsam mit Hrn. Wenzl nochmals versucht, auch ergebnislos
* Entschluss, das Vorgehen zu ändern
* neues Projekt auf Basis Interrupt Template vom 3. Semester
* Anpassung auf unsere Umgebung

|-
|NIBObee
|
* Implementierung gestartet mit folgenden Funktionen:
* Systemtimer mit 100Hz Taktfrequenz
* Statemachine für folgende Module:
** Drive, zuständig für das fahren entlang der Linie des Labyrinths
** Sensor, zuständig für die Fühler. Entprellen und melden von Änderungen.
** Line, zuständig für das erkennen der Linie und melden von Abweichungen
* Scheduler, der alle Module die einen Event bearbeiten müssen aufruft.

|-

|rowspan="3"|28.3.2011-3.4.2011
|Gemeinsam
|
*Leiterplatten eingetroffen, Beginn des Aufbaus der Bluetooth Module

|-
|Board
|

|-
|NIBObee
|
*Implementieren der Linienverfolgung mit den Statemachines
*Neuer Modul für Distanzmessung. Wurde von der Implementierung der Odometrie-Bibliothek abgeleitet.
*Erfolgreiches Ausrichten des NIBObee im Zentrum eines Felds des Labyrinths
*Probleme beim Unterscheiden von Spurabweichung und Kreuzung. Kann mit den vorhandenen Sensoren nicht gelöst werden. Es wird eine Erweiterung des NIBObee geplant.
*Zusätzliche 6 LEDs für Debugzwecke über Erweiterungsports angeschlossen und Ansteuerung implementiert

|-

|rowspan="3"|4.4.2011-10.4.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Fertigstellen des ersten Bluetooth Moduls
*Verbindung von NIBObee mit PC hergestellt
*Neue Funktionen zur Kommunikation. Senden und Empfangen mittels Interrupts implementiert
*Start Implementierung der State Maschine für das MaDeCo Protokoll
*Debug Möglichkeit mittels BT-Verbindung zum PC implementiert
*PC Testapplikation für die Bluetooth Verbindung mit spezieller Unterstützung des MaDeCo Protokolls implementiert.
*Erzeugen von DoxyGen Dokumentation

|-

|rowspan="3"|11.4.2011-1.5.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Überarbeiten des Event-Machanismus
*Optimieren der Debug-Protokollierung über Bluetooth. Strings belegten zu viel Speicher. Das führte zu undefinierbarem Verhalten wegen Überschreiben von Stack und Daten.
*Erweitern der PC Applikation zum bedienen der NIBObee BT-Schnittstelle. Die optimierte Debug-Ausgabe kann auf Basis von speziellen Kommentaren der NIBObee-Source (debug.h) symbolisch aufbereitet werden.
*Erweiterung mit zusätliche Liniensensoren angefertigt
*Wegen zusätzlicher Liniensensoren neue Applikation zum Kalibrieren der Liniensensoren (jetzt 5 Sück) erstellt.
*Wegen zusätzlicher Liniensensoren ersetzen des original Moduls zum Einlesen der Analogwerte.
*Wegen zusätzlicher Liniensensoren ersetzen des original Moduls zum ermitteln der Werte der Liniensensoren.
*Kreuzungserkennung und Linienverfolgung funktionieren nun parallel, NIBObee fährt kleines Testlabyrinth gezielt ab.
*Waagrechte Ausrichtung des NIBObee korrigiert da der Abstand der Liniensensoren zum Boden von essentieller Bedeutung ist.
*Doxygen Kommentare in Code eingefügt
*Doxygen in Entwicklungsumgebung eingebunden

|-

|rowspan="3"|2.5.2011-8.5.2011
|Gemeinsam
|

|-
|Board
|
* verschiedene UART sourcecodes aus fremden Demoapplikationen versucht auf das board zu portieren

|-
|NIBObee
|
*Tests mit neuen, zusätzlichen Liniensensoren.
*Probleme mit Hardwareausfällen der neuen Erweiterung. Die Phototransistoren reagieren nicht so gut wie erwartet. Ausserdem scheinen sie sehr leicht bei den Lötarbeiten defekt zu werden. Austausch notwendig
*Weitere Optimierungender Debugausgaben notwendig. Zusätzliche Funktionen in Testapplikation implementiert um nicht nur die Testpunkte, sondern auch die unterschiedlichen dezimalen Werte in symbolische Ausgaben umrechnen zu können.
*Fehlerhafte Linienendeerkennung, optimieren des Algorithmus.

|-

|rowspan="3"|9.5.2011-15.5.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Fertigstellen der MaDeCo State Machine für die unterschiedlichen Betriebsmodi und der Kommunikation mit dem drive Modul
*Implementieren der unterschiedlichen Betriebsmodi im drive Modul
*Test des Calibrate Modus zeigt Probleme beim Geradeauslauf nach Linienende, Kalibrierungsvorlage muss überarbeitet werden.

|-

|rowspan="3"|16.5.2011-22.5.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Zusätzliche MaDeCo Funktionen für den Testbetrieb
*Erweiterung des MaDeCo Protokolls für einfachere Implementierung
*Überarbeiten der Inlinedokumentation

|-

|rowspan="3"|23.5.2011-29.5.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Aktualisieren der Wiki Dokumentation
*Modus Calibration erfolgreich abgeschlossen, EEPROM wird mit korrekten Werten versorgt

|-

|rowspan="3"|30.5.2011-5.6.2011
|Gemeinsam
|

|-
|Board
|
* PLL Initialisierung kontrolliert, marginaler Fehler korrigiert
* UART Initialisierung kontrolliert, nichts gefunden. UART0 Senden OK, UART1 NOK
* UART1 Initialisierung auf P3.16 und P3.17 führt zum Erfolg
* Die nötigen UART Funktionen identifiziert und modular implementiert.
* UART Funktionen Interrupt getrieben implementiert
* bluetooth Modul aufgebaut

|-
|NIBObee
|

|-

|rowspan="3"|6.6.2011-19.6.2011
|Gemeinsam
|
* Funktionstest für bluetooth Modul am board und interruptgetriebene UART Funktionen

|-
|Board
|
* Interrupt Handler erweitert: signalisiert wenn message komplett (CR) empfangen
* Handling für Sequenz- und Acknowledge-Nummern
* state machine für MaDeCo Protokoll
* Interface zu PC-Applikation

|-
|NIBObee
|
*Überarbeiten des Scheduling um Linienverfolgung mit mehr Priorität zu versehen
*Weitere Überarbeitung der Linienerkennung
*Verbesserung der Schnittstelle zum Board (ACK strikt nach Protokoll, keine unnötigen Ausgaben)
*Korrigieren des problematischen Verhaltens wegen der Meldungen des BTM-222 in der Initialisierungsphase

|-

|'''20.06.2011'''
|colspan="2"|'''Projekt präsentiert -> Projektende'''
|-

|}

[[Kategorie:FH]]

RoLoMa

2011-06-24T19:30:36Z

Alois: /* Projektfortschritt */

RoLoMa ist der, vielleicht wenig einfallsreiche, Name des ESE-Projekts im 4. Semester. Es ist die Abkürzung für "Robots Lost in Maze".
== Projektbeschreibung ==
=== Aufgabe ===
Bei diesem Projekt soll ein autonomer Roboter ein Labyrinth analysieren, alle vorhandenen Abzweigungen protokollieren und diese Daten an eine zentrale Einheit senden. Die zentrale Einheit soll einen zweiten autonomen Roboter mit diesen Daten auf dem berechneten kürzesten Weg durch das Labyrinth lotsen können. Dazu muss eine Kommunikation zwischen dem Roboter und der zentralen Einheit hergestellt werden.
Die oben erwähnte zentrale Einheit wird im weiteren Dokument als „Board“ bezeichnet und der autonome Roboter, aufgrund des gewählten Produkts „[[NIBObee]]“.
=== Details ===
[[File:ExampleMaze.png|thumb|120px|Beispiellabyrinth]]
Das Labyrinth wird eine Matrix mit vordefinierter Größe sein (z.B. 8x8) bei dem die möglichen Wege als schwarze Linie dargestellt sind. Auf dieser Linie wird sich der [[NIBObee]] bewegen. Die Aufgabe des ersten [[NIBObee]] besteht nun darin das gesamt Labyrinth abzufahren und eine Karte zu erstellen.

Diese gesammelte Information wird dann an das Board übertragen. Dort wird das Labyrinth auf einer grafischen Ausgabe dargestellt und der Benutzer kann einen beliebigen Zielpunkt für den zweiten [[NIBObee]] festlegen. Der optimale Weg wird berechnet und der zweite [[NIBObee]] über diesen Weg an das definierte Ziel geleitet.


 

=== Aufgabenteilung ===
An dem Projekt sind zwei Gruppen beteiligt, eine die sich um die Roboter kümmert (Gruppe NIBObee), eine zweite die die Implementierung der zentralen Einheit (Gruppe Board) vornimmt. Gemeinsam muss die Übertragungstechnik (Hardware und Protokoll) erarbeitet werden. Die Implementierung kann dann getrennt erfolgen und am Ende des Projekts ist eine gemeinsame Testphase notwendig.

Da noch einige Festlegungen bezüglich der verwendeten Hardware und der Übertragungstechnik ausständig sind können sich im Zuge des weiteren Projektfortschritts durchaus noch Änderungen ergeben. Für alle kritischen Elemente wird so früh wie möglich auch eine alternative Lösung als Fallback vorgesehen. Das ist notwendig für den Fall, dass sich für ein Problem keine, zumindest im Rahmen dieses Semesters, realisierbare Implementierung ergibt.

==== Team Board ====
Teammitglieder dieser Gruppe sind:
* Michaela Escuyer
* Thomas Neuber
* Robert Pavljuk
==== Team NIBObee ====
Teammitglieder dieser Gruppe sind:
* Robert Peterfi
* Alois Pochmann
* Reinhard Weismann

== Realisierung ==

=== Plattformen / Hardware ===
Die Plattformen der Roboter und der Kontrolleinheit sind im Folgenden aufgelistet und stehen (wenn auch teilweise nur als Bausatz) fertig zur Verfügung. Die Hardware der Kommunikationseinrichtung wird im Zuge dieses Projekts erstellt.

==== Roboter ====
Der eingesetzte Roboter ist eine [[NIBObee]] von [http://www.nicai-systems.com/de/nibobee.html Nicai-Systems]. Dieser Roboter verfügt über einen Liniensensor der es prinzipiell ermöglicht einer kontrastreichen Linie, vorzugsweise schwarze Linie auf weißem Boden, zu folgen.

Weitere Dateils können der [[NIBObee]]-Seite entnommen werden.

==== Kontrolleinheit ====
Die Zentrale Kontrolleinheit wird auf dem vom 3. Semester bekannten [[LPC2478]] realisiert.

==== Kommunikation ====
Die Kommunikation der [[NIBObee]]-Roboter mit der zentralen Steuerung erfolgt über Bluetooth. Dazu wird über den auf beiden Plattformen bestehenden UART Anschluss ein Modul mit RS232-BT Umsetzung verwendet.
Die im Folgenden aufgelisteten Module kommen für die Umsetzung in Frage:
* BTM-112
* [[BTM-222]]
Die Entscheidung ist zugunsten des [[BTM-222]] gefallen. Details dazu können der [[BTM-222]]-Seite entnommen werden.

=== Software ===
Details zur Software sind auf den Seiten von [[NIBObee#Software|NIBObee]] und [[LPC2478#Software|LPC2478]] zu finden.

=== Protokolle ===
==== Bluetooth ====
Der gesamte Bluetooth Stack ist im [[BTM-222]] realsiert und muss daher im Projekt nicht betrachtet werden.
==== [[MaDeCo]] ====
Das projektspezifische Protokol zur Übertragung der Labyrinthdaten nach / bei der Erkundung und dann zu Steuerung durch das Labyrinth ('''Ma'''ze '''De'''tection and '''Co'''ntrol) ist zu definieren.

=== Testumgebung ===
==== Labyrinth ====
Wie schon in der Angabe zu sehen ist gelten für das Labyrinth einige Annahmen die als Voraussetzungen für die Implementierung festgelegt werden:
* Es gibt nur gerade Linien
* Alle Kreuzungen sind rechtwinkelig
* Alle Abstände sind genau ein Vielfaches der kürzesten Verbindung der Mittelpunkte zweier Felder
* Alle (nicht sichtbaren) Felder sind gleich groß
* Das gesamte Labyrinth entspricht einer Baumstruktur, d.h. es gibt niemals zwei paralelle Wege von einem Punkt zu einem Anderen, also keine geschlossenen Schleifen.
* Da die Steuerung ausschließlich über die Liniensensoren implementiert wird ist die Strecke kollisionsfrei zu halten, d.h. der [[NIBObee]] wird nicht auf Kontakt mit den Fühlern durch Ausweichmanöver reagieren.

==== Simulationen ====
Damit ein unabhängiges Testen der einzelnen Teile des Projekts möglich ist werden in einigen Bereichen Simulationen eingesetzt:
* Bluetooth-Verbindung kann mit einem PC und Terminalprogramm getestet werden
* [[MaDeCo]]-Protokoll wird textbasiert entworfen um mit einfachen Textfiles auf beiden Seiten testen zu können

== Projektfortschritt ==
Der Projektfortschritt wird im gleichen Intervall verfolgt in dem die Lehrveranstaltung abgehalten wird

{| class="wikitable"
|-
!Woche
!Block
!Tätigkeiten / Erkenntnisse
|-

|14.02.2011 - 20.02.2011
|Gemeinsam
|
* Projektdefinition: Festlegen des Projektinhalts und grobe Abstimmung der einzelnen beteiligten Komponenten.
* Erstellung eines Dokuments zur Projektbeschreibung
* Erstellen eines Projektplans

|-

|'''21.02.2011'''
|colspan="2"|'''Projekt akzeptiert -> Projektstart'''
|-

|rowspan="3"|21.02.2011 - 27.02.2011
|Gemeinsam
|
* Bestellungen besprochen.
* Wiki eingerichtet.
* Bestelliste für Bluetooth Module erstellt
** Auflistung siehe [[BTM-222#Hardware|BTM-222 Stückliste]]
* Gesamte Hardware bestellt:
** 2 NIBObee - Programmierbarer Roboter-Bausatz
** 5 x [[BTM-222#Hardware|BTM-222 Stückliste]] (3 x für das Nibobee und 2 x für das board) erstellt.

|-
|Board
|
* Display Erfahrungsberichte recherchiert.
* Grafik Konzept (Blöcke) besprochen
* Beispiel Implementierungen für Touchscreen und Grafik von [[LPC2478|LPC 2478]] gesucht

|-
|NIBObee
|
* Bestellungen besprochen.
* nach Bauanleitungen und Datenblätter recherchiert.
* Printlayout des BT-Modul für NIBObee erstellt
* Recherche der BTM-222 Konfigurationsmöglichkeiten.
* Sammeln offener Punkte, auflisten von Risiken und möglicher Massnahmen

|-

|rowspan="3"|28.02.2011 - 06.03.2011
|Gemeinsam
|
* Definition des proprietären Kommunikationsprotokolls [[MaDeCo| MaDeCo ('''Ma'''ze '''De'''tection and '''Co'''ntrol)]]

|-
|Board
|
* Weitere Analyse für Touchscreen und Grafikausgabe
* Demo Implementierung von Hr. Kramer angefordert und eingelesen
* Sourcen Demo Projekt in Eclipse Ganymed geladen und Debug Optionen ergänzt
* Debuggingversuche, Ursachensuche für fehlende Anzeige

|-
|NIBObee
|
* Bestellung eingetroffen. Zusammenbau der Roboter durchgeführt
* Detailabsprache der benötigten Roboterfunktionen
* Analyse der Probleme beim Befahren des Labyrinths und Abbildung auf notwendige Funktionen.

|-

|rowspan="3"|7.3.2011-13.3.2011
|Gemeinsam
|
* Recherche Ergebnisse besprochen
* Bauteile für Bluetooth Modul sind teilweise nicht optimal (vor allem wegen der Größe). Es werden noch Alternativen gesucht und das Layout und der Bestückungspan wurden geändert.

|-
|Board
|
* Mehrstündiger Versuch, das Display mit Demo Applikationen zu testen
* daraus resultierende Tests haben ergeben dass das Display defekt war. Das Board wurde gegen ein neues getauscht
* neuerliche Inbetriebnahme mit Demo Applikationen

|-
|NIBObee
|
* Installation der Entwicklungsumbegung
* Testen der Beispielprogramme
* Kalibrierung der Liniensensoren
* Erstellen eines Testprogramms für die Liniensensoren um die optimale Linienbreite für das Labyrinth ermitteln zu können (2 cm scheint zu breit, Kontrastwert nicht über 128).

|-

|rowspan="3"|14.3.2011-20.3.2011
|Gemeinsam
|
* Besprechung der jeweiligen Ergebnisse
* neue Bestückungsliste besprechen und fehlende Teile organisieren

|-
|Board
|
* weitere Recherche nach lauffähigen Demoapplikationen
* Für speziell dieses Board frustrierend wenige bis keine Ergebnisse

|-
|NIBObee
|
* Versuche mit zwei unterschiedlichen Ansätzen des Geradeauslaufs des NIBObee:
** Korrektur mittles Regelkreis unter Berücksichtigung der Odometriesensoren
** Korrektur nur mttels der Werte von den Liniensensoren
* Obwohl der Regelkreis eine gradeausfahrt auch ohne Linie schafft ist der Start problematisch und daher für unsere Zwecke ungeeignet

|-

|rowspan="3"|21.3.2011-27.3.2011
|Gemeinsam
|
* gegenseitiges Update
* fast alle Bauteile eingetroffen bzw. vorhanden, Ausnahme: Printplatte
** voraussichtlicher Liefertermin der Printplatte kommende Woche

|-
|Board
|
* vergebliche Versuche, den UART in Betrieb zu nehmen
* gemeinsam mit Hrn. Wenzl nochmals versucht, auch ergebnislos
* Entschluss, das Vorgehen zu ändern
* neues Projekt auf Basis Interrupt Template vom 3. Semester
* Anpassung auf unsere Umgebung

|-
|NIBObee
|
* Implementierung gestartet mit folgenden Funktionen:
* Systemtimer mit 100Hz Taktfrequenz
* Statemachine für folgende Module:
** Drive, zuständig für das fahren entlang der Linie des Labyrinths
** Sensor, zuständig für die Fühler. Entprellen und melden von Änderungen.
** Line, zuständig für das erkennen der Linie und melden von Abweichungen
* Scheduler, der alle Module die einen Event bearbeiten müssen aufruft.

|-

|rowspan="3"|28.3.2011-3.4.2011
|Gemeinsam
|
*Leiterplatten eingetroffen, Beginn des Aufbaus der Bluetooth Module

|-
|Board
|

|-
|NIBObee
|
*Implementieren der Linienverfolgung mit den Statemachines
*Neuer Modul für Distanzmessung. Wurde von der Implementierung der Odometrie-Bibliothek abgeleitet.
*Erfolgreiches Ausrichten des NIBObee im Zentrum eines Felds des Labyrinths
*Probleme beim Unterscheiden von Spurabweichung und Kreuzung. Kann mit den vorhandenen Sensoren nicht gelöst werden. Es wird eine Erweiterung des NIBObee geplant.

|-

|rowspan="3"|4.4.2011-10.4.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Fertigstellen des ersten Bluetooth Moduls
*Verbindung von NIBObee mit PC hergestellt
*Neue Funktionen zur Kommunikation. Senden und Empfangen mittels Interrupts implementiert
*Start Implementierung der State Maschine für das MaDeCo Protokoll
*Debug Möglichkeit mittels BT-Verbindung zum PC implementiert
*PC Testapplikation für die Bluetooth Verbindung mit spezieller Unterstützung des MaDeCo Protokolls implementiert.
*Erzeugen von DoxyGen Dokumentation

|-

|rowspan="3"|11.4.2011-1.5.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Überarbeiten des Event-Machanismus
*Optimieren der Debug-Protokollierung über Bluetooth. Strings belegten zu viel Speicher. Das führte zu undefinierbarem Verhalten wegen Überschreiben von Stack und Daten.
*Erweitern der PC Applikation zum bedienen der NIBObee BT-Schnittstelle. Die optimierte Debug-Ausgabe kann auf Basis von speziellen Kommentaren der NIBObee-Source (debug.h) symbolisch aufbereitet werden.
*Erweiterung mit zusätliche Liniensensoren angefertigt
*Wegen zusätzlicher Liniensensoren neue Applikation zum Kalibrieren der Liniensensoren (jetzt 5 Sück) erstellt.
*Wegen zusätzlicher Liniensensoren ersetzen des original Moduls zum Einlesen der Analogwerte.
*Wegen zusätzlicher Liniensensoren ersetzen des original Moduls zum ermitteln der Werte der Liniensensoren.
*Kreuzungserkennung und Linienverfolgung funktionieren nun parallel, NIBObee fährt kleines Testlabyrinth gezielt ab.
*Waagrechte Ausrichtung des NIBObee korrigiert da der Abstand der Liniensensoren zum Boden von essentieller Bedeutung ist.

|-

|rowspan="3"|2.5.2011-8.5.2011
|Gemeinsam
|

|-
|Board
|
* verschiedene UART sourcecodes aus fremden Demoapplikationen versucht auf das board zu portieren

|-
|NIBObee
|
*Tests mit neuen, zusätzlichen Liniensensoren.
*Probleme mit Hardwareausfällen der neuen Erweiterung. Die Phototransistoren reagieren nicht so gut wie erwartet. Ausserdem scheinen sie sehr leicht bei den Lötarbeiten defekt zu werden. Austausch notwendig
*Weitere Optimierungender Debugausgaben notwendig. Zusätzliche Funktionen in Testapplikation implementiert um nicht nur die Testpunkte, sondern auch die unterschiedlichen dezimalen Werte in symbolische Ausgaben umrechnen zu können.

|-

|rowspan="3"|9.5.2011-15.5.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Implementieren der MaDeCo State Machine und der Kommunikation mit dem drive Modul

|-

|rowspan="3"|16.5.2011-22.5.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Zusätzliche MaDeCo Funktionen für den Testbetrieb
*Erweiterung des MaDeCo Protokolls für einfachere Implementierung

|-

|rowspan="3"|23.5.2011-29.5.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Aktualisieren der Wiki Dokumentation

|-

|rowspan="3"|30.5.2011-5.6.2011
|Gemeinsam
|

|-
|Board
|
* PLL Initialisierung kontrolliert, marginaler Fehler korrigiert
* UART Initialisierung kontrolliert, nichts gefunden. UART0 Senden OK, UART1 NOK
* UART1 Initialisierung auf P3.16 und P3.17 führt zum Erfolg
* Die nötigen UART Funktionen identifiziert und modular implementiert.
* UART Funktionen Interrupt getrieben implementiert
* bluetooth Modul aufgebaut

|-
|NIBObee
|

|-

|rowspan="3"|6.6.2011-19.6.2011
|Gemeinsam
|
* Funktionstest für bluetooth Modul am board und interruptgetriebene UART Funktionen

|-
|Board
|
* Interrupt Handler erweitert: signalisiert wenn message komplett (CR) empfangen
* Handling für Sequenz- und Acknowledge-Nummern
* state machine für MaDeCo Protokoll
* Interface zu PC-Applikation

|-
|NIBObee
|

|-

|'''20.06.2011'''
|colspan="2"|'''Projekt präsentiert -> Projektende'''
|-

|}

[[Kategorie:FH]]

RoLoMa

2011-06-24T19:21:52Z

Alois: /* Projektfortschritt */

RoLoMa ist der, vielleicht wenig einfallsreiche, Name des ESE-Projekts im 4. Semester. Es ist die Abkürzung für "Robots Lost in Maze".
== Projektbeschreibung ==
=== Aufgabe ===
Bei diesem Projekt soll ein autonomer Roboter ein Labyrinth analysieren, alle vorhandenen Abzweigungen protokollieren und diese Daten an eine zentrale Einheit senden. Die zentrale Einheit soll einen zweiten autonomen Roboter mit diesen Daten auf dem berechneten kürzesten Weg durch das Labyrinth lotsen können. Dazu muss eine Kommunikation zwischen dem Roboter und der zentralen Einheit hergestellt werden.
Die oben erwähnte zentrale Einheit wird im weiteren Dokument als „Board“ bezeichnet und der autonome Roboter, aufgrund des gewählten Produkts „[[NIBObee]]“.
=== Details ===
[[File:ExampleMaze.png|thumb|120px|Beispiellabyrinth]]
Das Labyrinth wird eine Matrix mit vordefinierter Größe sein (z.B. 8x8) bei dem die möglichen Wege als schwarze Linie dargestellt sind. Auf dieser Linie wird sich der [[NIBObee]] bewegen. Die Aufgabe des ersten [[NIBObee]] besteht nun darin das gesamt Labyrinth abzufahren und eine Karte zu erstellen.

Diese gesammelte Information wird dann an das Board übertragen. Dort wird das Labyrinth auf einer grafischen Ausgabe dargestellt und der Benutzer kann einen beliebigen Zielpunkt für den zweiten [[NIBObee]] festlegen. Der optimale Weg wird berechnet und der zweite [[NIBObee]] über diesen Weg an das definierte Ziel geleitet.


 

=== Aufgabenteilung ===
An dem Projekt sind zwei Gruppen beteiligt, eine die sich um die Roboter kümmert (Gruppe NIBObee), eine zweite die die Implementierung der zentralen Einheit (Gruppe Board) vornimmt. Gemeinsam muss die Übertragungstechnik (Hardware und Protokoll) erarbeitet werden. Die Implementierung kann dann getrennt erfolgen und am Ende des Projekts ist eine gemeinsame Testphase notwendig.

Da noch einige Festlegungen bezüglich der verwendeten Hardware und der Übertragungstechnik ausständig sind können sich im Zuge des weiteren Projektfortschritts durchaus noch Änderungen ergeben. Für alle kritischen Elemente wird so früh wie möglich auch eine alternative Lösung als Fallback vorgesehen. Das ist notwendig für den Fall, dass sich für ein Problem keine, zumindest im Rahmen dieses Semesters, realisierbare Implementierung ergibt.

==== Team Board ====
Teammitglieder dieser Gruppe sind:
* Michaela Escuyer
* Thomas Neuber
* Robert Pavljuk
==== Team NIBObee ====
Teammitglieder dieser Gruppe sind:
* Robert Peterfi
* Alois Pochmann
* Reinhard Weismann

== Realisierung ==

=== Plattformen / Hardware ===
Die Plattformen der Roboter und der Kontrolleinheit sind im Folgenden aufgelistet und stehen (wenn auch teilweise nur als Bausatz) fertig zur Verfügung. Die Hardware der Kommunikationseinrichtung wird im Zuge dieses Projekts erstellt.

==== Roboter ====
Der eingesetzte Roboter ist eine [[NIBObee]] von [http://www.nicai-systems.com/de/nibobee.html Nicai-Systems]. Dieser Roboter verfügt über einen Liniensensor der es prinzipiell ermöglicht einer kontrastreichen Linie, vorzugsweise schwarze Linie auf weißem Boden, zu folgen.

Weitere Dateils können der [[NIBObee]]-Seite entnommen werden.

==== Kontrolleinheit ====
Die Zentrale Kontrolleinheit wird auf dem vom 3. Semester bekannten [[LPC2478]] realisiert.

==== Kommunikation ====
Die Kommunikation der [[NIBObee]]-Roboter mit der zentralen Steuerung erfolgt über Bluetooth. Dazu wird über den auf beiden Plattformen bestehenden UART Anschluss ein Modul mit RS232-BT Umsetzung verwendet.
Die im Folgenden aufgelisteten Module kommen für die Umsetzung in Frage:
* BTM-112
* [[BTM-222]]
Die Entscheidung ist zugunsten des [[BTM-222]] gefallen. Details dazu können der [[BTM-222]]-Seite entnommen werden.

=== Software ===
Details zur Software sind auf den Seiten von [[NIBObee#Software|NIBObee]] und [[LPC2478#Software|LPC2478]] zu finden.

=== Protokolle ===
==== Bluetooth ====
Der gesamte Bluetooth Stack ist im [[BTM-222]] realsiert und muss daher im Projekt nicht betrachtet werden.
==== [[MaDeCo]] ====
Das projektspezifische Protokol zur Übertragung der Labyrinthdaten nach / bei der Erkundung und dann zu Steuerung durch das Labyrinth ('''Ma'''ze '''De'''tection and '''Co'''ntrol) ist zu definieren.

=== Testumgebung ===
==== Labyrinth ====
Wie schon in der Angabe zu sehen ist gelten für das Labyrinth einige Annahmen die als Voraussetzungen für die Implementierung festgelegt werden:
* Es gibt nur gerade Linien
* Alle Kreuzungen sind rechtwinkelig
* Alle Abstände sind genau ein Vielfaches der kürzesten Verbindung der Mittelpunkte zweier Felder
* Alle (nicht sichtbaren) Felder sind gleich groß
* Das gesamte Labyrinth entspricht einer Baumstruktur, d.h. es gibt niemals zwei paralelle Wege von einem Punkt zu einem Anderen, also keine geschlossenen Schleifen.
* Da die Steuerung ausschließlich über die Liniensensoren implementiert wird ist die Strecke kollisionsfrei zu halten, d.h. der [[NIBObee]] wird nicht auf Kontakt mit den Fühlern durch Ausweichmanöver reagieren.

==== Simulationen ====
Damit ein unabhängiges Testen der einzelnen Teile des Projekts möglich ist werden in einigen Bereichen Simulationen eingesetzt:
* Bluetooth-Verbindung kann mit einem PC und Terminalprogramm getestet werden
* [[MaDeCo]]-Protokoll wird textbasiert entworfen um mit einfachen Textfiles auf beiden Seiten testen zu können

== Projektfortschritt ==
Der Projektfortschritt wird im gleichen Intervall verfolgt in dem die Lehrveranstaltung abgehalten wird

{| class="wikitable"
|-
!Woche
!Block
!Tätigkeiten / Erkenntnisse
|-

|14.02.2011 - 20.02.2011
|Gemeinsam
|
* Projektdefinition: Festlegen des Projektinhalts und grobe Abstimmung der einzelnen beteiligten Komponenten.
* Erstellung eines Dokuments zur Projektbeschreibung
* Erstellen eines Projektplans

|-

|'''21.02.2011'''
|colspan="2"|'''Projekt akzeptiert -> Projektstart'''
|-

|rowspan="3"|21.02.2011 - 27.02.2011
|Gemeinsam
|
* Bestellungen besprochen.
* Wiki eingerichtet.
* Bestelliste für Bluetooth Module erstellt
** Auflistung siehe [[BTM-222#Hardware|BTM-222 Stückliste]]
* Gesamte Hardware bestellt:
** 2 NIBObee - Programmierbarer Roboter-Bausatz
** 5 x [[BTM-222#Hardware|BTM-222 Stückliste]] (3 x für das Nibobee und 2 x für das board) erstellt.

|-
|Board
|
* Display Erfahrungsberichte recherchiert.
* Grafik Konzept (Blöcke) besprochen
* Beispiel Implementierungen für Touchscreen und Grafik von [[LPC2478|LPC 2478]] gesucht

|-
|NIBObee
|
* Bestellungen besprochen.
* nach Bauanleitungen und Datenblätter recherchiert.
* Printlayout des BT-Modul für NIBObee erstellt
* Recherche der BTM-222 Konfigurationsmöglichkeiten.
* Sammeln offener Punkte, auflisten von Risiken und möglicher Massnahmen

|-

|rowspan="3"|28.02.2011 - 06.03.2011
|Gemeinsam
|
* Definition des proprietären Kommunikationsprotokolls [[MaDeCo| MaDeCo ('''Ma'''ze '''De'''tection and '''Co'''ntrol)]]

|-
|Board
|
* Weitere Analyse für Touchscreen und Grafikausgabe
* Demo Implementierung von Hr. Kramer angefordert und eingelesen
* Sourcen Demo Projekt in Eclipse Ganymed geladen und Debug Optionen ergänzt
* Debuggingversuche, Ursachensuche für fehlende Anzeige

|-
|NIBObee
|
* Bestellung eingetroffen. Zusammenbau der Roboter durchgeführt
* Detailabsprache der benötigten Roboterfunktionen
* Analyse der Probleme beim Befahren des Labyrinths und Abbildung auf notwendige Funktionen.

|-

|rowspan="3"|7.3.2011-13.3.2011
|Gemeinsam
|
* Recherche Ergebnisse besprochen
* Bauteile für Bluetooth Modul sind teilweise nicht optimal (vor allem wegen der Größe). Es werden noch Alternativen gesucht und das Layout und der Bestückungspan wurden geändert.

|-
|Board
|
* Mehrstündiger Versuch, das Display mit Demo Applikationen zu testen
* daraus resultierende Tests haben ergeben dass das Display defekt war. Das Board wurde gegen ein neues getauscht
* neuerliche Inbetriebnahme mit Demo Applikationen

|-
|NIBObee
|
* Installation der Entwicklungsumbegung
* Testen der Beispielprogramme
* Kalibrierung der Liniensensoren
* Erstellen eines Testprogramms für die Liniensensoren um die optimale Linienbreite für das Labyrinth ermitteln zu können (2 cm scheint zu breit, Kontrastwert nicht über 128).

|-

|rowspan="3"|14.3.2011-20.3.2011
|Gemeinsam
|
* Besprechung der jeweiligen Ergebnisse
* neue Bestückungsliste besprechen und fehlende Teile organisieren

|-
|Board
|
* weitere Recherche nach lauffähigen Demoapplikationen
* Für speziell dieses Board frustrierend wenige bis keine Ergebnisse

|-
|NIBObee
|
* Versuche mit zwei unterschiedlichen Ansätzen des Geradeauslaufs des NIBObee:
** Korrektur mittles Regelkreis unter Berücksichtigung der Odometriesensoren
** Korrektur nur mttels der Werte von den Liniensensoren
* Obwohl der Regelkreis eine gradeausfahrt auch ohne Linie schafft ist der Start problematisch und daher für unsere Zwecke ungeeignet

|-

|rowspan="3"|21.3.2011-27.3.2011
|Gemeinsam
|
* gegenseitiges Update
* fast alle Bauteile eingetroffen bzw. vorhanden, Ausnahme: Printplatte
** voraussichtlicher Liefertermin der Printplatte kommende Woche

|-
|Board
|
* vergebliche Versuche, den UART in Betrieb zu nehmen
* gemeinsam mit Hrn. Wenzl nochmals versucht, auch ergebnislos
* Entschluss, das Vorgehen zu ändern
* neues Projekt auf Basis Interrupt Template vom 3. Semester
* Anpassung auf unsere Umgebung

|-
|NIBObee
|
* Implementierung gestartet mit folgenden Funktionen:
* Systemtimer mit 100Hz Taktfrequenz
* Statemachine für folgende Module:
** Drive, zuständig für das fahren entlang der Linie des Labyrinths
** Sensor, zuständig für die Fühler. Entprellen und melden von Änderungen.
** Line, zuständig für das erkennen der Linie und melden von Abweichungen
* Scheduler, der alle Module die einen Event bearbeiten müssen aufruft.

|-

|rowspan="3"|28.3.2011-3.4.2011
|Gemeinsam
|
*Leiterplatten eingetroffen, Beginn des Aufbaus der Bluetooth Module

|-
|Board
|

|-
|NIBObee
|
*Implementieren der Linienverfolgung mit den Statemachines
*Neuer Modul für Distanzmessung. Wurde von der Implementierung der Odometrie-Bibliothek abgeleitet.
*Erfolgreiches Ausrichten des NIBObee im Zentrum eines Felds des Labyrinths
*Probleme beim Unterscheiden von Spurabweichung und Kreuzung. Kann mit den vorhandenen Sensoren nicht gelöst werden. Es wird eine Erweiterung des NIBObee geplant.

|-

|rowspan="3"|4.4.2011-10.4.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Fertigstellen des ersten Bluetooth Moduls
*Verbindung von NIBObee mit PC hergestellt
*Neue Funktionen zur Kommunikation. Senden und Empfangen mittels Interrupts implementiert
*Start Implementierung der State Maschine für das MaDeCo Protokoll
*Debug Möglichkeit mittels BT-Verbindung zum PC implementiert
*PC Testapplikation für die Bluetooth Verbindung mit spezieller Unterstützung des MaDeCo Protokolls implementiert.
*Erzeugen von DoxyGen Dokumentation

|-

|rowspan="3"|11.4.2011-1.5.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Überarbeiten des Event-Machanismus
*Optimieren der Debug-Protokollierung über Bluetooth. Strings belegten zu viel Speicher. Das führte zu undefinierbarem Verhalten wegen Überschreiben von Stack und Daten.
*Erweitern der PC Applikation zum bedienen der NIBObee BT-Schnittstelle. Die optimierte Debug-Ausgabe kann auf Basis von speziellen Kommentaren der NIBObee-Source (debug.h) symbolisch aufbereitet werden.
*Erweiterung mit zusätliche Liniensensoren angefertigt
*Wegen zusätzlicher Liniensensoren neue Applikation zum Kalibrieren der Liniensensoren (jetzt 5 Sück) erstellt.
*Wegen zusätzlicher Liniensensoren ersetzen des original Moduls zum Einlesen der Analogwerte.
*Wegen zusätzlicher Liniensensoren ersetzen des original Moduls zum ermitteln der Werte der Liniensensoren.
*Kreuzungserkennung und Linienverfolgung funktionieren nun parallel, NIBObee fährt kleines Testlabyrinth gezielt ab.
*Waagrechte Ausrichtung des NIBObee korrigiert da der Abstand der Liniensensoren zum Boden von essentieller Bedeutung ist.

|-

|rowspan="3"|2.5.2011-8.5.2011
|Gemeinsam
|

|-
|Board
|
* verschiedene UART sourcecodes aus fremden Demoapplikationen versucht auf das board zu portieren

|-
|NIBObee
|
*Tests mit neuen, zusätzlichen Liniensensoren.
*Probleme mit Hardwareausfällen der neuen Erweiterung. Die Phototransistoren reagieren nicht so gut wie erwartet. Ausserdem scheinen sie sehr leicht bei den Lötarbeiten defekt zu werden. Austausch notwendig
*Weitere Optimierungender Debugausgaben notwendig. Zusätzliche Funktionen in Testapplikation implementiert um nicht nur die Testpunkte, sondern auch die unterschiedlichen dezimalen Werte in symbolische Ausgaben umrechnen zu können.

|-

|rowspan="3"|9.5.2011-15.5.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|

|-

|rowspan="3"|16.5.2011-22.5.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|

|-

|rowspan="3"|23.5.2011-29.5.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|

|-

|rowspan="3"|30.5.2011-5.6.2011
|Gemeinsam
|

|-
|Board
|
* PLL Initialisierung kontrolliert, marginaler Fehler korrigiert
* UART Initialisierung kontrolliert, nichts gefunden. UART0 Senden OK, UART1 NOK
* UART1 Initialisierung auf P3.16 und P3.17 führt zum Erfolg
* Die nötigen UART Funktionen identifiziert und modular implementiert.
* UART Funktionen Interrupt getrieben implementiert
* bluetooth Modul aufgebaut

|-
|NIBObee
|

|-

|rowspan="3"|6.6.2011-19.6.2011
|Gemeinsam
|
* Funktionstest für bluetooth Modul am board und interruptgetriebene UART Funktionen

|-
|Board
|
* Interrupt Handler erweitert: signalisiert wenn message komplett (CR) empfangen
* Handling für Sequenz- und Acknowledge-Nummern
* state machine für MaDeCo Protokoll
* Interface zu PC-Applikation

|-
|NIBObee
|

|-

|'''20.06.2011'''
|colspan="2"|'''Projekt präsentiert -> Projektende'''
|-

|}

[[Kategorie:FH]]

RoLoMa

2011-06-24T19:07:19Z

Alois: /* Projektfortschritt */

RoLoMa ist der, vielleicht wenig einfallsreiche, Name des ESE-Projekts im 4. Semester. Es ist die Abkürzung für "Robots Lost in Maze".
== Projektbeschreibung ==
=== Aufgabe ===
Bei diesem Projekt soll ein autonomer Roboter ein Labyrinth analysieren, alle vorhandenen Abzweigungen protokollieren und diese Daten an eine zentrale Einheit senden. Die zentrale Einheit soll einen zweiten autonomen Roboter mit diesen Daten auf dem berechneten kürzesten Weg durch das Labyrinth lotsen können. Dazu muss eine Kommunikation zwischen dem Roboter und der zentralen Einheit hergestellt werden.
Die oben erwähnte zentrale Einheit wird im weiteren Dokument als „Board“ bezeichnet und der autonome Roboter, aufgrund des gewählten Produkts „[[NIBObee]]“.
=== Details ===
[[File:ExampleMaze.png|thumb|120px|Beispiellabyrinth]]
Das Labyrinth wird eine Matrix mit vordefinierter Größe sein (z.B. 8x8) bei dem die möglichen Wege als schwarze Linie dargestellt sind. Auf dieser Linie wird sich der [[NIBObee]] bewegen. Die Aufgabe des ersten [[NIBObee]] besteht nun darin das gesamt Labyrinth abzufahren und eine Karte zu erstellen.

Diese gesammelte Information wird dann an das Board übertragen. Dort wird das Labyrinth auf einer grafischen Ausgabe dargestellt und der Benutzer kann einen beliebigen Zielpunkt für den zweiten [[NIBObee]] festlegen. Der optimale Weg wird berechnet und der zweite [[NIBObee]] über diesen Weg an das definierte Ziel geleitet.


 

=== Aufgabenteilung ===
An dem Projekt sind zwei Gruppen beteiligt, eine die sich um die Roboter kümmert (Gruppe NIBObee), eine zweite die die Implementierung der zentralen Einheit (Gruppe Board) vornimmt. Gemeinsam muss die Übertragungstechnik (Hardware und Protokoll) erarbeitet werden. Die Implementierung kann dann getrennt erfolgen und am Ende des Projekts ist eine gemeinsame Testphase notwendig.

Da noch einige Festlegungen bezüglich der verwendeten Hardware und der Übertragungstechnik ausständig sind können sich im Zuge des weiteren Projektfortschritts durchaus noch Änderungen ergeben. Für alle kritischen Elemente wird so früh wie möglich auch eine alternative Lösung als Fallback vorgesehen. Das ist notwendig für den Fall, dass sich für ein Problem keine, zumindest im Rahmen dieses Semesters, realisierbare Implementierung ergibt.

==== Team Board ====
Teammitglieder dieser Gruppe sind:
* Michaela Escuyer
* Thomas Neuber
* Robert Pavljuk
==== Team NIBObee ====
Teammitglieder dieser Gruppe sind:
* Robert Peterfi
* Alois Pochmann
* Reinhard Weismann

== Realisierung ==

=== Plattformen / Hardware ===
Die Plattformen der Roboter und der Kontrolleinheit sind im Folgenden aufgelistet und stehen (wenn auch teilweise nur als Bausatz) fertig zur Verfügung. Die Hardware der Kommunikationseinrichtung wird im Zuge dieses Projekts erstellt.

==== Roboter ====
Der eingesetzte Roboter ist eine [[NIBObee]] von [http://www.nicai-systems.com/de/nibobee.html Nicai-Systems]. Dieser Roboter verfügt über einen Liniensensor der es prinzipiell ermöglicht einer kontrastreichen Linie, vorzugsweise schwarze Linie auf weißem Boden, zu folgen.

Weitere Dateils können der [[NIBObee]]-Seite entnommen werden.

==== Kontrolleinheit ====
Die Zentrale Kontrolleinheit wird auf dem vom 3. Semester bekannten [[LPC2478]] realisiert.

==== Kommunikation ====
Die Kommunikation der [[NIBObee]]-Roboter mit der zentralen Steuerung erfolgt über Bluetooth. Dazu wird über den auf beiden Plattformen bestehenden UART Anschluss ein Modul mit RS232-BT Umsetzung verwendet.
Die im Folgenden aufgelisteten Module kommen für die Umsetzung in Frage:
* BTM-112
* [[BTM-222]]
Die Entscheidung ist zugunsten des [[BTM-222]] gefallen. Details dazu können der [[BTM-222]]-Seite entnommen werden.

=== Software ===
Details zur Software sind auf den Seiten von [[NIBObee#Software|NIBObee]] und [[LPC2478#Software|LPC2478]] zu finden.

=== Protokolle ===
==== Bluetooth ====
Der gesamte Bluetooth Stack ist im [[BTM-222]] realsiert und muss daher im Projekt nicht betrachtet werden.
==== [[MaDeCo]] ====
Das projektspezifische Protokol zur Übertragung der Labyrinthdaten nach / bei der Erkundung und dann zu Steuerung durch das Labyrinth ('''Ma'''ze '''De'''tection and '''Co'''ntrol) ist zu definieren.

=== Testumgebung ===
==== Labyrinth ====
Wie schon in der Angabe zu sehen ist gelten für das Labyrinth einige Annahmen die als Voraussetzungen für die Implementierung festgelegt werden:
* Es gibt nur gerade Linien
* Alle Kreuzungen sind rechtwinkelig
* Alle Abstände sind genau ein Vielfaches der kürzesten Verbindung der Mittelpunkte zweier Felder
* Alle (nicht sichtbaren) Felder sind gleich groß
* Das gesamte Labyrinth entspricht einer Baumstruktur, d.h. es gibt niemals zwei paralelle Wege von einem Punkt zu einem Anderen, also keine geschlossenen Schleifen.
* Da die Steuerung ausschließlich über die Liniensensoren implementiert wird ist die Strecke kollisionsfrei zu halten, d.h. der [[NIBObee]] wird nicht auf Kontakt mit den Fühlern durch Ausweichmanöver reagieren.

==== Simulationen ====
Damit ein unabhängiges Testen der einzelnen Teile des Projekts möglich ist werden in einigen Bereichen Simulationen eingesetzt:
* Bluetooth-Verbindung kann mit einem PC und Terminalprogramm getestet werden
* [[MaDeCo]]-Protokoll wird textbasiert entworfen um mit einfachen Textfiles auf beiden Seiten testen zu können

== Projektfortschritt ==
Der Projektfortschritt wird im gleichen Intervall verfolgt in dem die Lehrveranstaltung abgehalten wird

{| class="wikitable"
|-
!Woche
!Block
!Tätigkeiten / Erkenntnisse
|-

|14.02.2011 - 20.02.2011
|Gemeinsam
|
* Projektdefinition: Festlegen des Projektinhalts und grobe Abstimmung der einzelnen beteiligten Komponenten.
* Erstellung eines Dokuments zur Projektbeschreibung
* Erstellen eines Projektplans

|-

|'''21.02.2011'''
|colspan="2"|'''Projekt akzeptiert -> Projektstart'''
|-

|rowspan="3"|21.02.2011 - 27.02.2011
|Gemeinsam
|
* Bestellungen besprochen.
* Wiki eingerichtet.
* Bestelliste für Bluetooth Module erstellt
** Auflistung siehe [[BTM-222#Hardware|BTM-222 Stückliste]]
* Gesamte Hardware bestellt:
** 2 NIBObee - Programmierbarer Roboter-Bausatz
** 5 x [[BTM-222#Hardware|BTM-222 Stückliste]] (3 x für das Nibobee und 2 x für das board) erstellt.

|-
|Board
|
* Display Erfahrungsberichte recherchiert.
* Grafik Konzept (Blöcke) besprochen
* Beispiel Implementierungen für Touchscreen und Grafik von [[LPC2478|LPC 2478]] gesucht

|-
|NIBObee
|
* Bestellungen besprochen.
* nach Bauanleitungen und Datenblätter recherchiert.
* Printlayout des BT-Modul für NIBObee erstellt
* Recherche der BTM-222 Konfigurationsmöglichkeiten.
* Sammeln offener Punkte, auflisten von Risiken und möglicher Massnahmen

|-

|rowspan="3"|28.02.2011 - 06.03.2011
|Gemeinsam
|
* Definition des proprietären Kommunikationsprotokolls [[MaDeCo| MaDeCo ('''Ma'''ze '''De'''tection and '''Co'''ntrol)]]

|-
|Board
|
* Weitere Analyse für Touchscreen und Grafikausgabe
* Demo Implementierung von Hr. Kramer angefordert und eingelesen
* Sourcen Demo Projekt in Eclipse Ganymed geladen und Debug Optionen ergänzt
* Debuggingversuche, Ursachensuche für fehlende Anzeige

|-
|NIBObee
|
* Bestellung eingetroffen. Zusammenbau der Roboter durchgeführt
* Detailabsprache der benötigten Roboterfunktionen
* Analyse der Probleme beim Befahren des Labyrinths und Abbildung auf notwendige Funktionen.

|-

|rowspan="3"|7.3.2011-13.3.2011
|Gemeinsam
|
* Recherche Ergebnisse besprochen
* Bauteile für Bluetooth Modul sind teilweise nicht optimal (vor allem wegen der Größe). Es werden noch Alternativen gesucht und das Layout und der Bestückungspan wurden geändert.

|-
|Board
|
* Mehrstündiger Versuch, das Display mit Demo Applikationen zu testen
* daraus resultierende Tests haben ergeben dass das Display defekt war. Das Board wurde gegen ein neues getauscht
* neuerliche Inbetriebnahme mit Demo Applikationen

|-
|NIBObee
|
* Installation der Entwicklungsumbegung
* Testen der Beispielprogramme
* Kalibrierung der Liniensensoren
* Erstellen eines Testprogramms für die Liniensensoren um die optimale Linienbreite für das Labyrinth ermitteln zu können (2 cm scheint zu breit, Kontrastwert nicht über 128).

|-

|rowspan="3"|14.3.2011-20.3.2011
|Gemeinsam
|
* Besprechung der jeweiligen Ergebnisse
* neue Bestückungsliste besprechen und fehlende Teile organisieren

|-
|Board
|
* weitere Recherche nach lauffähigen Demoapplikationen
* Für speziell dieses Board frustrierend wenige bis keine Ergebnisse

|-
|NIBObee
|
* Versuche mit zwei unterschiedlichen Ansätzen des Geradeauslaufs des NIBObee:
** Korrektur mittles Regelkreis unter Berücksichtigung der Odometriesensoren
** Korrektur nur mttels der Werte von den Liniensensoren
* Obwohl der Regelkreis eine gradeausfahrt auch ohne Linie schafft ist der Start problematisch und daher für unsere Zwecke ungeeignet

|-

|rowspan="3"|21.3.2011-27.3.2011
|Gemeinsam
|
* gegenseitiges Update
* fast alle Bauteile eingetroffen bzw. vorhanden, Ausnahme: Printplatte
** voraussichtlicher Liefertermin der Printplatte kommende Woche

|-
|Board
|
* vergebliche Versuche, den UART in Betrieb zu nehmen
* gemeinsam mit Hrn. Wenzl nochmals versucht, auch ergebnislos
* Entschluss, das Vorgehen zu ändern
* neues Projekt auf Basis Interrupt Template vom 3. Semester
* Anpassung auf unsere Umgebung

|-
|NIBObee
|
* Implementierung gestartet mit folgenden Funktionen:
* Systemtimer mit 100Hz Taktfrequenz
* Statemachine für folgende Module:
** Drive, zuständig für das fahren entlang der Linie des Labyrinths
** Sensor, zuständig für die Fühler. Entprellen und melden von Änderungen.
** Line, zuständig für das erkennen der Linie und melden von Abweichungen
* Scheduler, der alle Module die einen Event bearbeiten müssen aufruft.

|-

|rowspan="3"|28.3.2011-3.4.2011
|Gemeinsam
|
*Leiterplatten eingetroffen, Beginn des Aufbaus der Bluetooth Module

|-
|Board
|

|-
|NIBObee
|
*Implementieren der Linienverfolgung mit den Statemachines
*Neuer Modul für Distanzmessung. Wurde von der Implementierung der Odometrie-Bibliothek abgeleitet.
*Erfolgreiches Ausrichten des NIBObee im Zentrum eines Felds des Labyrinths
*Probleme beim Unterscheiden von Spurabweichung und Kreuzung. Kann mit den vorhandenen Sensoren nicht gelöst werden. Es wird eine Erweiterung des NIBObee geplant.

|-

|rowspan="3"|4.4.2011-10.4.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Fertigstellen des ersten Bluetooth Moduls
*Verbindung von NIBObee mit PC hergestellt
*Neue Funktionen zur Kommunikation. Senden und Empfangen mittels Interrupts implementiert
*Start Implementierung der State Maschine für das MaDeCo Protokoll
*Debug Möglichkeit mittels BT-Verbindung zum PC implementiert
*PC Testapplikation für die Bluetooth Verbindung mit spezieller Unterstützung des MaDeCo Protokolls implementiert.
*Erzeugen von DoxyGen Dokumentation

|-

|rowspan="3"|11.4.2011-1.5.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Überarbeiten des Event-Machanismus
*Optimieren der Debug-Protokollierung über Bluetooth. Strings belegten zu viel Speicher. Das führte zu undefinierbarem Verhalten wegen Überschreiben von Stack und Daten.
*Erweitern der PC Applikation zum bedienen der NIBObee BT-Schnittstelle. Die optimierte Debug-Ausgabe kann auf Basis von speziellen Kommentaren der NIBObee-Source (debug.h) symbolisch aufbereitet werden.
*Erweiterung mit zusätliche Liniensensoren angefertigt
*Wegen zusätzlicher Liniensensoren neue Applikation zum Kalibrieren der Liniensensoren (jetzt 5 Sück) erstellt.
*Wegen zusätzlicher Liniensensoren ersetzen des original Moduls zum Einlesen der Analogwerte.
*Wegen zusätzlicher Liniensensoren ersetzen des original Moduls zum ermitteln der Werte der Liniensensoren.
*Kreuzungserkennung und Linienverfolgung funktionieren nun parallel, NIBObee fährt kleines Testlabyrinth gezielt ab.

|-

|rowspan="3"|2.5.2011-8.5.2011
|Gemeinsam
|

|-
|Board
|
* verschiedene UART sourcecodes aus fremden Demoapplikationen versucht auf das board zu portieren

|-
|NIBObee
|

|-

|rowspan="3"|9.5.2011-15.5.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|

|-

|rowspan="3"|16.5.2011-22.5.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|

|-

|rowspan="3"|23.5.2011-29.5.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|

|-

|rowspan="3"|30.5.2011-5.6.2011
|Gemeinsam
|

|-
|Board
|
* PLL Initialisierung kontrolliert, marginaler Fehler korrigiert
* UART Initialisierung kontrolliert, nichts gefunden. UART0 Senden OK, UART1 NOK
* UART1 Initialisierung auf P3.16 und P3.17 führt zum Erfolg
* Die nötigen UART Funktionen identifiziert und modular implementiert.
* UART Funktionen Interrupt getrieben implementiert
* bluetooth Modul aufgebaut

|-
|NIBObee
|

|-

|rowspan="3"|6.6.2011-19.6.2011
|Gemeinsam
|
* Funktionstest für bluetooth Modul am board und interruptgetriebene UART Funktionen

|-
|Board
|
* Interrupt Handler erweitert: signalisiert wenn message komplett (CR) empfangen
* Handling für Sequenz- und Acknowledge-Nummern
* state machine für MaDeCo Protokoll
* Interface zu PC-Applikation

|-
|NIBObee
|

|-

|'''20.06.2011'''
|colspan="2"|'''Projekt präsentiert -> Projektende'''
|-

|}

[[Kategorie:FH]]

MaDeCo

2011-06-19T16:56:23Z

Alois: /* Kürzester Weg */

= MaDeCo - Protokoll zur Kommunikation im [[RoLoMa]] Projekt =

MaDeCo ist ein sehr einfaches textbasiertes Protokoll für die Kommunikation zwischen den Beteiligten im [[RoLoMa]] Projekt, den [[NIBObee]] Einheiten und der Basisstation, dem [[LPC2478]].

== Rollen ==
Es gibt unter den Beteiligten zwei festgelegte Rollen, Sender und Empfänger. Der Sender überträgt Information, der Empfänger hingegen hat eine überwiegend passive Funktion, er quittiert Nachrichten und übermittelt einen Acknowledge Code.
Während der Kommunikation werden diese Rollen nicht gewechselt.

== Format ==
Eine Nachricht besteht aus genau zwei Datensätzen, ein Datensatz besteht jeweils aus einem 3 Zeichen breiten Header Teil, einem 2 Zeichen breiten Datenteil (je nach Kommando optional oder mandatory) und einem Zeilenende ("\n"), das als einzelnes Zeichen CR (0x0d) realisiert ist.<strike> Für kleinere Datenteile erfolgt ein Padding mit Leerzeichen.</strike>

Beide Teile der Nachricht werden unmittelbar hintereinander gesendet, also z.B. als ''SEQ13\nOPMSM\n''.<strike> In untenstehenden Beispielen werden die beiden Teile der Nachricht allerdings durch einen Zeilenumbruch getrennt, um die Nachricht lesbarer zu machen.</strike>

Eine Nachricht, wie sie ein Sender erstellt, besteht aus:
<Sequence>
<Command>

;<Sequence>
: besteht aus dem Header ''SEQ'', der Datenteil aus einer Nummer zwischen 1 und 99.
;<Command>
: besteht aus dem 3 Zeichen langen [[MaDeCo#Commands|Command-Code]], und einem entsprechenden Datenteil.

Eine Nachricht muss mit einer Antwort quittiert werden. Diese besteht aus:
<Acknowledge>
<Acknowledge Code>

;<Acknowledge>
: besteht aus dem Header ''ACK'' und der zu bestätigenden Sequence Number.
;<Acknowledge Code>
: besteht aus den Header ''ACC'' und dem [[MaDeCo#Acknowledge Codes|Code]].

Beispiel sind be den jeweiligen [[MaDeCo#Use Cases|Use Cases]] zu finden.

=== Commands ===
EOC ... end of communication, signalisiert das Ende einer Kommunikation
OPM ... Operation Mode (siehe [[MaDeCo#Betriebsmodus|Betriebsmodus]])
WAP ... Waypoint (siehe [[MaDeCo#Wegpunkte|Wegpunkte]])
DIR ... Angabe der Richtung im GO Betriebsmodus (siehe Kürzester Weg)

=== Acknowledge Codes ===
00 .. OK, Command acknowledged
01 .. unknown Command
02 .. invalid data
03 .. overflow (kann z.B. derzeit keine weiteren Richtungsanweisungen entgegennehmen)
11 .. unbekannter Betriebsmodus (e.g. OPMXX)
21 .. command refused, Labyrinth erkunden (OPMSM) vor [[NIBObee#Kalibrierung]] (OPMGA)

=== Betriebsmodus ===
GA ... Kalibrieren (siehe [[NIBObee#Kalibrierung]])
SM ... Labyrinth erkunden
GO ... kürzesten Weg nehmen (siehe Kürzester Weg)

=== Wegpunkte ===
Die Übertragung eines Wegpunkts erfolgt durch Angabe der Richtung (S,W,N,E), gefolgt von der Anzahl der Streckenteile.
Beispiel: WAPS4 der Wegpunkt befindet sich 4 Streckenteile südlich des zuletzt übertragenen Wegpunkts

== Ablauf ==
Im [[RoLoMa]] Projekt muss die Kommunikation aus Nachricht-Antwort Sequenzen bestehen. Wird eine gesendete Nachricht nicht bestätigt, erfolgt eine Neuübertragung nach dem RETRANSMISSION_TIMEOUT Interval.
Erfolgt auch nach RETRANSMISSION_COUNT Wiederholungen keine Antwort, wird die Übertragung abgebrochen und ein Fehler signalisiert.

Kommunikationen überschneiden sich nicht, das bedeutet, es findet zu jedem Zeitpunkt nur eine Kommunikation zwischen den Beteiligten statt. Daher ist auch zu jedem Zeitpunkt genau ein Teilnehmer der Sender, und ein Teilnehmer der Empfänger.

== Use Cases ==
Im folgenden werden Beispiele für die Kommunikation der unterschiedlichen Betriebsarten dargestellt. Daten vom Board werden normal, die von der NIBObee '''fett''' dargestellt.

=== Kalibrieren ===
Beim Kalibrieren wird das Kommando vom Board an die NIBObee geschickt und auch bei Erhalt sofort quittiert (sonst würde es zu einem Timeout kommen). Nachdem die Kalibrierung abgeschlossen ist wird die Verbindung getrennt.

''Beispiel:''
SEQ1
OPMGA

'''ACK1'''
'''ACC00'''

'''SEQ2'''
'''EOC'''

ACK2
ACC00

=== Labyrinth erkunden===
Das Kommando wird vom Board an die NIBObee geschickt und auch bei Erhalt sofort quittiert (es muss vorher allerdings eine Kalibrierung durchgeführt worden sein). Danach werden laufend die Punkte geschickt die abgefahren werden. Wenn das ganze Labyrinth erfasst wurde wir die Kommunikation wieder beendet.

''Beispiel:''
SEQ1
OPMSM

'''ACK1'''
'''ACC00'''

'''SEQ2'''
'''WAPN3'''

ACK2
ACC00

'''SEQ3'''
'''WAPE1'''

...

'''SEQ32'''
'''EOC'''

ACK32
ACC00

=== Kürzester Weg ===
Hier werden Richtungsanweisungen übertragen, die es der [[NIBObee]] ermöglichen, in einem Labyrinth den kürzesten Weg zu nehmen. Die Richtungen werden wieder mit Himmelsrichtungen beschrieben, diesmal allerdings ohne Längenangabe da immer bis zur nächsten Kreuzung gefahren wird.
In dem Beispiel wird der kürzeste Weg als S(üd)-W(est)-N(ord)-W(est) angegeben:
SEQ1
OPMGO

'''ACK1'''
'''ACC00'''

SEQ2
DIRS

'''ACK2'''
'''ACC00'''

SEQ3
DIRW

'''ACK3'''
'''ACC00'''

SEQ4
DIRN

'''ACK4'''
'''ACC00'''

SEQ5
DIRW

'''ACK5'''
'''ACC00'''

SEQ6
EOC

'''ACK6'''
'''ACC00'''

[[Kategorie:FH]]

MaDeCo

2011-05-26T08:13:06Z

Alois: /* Acknowledge Codes */

= MaDeCo - Protokoll zur Kommunikation im [[RoLoMa]] Projekt =

MaDeCo ist ein sehr einfaches textbasiertes Protokoll für die Kommunikation zwischen den Beteiligten im [[RoLoMa]] Projekt, den [[NIBObee]] Einheiten und der Basisstation, dem [[LPC2478]].

== Rollen ==
Es gibt unter den Beteiligten zwei festgelegte Rollen, Sender und Empfänger. Der Sender überträgt Information, der Empfänger hingegen hat eine überwiegend passive Funktion, er quittiert Nachrichten und übermittelt einen Acknowledge Code.
Während der Kommunikation werden diese Rollen nicht gewechselt.

== Format ==
Eine Nachricht besteht aus genau zwei Datensätzen, ein Datensatz besteht jeweils aus einem 3 Zeichen breiten Header Teil, einem 2 Zeichen breiten Datenteil (je nach Kommando optional oder mandatory) und einem Zeilenende ("\n").<strike> Für kleinere Datenteile erfolgt ein Padding mit Leerzeichen.</strike>

Beide Teile der Nachricht werden unmittelbar hintereinander gesendet, also z.B. als ''SEQ13\nOPMSM\n''.<strike> In untenstehenden Beispielen werden die beiden Teile der Nachricht allerdings durch einen Zeilenumbruch getrennt, um die Nachricht lesbarer zu machen.</strike>

Eine Nachricht, wie sie ein Sender erstellt, besteht aus:
<Sequence>
<Command>

;<Sequence>
: besteht aus dem Header ''SEQ'', der Datenteil aus einer Nummer zwischen 1 und 99.
;<Command>
: besteht aus dem 3 Zeichen langen [[MaDeCo#Commands|Command-Code]], und einem entsprechenden Datenteil.

Eine Nachricht muss mit einer Antwort quittiert werden. Diese besteht aus:
<Acknowledge>
<Acknowledge Code>

;<Acknowledge>
: besteht aus dem Header ''ACK'' und der zu bestätigenden Sequence Number.
;<Acknowledge Code>
: besteht aus den Header ''ACC'' und dem [[MaDeCo#Acknowledge Codes|Code]].

Beispiel sind be den jeweiligen [[MaDeCo#Use Cases|Use Cases]] zu finden.

=== Commands ===
EOC ... end of communication, signalisiert das Ende einer Kommunikation
OPM ... Operation Mode (siehe [[MaDeCo#Betriebsmodus|Betriebsmodus]])
WAP ... Waypoint (siehe [[MaDeCo#Wegpunkte|Wegpunkte]])
DIR ... Angabe der Richtung im GO Betriebsmodus (siehe Kürzester Weg)

=== Acknowledge Codes ===
00 .. OK, Command acknowledged
01 .. unknown Command
02 .. invalid data
03 .. overflow (kann z.B. derzeit keine weiteren Richtungsanweisungen entgegennehmen)
11 .. unbekannter Betriebsmodus (e.g. OPMXX)
21 .. command refused, Labyrinth erkunden (OPMSM) vor [[NIBObee#Kalibrierung]] (OPMGA)

=== Betriebsmodus ===
GA ... Kalibrieren (siehe [[NIBObee#Kalibrierung]])
SM ... Labyrinth erkunden
GO ... kürzesten Weg nehmen (siehe Kürzester Weg)

=== Wegpunkte ===
Die Übertragung eines Wegpunkts erfolgt durch Angabe der Richtung (S,W,N,E), gefolgt von der Anzahl der Streckenteile.
Beispiel: WAPS4 der Wegpunkt befindet sich 4 Streckenteile südlich des zuletzt übertragenen Wegpunkts

== Ablauf ==
Im [[RoLoMa]] Projekt muss die Kommunikation aus Nachricht-Antwort Sequenzen bestehen. Wird eine gesendete Nachricht nicht bestätigt, erfolgt eine Neuübertragung nach dem RETRANSMISSION_TIMEOUT Interval.
Erfolgt auch nach RETRANSMISSION_COUNT Wiederholungen keine Antwort, wird die Übertragung abgebrochen und ein Fehler signalisiert.

Kommunikationen überschneiden sich nicht, das bedeutet, es findet zu jedem Zeitpunkt nur eine Kommunikation zwischen den Beteiligten statt. Daher ist auch zu jedem Zeitpunkt genau ein Teilnehmer der Sender, und ein Teilnehmer der Empfänger.

== Use Cases ==
Im folgenden werden Beispiele für die Kommunikation der unterschiedlichen Betriebsarten dargestellt. Daten vom Board werden normal, die von der NIBObee '''fett''' dargestellt.

=== Kalibrieren ===
Beim Kalibrieren wird das Kommando vom Board an die NIBObee geschickt und auch bei Erhalt sofort quittiert (sonst würde es zu einem Timeout kommen). Nachdem die Kalibrierung abgeschlossen ist wird die Verbindung getrennt.

''Beispiel:''
SEQ1
OPMGA

'''ACK1'''
'''ACC00'''

'''SEQ2'''
'''EOC'''

ACK2
ACC00

=== Labyrinth erkunden===
Das Kommando wird vom Board an die NIBObee geschickt und auch bei Erhalt sofort quittiert (es muss vorher allerdings eine Kalibrierung durchgeführt worden sein). Danach werden laufend die Punkte geschickt die abgefahren werden. Wenn das ganze Labyrinth erfasst wurde wir die Kommunikation wieder beendet.

''Beispiel:''
SEQ1
OPMSM

'''ACK1'''
'''ACC00'''

'''SEQ2'''
'''WAPN3'''

ACK2
ACC00

'''SEQ3'''
'''WAPE1'''

...

'''SEQ32'''
'''EOC'''

ACK32
ACC00

=== Kürzester Weg ===
Hier werden Richtungsanweisungen übertragen, die es der [[NIBObee]] ermöglichen, in einem Labyrinth den kürzesten Weg zu nehmen. Die Richtungen werden wieder mit Himmelsrichtungen beschrieben, diesmal allerdings ohne Längenangabe da immer bis zur nächsten Kreuzung gefahren wird.
Beispiel (ohne ACKs), der kürzeste Weg wird als S(üd)-N(ord)-W(est)-S(üd) angegeben:
SEQ1
OPMGO

SEQ2
DIRS

SEQ3
DIRN

SEQ4
DIRW

SEQ5
DIRS

SEQ6
EOC

[[Kategorie:FH]]

MaDeCo

2011-05-26T07:13:20Z

Alois: /* Use Cases */

= MaDeCo - Protokoll zur Kommunikation im [[RoLoMa]] Projekt =

MaDeCo ist ein sehr einfaches textbasiertes Protokoll für die Kommunikation zwischen den Beteiligten im [[RoLoMa]] Projekt, den [[NIBObee]] Einheiten und der Basisstation, dem [[LPC2478]].

== Rollen ==
Es gibt unter den Beteiligten zwei festgelegte Rollen, Sender und Empfänger. Der Sender überträgt Information, der Empfänger hingegen hat eine überwiegend passive Funktion, er quittiert Nachrichten und übermittelt einen Acknowledge Code.
Während der Kommunikation werden diese Rollen nicht gewechselt.

== Format ==
Eine Nachricht besteht aus genau zwei Datensätzen, ein Datensatz besteht jeweils aus einem 3 Zeichen breiten Header Teil, einem 2 Zeichen breiten Datenteil (je nach Kommando optional oder mandatory) und einem Zeilenende ("\n").<strike> Für kleinere Datenteile erfolgt ein Padding mit Leerzeichen.</strike>

Beide Teile der Nachricht werden unmittelbar hintereinander gesendet, also z.B. als ''SEQ13\nOPMSM\n''.<strike> In untenstehenden Beispielen werden die beiden Teile der Nachricht allerdings durch einen Zeilenumbruch getrennt, um die Nachricht lesbarer zu machen.</strike>

Eine Nachricht, wie sie ein Sender erstellt, besteht aus:
<Sequence>
<Command>

;<Sequence>
: besteht aus dem Header ''SEQ'', der Datenteil aus einer Nummer zwischen 1 und 99.
;<Command>
: besteht aus dem 3 Zeichen langen [[MaDeCo#Commands|Command-Code]], und einem entsprechenden Datenteil.

Eine Nachricht muss mit einer Antwort quittiert werden. Diese besteht aus:
<Acknowledge>
<Acknowledge Code>

;<Acknowledge>
: besteht aus dem Header ''ACK'' und der zu bestätigenden Sequence Number.
;<Acknowledge Code>
: besteht aus den Header ''ACC'' und dem [[MaDeCo#Acknowledge Codes|Code]].

Beispiel sind be den jeweiligen [[MaDeCo#Use Cases|Use Cases]] zu finden.

=== Commands ===
EOC ... end of communication, signalisiert das Ende einer Kommunikation
OPM ... Operation Mode (siehe [[MaDeCo#Betriebsmodus|Betriebsmodus]])
WAP ... Waypoint (siehe [[MaDeCo#Wegpunkte|Wegpunkte]])
DIR ... Angabe der Richtung im GO Betriebsmodus (siehe Kürzester Weg)

=== Acknowledge Codes ===
00 .. OK, Command acknowledged
01 .. unknown Command
02 .. invalid data
11 .. unbekannter Betriebsmodus (e.g. OPMXX)
21 .. Command refused, Labyrinth erkunden (OPMSM) vor [[NIBObee#Kalibrierung]] (OPMGA)

=== Betriebsmodus ===
GA ... Kalibrieren (siehe [[NIBObee#Kalibrierung]])
SM ... Labyrinth erkunden
GO ... kürzesten Weg nehmen (siehe Kürzester Weg)

=== Wegpunkte ===
Die Übertragung eines Wegpunkts erfolgt durch Angabe der Richtung (S,W,N,E), gefolgt von der Anzahl der Streckenteile.
Beispiel: WAPS4 der Wegpunkt befindet sich 4 Streckenteile südlich des zuletzt übertragenen Wegpunkts

== Ablauf ==
Im [[RoLoMa]] Projekt muss die Kommunikation aus Nachricht-Antwort Sequenzen bestehen. Wird eine gesendete Nachricht nicht bestätigt, erfolgt eine Neuübertragung nach dem RETRANSMISSION_TIMEOUT Interval.
Erfolgt auch nach RETRANSMISSION_COUNT Wiederholungen keine Antwort, wird die Übertragung abgebrochen und ein Fehler signalisiert.

Kommunikationen überschneiden sich nicht, das bedeutet, es findet zu jedem Zeitpunkt nur eine Kommunikation zwischen den Beteiligten statt. Daher ist auch zu jedem Zeitpunkt genau ein Teilnehmer der Sender, und ein Teilnehmer der Empfänger.

== Use Cases ==
Im folgenden werden Beispiele für die Kommunikation der unterschiedlichen Betriebsarten dargestellt. Daten vom Board werden normal, die von der NIBObee '''fett''' dargestellt.

=== Kalibrieren ===
Beim Kalibrieren wird das Kommando vom Board an die NIBObee geschickt und auch bei Erhalt sofort quittiert (sonst würde es zu einem Timeout kommen). Nachdem die Kalibrierung abgeschlossen ist wird die Verbindung getrennt.

''Beispiel:''
SEQ1
OPMGA

'''ACK1'''
'''ACC00'''

'''SEQ2'''
'''EOC'''

ACK2
ACC00

=== Labyrinth erkunden===
Das Kommando wird vom Board an die NIBObee geschickt und auch bei Erhalt sofort quittiert (es muss vorher allerdings eine Kalibrierung durchgeführt worden sein). Danach werden laufend die Punkte geschickt die abgefahren werden. Wenn das ganze Labyrinth erfasst wurde wir die Kommunikation wieder beendet.

''Beispiel:''
SEQ1
OPMSM

'''ACK1'''
'''ACC00'''

'''SEQ2'''
'''WAPN3'''

ACK2
ACC00

'''SEQ3'''
'''WAPE1'''

...

'''SEQ32'''
'''EOC'''

ACK32
ACC00

=== Kürzester Weg ===
Hier werden Richtungsanweisungen übertragen, die es der [[NIBObee]] ermöglichen, in einem Labyrinth den kürzesten Weg zu nehmen. Die Richtungen werden wieder mit Himmelsrichtungen beschrieben, diesmal allerdings ohne Längenangabe da immer bis zur nächsten Kreuzung gefahren wird.
Beispiel (ohne ACKs), der kürzeste Weg wird als S(üd)-N(ord)-W(est)-S(üd) angegeben:
SEQ1
OPMGO

SEQ2
DIRS

SEQ3
DIRN

SEQ4
DIRW

SEQ5
DIRS

SEQ6
EOC

[[Kategorie:FH]]

MaDeCo

2011-05-26T06:51:12Z

Alois: /* Format */

= MaDeCo - Protokoll zur Kommunikation im [[RoLoMa]] Projekt =

MaDeCo ist ein sehr einfaches textbasiertes Protokoll für die Kommunikation zwischen den Beteiligten im [[RoLoMa]] Projekt, den [[NIBObee]] Einheiten und der Basisstation, dem [[LPC2478]].

== Rollen ==
Es gibt unter den Beteiligten zwei festgelegte Rollen, Sender und Empfänger. Der Sender überträgt Information, der Empfänger hingegen hat eine überwiegend passive Funktion, er quittiert Nachrichten und übermittelt einen Acknowledge Code.
Während der Kommunikation werden diese Rollen nicht gewechselt.

== Format ==
Eine Nachricht besteht aus genau zwei Datensätzen, ein Datensatz besteht jeweils aus einem 3 Zeichen breiten Header Teil, einem 2 Zeichen breiten Datenteil (je nach Kommando optional oder mandatory) und einem Zeilenende ("\n").<strike> Für kleinere Datenteile erfolgt ein Padding mit Leerzeichen.</strike>

Beide Teile der Nachricht werden unmittelbar hintereinander gesendet, also z.B. als ''SEQ13\nOPMSM\n''.<strike> In untenstehenden Beispielen werden die beiden Teile der Nachricht allerdings durch einen Zeilenumbruch getrennt, um die Nachricht lesbarer zu machen.</strike>

Eine Nachricht, wie sie ein Sender erstellt, besteht aus:
<Sequence>
<Command>

;<Sequence>
: besteht aus dem Header ''SEQ'', der Datenteil aus einer Nummer zwischen 1 und 99.
;<Command>
: besteht aus dem 3 Zeichen langen [[MaDeCo#Commands|Command-Code]], und einem entsprechenden Datenteil.

Eine Nachricht muss mit einer Antwort quittiert werden. Diese besteht aus:
<Acknowledge>
<Acknowledge Code>

;<Acknowledge>
: besteht aus dem Header ''ACK'' und der zu bestätigenden Sequence Number.
;<Acknowledge Code>
: besteht aus den Header ''ACC'' und dem [[MaDeCo#Acknowledge Codes|Code]].

Beispiel sind be den jeweiligen [[MaDeCo#Use Cases|Use Cases]] zu finden.

=== Commands ===
EOC ... end of communication, signalisiert das Ende einer Kommunikation
OPM ... Operation Mode (siehe [[MaDeCo#Betriebsmodus|Betriebsmodus]])
WAP ... Waypoint (siehe [[MaDeCo#Wegpunkte|Wegpunkte]])
DIR ... Angabe der Richtung im GO Betriebsmodus (siehe Kürzester Weg)

=== Acknowledge Codes ===
00 .. OK, Command acknowledged
01 .. unknown Command
02 .. invalid data
11 .. unbekannter Betriebsmodus (e.g. OPMXX)
21 .. Command refused, Labyrinth erkunden (OPMSM) vor [[NIBObee#Kalibrierung]] (OPMGA)

=== Betriebsmodus ===
GA ... Kalibrieren (siehe [[NIBObee#Kalibrierung]])
SM ... Labyrinth erkunden
GO ... kürzesten Weg nehmen (siehe Kürzester Weg)

=== Wegpunkte ===
Die Übertragung eines Wegpunkts erfolgt durch Angabe der Richtung (S,W,N,E), gefolgt von der Anzahl der Streckenteile.
Beispiel: WAPS4 der Wegpunkt befindet sich 4 Streckenteile südlich des zuletzt übertragenen Wegpunkts

== Ablauf ==
Im [[RoLoMa]] Projekt muss die Kommunikation aus Nachricht-Antwort Sequenzen bestehen. Wird eine gesendete Nachricht nicht bestätigt, erfolgt eine Neuübertragung nach dem RETRANSMISSION_TIMEOUT Interval.
Erfolgt auch nach RETRANSMISSION_COUNT Wiederholungen keine Antwort, wird die Übertragung abgebrochen und ein Fehler signalisiert.

Kommunikationen überschneiden sich nicht, das bedeutet, es findet zu jedem Zeitpunkt nur eine Kommunikation zwischen den Beteiligten statt. Daher ist auch zu jedem Zeitpunkt genau ein Teilnehmer der Sender, und ein Teilnehmer der Empfänger.

== Use Cases ==
Im folgenden werden Beispiele für die Kommunikation der unterschiedlichen Betriebsarten dargestellt. Daten vom Borad werden normal, die von der NIBObee '''fett''' dargestellt.

=== Kalibrieren ===
Beim Kalibrieren wird das Kommando vom Board an die NIBObee geschickt und auch bei Erhalt sofort quittiert (sonst würde es zu einem Timeout kommen). Nachdem die Kalibrierung abgeschlossen ist wird die Verbindung getrennt.

''Beispiel:''
SEQ1
OPMGA

'''ACK1'''
'''ACC00'''

'''SEQ2'''
'''EOC'''

ACK2
ACC00

=== Labyrinth erkunden===
Das Kommando wird vom Board an die NIBObee geschickt und auch bei Erhalt sofort quittiert (es muss vorher allerdings eine Kalibrierung durchgeführt worden sein). Danach werden laufend die Punkte geschickt die abgefahren werden. Wenn das ganze Labyrinth erfasst wurde wir die Kommunikation wieder beendet.

''Beispiel:''
SEQ1
OPMSM

'''ACK1'''
'''ACC00'''

'''SEQ2'''
'''WAPN3'''

ACK2
ACC00

'''SEQ3'''
'''WAPE1'''

...

'''SEQ32'''
'''EOC'''

ACK32
ACC00

=== Kürzester Weg ===
Hier werden Richtungsanweisungen übertragen, die es der [[NIBObee]] ermöglichen, in einem Labyrinth den kürzesten Weg zu nehmen.
Beispiel (ohne ACKs), der kürzeste Weg wird als S(üd)-N(ord)-W(est)-S(üd) angegeben:
SEQ1
OPMGO

SEQ2
DIRS

SEQ3
DIRN

SEQ4
DIRW

SEQ5
DIRS

SEQ6
EOC

[[Kategorie:FH]]

MaDeCo

2011-05-26T06:31:43Z

Alois: /* Labyrinth erkunden */

= MaDeCo - Protokoll zur Kommunikation im [[RoLoMa]] Projekt =

MaDeCo ist ein sehr einfaches textbasiertes Protokoll für die Kommunikation zwischen den Beteiligten im [[RoLoMa]] Projekt, den [[NIBObee]] Einheiten und der Basisstation, dem [[LPC2478]].

== Rollen ==
Es gibt unter den Beteiligten zwei festgelegte Rollen, Sender und Empfänger. Der Sender überträgt Information, der Empfänger hingegen hat eine überwiegend passive Funktion, er quittiert Nachrichten und übermittelt einen Acknowledge Code.
Während der Kommunikation werden diese Rollen nicht gewechselt.

== Format ==
Eine Nachricht besteht aus genau zwei Datensätzen, ein Datensatz besteht jeweils aus einem 3 Zeichen breiten Header Teil, und einem 2 Zeichen breiten Datenteil. Für kleinere Datenteile erfolgt ein Padding mit Leerzeichen.

Beide Teile der Nachricht werden unmittelbar hintereinander gesendet, also z.B. als ''SEQ13OPMSM''. In untenstehenden Beispielen werden die beiden Teile der Nachricht allerdings durch einen Zeilenumbruch getrennt, um die Nachricht lesbarer zu machen.

Eine Nachricht, wie sie ein Sender erstellt, besteht aus:
<Sequence>
<Command>

<Sequence> besteht aus dem Header SEQ, der Datenteil aus einer Nummer zwischen 1 und 99.
<Command> besteht aus dem 3 Zeichen langen Command-Code, und einem entsprechenden Datenteil.

Eine Nachricht muss mit einer Antwort quittiert werden. Diese besteht aus:
<Acknowledge>
<Acknowledge Code>

<Acknowledge> besteht aus dem Header ACK und der zu bestätigenden Sequence Number.
<Acknowledge Code> besteht aus den Header ACC und dem Code.

Beispiel sind be den jeweiligen [[MaDeCo#Use Cases|Use Cases]] zu finden.

=== Commands ===
EOC ... end of communication, signalisiert das Ende einer Kommunikation
OPM ... Operation Mode (siehe Betriebsmodus)
WAP ... Waypoint (siehe Wegpunkte)
DIR ... Angabe der Richtung im GO Betriebsmodus (siehe Kürzester Weg)

=== Acknowledge Codes ===
00 .. OK, Command acknowledged
01 .. unknown Command
02 .. invalid data
11 .. unbekannter Betriebsmodus (e.g. OPMXX)
21 .. Command refused, Labyrinth erkunden (OPMSM) vor [[NIBObee#Kalibrierung]] (OPMGA)

=== Betriebsmodus ===
GA ... Kalibrieren (siehe [[NIBObee#Kalibrierung]])
SM ... Labyrinth erkunden
GO ... kürzesten Weg nehmen (siehe Kürzester Weg)

=== Wegpunkte ===
Die Übertragung eines Wegpunkts erfolgt durch Angabe der Richtung (S,W,N,E), gefolgt von der Anzahl der Streckenteile.
Beispiel: WAPS4 der Wegpunkt befindet sich 4 Streckenteile südlich des zuletzt übertragenen Wegpunkts

== Ablauf ==
Im [[RoLoMa]] Projekt muss die Kommunikation aus Nachricht-Antwort Sequenzen bestehen. Wird eine gesendete Nachricht nicht bestätigt, erfolgt eine Neuübertragung nach dem RETRANSMISSION_TIMEOUT Interval.
Erfolgt auch nach RETRANSMISSION_COUNT Wiederholungen keine Antwort, wird die Übertragung abgebrochen und ein Fehler signalisiert.

Kommunikationen überschneiden sich nicht, das bedeutet, es findet zu jedem Zeitpunkt nur eine Kommunikation zwischen den Beteiligten statt. Daher ist auch zu jedem Zeitpunkt genau ein Teilnehmer der Sender, und ein Teilnehmer der Empfänger.

== Use Cases ==
Im folgenden werden Beispiele für die Kommunikation der unterschiedlichen Betriebsarten dargestellt. Daten vom Borad werden normal, die von der NIBObee '''fett''' dargestellt.

=== Kalibrieren ===
Beim Kalibrieren wird das Kommando vom Board an die NIBObee geschickt und auch bei Erhalt sofort quittiert (sonst würde es zu einem Timeout kommen). Nachdem die Kalibrierung abgeschlossen ist wird die Verbindung getrennt.

''Beispiel:''
SEQ1
OPMGA

'''ACK1'''
'''ACC00'''

'''SEQ2'''
'''EOC'''

ACK2
ACC00

=== Labyrinth erkunden===
Das Kommando wird vom Board an die NIBObee geschickt und auch bei Erhalt sofort quittiert (es muss vorher allerdings eine Kalibrierung durchgeführt worden sein). Danach werden laufend die Punkte geschickt die abgefahren werden. Wenn das ganze Labyrinth erfasst wurde wir die Kommunikation wieder beendet.

''Beispiel:''
SEQ1
OPMSM

'''ACK1'''
'''ACC00'''

'''SEQ2'''
'''WAPN3'''

ACK2
ACC00

'''SEQ3'''
'''WAPE1'''

...

'''SEQ32'''
'''EOC'''

ACK32
ACC00

=== Kürzester Weg ===
Hier werden Richtungsanweisungen übertragen, die es der [[NIBObee]] ermöglichen, in einem Labyrinth den kürzesten Weg zu nehmen.
Beispiel (ohne ACKs), der kürzeste Weg wird als S(üd)-N(ord)-W(est)-S(üd) angegeben:
SEQ1
OPMGO

SEQ2
DIRS

SEQ3
DIRN

SEQ4
DIRW

SEQ5
DIRS

SEQ6
EOC

[[Kategorie:FH]]

NIBObee

2011-05-16T14:00:11Z

Alois: /* Technische Daten */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
Hier wird nur ein kleiner Ausschnitt der technischen Daten dargestellt. Es handelt sich nur um jenen Teil der für die Bewertung oder Implementierung der gestellten Aufgaben relevant ist:

{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|RAM: 1 kB
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar.

Zwei Analoge Eingänge werden für die Fototransistoren der zusätzlichen Linienerkennung verwendet. Diese sind am NIBObee am Port X1 verfügbar.

Ein Ausgang dient zum ein- und ausschalten der zusätzlichen IR-LEDs. Dafür wird der PIN 1 des Port X4 verwendet.

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===

==== ATMega16 ====
Die Speichergröße scheint durchaus ausreichend zu sein. Nach implementierung aller wichtigen Grundfunktionen ist erst weniger als die Hälfte des Programmspeichers belegt.

Problematisch war anfangs nur der geringe RAM der auch alle konstanten Strings enthält. Dies ist zwar nicht notwendig, ist mit dieser Entwicklungsumgebung allerdings so gelöst. Besonders die umfangreichen Debug-Informationen die über Bluetooth an den PC gesendet werden führten dabei zu massiven Problemen. Durch kurze symbolische Debugausgaben, die dann am PC im eigens entwickelten Terminalprogramm auf sprechende symbolische Ausgabe konvertiert wird, konnte das Problem behoben werden.

==== Liniensensoren ====
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
Die original NIBObee Biliothek wird nicht verwendet. Sie wurde durch eine eigene Implementierung im [[NIBObee#Line-Modul|Line-Modul]] ersetzt. Der Grund ist die Notwendigkeit die zusätzlichen Liniensensoren in der gleichen weise wie die drei Originalsensoren zu behandeln.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen Gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

Nach einigen ersten Tests ist folgende weitere Aufgabe hinzugekommen:
* Herstellung der Hardware-Erweiterung mit zusätzlichen Liniensensoren

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusätzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt ausschließlich über Events. Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 2 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. lesen der Liniensensoren). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird nicht direkt vom Scheduler aufgerufen sondern über die Funktion <xx>_eventHandler. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; eine Funktion mit dem Namen <xx>_eventHandler (extern)
: Ist die Funktion die vom Scheduler aufgerufen wird damit die Statemaschine mit dem aktuellen Event, sofern vorhanden, durchlaufen wird.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.
; eine Funktion mit dem Namen <xx>_receiveEvent (intern)
: ReceiveEvent ist eigentlich eine interne Funktion (wird also nicht im Header File deklariert), der Pointer auf diese Funktion wird allerdings als Callback beim Subscribe übergeben damit der Event dem Modul zugestellt werden kann.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog-Modul ====
Digitalisieren der Analogeingänge
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Dies war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16 die Behandlung der Messung der Batteriespannung verbessert. Da hier die Referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.
Die einzelnen Werte werden weiterhin über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt nun 13 analoge Werte (statt bisher 11) die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von ca 117 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 111 µs (statt bisher 94 µs) aktualisiert wird.

==== Line-Modul ====
Ermitteln der Werte der Liniensensoren
Dateien: line.c
line.h
Dieser Modul ersetzt die originalen Bibliotheksfunktionen der Liniensensoren. Dies war notwendig da wir zusätzliche Liniensensoren verwenden.

Die Werte der Liniensensoren können nun mit der Funktion
<code>ln_get(index)</code>
gelesen werden. Die Werte selbst werden über den [[NIBObee#Analog-Modul|Analog-Modul]] ermittelt.

==== Bluetooth-Modul ====
Wickelt die Kommunikation über den Bluetooth Modul ab. Zur Kommunikation wird allerdings nur der USART als Terminal angesprochen, der Bluetooth Stack ist im [[BTM-222]] implementiert.
Dateien: bluetooth.c
bluetooth.h

==== Common-Modul ====
Stellt gemeinsame Funktionen zurVerfügung
Dateien: common.c
common.h

==== Distance-Modul ====
Behandelt die Odometrie Sensoren
Dateien: distance.c
distance.h

==== Drive-Modul ====
Bewegt den NIBObee
Dateien: drive.c
drive.h

==== Follow-Modul ====
Ist für die Linienverfolgung zuständig
Dateien: follow.c
follow.h

==== MaDeCo-Modul ====
Behandelt das MaDeCo Protokoll
Dateien: madeco.c
madeco.h

==== Main-Modul ====
Scheduler und zentraler Taktgeber
Dateien: main.c
main.h

==== Sensor-Modul ====
Ist für die "Fühler" zuständig
Dateien: follow.c
follow.h

=== Applikationen ===
==== Labyrinth erkunden ====

==== Kürzesten Weg durch Labyrinth ====

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-05-16T13:52:07Z

Alois: /* Aufgaben */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|...
|-
|...
|...
|...
|-
|...
|...
|...
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===

==== ATMega16 ====
Die Speichergröße scheint durchaus ausreichend zu sein. Nach implementierung aller wichtigen Grundfunktionen ist erst weniger als die Hälfte des Programmspeichers belegt.

Problematisch war anfangs nur der geringe RAM der auch alle konstanten Strings enthält. Dies ist zwar nicht notwendig, ist mit dieser Entwicklungsumgebung allerdings so gelöst. Besonders die umfangreichen Debug-Informationen die über Bluetooth an den PC gesendet werden führten dabei zu massiven Problemen. Durch kurze symbolische Debugausgaben, die dann am PC im eigens entwickelten Terminalprogramm auf sprechende symbolische Ausgabe konvertiert wird, konnte das Problem behoben werden.

==== Liniensensoren ====
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
Die original NIBObee Biliothek wird nicht verwendet. Sie wurde durch eine eigene Implementierung im [[NIBObee#Line-Modul|Line-Modul]] ersetzt. Der Grund ist die Notwendigkeit die zusätzlichen Liniensensoren in der gleichen weise wie die drei Originalsensoren zu behandeln.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen Gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

Nach einigen ersten Tests ist folgende weitere Aufgabe hinzugekommen:
* Herstellung der Hardware-Erweiterung mit zusätzlichen Liniensensoren

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusätzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt ausschließlich über Events. Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 2 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. lesen der Liniensensoren). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird nicht direkt vom Scheduler aufgerufen sondern über die Funktion <xx>_eventHandler. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; eine Funktion mit dem Namen <xx>_eventHandler (extern)
: Ist die Funktion die vom Scheduler aufgerufen wird damit die Statemaschine mit dem aktuellen Event, sofern vorhanden, durchlaufen wird.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.
; eine Funktion mit dem Namen <xx>_receiveEvent (intern)
: ReceiveEvent ist eigentlich eine interne Funktion (wird also nicht im Header File deklariert), der Pointer auf diese Funktion wird allerdings als Callback beim Subscribe übergeben damit der Event dem Modul zugestellt werden kann.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog-Modul ====
Digitalisieren der Analogeingänge
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Dies war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16 die Behandlung der Messung der Batteriespannung verbessert. Da hier die Referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.
Die einzelnen Werte werden weiterhin über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt nun 13 analoge Werte (statt bisher 11) die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von ca 117 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 111 µs (statt bisher 94 µs) aktualisiert wird.

==== Line-Modul ====
Ermitteln der Werte der Liniensensoren
Dateien: line.c
line.h
Dieser Modul ersetzt die originalen Bibliotheksfunktionen der Liniensensoren. Dies war notwendig da wir zusätzliche Liniensensoren verwenden.

Die Werte der Liniensensoren können nun mit der Funktion
<code>ln_get(index)</code>
gelesen werden. Die Werte selbst werden über den [[NIBObee#Analog-Modul|Analog-Modul]] ermittelt.

==== Bluetooth-Modul ====
Wickelt die Kommunikation über den Bluetooth Modul ab. Zur Kommunikation wird allerdings nur der USART als Terminal angesprochen, der Bluetooth Stack ist im [[BTM-222]] implementiert.
Dateien: bluetooth.c
bluetooth.h

==== Common-Modul ====
Stellt gemeinsame Funktionen zurVerfügung
Dateien: common.c
common.h

==== Distance-Modul ====
Behandelt die Odometrie Sensoren
Dateien: distance.c
distance.h

==== Drive-Modul ====
Bewegt den NIBObee
Dateien: drive.c
drive.h

==== Follow-Modul ====
Ist für die Linienverfolgung zuständig
Dateien: follow.c
follow.h

==== MaDeCo-Modul ====
Behandelt das MaDeCo Protokoll
Dateien: madeco.c
madeco.h

==== Main-Modul ====
Scheduler und zentraler Taktgeber
Dateien: main.c
main.h

==== Sensor-Modul ====
Ist für die "Fühler" zuständig
Dateien: follow.c
follow.h

=== Applikationen ===
==== Labyrinth erkunden ====

==== Kürzesten Weg durch Labyrinth ====

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-05-16T13:44:27Z

Alois: /* Besondere Erkenntnisse */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|...
|-
|...
|...
|...
|-
|...
|...
|...
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===

==== ATMega16 ====
Die Speichergröße scheint durchaus ausreichend zu sein. Nach implementierung aller wichtigen Grundfunktionen ist erst weniger als die Hälfte des Programmspeichers belegt.

Problematisch war anfangs nur der geringe RAM der auch alle konstanten Strings enthält. Dies ist zwar nicht notwendig, ist mit dieser Entwicklungsumgebung allerdings so gelöst. Besonders die umfangreichen Debug-Informationen die über Bluetooth an den PC gesendet werden führten dabei zu massiven Problemen. Durch kurze symbolische Debugausgaben, die dann am PC im eigens entwickelten Terminalprogramm auf sprechende symbolische Ausgabe konvertiert wird, konnte das Problem behoben werden.

==== Liniensensoren ====
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
Die original NIBObee Biliothek wird nicht verwendet. Sie wurde durch eine eigene Implementierung im [[NIBObee#Line-Modul|Line-Modul]] ersetzt. Der Grund ist die Notwendigkeit die zusätzlichen Liniensensoren in der gleichen weise wie die drei Originalsensoren zu behandeln.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen Gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusätzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt ausschließlich über Events. Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 2 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. lesen der Liniensensoren). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird nicht direkt vom Scheduler aufgerufen sondern über die Funktion <xx>_eventHandler. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; eine Funktion mit dem Namen <xx>_eventHandler (extern)
: Ist die Funktion die vom Scheduler aufgerufen wird damit die Statemaschine mit dem aktuellen Event, sofern vorhanden, durchlaufen wird.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.
; eine Funktion mit dem Namen <xx>_receiveEvent (intern)
: ReceiveEvent ist eigentlich eine interne Funktion (wird also nicht im Header File deklariert), der Pointer auf diese Funktion wird allerdings als Callback beim Subscribe übergeben damit der Event dem Modul zugestellt werden kann.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog-Modul ====
Digitalisieren der Analogeingänge
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Dies war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16 die Behandlung der Messung der Batteriespannung verbessert. Da hier die Referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.
Die einzelnen Werte werden weiterhin über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt nun 13 analoge Werte (statt bisher 11) die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von ca 117 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 111 µs (statt bisher 94 µs) aktualisiert wird.

==== Line-Modul ====
Ermitteln der Werte der Liniensensoren
Dateien: line.c
line.h
Dieser Modul ersetzt die originalen Bibliotheksfunktionen der Liniensensoren. Dies war notwendig da wir zusätzliche Liniensensoren verwenden.

Die Werte der Liniensensoren können nun mit der Funktion
<code>ln_get(index)</code>
gelesen werden. Die Werte selbst werden über den [[NIBObee#Analog-Modul|Analog-Modul]] ermittelt.

==== Bluetooth-Modul ====
Wickelt die Kommunikation über den Bluetooth Modul ab. Zur Kommunikation wird allerdings nur der USART als Terminal angesprochen, der Bluetooth Stack ist im [[BTM-222]] implementiert.
Dateien: bluetooth.c
bluetooth.h

==== Common-Modul ====
Stellt gemeinsame Funktionen zurVerfügung
Dateien: common.c
common.h

==== Distance-Modul ====
Behandelt die Odometrie Sensoren
Dateien: distance.c
distance.h

==== Drive-Modul ====
Bewegt den NIBObee
Dateien: drive.c
drive.h

==== Follow-Modul ====
Ist für die Linienverfolgung zuständig
Dateien: follow.c
follow.h

==== MaDeCo-Modul ====
Behandelt das MaDeCo Protokoll
Dateien: madeco.c
madeco.h

==== Main-Modul ====
Scheduler und zentraler Taktgeber
Dateien: main.c
main.h

==== Sensor-Modul ====
Ist für die "Fühler" zuständig
Dateien: follow.c
follow.h

=== Applikationen ===
==== Labyrinth erkunden ====

==== Kürzesten Weg durch Labyrinth ====

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-05-16T13:37:12Z

Alois: /* Liniensensoren */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|...
|-
|...
|...
|...
|-
|...
|...
|...
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
Die original NIBObee Biliothek wird nicht verwendet. Sie wurde durch eine eigene Implementierung im [[NIBObee#Line-Modul|Line-Modul]] ersetzt. Der Grund ist die Notwendigkeit die zusätzlichen Liniensensoren in der gleichen weise wie die drei Originalsensoren zu behandeln.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen Gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusätzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt ausschließlich über Events. Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 2 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. lesen der Liniensensoren). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird nicht direkt vom Scheduler aufgerufen sondern über die Funktion <xx>_eventHandler. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; eine Funktion mit dem Namen <xx>_eventHandler (extern)
: Ist die Funktion die vom Scheduler aufgerufen wird damit die Statemaschine mit dem aktuellen Event, sofern vorhanden, durchlaufen wird.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.
; eine Funktion mit dem Namen <xx>_receiveEvent (intern)
: ReceiveEvent ist eigentlich eine interne Funktion (wird also nicht im Header File deklariert), der Pointer auf diese Funktion wird allerdings als Callback beim Subscribe übergeben damit der Event dem Modul zugestellt werden kann.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog-Modul ====
Digitalisieren der Analogeingänge
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Dies war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16 die Behandlung der Messung der Batteriespannung verbessert. Da hier die Referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.
Die einzelnen Werte werden weiterhin über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt nun 13 analoge Werte (statt bisher 11) die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von ca 117 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 111 µs (statt bisher 94 µs) aktualisiert wird.

==== Line-Modul ====
Ermitteln der Werte der Liniensensoren
Dateien: line.c
line.h
Dieser Modul ersetzt die originalen Bibliotheksfunktionen der Liniensensoren. Dies war notwendig da wir zusätzliche Liniensensoren verwenden.

Die Werte der Liniensensoren können nun mit der Funktion
<code>ln_get(index)</code>
gelesen werden. Die Werte selbst werden über den [[NIBObee#Analog-Modul|Analog-Modul]] ermittelt.

==== Bluetooth-Modul ====
Wickelt die Kommunikation über den Bluetooth Modul ab. Zur Kommunikation wird allerdings nur der USART als Terminal angesprochen, der Bluetooth Stack ist im [[BTM-222]] implementiert.
Dateien: bluetooth.c
bluetooth.h

==== Common-Modul ====
Stellt gemeinsame Funktionen zurVerfügung
Dateien: common.c
common.h

==== Distance-Modul ====
Behandelt die Odometrie Sensoren
Dateien: distance.c
distance.h

==== Drive-Modul ====
Bewegt den NIBObee
Dateien: drive.c
drive.h

==== Follow-Modul ====
Ist für die Linienverfolgung zuständig
Dateien: follow.c
follow.h

==== MaDeCo-Modul ====
Behandelt das MaDeCo Protokoll
Dateien: madeco.c
madeco.h

==== Main-Modul ====
Scheduler und zentraler Taktgeber
Dateien: main.c
main.h

==== Sensor-Modul ====
Ist für die "Fühler" zuständig
Dateien: follow.c
follow.h

=== Applikationen ===
==== Labyrinth erkunden ====

==== Kürzesten Weg durch Labyrinth ====

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-05-16T13:33:47Z

Alois: /* Bluetooth-Modul */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|...
|-
|...
|...
|...
|-
|...
|...
|...
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
Die original NIBObee Biliothek wird nicht verwendet. Wurde durch eine eigene Implementierung im [[NIBObee#Line-Modul|Line-Modul]] ersetzt.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen Gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusätzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt ausschließlich über Events. Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 2 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. lesen der Liniensensoren). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird nicht direkt vom Scheduler aufgerufen sondern über die Funktion <xx>_eventHandler. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; eine Funktion mit dem Namen <xx>_eventHandler (extern)
: Ist die Funktion die vom Scheduler aufgerufen wird damit die Statemaschine mit dem aktuellen Event, sofern vorhanden, durchlaufen wird.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.
; eine Funktion mit dem Namen <xx>_receiveEvent (intern)
: ReceiveEvent ist eigentlich eine interne Funktion (wird also nicht im Header File deklariert), der Pointer auf diese Funktion wird allerdings als Callback beim Subscribe übergeben damit der Event dem Modul zugestellt werden kann.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog-Modul ====
Digitalisieren der Analogeingänge
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Dies war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16 die Behandlung der Messung der Batteriespannung verbessert. Da hier die Referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.
Die einzelnen Werte werden weiterhin über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt nun 13 analoge Werte (statt bisher 11) die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von ca 117 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 111 µs (statt bisher 94 µs) aktualisiert wird.

==== Line-Modul ====
Ermitteln der Werte der Liniensensoren
Dateien: line.c
line.h
Dieser Modul ersetzt die originalen Bibliotheksfunktionen der Liniensensoren. Dies war notwendig da wir zusätzliche Liniensensoren verwenden.

Die Werte der Liniensensoren können nun mit der Funktion
<code>ln_get(index)</code>
gelesen werden. Die Werte selbst werden über den [[NIBObee#Analog-Modul|Analog-Modul]] ermittelt.

==== Bluetooth-Modul ====
Wickelt die Kommunikation über den Bluetooth Modul ab. Zur Kommunikation wird allerdings nur der USART als Terminal angesprochen, der Bluetooth Stack ist im [[BTM-222]] implementiert.
Dateien: bluetooth.c
bluetooth.h

==== Common-Modul ====
Stellt gemeinsame Funktionen zurVerfügung
Dateien: common.c
common.h

==== Distance-Modul ====
Behandelt die Odometrie Sensoren
Dateien: distance.c
distance.h

==== Drive-Modul ====
Bewegt den NIBObee
Dateien: drive.c
drive.h

==== Follow-Modul ====
Ist für die Linienverfolgung zuständig
Dateien: follow.c
follow.h

==== MaDeCo-Modul ====
Behandelt das MaDeCo Protokoll
Dateien: madeco.c
madeco.h

==== Main-Modul ====
Scheduler und zentraler Taktgeber
Dateien: main.c
main.h

==== Sensor-Modul ====
Ist für die "Fühler" zuständig
Dateien: follow.c
follow.h

=== Applikationen ===
==== Labyrinth erkunden ====

==== Kürzesten Weg durch Labyrinth ====

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-05-16T13:32:52Z

Alois: /* Communication-Modul */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|...
|-
|...
|...
|...
|-
|...
|...
|...
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
Die original NIBObee Biliothek wird nicht verwendet. Wurde durch eine eigene Implementierung im [[NIBObee#Line-Modul|Line-Modul]] ersetzt.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen Gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusätzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt ausschließlich über Events. Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 2 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. lesen der Liniensensoren). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird nicht direkt vom Scheduler aufgerufen sondern über die Funktion <xx>_eventHandler. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; eine Funktion mit dem Namen <xx>_eventHandler (extern)
: Ist die Funktion die vom Scheduler aufgerufen wird damit die Statemaschine mit dem aktuellen Event, sofern vorhanden, durchlaufen wird.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.
; eine Funktion mit dem Namen <xx>_receiveEvent (intern)
: ReceiveEvent ist eigentlich eine interne Funktion (wird also nicht im Header File deklariert), der Pointer auf diese Funktion wird allerdings als Callback beim Subscribe übergeben damit der Event dem Modul zugestellt werden kann.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog-Modul ====
Digitalisieren der Analogeingänge
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Dies war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16 die Behandlung der Messung der Batteriespannung verbessert. Da hier die Referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.
Die einzelnen Werte werden weiterhin über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt nun 13 analoge Werte (statt bisher 11) die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von ca 117 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 111 µs (statt bisher 94 µs) aktualisiert wird.

==== Line-Modul ====
Ermitteln der Werte der Liniensensoren
Dateien: line.c
line.h
Dieser Modul ersetzt die originalen Bibliotheksfunktionen der Liniensensoren. Dies war notwendig da wir zusätzliche Liniensensoren verwenden.

Die Werte der Liniensensoren können nun mit der Funktion
<code>ln_get(index)</code>
gelesen werden. Die Werte selbst werden über den [[NIBObee#Analog-Modul|Analog-Modul]] ermittelt.

==== Bluetooth-Modul ====
Wickelt die Kommunikation über den Bluetooth Modul ab. Zur Kommunikation wird allerdings nur der USART als Terminal angesprochen, der Bluetooth Stack ist in BTM222 implementiert.
Dateien: bluetooth.c
bluetooth.h

==== Common-Modul ====
Stellt gemeinsame Funktionen zurVerfügung
Dateien: common.c
common.h

==== Distance-Modul ====
Behandelt die Odometrie Sensoren
Dateien: distance.c
distance.h

==== Drive-Modul ====
Bewegt den NIBObee
Dateien: drive.c
drive.h

==== Follow-Modul ====
Ist für die Linienverfolgung zuständig
Dateien: follow.c
follow.h

==== MaDeCo-Modul ====
Behandelt das MaDeCo Protokoll
Dateien: madeco.c
madeco.h

==== Main-Modul ====
Scheduler und zentraler Taktgeber
Dateien: main.c
main.h

==== Sensor-Modul ====
Ist für die "Fühler" zuständig
Dateien: follow.c
follow.h

=== Applikationen ===
==== Labyrinth erkunden ====

==== Kürzesten Weg durch Labyrinth ====

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

MaDeCo

2011-05-15T14:26:16Z

Alois: /* Format */

= MaDeCo - Protokoll zur Kommunikation im [[RoLoMa]] Projekt =

MaDeCo ist ein sehr einfaches textbasiertes Protokoll für die Kommunikation zwischen den Beteiligten im [[RoLoMa]] Projekt, den [[NIBObee]] Einheiten und der Basisstation, dem [[LPC2478]].

== Rollen ==
Es gibt unter den Beteiligten zwei festgelegte Rollen, Sender und Empfänger. Der Sender überträgt Information, der Empfänger hingegen hat eine überwiegend passive Funktion, er quittiert Nachrichten und übermittelt einen Acknowledge Code.
Während der Kommunikation werden diese Rollen nicht gewechselt.

== Format ==
Eine Nachricht besteht aus genau zwei Datensätzen, ein Datensatz besteht jeweils aus einem 3 Zeichen breiten Header Teil, und einem 2 Zeichen breiten Datenteil. Für kleinere Datenteile erfolgt ein Padding mit Leerzeichen.

Beide Teile der Nachricht werden unmittelbar hintereinander gesendet, also z.B. als ''SEQ13OPMSM''. In untenstehenden Beispielen werden die beiden Teile der Nachricht allerdings durch einen Zeilenumbruch getrennt, um die Nachricht lesbarer zu machen.

Eine Nachricht, wie sie ein Sender erstellt, besteht aus:
<Sequence>
<Command>

<Sequence> besteht aus dem Header SEQ, der Datenteil aus einer Nummer zwischen 1 und 99.
<Command> besteht aus dem 3 Zeichen langen Command-Code, und einem entsprechenden Datenteil.

Eine Nachricht muss mit einer Antwort quittiert werden. Diese besteht aus:
<Acknowledge>
<Acknowledge Code>

<Acknowledge> besteht aus dem Header ACK und der zu bestätigenden Sequence Number.
<Acknowledge Code> besteht aus den Header ACC und dem Code.

Beispiel sind be den jeweiligen [[MaDeCo#Use Cases|Use Cases]] zu finden.

=== Commands ===
EOC ... end of communication, signalisiert das Ende einer Kommunikation
OPM ... Operation Mode (siehe Betriebsmodus)
WAP ... Waypoint (siehe Wegpunkte)
DIR ... Angabe der Richtung im GO Betriebsmodus (siehe Kürzester Weg)

=== Acknowledge Codes ===
00 .. OK, Command acknowledged
01 .. unknown Command
02 .. invalid data
11 .. unbekannter Betriebsmodus (e.g. OPMXX)
21 .. Command refused, Labyrinth erkunden (OPMSM) vor [[NIBObee#Kalibrierung]] (OPMGA)

=== Betriebsmodus ===
GA ... Kalibrieren (siehe [[NIBObee#Kalibrierung]])
SM ... Labyrinth erkunden
GO ... kürzesten Weg nehmen (siehe Kürzester Weg)

=== Wegpunkte ===
Die Übertragung eines Wegpunkts erfolgt durch Angabe der Richtung (S,W,N,E), gefolgt von der Anzahl der Streckenteile.
Beispiel: WAPS4 der Wegpunkt befindet sich 4 Streckenteile südlich des zuletzt übertragenen Wegpunkts

== Ablauf ==
Im [[RoLoMa]] Projekt muss die Kommunikation aus Nachricht-Antwort Sequenzen bestehen. Wird eine gesendete Nachricht nicht bestätigt, erfolgt eine Neuübertragung nach dem RETRANSMISSION_TIMEOUT Interval.
Erfolgt auch nach RETRANSMISSION_COUNT Wiederholungen keine Antwort, wird die Übertragung abgebrochen und ein Fehler signalisiert.

Kommunikationen überschneiden sich nicht, das bedeutet, es findet zu jedem Zeitpunkt nur eine Kommunikation zwischen den Beteiligten statt. Daher ist auch zu jedem Zeitpunkt genau ein Teilnehmer der Sender, und ein Teilnehmer der Empfänger.

== Use Cases ==
Im folgenden werden Beispiele für die Kommunikation der unterschiedlichen Betriebsarten dargestellt. Daten vom Borad werden normal, die von der NIBObee '''fett''' dargestellt.

=== Kalibrieren ===
Beim Kalibrieren wird das Kommando vom Board an die NIBObee geschickt und auch bei Erhalt sofort quittiert (sonst würde es zu einem Timeout kommen). Nachdem die Kalibrierung abgeschlossen ist wird die Verbindung getrennt.

''Beispiel:''
SEQ1
OPMGA

'''ACK1'''
'''ACC00'''

'''SEQ2'''
'''EOC'''

ACK2
ACC00

=== Labyrinth erkunden===
Das Kommando wird vom Board an die NIBObee geschickt und auch bei Erhalt sofort quittiert (es muss vorher allerdings eine Kalibrierung durchgeführt worden sein). Danach werden laufend die Punkte geschickt die abgefahren werden. Wenn das ganze Labyrinth erfasst wurde wir die Kommunikation wieder beendet.

''Beispiel:''
SEQ1
OPMSM

'''ACK1'''
'''ACC00'''

'''SEQ2'''
'''WAPN3'''

ACK2
ACC00

'''SEQ3'''
'''WAPO1'''

...

'''SEQ32'''
'''EOC'''

ACK32
ACC00

=== Kürzester Weg ===
Hier werden Richtungsanweisungen übertragen, die es der [[NIBObee]] ermöglichen, in einem Labyrinth den kürzesten Weg zu nehmen.
Beispiel (ohne ACKs), der kürzeste Weg wird als S(üd)-N(ord)-W(est)-S(üd) angegeben:
SEQ1
OPMGO

SEQ2
DIRS

SEQ3
DIRN

SEQ4
DIRW

SEQ5
DIRS

SEQ6
EOC

[[Kategorie:FH]]

MaDeCo

2011-05-15T14:25:03Z

Alois: /* Format */

= MaDeCo - Protokoll zur Kommunikation im [[RoLoMa]] Projekt =

MaDeCo ist ein sehr einfaches textbasiertes Protokoll für die Kommunikation zwischen den Beteiligten im [[RoLoMa]] Projekt, den [[NIBObee]] Einheiten und der Basisstation, dem [[LPC2478]].

== Rollen ==
Es gibt unter den Beteiligten zwei festgelegte Rollen, Sender und Empfänger. Der Sender überträgt Information, der Empfänger hingegen hat eine überwiegend passive Funktion, er quittiert Nachrichten und übermittelt einen Acknowledge Code.
Während der Kommunikation werden diese Rollen nicht gewechselt.

== Format ==
Eine Nachricht besteht aus genau zwei Datensätzen, ein Datensatz besteht jeweils aus einem 3 Zeichen breiten Header Teil, und einem 2 Zeichen breiten Datenteil. Für kleinere Datenteile erfolgt ein Padding mit Leerzeichen.

Beide Teile der Nachricht werden unmittelbar hintereinander gesendet, also z.B. als ''SEQ13OPMSM''. In untenstehenden Beispielen werden die beiden Teile der Nachricht allerdings durch einen Zeilenumbruch getrennt, um die Nachricht lesbarer zu machen.

Eine Nachricht, wie sie ein Sender erstellt, besteht aus:
<Sequence>
<Command>

<Sequence> besteht aus dem Header SEQ, der Datenteil aus einer Nummer zwischen 1 und 99.
<Command> besteht aus dem 3 Zeichen langen Command-Code, und einem entsprechenden Datenteil.

Eine Nachricht muss mit einer Antwort quittiert werden. Diese besteht aus:
<Acknowledge>
<Acknowledge Code>

<Acknowledge> besteht aus dem Header ACK und der zu bestätigenden Sequence Number.
<Acknowledge Code> besteht aus den Header ACC und dem Code.

Beispiel sind be den jeweiligen Use Cases zu finden.

=== Commands ===
EOC ... end of communication, signalisiert das Ende einer Kommunikation
OPM ... Operation Mode (siehe Betriebsmodus)
WAP ... Waypoint (siehe Wegpunkte)
DIR ... Angabe der Richtung im GO Betriebsmodus (siehe Kürzester Weg)

=== Acknowledge Codes ===
00 .. OK, Command acknowledged
01 .. unknown Command
02 .. invalid data
11 .. unbekannter Betriebsmodus (e.g. OPMXX)
21 .. Command refused, Labyrinth erkunden (OPMSM) vor [[NIBObee#Kalibrierung]] (OPMGA)

=== Betriebsmodus ===
GA ... Kalibrieren (siehe [[NIBObee#Kalibrierung]])
SM ... Labyrinth erkunden
GO ... kürzesten Weg nehmen (siehe Kürzester Weg)

=== Wegpunkte ===
Die Übertragung eines Wegpunkts erfolgt durch Angabe der Richtung (S,W,N,E), gefolgt von der Anzahl der Streckenteile.
Beispiel: WAPS4 der Wegpunkt befindet sich 4 Streckenteile südlich des zuletzt übertragenen Wegpunkts

== Ablauf ==
Im [[RoLoMa]] Projekt muss die Kommunikation aus Nachricht-Antwort Sequenzen bestehen. Wird eine gesendete Nachricht nicht bestätigt, erfolgt eine Neuübertragung nach dem RETRANSMISSION_TIMEOUT Interval.
Erfolgt auch nach RETRANSMISSION_COUNT Wiederholungen keine Antwort, wird die Übertragung abgebrochen und ein Fehler signalisiert.

Kommunikationen überschneiden sich nicht, das bedeutet, es findet zu jedem Zeitpunkt nur eine Kommunikation zwischen den Beteiligten statt. Daher ist auch zu jedem Zeitpunkt genau ein Teilnehmer der Sender, und ein Teilnehmer der Empfänger.

== Use Cases ==
Im folgenden werden Beispiele für die Kommunikation der unterschiedlichen Betriebsarten dargestellt. Daten vom Borad werden normal, die von der NIBObee '''fett''' dargestellt.

=== Kalibrieren ===
Beim Kalibrieren wird das Kommando vom Board an die NIBObee geschickt und auch bei Erhalt sofort quittiert (sonst würde es zu einem Timeout kommen). Nachdem die Kalibrierung abgeschlossen ist wird die Verbindung getrennt.

''Beispiel:''
SEQ1
OPMGA

'''ACK1'''
'''ACC00'''

'''SEQ2'''
'''EOC'''

ACK2
ACC00

=== Labyrinth erkunden===
Das Kommando wird vom Board an die NIBObee geschickt und auch bei Erhalt sofort quittiert (es muss vorher allerdings eine Kalibrierung durchgeführt worden sein). Danach werden laufend die Punkte geschickt die abgefahren werden. Wenn das ganze Labyrinth erfasst wurde wir die Kommunikation wieder beendet.

''Beispiel:''
SEQ1
OPMSM

'''ACK1'''
'''ACC00'''

'''SEQ2'''
'''WAPN3'''

ACK2
ACC00

'''SEQ3'''
'''WAPO1'''

...

'''SEQ32'''
'''EOC'''

ACK32
ACC00

=== Kürzester Weg ===
Hier werden Richtungsanweisungen übertragen, die es der [[NIBObee]] ermöglichen, in einem Labyrinth den kürzesten Weg zu nehmen.
Beispiel (ohne ACKs), der kürzeste Weg wird als S(üd)-N(ord)-W(est)-S(üd) angegeben:
SEQ1
OPMGO

SEQ2
DIRS

SEQ3
DIRN

SEQ4
DIRW

SEQ5
DIRS

SEQ6
EOC

[[Kategorie:FH]]

Benutzer:Alois/monobook.css

2011-05-15T14:21:08Z

Alois:

@media screen {
h3 {
font-size: 132%;
border-bottom: 1px dashed #aaa;
font-weight: normal;
}
}

@media print {
/* automatic header numbering */
body {
counter-reset:h1;
/* counter-increment:h1 -1; // to start with 0 */
}

h1:before {
content:counter(h1) ". ";
counter-increment:h1 ;
}
h1{
counter-reset:h2;
}

h2:before {
content:counter(h1) "." counter(h2) ". ";
counter-increment:h2 ;
}
h2{
counter-reset:h3;
}

h3:before {
content:counter(h1) "." counter(h2) "." counter(h3) ". ";
counter-increment:h3 ;
}
h3{
counter-reset:h4;
}

h4:before {
content:counter(h1) "." counter(h2) "." counter(h3) "." counter(h4) ". ";
counter-increment:h4 ;
}
}

MaDeCo

2011-05-14T15:52:59Z

Alois:

= MaDeCo - Protokoll zur Kommunikation im [[RoLoMa]] Projekt =

MaDeCo ist ein sehr einfaches textbasiertes Protokoll für die Kommunikation zwischen den Beteiligten im [[RoLoMa]] Projekt, den [[NIBObee]] Einheiten und der Basisstation, dem [[LPC2478]].

== Rollen ==
Es gibt unter den Beteiligten zwei festgelegte Rollen, Sender und Empfänger. Der Sender überträgt Information, der Empfänger hingegen hat eine überwiegend passive Funktion, er quittiert Nachrichten und übermittelt einen Acknowledge Code.
Während der Kommunikation werden diese Rollen nicht gewechselt.

== Format ==
Eine Nachricht besteht aus genau zwei Datensätzen, ein Datensatz besteht jeweils aus einem 3 Zeichen breiten Header Teil, und einem 2 Zeichen breiten Datenteil. Für kleinere Datenteile erfolgt ein Padding mit Leerzeichen.

Beide Teile der Nachricht werden unmittelbar hintereinander gesendet, also z.B. als ''SEQ13OPMSM''. In untenstehenden Beispielen werden die beiden Teile der Nachricht allerdings durch einen Zeilenumbruch getrennt, um die Nachricht lesbarer zu machen.

Eine Nachricht, wie sie ein Sender erstellt, besteht aus:
<Sequence>
<Command>

<Sequence> besteht aus dem Header SEQ, der Datenteil aus einer Nummer zwischen 1 und 99.
<Command> besteht aus dem 3 Zeichen langen Command-Code, und einem entsprechenden Datenteil.

Eine Nachricht muss mit einer Antwort quittiert werden. Diese besteht aus:
<Acknowledge>
<Acknowledge Code>

<Acknowledge> besteht aus dem Header ACK und der zu bestätigenden Sequence Number.
<Acknowledge Code> besteht aus den Header ACC und dem Code.

''Beispiel:''
SEQ1
OPMSM

ACK1
ACC00

SEQ2
EOC

ACK2
ACC00

=== Commands ===
EOC ... end of communication, signalisiert das Ende einer Kommunikation
OPM ... Operation Mode (siehe Betriebsmodus)
WAP ... Waypoint (siehe Wegpunkte)
DIR ... Angabe der Richtung im GO Betriebsmodus (siehe Kürzester Weg)

=== Acknowledge Codes ===
00 .. OK, Command acknowledged
01 .. unknown Command
02 .. invalid data
11 .. unbekannter Betriebsmodus (e.g. OPMXX)
21 .. Command refused, Labyrinth erkunden (OPMSM) vor [[NIBObee#Kalibrierung]] (OPMGA)

=== Betriebsmodus ===
GA ... Kalibrieren (siehe [[NIBObee#Kalibrierung]])
SM ... Labyrinth erkunden
GO ... kürzesten Weg nehmen (siehe Kürzester Weg)

=== Wegpunkte ===
Die Übertragung eines Wegpunkts erfolgt durch Angabe der Richtung (S,W,N,E), gefolgt von der Anzahl der Streckenteile.
Beispiel: WAPS4 der Wegpunkt befindet sich 4 Streckenteile südlich des zuletzt übertragenen Wegpunkts

== Ablauf ==
Im [[RoLoMa]] Projekt muss die Kommunikation aus Nachricht-Antwort Sequenzen bestehen. Wird eine gesendete Nachricht nicht bestätigt, erfolgt eine Neuübertragung nach dem RETRANSMISSION_TIMEOUT Interval.
Erfolgt auch nach RETRANSMISSION_COUNT Wiederholungen keine Antwort, wird die Übertragung abgebrochen und ein Fehler signalisiert.

Kommunikationen überschneiden sich nicht, das bedeutet, es findet zu jedem Zeitpunkt nur eine Kommunikation zwischen den Beteiligten statt. Daher ist auch zu jedem Zeitpunkt genau ein Teilnehmer der Sender, und ein Teilnehmer der Empfänger.

== Use Cases ==
Im folgenden werden Beispiele für die Kommunikation der unterschiedlichen Betriebsarten dargestellt. Daten vom Borad werden normal, die von der NIBObee '''fett''' dargestellt.

=== Kalibrieren ===
Beim Kalibrieren wird das Kommando vom Board an die NIBObee geschickt und auch bei Erhalt sofort quittiert (sonst würde es zu einem Timeout kommen). Nachdem die Kalibrierung abgeschlossen ist wird die Verbindung getrennt.

''Beispiel:''
SEQ1
OPMGA

'''ACK1'''
'''ACC00'''

'''SEQ2'''
'''EOC'''

ACK2
ACC00

=== Labyrinth erkunden===
Das Kommando wird vom Board an die NIBObee geschickt und auch bei Erhalt sofort quittiert (es muss vorher allerdings eine Kalibrierung durchgeführt worden sein). Danach werden laufend die Punkte geschickt die abgefahren werden. Wenn das ganze Labyrinth erfasst wurde wir die Kommunikation wieder beendet.

''Beispiel:''
SEQ1
OPMSM

'''ACK1'''
'''ACC00'''

'''SEQ2'''
'''WAPN3'''

ACK2
ACC00

'''SEQ3'''
'''WAPO1'''

...

'''SEQ32'''
'''EOC'''

ACK32
ACC00

=== Kürzester Weg ===
Hier werden Richtungsanweisungen übertragen, die es der [[NIBObee]] ermöglichen, in einem Labyrinth den kürzesten Weg zu nehmen.
Beispiel (ohne ACKs), der kürzeste Weg wird als S(üd)-N(ord)-W(est)-S(üd) angegeben:
SEQ1
OPMGO

SEQ2
DIRS

SEQ3
DIRN

SEQ4
DIRW

SEQ5
DIRS

SEQ6
EOC

[[Kategorie:FH]]

NIBObee

2011-05-02T09:48:02Z

Alois: /* Communication-Modul */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|...
|-
|...
|...
|...
|-
|...
|...
|...
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
Die original NIBObee Biliothek wird nicht verwendet. Wurde durch eine eigene Implementierung im [[NIBObee#Line-Modul|Line-Modul]] ersetzt.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen Gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusätzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt ausschließlich über Events. Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 2 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. lesen der Liniensensoren). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird nicht direkt vom Scheduler aufgerufen sondern über die Funktion <xx>_eventHandler. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; eine Funktion mit dem Namen <xx>_eventHandler (extern)
: Ist die Funktion die vom Scheduler aufgerufen wird damit die Statemaschine mit dem aktuellen Event, sofern vorhanden, durchlaufen wird.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.
; eine Funktion mit dem Namen <xx>_receiveEvent (intern)
: ReceiveEvent ist eigentlich eine interne Funktion (wird also nicht im Header File deklariert), der Pointer auf diese Funktion wird allerdings als Callback beim Subscribe übergeben damit der Event dem Modul zugestellt werden kann.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog-Modul ====
Digitalisieren der Analogeingänge
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Dies war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16 die Behandlung der Messung der Batteriespannung verbessert. Da hier die Referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.
Die einzelnen Werte werden weiterhin über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt nun 13 analoge Werte (statt bisher 11) die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von ca 117 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 111 µs (statt bisher 94 µs) aktualisiert wird.

==== Line-Modul ====
Ermitteln der Werte der Liniensensoren
Dateien: line.c
line.h
Dieser Modul ersetzt die originalen Bibliotheksfunktionen der Liniensensoren. Dies war notwendig da wir zusätzliche Liniensensoren verwenden.

Die Werte der Liniensensoren können nun mit der Funktion
<code>ln_get(index)</code>
gelesen werden. Die Werte selbst werden über den [[NIBObee#Analog-Modul|Analog-Modul]] ermittelt.

==== Communication-Modul ====
Wickelt die Kommunikation über den Bluetooth Modul ab
Dateien: comm.c
comm.h

==== Common-Modul ====
Stellt gemeinsame Funktionen zurVerfügung
Dateien: common.c
common.h

==== Distance-Modul ====
Behandelt die Odometrie Sensoren
Dateien: distance.c
distance.h

==== Drive-Modul ====
Bewegt den NIBObee
Dateien: drive.c
drive.h

==== Follow-Modul ====
Ist für die Linienverfolgung zuständig
Dateien: follow.c
follow.h

==== MaDeCo-Modul ====
Behandelt das MaDeCo Protokoll
Dateien: madeco.c
madeco.h

==== Main-Modul ====
Scheduler und zentraler Taktgeber
Dateien: main.c
main.h

==== Sensor-Modul ====
Ist für die "Fühler" zuständig
Dateien: follow.c
follow.h

=== Applikationen ===
==== Labyrinth erkunden ====

==== Kürzesten Weg durch Labyrinth ====

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-05-02T09:46:51Z

Alois: /* Motorensteuerung */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|...
|-
|...
|...
|...
|-
|...
|...
|...
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
Die original NIBObee Biliothek wird nicht verwendet. Wurde durch eine eigene Implementierung im [[NIBObee#Line-Modul|Line-Modul]] ersetzt.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen Gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusätzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt ausschließlich über Events. Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 2 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. lesen der Liniensensoren). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird nicht direkt vom Scheduler aufgerufen sondern über die Funktion <xx>_eventHandler. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; eine Funktion mit dem Namen <xx>_eventHandler (extern)
: Ist die Funktion die vom Scheduler aufgerufen wird damit die Statemaschine mit dem aktuellen Event, sofern vorhanden, durchlaufen wird.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.
; eine Funktion mit dem Namen <xx>_receiveEvent (intern)
: ReceiveEvent ist eigentlich eine interne Funktion (wird also nicht im Header File deklariert), der Pointer auf diese Funktion wird allerdings als Callback beim Subscribe übergeben damit der Event dem Modul zugestellt werden kann.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog-Modul ====
Digitalisieren der Analogeingänge
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Dies war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16 die Behandlung der Messung der Batteriespannung verbessert. Da hier die Referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.
Die einzelnen Werte werden weiterhin über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt nun 13 analoge Werte (statt bisher 11) die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von ca 117 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 111 µs (statt bisher 94 µs) aktualisiert wird.

==== Line-Modul ====
Ermitteln der Werte der Liniensensoren
Dateien: line.c
line.h
Dieser Modul ersetzt die originalen Bibliotheksfunktionen der Liniensensoren. Dies war notwendig da wir zusätzliche Liniensensoren verwenden.

Die Werte der Liniensensoren können nun mit der Funktion
<code>ln_get(index)</code>
gelesen werden. Die Werte selbst werden über den [[NIBObee#Analog-Modul|Analog-Modul]] ermittelt.

==== Communication-Modul ====
Wickelt die Kommunikation über den Bluetooth Modul ab
Dateien: comm.c
comm.h

==== Communication-Modul ====
Wickelt die Kommunikation über den Bluetooth Modul ab
Dateien: comm.c
comm.h

==== Common-Modul ====
Stellt gemeinsame Funktionen zurVerfügung
Dateien: common.c
common.h

==== Distance-Modul ====
Behandelt die Odometrie Sensoren
Dateien: distance.c
distance.h

==== Drive-Modul ====
Bewegt den NIBObee
Dateien: drive.c
drive.h

==== Follow-Modul ====
Ist für die Linienverfolgung zuständig
Dateien: follow.c
follow.h

==== MaDeCo-Modul ====
Behandelt das MaDeCo Protokoll
Dateien: madeco.c
madeco.h

==== Main-Modul ====
Scheduler und zentraler Taktgeber
Dateien: main.c
main.h

==== Sensor-Modul ====
Ist für die "Fühler" zuständig
Dateien: follow.c
follow.h

=== Applikationen ===
==== Labyrinth erkunden ====

==== Kürzesten Weg durch Labyrinth ====

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-05-02T09:45:45Z

Alois: /* Module */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|...
|-
|...
|...
|...
|-
|...
|...
|...
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
Die original NIBObee Biliothek wird nicht verwendet. Wurde durch eine eigene Implementierung im [[NIBObee#Line-Modul|Line-Modul]] ersetzt.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusätzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt ausschließlich über Events. Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 2 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. lesen der Liniensensoren). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird nicht direkt vom Scheduler aufgerufen sondern über die Funktion <xx>_eventHandler. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; eine Funktion mit dem Namen <xx>_eventHandler (extern)
: Ist die Funktion die vom Scheduler aufgerufen wird damit die Statemaschine mit dem aktuellen Event, sofern vorhanden, durchlaufen wird.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.
; eine Funktion mit dem Namen <xx>_receiveEvent (intern)
: ReceiveEvent ist eigentlich eine interne Funktion (wird also nicht im Header File deklariert), der Pointer auf diese Funktion wird allerdings als Callback beim Subscribe übergeben damit der Event dem Modul zugestellt werden kann.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog-Modul ====
Digitalisieren der Analogeingänge
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Dies war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16 die Behandlung der Messung der Batteriespannung verbessert. Da hier die Referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.
Die einzelnen Werte werden weiterhin über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt nun 13 analoge Werte (statt bisher 11) die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von ca 117 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 111 µs (statt bisher 94 µs) aktualisiert wird.

==== Line-Modul ====
Ermitteln der Werte der Liniensensoren
Dateien: line.c
line.h
Dieser Modul ersetzt die originalen Bibliotheksfunktionen der Liniensensoren. Dies war notwendig da wir zusätzliche Liniensensoren verwenden.

Die Werte der Liniensensoren können nun mit der Funktion
<code>ln_get(index)</code>
gelesen werden. Die Werte selbst werden über den [[NIBObee#Analog-Modul|Analog-Modul]] ermittelt.

==== Communication-Modul ====
Wickelt die Kommunikation über den Bluetooth Modul ab
Dateien: comm.c
comm.h

==== Communication-Modul ====
Wickelt die Kommunikation über den Bluetooth Modul ab
Dateien: comm.c
comm.h

==== Common-Modul ====
Stellt gemeinsame Funktionen zurVerfügung
Dateien: common.c
common.h

==== Distance-Modul ====
Behandelt die Odometrie Sensoren
Dateien: distance.c
distance.h

==== Drive-Modul ====
Bewegt den NIBObee
Dateien: drive.c
drive.h

==== Follow-Modul ====
Ist für die Linienverfolgung zuständig
Dateien: follow.c
follow.h

==== MaDeCo-Modul ====
Behandelt das MaDeCo Protokoll
Dateien: madeco.c
madeco.h

==== Main-Modul ====
Scheduler und zentraler Taktgeber
Dateien: main.c
main.h

==== Sensor-Modul ====
Ist für die "Fühler" zuständig
Dateien: follow.c
follow.h

=== Applikationen ===
==== Labyrinth erkunden ====

==== Kürzesten Weg durch Labyrinth ====

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-05-02T09:38:29Z

Alois: /* Analog-Modul */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|...
|-
|...
|...
|...
|-
|...
|...
|...
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
Die original NIBObee Biliothek wird nicht verwendet. Wurde durch eine eigene Implementierung im [[NIBObee#Line-Modul|Line-Modul]] ersetzt.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusätzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt ausschließlich über Events. Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 2 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. lesen der Liniensensoren). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird nicht direkt vom Scheduler aufgerufen sondern über die Funktion <xx>_eventHandler. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; eine Funktion mit dem Namen <xx>_eventHandler (extern)
: Ist die Funktion die vom Scheduler aufgerufen wird damit die Statemaschine mit dem aktuellen Event, sofern vorhanden, durchlaufen wird.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.
; eine Funktion mit dem Namen <xx>_receiveEvent (intern)
: ReceiveEvent ist eigentlich eine interne Funktion (wird also nicht im Header File deklariert), der Pointer auf diese Funktion wird allerdings als Callback beim Subscribe übergeben damit der Event dem Modul zugestellt werden kann.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog-Modul ====
Digitalisieren der Analogeingänge
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Dies war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16 die Behandlung der Messung der Batteriespannung verbessert. Da hier die Referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.
Die einzelnen Werte werden weiterhin über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt nun 13 analoge Werte (statt bisher 11) die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von ca 117 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 111 µs (statt bisher 94 µs) aktualisiert wird.

==== Line-Modul ====
Ermitteln der Werte der Liniensensoren
Dateien: line.c
line.h
Dieser Modul ersetzt die originalen Bibliotheksfunktionen der Liniensensoren. Dies war notwendig da wir zusätzliche Liniensensoren verwenden.

Die Werte der Liniensensoren können nun mit der Funktion
<code>ln_get(index)</code>
gelesen werden. Die Werte selbst werden über den [[NIBObee#Analog-Modul|Analog-Modul]] ermittelt.

=== Applikationen ===
==== Labyrinth erkunden ====

==== Kürzesten Weg durch Labyrinth ====

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-05-02T09:32:35Z

Alois: /* Line-Modul */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|...
|-
|...
|...
|...
|-
|...
|...
|...
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
Die original NIBObee Biliothek wird nicht verwendet. Wurde durch eine eigene Implementierung im [[NIBObee#Line-Modul|Line-Modul]] ersetzt.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusätzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt ausschließlich über Events. Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 2 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. lesen der Liniensensoren). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird nicht direkt vom Scheduler aufgerufen sondern über die Funktion <xx>_eventHandler. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; eine Funktion mit dem Namen <xx>_eventHandler (extern)
: Ist die Funktion die vom Scheduler aufgerufen wird damit die Statemaschine mit dem aktuellen Event, sofern vorhanden, durchlaufen wird.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.
; eine Funktion mit dem Namen <xx>_receiveEvent (intern)
: ReceiveEvent ist eigentlich eine interne Funktion (wird also nicht im Header File deklariert), der Pointer auf diese Funktion wird allerdings als Callback beim Subscribe übergeben damit der Event dem Modul zugestellt werden kann.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog-Modul ====
Digitalisieren der Analogeingänge
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Dies war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16 die Behandlung der Messung der Batteriespannung verbessert. Da hier die referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.

==== Line-Modul ====
Ermitteln der Werte der Liniensensoren
Dateien: line.c
line.h
Dieser Modul ersetzt die originalen Bibliotheksfunktionen der Liniensensoren. Dies war notwendig da wir zusätzliche Liniensensoren verwenden.

Die Werte der Liniensensoren können nun mit der Funktion
<code>ln_get(index)</code>
gelesen werden. Die Werte selbst werden über den [[NIBObee#Analog-Modul|Analog-Modul]] ermittelt.

=== Applikationen ===
==== Labyrinth erkunden ====

==== Kürzesten Weg durch Labyrinth ====

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-05-02T09:30:03Z

Alois: /* Liniensensoren */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|...
|-
|...
|...
|...
|-
|...
|...
|...
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
Die original NIBObee Biliothek wird nicht verwendet. Wurde durch eine eigene Implementierung im [[NIBObee#Line-Modul|Line-Modul]] ersetzt.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusätzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt ausschließlich über Events. Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 2 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. lesen der Liniensensoren). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird nicht direkt vom Scheduler aufgerufen sondern über die Funktion <xx>_eventHandler. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; eine Funktion mit dem Namen <xx>_eventHandler (extern)
: Ist die Funktion die vom Scheduler aufgerufen wird damit die Statemaschine mit dem aktuellen Event, sofern vorhanden, durchlaufen wird.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.
; eine Funktion mit dem Namen <xx>_receiveEvent (intern)
: ReceiveEvent ist eigentlich eine interne Funktion (wird also nicht im Header File deklariert), der Pointer auf diese Funktion wird allerdings als Callback beim Subscribe übergeben damit der Event dem Modul zugestellt werden kann.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog-Modul ====
Digitalisieren der Analogeingänge
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Dies war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16 die Behandlung der Messung der Batteriespannung verbessert. Da hier die referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.

==== Line-Modul ====
Ermitteln der Werte der Liniensensoren
Dateien: line.c
line.h
Dieser Modul ersetzt die originalen Bibliotheksfunktionen der Liniensensoren. Dies war notwendig da wir zusätzliche Liniensensoren verwenden.

=== Applikationen ===
==== Labyrinth erkunden ====

==== Kürzesten Weg durch Labyrinth ====

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-05-02T09:28:57Z

Alois: /* Analogeingänge digitalisieren */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|...
|-
|...
|...
|...
|-
|...
|...
|...
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
line.h
Die Werte der Liniensensoren können mit der Funktion
<code>line_get(index)</code>
gelesen werden. Die Werte selbst werden über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt 11 analoge Werte die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von 120 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 94 µs aktualisiert wird.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusätzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt ausschließlich über Events. Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 2 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. lesen der Liniensensoren). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird nicht direkt vom Scheduler aufgerufen sondern über die Funktion <xx>_eventHandler. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; eine Funktion mit dem Namen <xx>_eventHandler (extern)
: Ist die Funktion die vom Scheduler aufgerufen wird damit die Statemaschine mit dem aktuellen Event, sofern vorhanden, durchlaufen wird.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.
; eine Funktion mit dem Namen <xx>_receiveEvent (intern)
: ReceiveEvent ist eigentlich eine interne Funktion (wird also nicht im Header File deklariert), der Pointer auf diese Funktion wird allerdings als Callback beim Subscribe übergeben damit der Event dem Modul zugestellt werden kann.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog-Modul ====
Digitalisieren der Analogeingänge
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Dies war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16 die Behandlung der Messung der Batteriespannung verbessert. Da hier die referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.

==== Line-Modul ====
Ermitteln der Werte der Liniensensoren
Dateien: line.c
line.h
Dieser Modul ersetzt die originalen Bibliotheksfunktionen der Liniensensoren. Dies war notwendig da wir zusätzliche Liniensensoren verwenden.

=== Applikationen ===
==== Labyrinth erkunden ====

==== Kürzesten Weg durch Labyrinth ====

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-05-02T09:21:46Z

Alois: /* Analog */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|...
|-
|...
|...
|...
|-
|...
|...
|...
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
line.h
Die Werte der Liniensensoren können mit der Funktion
<code>line_get(index)</code>
gelesen werden. Die Werte selbst werden über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt 11 analoge Werte die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von 120 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 94 µs aktualisiert wird.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusätzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt ausschließlich über Events. Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 2 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. lesen der Liniensensoren). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird nicht direkt vom Scheduler aufgerufen sondern über die Funktion <xx>_eventHandler. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; eine Funktion mit dem Namen <xx>_eventHandler (extern)
: Ist die Funktion die vom Scheduler aufgerufen wird damit die Statemaschine mit dem aktuellen Event, sofern vorhanden, durchlaufen wird.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.
; eine Funktion mit dem Namen <xx>_receiveEvent (intern)
: ReceiveEvent ist eigentlich eine interne Funktion (wird also nicht im Header File deklariert), der Pointer auf diese Funktion wird allerdings als Callback beim Subscribe übergeben damit der Event dem Modul zugestellt werden kann.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analogeingänge digitalisieren ====
Dateien: analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Dies war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16 die Behandlung der Messung der Batteriespannung verbessert. Da hier die referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.

=== Applikationen ===
==== Labyrinth erkunden ====

==== Kürzesten Weg durch Labyrinth ====

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-05-02T09:19:06Z

Alois: /* Applikationen */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|...
|-
|...
|...
|...
|-
|...
|...
|...
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
line.h
Die Werte der Liniensensoren können mit der Funktion
<code>line_get(index)</code>
gelesen werden. Die Werte selbst werden über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt 11 analoge Werte die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von 120 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 94 µs aktualisiert wird.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusätzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt ausschließlich über Events. Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 2 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. lesen der Liniensensoren). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird nicht direkt vom Scheduler aufgerufen sondern über die Funktion <xx>_eventHandler. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; eine Funktion mit dem Namen <xx>_eventHandler (extern)
: Ist die Funktion die vom Scheduler aufgerufen wird damit die Statemaschine mit dem aktuellen Event, sofern vorhanden, durchlaufen wird.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.
; eine Funktion mit dem Namen <xx>_receiveEvent (intern)
: ReceiveEvent ist eigentlich eine interne Funktion (wird also nicht im Header File deklariert), der Pointer auf diese Funktion wird allerdings als Callback beim Subscribe übergeben damit der Event dem Modul zugestellt werden kann.

=== Module ===
Im folgenden sind alle Module und deren Hauptfunktionen aufgelistet.

==== Analog ====
analog.c
analog.h
Dieser Modul ist abgeleitet von den gleichnamigen Dateien der original NIBObee Bibliothek. Dies war notwendig da wir zusätzliche Liniensensoren verwenden und deren Ansteuerung in gleicher Weise erfolgen sollte. Das bedeutet dass für die entsprechenden Analogeingänge Messungen mit ein- und ausgeschalteten IR-LEDs durchgeführt werden müssen. Außerdem wurde, entsprechend dem Datenblatt des ATMega16 die Behandlung der Messung der Batteriespannung verbessert. Da hier die referenzspannung umgeschalten wird muss eine Messung verworfen werden bevor mit einem richtigen Ergebnis gerechnet werden kann. Das wurde in der Originalbibliothek nicht berücksichtigt.

=== Applikationen ===
==== Labyrinth erkunden ====

==== Kürzesten Weg durch Labyrinth ====

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-05-02T08:58:40Z

Alois: /* Aufgaben */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|...
|-
|...
|...
|...
|-
|...
|...
|...
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
line.h
Die Werte der Liniensensoren können mit der Funktion
<code>line_get(index)</code>
gelesen werden. Die Werte selbst werden über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt 11 analoge Werte die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von 120 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 94 µs aktualisiert wird.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

== Hardware ==

=== Bluetooth ===
Der Bluetooth Modul ist im Detail auf den Seiten des [[BTM-222]] beschrieben.

=== Liniensensoren ===
Zum Erkennen der Kreuzungen bei gleichzeitigem folgen der Linie war es notwendig zusätzliche Liniensensoren zu verwenden. Diese wurden mit einer Zusätzplatine in einer Reihe mit den bereits vorhandenen Liniensensoren, allerdings so weit wie möglich linke und rechts außen, montiert. Das einlesen der Analogwerte erfolgt über die beiden Analogeingänge am Stecker X1. Die IR-LEDs sind, analog zu den bestehenden IR-LEDs der vorhandenen Liniensensoren, über den Ausgang 1 am Stecker X4 schaltbar. Dies ist notwendig da jeweils eine Messung mit eingschalteter LED und eine mit ausgeschalteter LED durchgeführt wird. Damit wird der Einfluß des Umgebungslichts korrigiert.

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt ausschließlich über Events. Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 2 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. lesen der Liniensensoren). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird nicht direkt vom Scheduler aufgerufen sondern über die Funktion <xx>_eventHandler. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; eine Funktion mit dem Namen <xx>_eventHandler (extern)
: Ist die Funktion die vom Scheduler aufgerufen wird damit die Statemaschine mit dem aktuellen Event, sofern vorhanden, durchlaufen wird.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.
; eine Funktion mit dem Namen <xx>_receiveEvent (intern)
: ReceiveEvent ist eigentlich eine interne Funktion (wird also nicht im Header File deklariert), der Pointer auf diese Funktion wird allerdings als Callback beim Subscribe übergeben damit der Event dem Modul zugestellt werden kann.

=== Applikationen ===
==== Labyrinth erkunden ====

==== Kürzesten Weg durch Labyrinth ====

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

NIBObee

2011-05-02T08:50:35Z

Alois: /* Resourcen */

NIBObee ist der Roboter der im Projekt [[RoLoMa]] verwendet wird.
== Technische Daten ==
{| class="wikitable"
|-
!Art
!Typ
!Bemerkung
|-
|rowspan="3"|Mikrocontroller
|ATMEL ATMega16, , 15 MHz
|rowspan="3"|Integrierter UART wird verwendet um den Bluetooth Modul anzubinden.

Sollte die Leistung nicht ausreichen kann entweder der Erweiterungssatz von Nicai-Systems verwendet werden oder nur der Controller wird gegen einen Pinkompatiblen Typ ausgetauscht (z.B. ATMega32, ATMega644, ATMega1284)
|-
|Flash: 16 kB
|-
|...
|-
|...
|...
|...
|-
|...
|...
|...
|-
|rowspan="3"|Maße
|Radumfang: 11,8 cm
|rowspan="3"|Diese Maße sind wichtig um den NIBObee so exakt wie möglich am Mittelpunkt des Labyrinthfeldes positionieren zu können.
|-
|Abstand Liniensensor zu Radachse: 10,4 cm
|-
|Impulse pro Umdrehung: 20
|}
=== Ports ===
Über den UART wird der Bluetooth Modul [[BTM-222]] angebunden. Am NIObee ist diese Schnittstelle am Port X5 verfügbar

=== Resourcen ===
Folgende Resourcen werden für unsere Implementierung verwendet (''kursiv'' markierte Resourcen werden bereits durch die Bibliothek belegt):

{| class="wikitable"
|-
!Resource
!Verwendung
!Interrupts
!Dateien
|-
|Timer 1
|Motor PWM
|TIMER1_COMPA_vect, TIMER1_COMPB_vect
|motpwm.c
|-
|ADC
|Analog, Line
|ADC_vect
|analog.c, line.c
|-
|EEPROM
|Line (12 Byte)
|
|line.c
|-
|Ext. IRQ
|Odometrie
|INT0_vect, INT1_vect
|odometry.c
|}

Eine für den NIBObee allgemein gültige Auflistung findet man im [http://www.nibo-roboter.de/wiki/NIBObee/Lib/Resourcen NIBObee Wiki].

=== Besondere Erkenntnisse ===
Es hat sich, nach einigen Fehlschlägen bei der Linienverfolung, herausgestellt dass es ungünstig ist den NIBObee in eine optisch ansprechende waagrechte Position zu bringen indem eine kleinere Halbkugel auf der Unterseite angebracht wird. Der Grund: Nur mit der original Halbkugel und dem damit nach vorne ansteigenden Bodenabstand sind die IR-LED's weit genug vom Boden entfernt um einen Lichtkegen zu erzeugen der auch vernünftig vom Phototransistor erfasst werden kann. Bei waagrechter Ausrichtung des NIBObee ist dieser Kegel, aufgrund des geringeren Abstands zum Boden, zu klein!

=== Bibliotheksfunktionen ===
==== Liniensensoren ====
line.h
Die Werte der Liniensensoren können mit der Funktion
<code>line_get(index)</code>
gelesen werden. Die Werte selbst werden über einen A/D-Wandler ermittelt und zwischengespeichert. Es gibt 11 analoge Werte die zyklisch digitalisiert werden. Dieser Vorgang wird mit einer Frequenz von 120 kHz durchgeführt, d.h. dass jeder dieser Werte ca. alle 94 µs aktualisiert wird.

==== Motorensteuerung ====
motpwm.h
Die Motoren des NIBObee werden mit PWM ([http://de.wikipedia.org/wiki/Pulsweitenmodulation Pulsweitenmodulation]) angesteuert. Das garantiert natürlich ohne Regelung noch keinen gleichlauf der beiden Motoren was sich je nach Zustand des Getriebes in einer weiteren oder engernen Kurve zeigt.
motpid.h
Hier stehen Funktionen zur Verfügung die mit Hilfe der Odometrie die Motoren regeln. Diese Funktionen sind für unsere Zwecke allerdings nicht geeignet.

== Aufgaben ==
Folgende Aufgaben sind im Rahmen des Projekts [[RoLoMa]] vom NIBObee Team zu lösen:
* Herstellung der Bluetooth Hardware-Erweiterung
* Softwaremodul zum Bedienen der Bluetooth-Schnittstelle via RS232
* Softwaremodul zum Erkennen der Linie im Labyrinth und im speziellen der unterschiedlichen Kreuzungstypen
* Messen des zurückgelegten Weges
* Steuerung, die den Abstand des Sensors zur Radachse berücksichtigt um den Roboter an der korrekten Stelle um die eigene Achse zu drehen
* Erstellen eines Abbilds des Labyrinths im Speicher und navigieren bis der Roboter wieder am Startpunkt gelandet ist (z.B. immer Links abbiegen)
* Implementieren des [[MaDeCo]] Protokolls

== Software ==
Die Aufgaben der Software sollen in möglichst unabhängigen Modulen realisiert werden um das Testen einfacher zu gestalten. Die einzelnen Module sind im Folgenden beschrieben.

=== Architektur ===
Das Gesamtsystem besteht aus einem zentralen Taktgeber, einem Scheduler und mehreren State Maschinen. Die Kommunikation erfolgt ausschließlich über Events. Die Module können mittels Subscribe einen Event, den ein anderer Modul zur Verfügung steht, abonnieren.

==== Systemtakt, Scheduler ====
Im Main Modul befindet sich der zentrale Taktgeber der aus dem Interrupt des Timer 2 einen gleichmäßigen Takt von 100Hz erzeugt. Dieser Takt kann von anderen Modulen verwendet werden um zyklische Aufgaben zu erfüllen (z.B. lesen der Liniensensoren). Im Main Modul befindet sich auch der Scheduler der ganz einfach in der Endlosschleife sequenziell jeden Modul aufruft um anstehende Events zu bearbeiten.

==== State / Event Maschinen ====
Die State / Event Maschinen sind in allen Modulen gleich aufgebaut. Es gibt die folgenden Funktionen (wobei statt "<xx>" das Kürzel des Moduls steht, z.B "dr" für Drive):
; eine Funktion mit dem Namen <xx>_main (intern)
: Das ist die eigentliche State Maschine. Wird nicht direkt vom Scheduler aufgerufen sondern über die Funktion <xx>_eventHandler. Hier gibt es ein switch Statement über den aktuellen Zustand und für jeden Zustand ein switch Statement über den empfangenen Event.
; eine Funktion mit dem Namen <xx>_init (extern)
: Hier werden Variableninitialisierungen gemacht und die ersten subscribe Aufrufe um Events zu abonnieren. Diese Funktion wird beim Systemstart vom Main Modul aufgerufen.
; eine Funktion mit dem Namen <xx>_eventHandler (extern)
: Ist die Funktion die vom Scheduler aufgerufen wird damit die Statemaschine mit dem aktuellen Event, sofern vorhanden, durchlaufen wird.
; optional Funktionen mit den Namen <xx>_subscribe_<event> und <xx>_unsubscribe_<event> (extern)
: für jeden Event den dieser Modul verschicken kann ist sowohl eine Subscribe Funktion als auch ein Unsubscribe Funktion vorhanden. Mit diesen Funktionen kann der Event von einem anderen Modul abboniert werden.
; eine Funktion mit dem Namen <xx>_receiveEvent (intern)
: ReceiveEvent ist eigentlich eine interne Funktion (wird also nicht im Header File deklariert), der Pointer auf diese Funktion wird allerdings als Callback beim Subscribe übergeben damit der Event dem Modul zugestellt werden kann.

=== Applikationen ===
==== Labyrinth erkunden ====

==== Kürzesten Weg durch Labyrinth ====

==== Kalibrierung ====
Zur Kalibrierung fährt der NIBObee ein Viereck entlang dass genau die Seitenlänge eines der Felder des Labyrinths hat. Dies ist notwendig um relativ einfach die Karte des Labyrinths erstellen zu können.

=== Protokolle und deren Implementierung ===
==== [[MaDeCo]] ====
===== Interface Definition =====
* int set_opmode(OPMODE)
* int send_waypoint(WAYPOINT)
* int direct(DIRECTION[])
* int ack()

==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====
* pairing
* Konfigurations-Commands
* ack
* read_command
* send_command

=== Steuerungssoftware ===
==== Bluetooth Modul einschalten ====
Durch Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird das Bluetooth Modul eingeschalten.
Daraufhin muss auf eingehenden Bluetooth Traffic gelauscht werden.

==== Blink Codes ====
Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der Status LEDs aus.
'''TODO:''' Spezifikation der Blink Codes

==== Gerade fahren ====
Das Problem beim geradeaus fahren ist dass der Roboter von der Spur abweichen kann und dann neu ausgerichtet werden muss. Üblicherweise erfolgt das mit Hilfe der Liniensensoren indem, sobald einer der seitlichen Sensoren die Linie erkennt, durch beschleunigen oder bremsen eines Rades in diese Richtung korrigierend gelenkt wird.

In unserem Fall müssen wir diese Korrektur solange verzögern bis der seitliche Liniensensor eine mögliche Kreuzung passiert hat. Erst danach können wir feststellen ob wir nur die schwarze Linie einer Kreuzung überfahren sind oder ob tatsächlich eine Abweichung vorliegt. Die Anzahl der zu ignorierenden Odometrie-Impule kann folgendermaßen errechnet werden:

<Impulse pro Radumdrehung> / <Radumfang> * <Linienbreite> =
20 / 11,8 * 1 = 1,69491525

Wir werden also nur zwei Impulse abwarten bevor wir mit der Korrektur beginnen

===== Funktionsaufteilung =====
Die Zuständigkeiten für diese Aufgabe sind wie folgt:
;drive Modul
:sorgt für die Steuerung der Motoren. Reduzieren der Geschwindigkeit eines Rades um eine ausgleichende Kurve zu fahren und stoppen wenn das Ende der geraden Linie erreicht wurde. Dazu aboniert der Modul die Events des line Modul die eine Abweichung von der Linie melden und vom distance Modul den Event zum fahren der Distanz zwischen Liniensensoren und Achse der Räder.
;line Modul
:prüft zyklisch die position der Linie unter dem NIBObee und meldet Abweichungen mittels Events. Dieses Melden wird allerdings verzögert bis zumindest die Breite der Linie überfahren wurde. Dazu aboniert der Modul den Event vom distance Modul den Event zum fahren der der Breite der Linie.
;distance Modul
:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder oder der Breite der Linie.

==== Kreuzung fahren ====
An einer Kreuzung wird abgebogen indem der NIBObee zuerst unbeirrt geradeaus fährt bis die Achse genau auf dem Mittelpunkt der Kreuzung zu stehen kommt. Danach wird eine Drehung nach rechts oder links durchgeführt bis sich die Linie wieder genau unter dem mittleren Sensor befindet.

Die Sensoren sind von der Achse 10,4 cm entfernt, eine Radumdrehung bewegt den NIBObee um 11,8 cm weiter und bei dieser Umdrehung werden vom Odometriesensor 20 Impulse abgegeben. Die Linienbreite wird 2 cm betragen. Daher errechnet sich die Strecke die nach Erkennen der Kreuzung gefahren werden muss folgendermassen:

<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
20 / 11,8 * (10,4 - 0,5) = 16,779661

Nach passieren der Kreuzung muss der NIBObee also noch 17 Impulse über den Odometriesensor empfangen bevor er stoppt.

== Risikoanalyse ==
Im Folgenden wird versucht für die möglichen Risikopunkte Alternativen aufzuzeigen.

; ATmega16 ist nicht Leisungsfägig genug
: Es kann auf den [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html Tuning-Kit von Nicai-Systems] zurückgerifffen werden. Dies könnte eine nicht akzeptable Verzögerung verursachen (erkennen, bestellen, NIBObee umrüsten)

: Ein beliebiger PIN-kompatiber Microcontroller ATmega... wird statt dem ATmega16 eingesetzt. Die funktioniert soange der Ersatz-µC mit der Frequenz vom 15 MHz betrieben werden kann. Wichtig ist auch dass es adaptierte Bibliotheken gibt die auf den Ersatz-µC abgestimmt sind (z.B. andere Register oder geänderte Adressen für Register, ...)

; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
: Die Signale am UART werden mit Bordspannung erzeugt/erwartet. Für die Kommunikation mit dem BT-Modul ist daher keine Anpassung durchzuführen.

: Soll zu Testzwecken ein PC über RS232 angeschalten werden ist unbedingt auf die Spannung achten. Möglicherweise verwendet ein USB-RS232 Adapter nicht die 12V sonder nur 5V.

== Open Issues ==
* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.
* Wie kann das verlassen der Spur von dem Überfahren einer Kreuzung unterschieden werden? Wenn es hier zu Problemen kommt könnten zwei zusätzliche lichtempfindliche Sensoren rechts und links oder noch ein Element mit drei zusätzlichen Sensoren auf Höhe der Achsen angebracht werden -> Mehraufwand!
* Soll Aktivierung der BT-Schnittstelle manuell erfolgen?
* Soll der Betriebsmodus gewählt werden können?

== Links ==
* [http://www.nicai-systems.de/nibobee.html NIBObee Homepage bei Nicai Systems]
* [http://download.nicai-systems.com/nibo/Tutorial_NIBObee_20091123.pdf NIBObee - Tutorial zur Programmierung]
* [http://www.nicai-systems.com/de/zubehoer/nibobee-tuning-kit.html NIBObee - Tuning-Kit von Nicai-Systems]
* [http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Der_UART Tutorial zur USART Programmierung]
[[Kategorie:FH]]

RoLoMa

2011-05-02T06:36:13Z

Alois: /* Projektfortschritt */

RoLoMa ist der, vielleicht wenig einfallsreiche, Name des ESE-Projekts im 4. Semester. Es ist die Abkürzung für "Robots Lost in Maze".
== Projektbeschreibung ==
=== Aufgabe ===
Bei diesem Projekt soll ein autonomer Roboter ein Labyrinth analysieren, alle vorhandenen Abzweigungen protokollieren und diese Daten an eine zentrale Einheit senden. Die zentrale Einheit soll einen zweiten autonomen Roboter mit diesen Daten auf dem berechneten kürzesten Weg durch das Labyrinth lotsen können. Dazu muss eine Kommunikation zwischen dem Roboter und der zentralen Einheit hergestellt werden.
Die oben erwähnte zentrale Einheit wird im weiteren Dokument als „Board“ bezeichnet und der autonome Roboter, aufgrund des gewählten Produkts „[[NIBObee]]“.
=== Details ===
[[File:ExampleMaze.png|thumb|120px|Beispiellabyrinth]]
Das Labyrinth wird eine Matrix mit vordefinierter Größe sein (z.B. 8x8) bei dem die möglichen Wege als schwarze Linie dargestellt sind. Auf dieser Linie wird sich der [[NIBObee]] bewegen. Die Aufgabe des ersten [[NIBObee]] besteht nun darin das gesamt Labyrinth abzufahren und eine Karte zu erstellen.

Diese gesammelte Information wird dann an das Board übertragen. Dort wird das Labyrinth auf einer grafischen Ausgabe dargestellt und der Benutzer kann einen beliebigen Zielpunkt für den zweiten [[NIBObee]] festlegen. Der optimale Weg wird berechnet und der zweite [[NIBObee]] über diesen Weg an das definierte Ziel geleitet.


 

=== Aufgabenteilung ===
An dem Projekt sind zwei Gruppen beteiligt, eine die sich um die Roboter kümmert (Gruppe NIBObee), eine zweite die die Implementierung der zentralen Einheit (Gruppe Board) vornimmt. Gemeinsam muss die Übertragungstechnik (Hardware und Protokoll) erarbeitet werden. Die Implementierung kann dann getrennt erfolgen und am Ende des Projekts ist eine gemeinsame Testphase notwendig.

Da noch einige Festlegungen bezüglich der verwendeten Hardware und der Übertragungstechnik ausständig sind können sich im Zuge des weiteren Projektfortschritts durchaus noch Änderungen ergeben. Für alle kritischen Elemente wird so früh wie möglich auch eine alternative Lösung als Fallback vorgesehen. Das ist notwendig für den Fall, dass sich für ein Problem keine, zumindest im Rahmen dieses Semesters, realisierbare Implementierung ergibt.

==== Team Board ====
Teammitglieder dieser Gruppe sind:
* Michaela Escuyer
* Thomas Neuber
* Robert Pavljuk
==== Team NIBObee ====
Teammitglieder dieser Gruppe sind:
* Robert Peterfi
* Alois Pochmann
* Reinhard Weismann

== Realisierung ==

=== Plattformen / Hardware ===
Die Plattformen der Roboter und der Kontrolleinheit sind im Folgenden aufgelistet und stehen (wenn auch teilweise nur als Bausatz) fertig zur Verfügung. Die Hardware der Kommunikationseinrichtung wird im Zuge dieses Projekts erstellt.

==== Roboter ====
Der eingesetzte Roboter ist eine [[NIBObee]] von [http://www.nicai-systems.com/de/nibobee.html Nicai-Systems]. Dieser Roboter verfügt über einen Liniensensor der es prinzipiell ermöglicht einer kontrastreichen Linie, vorzugsweise schwarze Linie auf weißem Boden, zu folgen.

Weitere Dateils können der [[NIBObee]]-Seite entnommen werden.

==== Kontrolleinheit ====
Die Zentrale Kontrolleinheit wird auf dem vom 3. Semester bekannten [[LPC2478]] realisiert.

==== Kommunikation ====
Die Kommunikation der [[NIBObee]]-Roboter mit der zentralen Steuerung erfolgt über Bluetooth. Dazu wird über den auf beiden Plattformen bestehenden UART Anschluss ein Modul mit RS232-BT Umsetzung verwendet.
Die im Folgenden aufgelisteten Module kommen für die Umsetzung in Frage:
* BTM-112
* [[BTM-222]]
Die Entscheidung ist zugunsten des [[BTM-222]] gefallen. Details dazu können der [[BTM-222]]-Seite entnommen werden.

=== Software ===
Details zur Software sind auf den Seiten von [[NIBObee#Software|NIBObee]] und [[LPC2478#Software|LPC2478]] zu finden.

=== Protokolle ===
==== Bluetooth ====
Der gesamte Bluetooth Stack ist im [[BTM-222]] realsiert und muss daher im Projekt nicht betrachtet werden.
==== [[MaDeCo]] ====
Das projektspezifische Protokol zur Übertragung der Labyrinthdaten nach / bei der Erkundung und dann zu Steuerung durch das Labyrinth ('''Ma'''ze '''De'''tection and '''Co'''ntrol) ist zu definieren.

=== Testumgebung ===
==== Labyrinth ====
Wie schon in der Angabe zu sehen ist gelten für das Labyrinth einige Annahmen die als Voraussetzungen für die Implementierung festgelegt werden:
* Es gibt nur gerade Linien
* Alle Kreuzungen sind rechtwinkelig
* Alle Abstände sind genau ein Vielfaches der kürzesten Verbindung der Mittelpunkte zweier Felder
* Alle (nicht sichtbaren) Felder sind gleich groß
* Das gesamte Labyrinth entspricht einer Baumstruktur, d.h. es gibt niemals zwei paralelle Wege von einem Punkt zu einem Anderen, also keine geschlossenen Schleifen.
* Da die Steuerung ausschließlich über die Liniensensoren implementiert wird ist die Strecke kollisionsfrei zu halten, d.h. der [[NIBObee]] wird nicht auf Kontakt mit den Fühlern durch Ausweichmanöver reagieren.

==== Simulationen ====
Damit ein unabhängiges Testen der einzelnen Teile des Projekts möglich ist werden in einigen Bereichen Simulationen eingesetzt:
* Bluetooth-Verbindung kann mit einem PC und Terminalprogramm getestet werden
* [[MaDeCo]]-Protokoll wird textbasiert entworfen um mit einfachen Textfiles auf beiden Seiten testen zu können

== Projektfortschritt ==
Der Projektfortschritt wird im gleichen Intervall verfolgt in dem die Lehrveranstaltung abgehalten wird

{| class="wikitable"
|-
!Woche
!Block
!Tätigkeiten / Erkenntnisse
|-

|14.02.2011 - 20.02.2011
|Gemeinsam
|
* Projektdefinition: Festlegen des Projektinhalts und grobe Abstimmung der einzelnen beteiligten Komponenten.
* Erstellung eines Dokuments zur Projektbeschreibung
* Erstellen eines Projektplans

|-

|colspan="3"|'''Projekt akzeptiert -> Projektstart'''
|-

|rowspan="3"|21.02.2011 - 27.02.2011
|Gemeinsam
|
* Bestellungen besprochen.
* Wiki eingerichtet.
* Bestelliste für Bluetooth Module erstellt
** Auflistung siehe [[BTM-222#Hardware|BTM-222 Stückliste]]
* Gesamte Hardware bestellt:
** 2 NIBObee - Programmierbarer Roboter-Bausatz
** 5 x [[BTM-222#Hardware|BTM-222 Stückliste]] (3 x für das Nibobee und 2 x für das board) erstellt.

|-
|Board
|
* Display Erfahrungsberichte recherchiert.
* Grafik Konzept (Blöcke) besprochen
* Beispiel Implementierungen für Touchscreen und Grafik von [[LPC2478|LPC 2478]] gesucht

|-
|NIBObee
|
* Bestellungen besprochen.
* nach Bauanleitungen und Datenblätter recherchiert.
* Printlayout des BT-Modul für NIBObee erstellt
* Recherche der BTM-222 Konfigurationsmöglichkeiten.
* Sammeln offener Punkte, auflisten von Risiken und möglicher Massnahmen

|-

|rowspan="3"|28.02.2011 - 06.03.2011
|Gemeinsam
|
* Definition des proprietären Kommunikationsprotokolls [[MaDeCo| MaDeCo ('''Ma'''ze '''De'''tection and '''Co'''ntrol)]]

|-
|Board
|
* Weitere Analyse für Touchscreen und Grafikausgabe
* Demo Implementierung von Hr. Kramer angefordert und eingelesen
* Sourcen Demo Projekt in Eclipse Ganymed geladen und Debug Optionen ergänzt
* Debuggingversuche, Ursachensuche für fehlende Anzeige

|-
|NIBObee
|
* Bestellung eingetroffen. Zusammenbau der Roboter durchgeführt
* Detailabsprache der benötigten Roboterfunktionen
* Analyse der Probleme beim Befahren des Labyrinths und Abbildung auf notwendige Funktionen.

|-

|rowspan="3"|7.3.2011-13.3.2011
|Gemeinsam
|
* Recherche Ergebnisse besprochen
* Bauteile für Bluetooth Modul sind teilweise nicht optimal (vor allem wegen der Größe). Es werden noch Alternativen gesucht und das Layout und der Bestückungspan wurden geändert.

|-
|Board
|
* Mehrstündiger Versuch, das Display mit Demo Applikationen zu testen
* daraus resultierende Tests haben ergeben dass das Display defekt war. Das Board wurde gegen ein neues getauscht
* neuerliche Inbetriebnahme mit Demo Applikationen

|-
|NIBObee
|
* Installation der Entwicklungsumbegung
* Testen der Beispielprogramme
* Kalibrierung der Liniensensoren
* Erstellen eines Testprogramms für die Liniensensoren um die optimale Linienbreite für das Labyrinth ermitteln zu können (2 cm scheint zu breit, Kontrastwert nicht über 128).

|-

|rowspan="3"|14.3.2011-20.3.2011
|Gemeinsam
|
* Besprechung der jeweiligen Ergebnisse
* neue Bestückungsliste besprechen und fehlende Teile organisieren

|-
|Board
|
* weitere Recherche nach lauffähigen Demoapplikationen
* Für speziell dieses Board frustrierend wenige bis keine Ergebnisse

|-
|NIBObee
|
* Versuche mit zwei unterschiedlichen Ansätzen des Geradeauslaufs des NIBObee:
** Korrektur mittles Regelkreis unter Berücksichtigung der Odometriesensoren
** Korrektur nur mttels der Werte von den Liniensensoren
* Obwohl der Regelkreis eine gradeausfahrt auch ohne Linie schafft ist der Start problematisch und daher für unsere Zwecke ungeeignet

|-

|rowspan="3"|21.3.2011-27.3.2011
|Gemeinsam
|
* gegenseitiges Update
* fast alle Bauteile eingetroffen bzw. vorhanden, Ausnahme: Printplatte
** voraussichtlicher Liefertermin der Printplatte kommende Woche

|-
|Board
|
* vergebliche Versuche, den UART in Betrieb zu nehmen
* gemeinsam mit Hrn. Wenzl nochmals versucht, auch ergebnislos
* Entschluss, das Vorgehen zu ändern
* neues Projekt auf Basis Interrupt Template vom 3. Semester
* Anpassung auf unsere Umgebung

|-
|NIBObee
|
* Implementierung gestartet mit folgenden Funktionen:
* Systemtimer mit 100Hz Taktfrequenz
* Statemachine für folgende Module:
** Drive, zuständig für das fahren entlang der Linie des Labyrinths
** Sensor, zuständig für die Fühler. Entprellen und melden von Änderungen.
** Line, zuständig für das erkennen der Linie und melden von Abweichungen
* Scheduler, der alle Module die einen Event bearbeiten müssen aufruft.

|-

|rowspan="3"|28.3.2011-3.4.2011
|Gemeinsam
|
*Leiterplatten eingetroffen, Beginn des Aufbaus der Bluetooth Module

|-
|Board
|

|-
|NIBObee
|
*Implementieren der Linienverfolgung mit den Statemachines
*Neuer Modul für Distanzmessung. Wurde von der Implementierung der Odometrie-Bibliothek abgeleitet.
*Erfolgreiches Ausrichten des NIBObee im Zentrum eines Felds des Labyrinths
*Probleme beim Unterscheiden von Spurabweichung und Kreuzung. Kann mit den vorhandenen Sensoren nicht gelöst werden. Es wird eine Erweiterung des NIBObee geplant.

|-

|rowspan="3"|4.4.2011-10.4.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Fertigstellen des ersten Bluetooth Moduls
*Verbindung von NIBObee mit PC hergestellt
*Neue Funktionen zur Kommunikation. Senden und Empfangen mittels Interrupts implementiert
*Start Implementierung der State Maschine für das MaDeCo Protokoll
*Debug Möglichkeit mittels BT-Verbindung zum PC implementiert
*PC Testapplikation für die Bluetooth Verbindung mit spezieller Unterstützung des MaDeCo Protokolls implementiert.
*Erzeugen von DoxyGen Dokumentation

|-

|rowspan="3"|11.4.2011-1.5.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|
*Überarbeiten des Event-Machanismus
*Optimieren der Debug-Protokollierung über Bluetooth. Strings belegten zu viel Speicher. Das führte zu undefinierbarem Verhalten wegen Überschreiben von Stack und Daten.
*Erweitern der PC Applikation zum bedienen der NIBObee BT-Schnittstelle. Die optimierte Debug-Ausgabe kann auf Basis von speziellen Kommentaren der NIBObee-Source (debug.h) symbolisch aufbereitet werden.
*Erweiterung mit zusätliche Liniensensoren angefertigt
*Wegen zusätzlicher Liniensensoren neue Applikation zum Kalibrieren der Liniensensoren (jetzt 5 Sück) erstellt.
*Wegen zusätzlicher Liniensensoren ersetzen des original Moduls zum Einlesen der Analogwerte.
*Wegen zusätzlicher Liniensensoren ersetzen des original Moduls zum ermitteln der Werte der Liniensensoren.
*Kreuzungserkennung und Linienverfolgung funktionieren nun parallel, NIBObee fährt kleines Testlabyrinth gezielt ab.

|-

|rowspan="3"|2.5.2011-8.5.2011
|Gemeinsam
|

|-
|Board
|

|-
|NIBObee
|

|-

|}

[[Kategorie:FH]]