NIBObee

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:

Art	Typ	Bemerkung
Mikrocontroller	ATMEL ATMega16, , 15 MHz	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
Maße	Radumfang: 11,8 cm	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):

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 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 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 (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:

Dokumentation
	Projektfortschritt, Controlling	Robert Peterfi
	Hardware, Software (Wiki)	Alois Pochmann, Reinhard Weismann
	Codedokumentation	Robert Peterfi, Alois Pochmann, Reinhard Weismann
Hardware
	Entwurf, Design	Alois Pochmann
	Bestellung, Aufbau	Robert Peterfi, Alois Pochmann
	Test	Robert Peterfi, Alois Pochmann, Reinhard Weismann
Software
	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 ln_get(index) gelesen werden. Die Werte selbst werden über den 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

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

• NIBObee Homepage bei Nicai Systems
• NIBObee - Tutorial zur Programmierung
• NIBObee - Tuning-Kit von Nicai-Systems
• Tutorial zur USART Programmierung