NIBObee - Versionsgeschichte

Alois am 26. Juni 2011 um 18:50 Uhr

2011-06-26T18:50:29Z

← Nächstältere Version		Version vom 26. Juni 2011, 18:50 Uhr
Zeile 291:		Zeile 291:
	=== Steuerungssoftware ===		=== Steuerungssoftware ===
	==== Bluetooth Modul einschalten ====		==== Bluetooth Modul einschalten ====
	~~Durch~~ Bewegen der "Fühler" der NIBObee nach oben bis Einrasten wird ~~das~~ Bluetooth Modul ~~eingeschalten.~~		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.
	~~Daraufhin~~ muss auf eingehenden Bluetooth Traffic gelauscht werden.

	==== Blink Codes ====		==== Blink Codes ====
	~~Bestimmte Events oder Commands lösen bestimmte Blink- oder Leuchtmuster der~~ Status LEDs ~~aus~~.		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:
	~~'''TODO:''' Spezifikation~~ der ~~Blink Codes~~		* Überschneidender Aufruf der Timerinterrupt Behandlungsroutine (nested Interrupt)
			* Overflow des Empfangsbuffers für Bluetooth-Verbindung

	==== Gerade fahren ====		==== 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.		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:~~		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.

	~~<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 =====		===== Funktionsaufteilung =====
	Die Zuständigkeiten für diese Aufgabe sind wie folgt:		Die Zuständigkeiten für diese Aufgabe sind wie folgt:
	;drive Modul		;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.		: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		;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~~.		: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		;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~~.		:meldet auf Anforderung das zurücklegen einer Strecke in der Länge der Distanz zwischen Liniensensoren und Achse der Räder.

	==== Kreuzung fahren ====		==== 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.		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:		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>) =		<Impulse pro Radumdrehung> / <Radumfang> * (<Achsabstand> - <halbe Linienbreite>) =
Zeile 334:		Zeile 329:

	: 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, ...)		: 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)		; Signale am UART mit Bordspannung im Gegensatz zu RS232-Level (12V)
Zeile 339:		Zeile 336:

	: 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.		: 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 ==		== Open Issues ==
	* Es muss noch überprüft werden ob die NIBObee Hardware ausreichend leistungsfähig ist oder ein Upgrade gemacht werden muss.		* 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!		** 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?		* 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?		* Soll der Betriebsmodus gewählt werden können?
			** Der Betriebsmodus wird vom Board per [[MaDeCo]] Kommando ausgewählt

	== Links ==		== Links ==

Alois: /* Protokolle und deren Implementierung */

2011-06-25T08:09:33Z

Protokolle und deren Implementierung

← Nächstältere Version		Version vom 25. Juni 2011, 08:09 Uhr
Zeile 278:		Zeile 278:
	Neben der State Machine die per Event kommuniziert ist auch noch ein Funktionsinterface vorhanden		Neben der State Machine die per Event kommuniziert ist auch noch ein Funktionsinterface vorhanden
	===== Message Interface Definition =====		===== Message Interface Definition =====
	~~Das Bild zeigt die State Machine des MaDeCo Moduls mit den unterstützten Events~~		* Empfang der Kommandos vom Bluetooth Modul
			* Start/Ende and Drive Modul
			* Status und Ende vom Drive Modul
	===== Function Interface Definition =====		===== Function Interface Definition =====
	;void ma_sendWap(uint8_t direction, uint8_t length);		* void ma_sendWap(uint8_t direction, uint8_t length);
	:Senden eines Wegpunktes an das Board direkt vom Drive Modul		** Senden eines Wegpunktes an das Board direkt vom Drive Modul

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

	=== Steuerungssoftware ===		=== Steuerungssoftware ===

Alois: /* MaDeCo */

2011-06-25T08:04:29Z

MaDeCo

← Nächstältere Version		Version vom 25. Juni 2011, 08:04 Uhr
Zeile 276:		Zeile 276:
	=== Protokolle und deren Implementierung ===		=== Protokolle und deren Implementierung ===
	==== [[MaDeCo]] ====		==== [[MaDeCo]] ====
	===== Interface Definition =====		Neben der State Machine die per Event kommuniziert ist auch noch ein Funktionsinterface vorhanden
	* int set_opmode(OPMODE)		===== Message Interface Definition =====
	* int send_waypoint(WAYPOINT)		Das Bild zeigt die State Machine des MaDeCo Moduls mit den unterstützten Events
	* int direct(~~DIRECTION[]~~)		===== Function Interface Definition =====
	* int ack()		;void ma_sendWap(uint8_t direction, uint8_t length);
			:Senden eines Wegpunktes an das Board direkt vom Drive Modul

	==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====		==== Schnittstelle [[MaDeCo]] - RS232-Schnittstelle ====

Alois: /* Kalibrierung */

2011-06-25T07:55:49Z

Kalibrierung

← Nächstältere Version		Version vom 25. Juni 2011, 07:55 Uhr
Zeile 272:		Zeile 272:

	==== Kalibrierung ====		==== 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.		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 ===		=== Protokolle und deren Implementierung ===

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

2011-06-25T07:52:59Z

Kürzesten Weg durch Labyrinth

← Nächstältere Version		Version vom 25. Juni 2011, 07:52 Uhr
Zeile 269:		Zeile 269:

	==== Kürzesten Weg durch Labyrinth ====		==== 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.		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 ====		==== Kalibrierung ====

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

2011-06-25T07:52:38Z

Kürzesten Weg durch Labyrinth

← Nächstältere Version		Version vom 25. Juni 2011, 07:52 Uhr
Zeile 269:		Zeile 269:

	==== Kürzesten Weg durch Labyrinth ====		==== 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 ====		==== Kalibrierung ====

Alois: /* Labyrinth erkunden */

2011-06-25T07:49:44Z

Labyrinth erkunden

← Nächstältere Version		Version vom 25. Juni 2011, 07:49 Uhr
Zeile 266:		Zeile 266:
	=== Applikationen ===		=== Applikationen ===
	==== Labyrinth erkunden ====		==== 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 ====		==== Kürzesten Weg durch Labyrinth ====

Alois: /* Analog-Modul */

2011-06-25T07:40:44Z

Analog-Modul

← Nächstältere Version		Version vom 25. Juni 2011, 07:40 Uhr
Zeile 211:		Zeile 211:
	Dateien: analog.c		Dateien: analog.c
	analog.h		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.		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.		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.

Alois: /* Architektur */

2011-06-24T23:00:32Z

Architektur

← Nächstältere Version		Version vom 24. Juni 2011, 23:00 Uhr
Zeile 190:		Zeile 190:

	=== Architektur ===		=== 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.		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 ====		==== 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.		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 ====		==== 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):		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)		; 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.		: 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)		; 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.		: Hier werden Variableninitialisierungen gemacht und eventuell 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)		; 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.		: 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.
	~~; 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 ===		=== Module ===

Alois: /* Liniensensoren */

2011-06-24T22:53:21Z

Liniensensoren

← Nächstältere Version		Version vom 24. Juni 2011, 22:53 Uhr
Zeile 184:		Zeile 184:

	=== Liniensensoren ===		=== 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.		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 ==		== Software ==