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

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

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