1. BACHELORARBEIT
AM LEHRSTUHL FÜR INTEGRIERTE SYSTEME
An Embedded System for
Adaptive Cruise Control
Technische Universität München
Lehrstuhl für Integrierte Systeme
Univ.-Prof. Dr. sc.techn. Andreas Herkersdorf
Diplomand: Benjamin Gatscher
Fachbereich: Elektrotechnik und Informationstechnik
Fachrichtung: Integrierte Systeme
Betreuer: M.Sc. Zhonglei Wang
Abgabedatum: 11.04.2008

2. Erklärung
Erklärung
Hiermit versichere ich, dass die vorliegende Bachelorarbeit mit dem Thema „An
Embedded System for Adaptive Cruise Control“ selbständig und ohne fremde
Hilfe verfasst wurde und keine anderen als die angegeben Hilfsmittel verwendet
wurden.
München, im April 2008
Benjamin Gatscher
-2-

3. Danksagung
Danksagung
Ich danke Herrn Prof. Herkersdorf, dass ich diese Arbeit an seinem Lehrstuhl
anfertigen durfte und dabei die vom Lehrstuhl bereitgestellten Materialien und
Geräte benutzen konnte. Ebenfalls möchte ich mich bei meinem Betreuer
Zhonglei Wang für die äußerst nette und fachlich sehr kompetente Betreuung
bedanken. Außerdem geht mein Dank an Jörg Wunsch, der mir neben der
Möglichkeit der professionellen Platinenfertigung auch zahlreichen Tipps und
Tricks zur Bearbeitung der Platine gegeben hat. Mein ganz besonderer Dank geht
an meine ganze Familie, speziell an meine größten Vorbilder, meine lieben
Eltern, die mich auf meinem Weg immer vorbehaltlos unterstützt und mir dieses
Studium erst ermöglicht haben.
-3-

4. Inhalt
Inhalt
ERKLÄRUNG 2
DANKSAGUNG 3
INHALT 4
KAPITEL I EINFÜHRUNG 7
I.1 MOTIVATION UND ZIELE DER ARBEIT 7
I.2 AUFBAU DER ARBEIT 8
KAPITEL II HARDWARE 9
II.1 GUMSTIX-MODULE 9
II.2 GESCHWINDIGKEITSSENSOR 10
II.2.1 AUSWAHL DER MESSMETHODE 10
II.2.2 GESCHWINDIGKEITSMESSUNG MITTELS GABELLICHTSCHRANKE UND
IMPULSGEBERSCHEIBE 10
II.3 ABSTANDSSENSOR 13
II.4 MIKROCONTROLLER 13
II.5 PLATINE 14
KAPITEL III SOFTWARE 16
III.1 ALLGEMEINE ERLÄUTERUNGEN 16
III.2 SOFTWARE DES SENSORSYSTEMS 16
III.2.1 PROGRAMMSTRUKTUR DER SENSORERFASSUNG 16
III.2.2 GESCHWINDIGKEITSMESSUNG 19
III.2.3 ABSTANDSMESSUNG 24
III.2.4 KOMMUNIKATION MIT DEM MASTERSYSTEM 26
III.3 SOFTWARE DES MASTERSYSTEMS 28
-4-

5. Inhalt
III.3.1 BERECHNUNG DER SENSORDATEN 29
III.3.2 ACC 31
KAPITEL IV COLA – THE COMPONENT LANGUAGE 37
IV.1 BESCHREIBUNG DER SPRACHE COLA 37
IV.2 MODELLIERUNG DES ACC-SYSTEMS IN COLA 38
IV.2.1 DIE UNIT „DISTANCE“ 39
IV.2.2 DIE UNIT „ACC“ 42
KAPITEL V ERGEBNISSE 46
V.1 GESCHWINDIGKEITSMESSUNG 46
V.2 DISTANZMESSUNG 47
V.3 TESTUMGEBUNG 47
V.4 AUTOMATISCH GENERIERTER QUELLCODE 48
KAPITEL VI ZUSAMMENFASSUNG UND AUSBLICK 49
ABBILDUNGSVERZEICHNIS 50
LITERATURVERZEICHNIS 52
ANHANG 1 SCHALTPLÄNE UND LAYOUTDATEIEN DER
MIKROCONTROLLER-PLATINE FEHLER! TEXTMARKE NICHT DEFINIERT.
A1.I SCHALTPLÄNE FEHLER! TEXTMARKE NICHT DEFINIERT.
A1.II LAYOUTDATEIEN FEHLER! TEXTMARKE NICHT DEFINIERT.
A1.III STÜCKLISTE FEHLER! TEXTMARKE NICHT DEFINIERT.
ANHANG 2 QUELLCODE DES MIKROCONTROLLER-PROGRAMMS (SENSOR-
SYSTEM) FEHLER! TEXTMARKE NICHT DEFINIERT.
A2.I ROUTINEN ZUR GESCHWINDIGKEITSMESSUNG FEHLER! TEXTMARKE NICHT
DEFINIERT.
-5-

6. Inhalt
A2.II ROUTINEN ZUR DISTANZ-ERFASSUNG FEHLER! TEXTMARKE NICHT DEFINIERT.
A2.III ÜBERTRAGUNGS-ROUTINE FEHLER! TEXTMARKE NICHT DEFINIERT.
A2.IV HAUPTPROGRAMM FEHLER! TEXTMARKE NICHT DEFINIERT.
ANHANG 3 COLA-GENERIERTER QUELLCODE DES ACC-SYSTEMS
(MASTER-SYSTEM) FEHLER! TEXTMARKE NICHT DEFINIERT.
A3.I ACC_SYSTEM.H FEHLER! TEXTMARKE NICHT DEFINIERT.
A3.II ACC_SYSTEM.C FEHLER! TEXTMARKE NICHT DEFINIERT.
ANHANG 4 QUELLCODE DER TESTUMGEBUNG UND DER MIDDLEWARE-
ROUTINE FEHLER! TEXTMARKE NICHT DEFINIERT.
-6-

7. Einführung
Kapitel I Einführung
I.1 Motivation und Ziele der Arbeit
Im Rahmen eines Fahrerassistenzsystems soll in dieser Arbeit ein System für
eine automatische Geschwindigkeits- und Abstandsregelung (Adaptive Cruise
Control - ACC) entwickelt werden. Befindet sich kein Objekt im Bereich vor dem
Fahrzeug, auch Fahrschlauch des Fahrzeugs genannt, wird eine einfache
Geschwindigkeitsregelung ausgeführt, d.h. eine vom Benutzer vorgegebene
Geschwindigkeit wird automatisch gehalten (Tempomatenfunktion). Befindet sich
jedoch ein Objekt im Fahrschlauch des Fahrzeugs, hat natürlich die Vermeidung
einer Gefahrensituation Priorität und es erfolgt dann eine Abstandsregelung, der
die Geschwindigkeitsregelung untergeordnet ist. Die Spezifikationen des ACC-
Systems sind in Abschnitt III.3.2.1 aufgeführt.
Das ACC-System soll als Teil einer Fallstudie in ein Modellauto integriert werden.
Mit dieser Fallstudie soll die Anwendbarkeit und der Nutzen der Sprache COLA
(The Component Language) demonstriert werden, mit der komplexe
Softwaresysteme modelliert werden können. Nach einer kurzen Einführung und
Erläuterung der Vorteile der Sprache COLA wird das ACC-System mit ihrer Hilfe
modelliert.
Das bisher bestehende Fahrerassistenzsystem, dessen Blockschaltbild in
Abbildung 1 dargestellt ist, verfügt noch über keine Geschwindigkeitsmessung.
Abbildung 1: Blockschaltbild des bestehenden Systems
-7-

8. Einführung
Die Hardware des Fahrerassistenzsystem ist jedoch bereits stark ausgelastet, so
dass für eine Implementierung der Geschwindigkeitsmessung neben der
Sensorik auch noch zusätzliche Hardware zur Sensorauswertung hinzugefügt
werden muss. Diese zusätzliche Hardware soll im Vergleich zu den relativ teuren
Gumstix-Modulen möglichst kostengünstig sein. Im Vergleich zu den recht
teuren Gumstix-Modulen ist der verwendete Mikrocontroller vom Typ ATMega der
Firma Atmel sehr preiswert und deshalb für diese Anwendung ideal geeignet.
Das um die Geschwindigkeitssensorik erweiterte Gesamtsystems zeigt Abbildung
2:
Abbildung 2: Blockschaltbild des erweiterten Systems
I.2 Aufbau der Arbeit
Diese Arbeit gliedert sich im wesentlichen in vier Teile. Zuerst soll der
hardwareseitige Aufbau des Systems beschrieben werden, im zweiten Teil wird
dann auf die Implementierung der Software eingegangen. Anschließend wird die
Sprache COLA zur Modellierung komplexer Softwaresysteme kurz vorgestellt und
das ACC-System mit ihrer Hilfe modelliert. Im abschließenden vierten Teil
werden Ergebnisse und aufgetretene Probleme erläutert.
-8-

9. Hardware
Kapitel II Hardware
II.1 Gumstix-Module
Bei den Gumstix-Modulen handelt es sich um leistungsstarke Mini-Computer. Die
Größe des Motherboards eines Gumstix-Moduls beträgt 80mm x 20mm x 6.3mm
und ist damit von der Größe her mit einem Streifen Kaugummi vergleichbar.
Daher auch der Name Gumstix. Über Erweiterungsmodule wird die
Kommunikation mit Peripheriegeräten ermöglicht. Angeboten werden u.a.
Erweiterungsmodule für die Kommunikation via Bluetooth, Ethernet und USB.
Die Gumstix-Boards sind mit XScale-Prozessorkernen ausgerüstet, die auf der
ARM-Architektur basieren. Erhältlich sind Module mit Taktfrequenz zwischen 200
MHz und 600 MHz und einer SD-RAM-Speichergröße bis zu 128 MB. Die
Versorgungsspannung beträgt 5V. Sie werden standardmäßig mit einem Linux-
Betriebssystem ausgeliefert.
Abbildung 3: Gumstix-Modul mit Erweiterungsboard
Das in Abbildung 3 dargestellte Modul hat inklusive Erweiterungsboard eine
Größe von 10cm x 5cm x 3cm.
Weitere Informationen zu den Gumstix-Modulen finden sich unter [1].
-9-

10. Hardware
II.2 Geschwindigkeitssensor
II.2.1 Auswahl der Messmethode
Eine Möglichkeit der Geschwindigkeitsmessung wäre die Ausnutzung der
elektromagnetischen Induktion, wie sie auch beim Fahrradtacho verwendet wird.
Da mit dieser Methode allerdings keine Drehrichtungserkennung möglich ist und
damit ein Rückwärtsfahren nicht detektiert werden kann, scheidet diese Methode
jedoch aus. Außerdem sollen für eine höhere Auflösung mehrere Impulse pro
Radumdrehung aufgenommen werden, was mehrere induktive Signalgeber
erfordern würde. Eine Montage mehrerer Magnete auf eine nur wenige Millimeter
dicke Achse ist jedoch nicht zweckmäßig. Deshalb wurde ein optisches
Verfahren, eine Gabellichtschranke, verwendet.
II.2.2 Geschwindigkeitsmessung mittels Gabellichtschranke und
Impulsgeberscheibe
Die Geschwindigkeit wird mittels eines Fotointerrupters (GP1A038RBK) der Firma
Sharp mit Taktscheibe gemessen, auch Gabellichtschranke, optischer
Inkrementalgeber oder optischer Drehgeber genannt.
Abbildung 4: Gabellichtschranke GP1A038RBK mit Impulsgeberscheibe
Hierbei handelt es sich um einen Sensor bestehend aus einer LED und einem
Phototransistor. Zwischen der emittierenden LED und dem detektierenden
Phototransistor befindet sich ein Schlitz im Sensorgehäuse, durch den die
Geberscheibe läuft, die auf der Achse des Fahrzeugs montiert ist. Auf dieser
lichtdurchlässigen Geberscheibe befinden sich lichtundurchlässige Sektoren, mit
denen der Lichtstrahl zwischen Sende-LED und detektierendem Fototransistor
zyklisch unterbrochen wird, sobald die Scheibe rotiert. Je nach Geschwindigkeit
- 10 -

11. Hardware
des Fahrzeugs werden so Rechteck-Impulsfolgen unterschiedlicher Frequenz
generiert. Die Abstände zwischen den Impulsen werden mit Hilfe eines Timers
eines Mikrocontrollers gemessen und daraus die Geschwindigkeit berechnet. Die
hier verwendete Scheibe hat 120 Schlitze pro Umdrehung, der Raddurchmesser
d beträgt 6.5cm und damit der Radumfang u = π d = 20.27cm .
Damit berechnet sich die Geschwindigkeit, unter der Annahme, dass pro
Inkrement genau ein gültiger Impuls erzeugt wird, folgendermaßen:
u
x 120
v= =
t t
Um außer der Drehgeschwindigkeit auch noch die Drehrichtung bestimmen zu
können, wird hier ein sog. zweispuriger Inkrementalgeber verwendet. Dieser gibt
über einen zweiten Ausgang eine um 90 Grad verschobene Impulsfolge aus, die
von einer zweiten Fotodiode-Fototransistor-Kombination erzeugt wird. Je nach
Phasenlage der Impulsfolge der Spur B gegenüber der Impulsfolge der Spur A
kann so die Drehrichtung detektiert werden. Eine mögliche Impulsfolge der
beiden Ausgänge mit Drehrichtungsumkehr ist in Abbildung 5 dargestellt.
Abbildung 5: Impulsfolgen der beiden Ausgänge der
Gabellichtschranke mit Drehrichtungsumkehr
Die Decodierung dieser beiden Impulsfolgen erfolgt über eine Finite State
Machine, die im Softwareteil beschrieben wird.
- 11 -

12. Hardware
Schaltplan und Anschlussbelegung des Fotointerrupters:
Abbildung 6: Schaltplan der Gabellichtschranke
Anschlussbelegung:
1: Anode der LED
2: Kathode der LED
3: GND
4: Ausgangspin B
5: Ausgangspin A
6: VCC
Über den Widerstand R kann der Strom durch die Fotodiode begrenzt werden.
Der Spannungsabfall der Fotodiode in Vorwärtsrichtung beträgt laut Datenblatt
typischerweise 1.2V. Die meisten Kenndaten des Sensors werden im Datenblatt
bei einem Fotostrom von IF = 11mA angegeben. Um diesen Strom durch die
Fotodiode zu erzeugen wird bei einer Versorgung mit 5V ein Vorwiderstand
5V − 1.2V
R= = 345 Ω
11 mA
benötigt. Der nächste Wert der E24-Reihe beträgt 330 Ohm, damit ergibt sich
ein Fotostrom von 11.5mA. Der Kondensator C1 = 10nF wird zur Stabilisierung
der Spannungsversorgung eingefügt. Zusätzlich wird C2 = 10uF hinzugefügt, um
Spannungsschwankungen aufgrund langer Zuleitungen zu kompensieren.
- 12 -

13. Hardware
II.3 Abstandssensor
Im Modellauto kommen für die Distanzmessungen sowohl Infrarotsensoren als
auch Ultraschallsensoren zum Einsatz. Der Vorteil der Ultraschallsensoren
gegenüber den Infrarotsensoren ist v.a. ihre größere Reichweite bis hin zu
einigen Metern. Die verwendeten Infrarotsensoren haben nur eine Reichweite bis
ca. 30cm. Da es für das ACC-System jedoch ausreichend ist, Distanzen zwischen
4cm und 30cm zu erfassen und die Infrarotsensoren kostengünstiger sind,
wurden Infrarotsensoren verwendet.
Der Abstandssensor besteht aus einem Infrarotsensor vom Typ GP2D120 der
Firma Sharp, der abhängig von der gemessenen Distanz einen analogen
Spannungspegel an seinem Ausgang ausgibt.
Abbildung 7: Infrarotsensor GP2D120
Dieser analoge Spannungswert wird mittels eines AD-Wandlers digitalisiert und
mit Hilfe der im Datenblatt gegebenen Kennlinie in einen Abstand umgerechnet.
Die Kennlinie ist in Abbildung 20 im Softwareabschnitt III.3.1.1 abgebildet, wo
auch die Linearisierung und Umrechnung des digitalisierten Wertes in einen
Abstand beschrieben wird.
II.4 Mikrocontroller
Zur Auswertung der Sensorsignale kommt ein 8bit-Mikrocontroller vom Typ
ATMega32 [4] der Firma Atmel zum Einsatz. Der RISC-Prozessorkern basiert auf
der Harvard-Architektur. Der ATMega32 verfügt über folgende Speicherarten-
und größen: 32Kbyte Programmspeicher, 1Kbyte EEPROM und 2Kbyte SRAM.
Außerdem besitzt dieser Mikrocontroller noch eine Reihe nützlicher Hardware-
Peripherie, wie z.B. mehrere Timer, eine I2C-Schnittstelle, einen mehrkanaligen
10-bit-AD-Wandler sowie eine Hardware-USART-Schnittstelle, mit deren Hilfe die
Kommunikation mit dem PC über die RS232-Schnittstelle möglich ist.
- 13 -

14. Hardware
Programmierbar ist der Controller neben der SPI-Schnittstelle auch über das
JTAG-Interface, das neben der Programmierung außerdem noch das On-Chip-
Debugging ermöglicht. Über beide Programmierschnittstellen ist „In-System-
Programming“ möglich, d.h. der Controller muss nicht aus der Zielhardware
entfernt werden, sondern kann direkt in der verwendeten Schaltung
programmiert werden. Laut Datenblatt werden 10000 Schreibzyklen des
Programmspeichers garantiert.
Mit Hilfe der kostenfreien Entwicklungsumgebung AVR Studio der Firma ATMEL
können die Controller sowohl in Assembler als auch in C programmiert werden.
Diese Entwicklungsumgebung enthält außerdem einen Simulator, mit dem die
Programme getestet werden können.
II.5 Platine
Da das gesamte Fahrerassistenzsystem aus den drei schon erwähnten Gumstix-
Modulen besteht, ist das Raumangebot für die Platine zur Auswertung des
Geschwindigkeitssensors im Modellfahrzeug sehr begrenzt. Aus diesem Grund
konnte keines der standardmäßig angebotenen Evaluation-Boards für den
Controller genutzt werden, sondern es musste eine maßgeschneiderte Platine in
Auftrag gegeben werden. Ein Bild der Vorder- und Rückseite der fertig gelöteten
Platine zeigen die Abbildungen 8 und 9.
Abbildung 8: Mikrocontroller-Platine: Vorderseite
Die Schaltplan- und Layoutdateien sowie eine Stückliste der verwendeten
Bauelemente befinden sich in Anhang A.
- 14 -

15. Hardware
Abbildung 9: Mikrocontroller-Platine: Rückseite
Alle Widerstände und Kondensatoren, außer dem Elektrolytkondensator C301 in
Bauform B, haben die Baugröße 0805 und sind damit wie der Pegelshifter im
SOT-Gehäuse (Pinabstand 1,27mm) noch gut von Hand lötbar. Der Controller ist
neben dem hier unzweckmäßig großen DIP-Package nur in einem TQFP-Gehäuse
mit 0.8mm Pinabstand erhältlich. Mit Verwendung eines Flussmittelstiftes und
Lötsauglitze kann aber auch dieser gut gelötet werden. Um Korrosion der
Leiterbahnen zu verhindern wurde die Platine abschließend mit Aceton gereinigt
und mit klarem Wasser abgespült. Die Platine ist 5cm x 2cm groß und damit
klein genug um problemlos im Modellauto integriert werden zu können. Auf ihr
befinden sich neben dem Controller selbst noch Pfostenstecker, über die die
benötigten Ein- und Ausgänge des Controllers nach außen geführt sind, sowie die
für den Betrieb des Controllers benötigte Peripherie wie der Quarz, der den
16MHz-Systemtakt erzeugt und diverse Kondensatoren, die die
Betriebsspannung stabilisieren und Störungen eliminieren. Außerdem befinden
sich, neben einem Spannungsregler, der eine stabile 5V-Spannungsversorgung
des Controllers gewährleistet, ein Pegelwandler auf der Platine der die
Anpassung der 5V-Logikpegel des Controllers an die +-12V-Pegel der RS232-
Schnittstelle bewerkstelligt, sowie ein Filternetzwerk für den AD-Wandler. Der
Controller kann über die JTAG-Schnittstelle direkt auf der Platine, d.h. „in-
system“ programmiert und debugged werden.
- 15 -

16. Software
Kapitel III Software
III.1 Allgemeine Erläuterungen
Alle Software-Routinen sind in C implementiert, da hiermit sowohl die
Programmierung der Regelungsalgorithmen auf den Gumstix-Modulen sowie die
hardwarenahe Programmierung des Mikrocontrollers möglich ist. Das ACC-
System wird außerdem in einem späteren Abschnitt zusätzlich mit Hilfe der
später erläuterten Sprache COLA modelliert. COLA ermöglicht die für den
Benutzer sehr angenehme graphische Modellierung komplexer Softwaresysteme
und bietet die Möglichkeit aus diesem Modell automatisch Code zu generieren.
Eine manuelle Programmierung ist damit nicht mehr notwendig und eine Vielzahl
dadurch begründeter Fehler können so vermieden werden, was gerade bei
komplexen sicherheitsrelevanten Anwendungen, wie sie im Automobil- oder
Flugtechnikbereich häufig auftreten, wichtig ist.
In Abschnitt III.2 werden die Routinen des Sensorsystems beschrieben, in
Abschnitt III.3 folgt dann eine Beschreibung der Software des Mastersystems.
III.2 Software des Sensorsystems
III.2.1 Programmstruktur der Sensorerfassung
Die Auswertung aller Sensoren erfolgt komplett interrupt-gesteuert. Im
Gegensatz zum in Abbildung 10 dargestellten sequentiellen Programmablauf ist
hier eine Unterbrechung der Codeausführung des Hauptprogrammes möglich. Zu
Beginn werden die Interruptquellen aktiviert und anschließend wird, wie beim
sequentiellen Programmablauf, eine Endlosschleife gestartet [6]. Innerhalb
dieser Endlosschleife können die nicht-zeitkritischen Programmteile ausgeführt
werden. Die aktivierten Interruptquellen können verschiedene Interrupts
auslösen wodurch das aktuell ausgeführte Hauptprogramm unterbrochen wird
und die jeweiligen Interrupt-Serviceroutinen ausgeführt werden. Nach der
Abarbeitung der entsprechenden Interrupt-Serviceroutine wird die Ausführung
des Hauptprogramms an dem Punkt fortgesetzt, an dem sie unterbrochen wurde.
- 16 -

17. Software
Abbildung 10: Sequentieller Programmablauf
Abbildung 11: Interruptgesteuerte Programmausführung mit
zugehöriger Interrupt-Serviceroutine
Abbildung 12 zeigt den Programmablaufplan des Hauptprogrammes. In diesem
werden nur die erfassten Sensorwerte in das für die Übertragung besser
geeignete ASCII-Format gewandelt, sowie die Übertragung der Sensorwerte an
das Mastersystem, sofern eine Anfrage von diesem vorliegt, ausgeführt. Die
Routine „send_check“, die die Übertragung der Sensorwerte an das
Mastersystem ausführt ist in Abschnitt III.2.4 näher beschrieben.
Um Rechenzeit zu sparen, wird eine Umwandlung in das ASCII-Format nur
ausgeführt, wenn sich der Wert geändert hat.
Die Sensorauswertung erfolgt dann innerhalb mehrerer Interrupt-
Serviceroutinen. Der Geschwindigkeitssensor wird mittels zweier Interrupt-
Serviceroutinen ausgewertet, die in Abschnitt III.2.2.3 beschrieben sind, die
- 17 -

18. Software
beiden Distanzsensoren werden durch zwei weitere Interrupt-Serviceroutinen
ausgewertet, die in Abschnitt III.2.3 näher beschrieben wird.
Abbildung 12: Programmablaufplan des Hauptprogramms
Der dem Programmablaufplan in Abbildung 12 entsprechende Quellcode befindet
sich in Anhang A2.IV unter „Main-Routine“.
- 18 -

19. Software
III.2.2 Geschwindigkeitsmessung
III.2.2.1 Einführung
Zur Berechnung der Geschwindigkeit sind Multiplikations- sowie
Divisionsoperationen notwendig. Die ALU des Mikrocontrollers ist jedoch nicht
auf diese Operationen optimiert, so dass diese nur durch einen
zeitaufwändigeren Umweg implementiert werden können.
Das Ergebnis der Berechnung wäre außerdem eine Zahl in
Fließkommadarstellung. Das UART-Datenregister des Controllers ist jedoch nur
8bit breit und eine sinnvolle Speicherung von Fließkommazahlen somit nicht
möglich, d.h. zu übertragende Werte müssen vorher in das ASCII-Format
umgewandelt werden. Diese Umwandlung dauert für Float-Werte wesentlich
länger als für Integer-Werte.
Diese beiden Umstände führen zusammen mit der benötigten Rechenzeit zur
Auswertung der Abstandssensoren zu einer zu hohen Rechenzeitanforderung.
Würde man nun die Geschwindigkeitsberechnung direkt im Mikrocontroller
ausführen, könnten die Sensoren nicht mehr oft genug abgefragt werden, und so
eine Kollision mit einem Objekt im Fahrschlauch des Fahrzeugs nicht mehr
rechtzeitig vermieden werden.
Die Geschwindigkeitsmessung wird deshalb in zwei Teilabschnitte zerlegt. Der
Mikrocontroller misst nur mit Hilfe eines Counters die Zeit zwischen zwei
nacheinander auftretenden Impulsen der Gabellichtschranke und übermittelt
diesen Zählerwert per RS232-Schnittstelle an das Mastersystem. Das
Mastersystem berechnet aus diesem Zählerstand und weiteren
Randbedingungen, wie Zählerfrequenz des Mikrocontrollers und Raddurchmesser
des Fahrzeuges, dann die aktuelle Geschwindigkeit.
Wie bereits im Abschnitt Hardware näher erläutert, wird zur
Geschwindigkeitsbestimmung eine Gabellichtschranke mit Impulsgeberscheibe
verwendet. Die Auswertung der beiden Spuren der Gabellichtschranke erfolgt mit
Hilfe einer Finite State Machine.
III.2.2.2 Finite State Machine
Wie in [6] beschrieben, gibt es mehrere Möglichkeiten, der Signalauswertung
zweispuriger Inkrementalgeber. Aufgrund ihrer Überlegenheit gegenüber allen
- 19 -

20. Software
anderen Methoden wird hier eine Auswertung beider Spuren mit fester
Abtastfrequenz durchgeführt. Hierbei werden die Logikpegel beider Spuren mit
einer festgelegten Frequenz abgetastet und mittels einer „Finite State Machine“
ausgewertet.
Die Finite State Machine (FSM) besteht aus vier Zuständen: „00“, „01“, „10“ und
„11“ (siehe Abbildung 13), die sich aus den Logikpegeln der beiden Signale A
und B des Fotointerrupters ergeben. Sind beide Signalleitungen auf logischem
„High“-Pegel, so ergibt sich der Zustand „11“ für die FSM, befindet sich nur die
Signalleitung A auf „High“, Signalleitung B jedoch auf „low“, so ist der Zustand
der FSM „10“. Der Fotointerrupter übermittelt seine Zustände mit einem Gray-
Code, d.h. direkt benachbarte Binärwerte (und damit direkt benachbarte
Zustände) unterscheiden sich nur in einer Ziffer. So ist z.B. ein Übergang vom
Zustand 00 nur zu den Zuständen 01 und 10 möglich, da sich beim Übergang
vom Zustand 00 in den Zustand 11 zwei benachbarte Ziffern gleichzeitig ändern
würden. Hiermit können fehlerhafte Zustandsübergänge detektiert werden.
Fehlerhafte Zustandswechsel sind also 00->11, 11->00 sowie 01->10, 10->01.
Diese fehlerhaften Zustandsübergänge sind in Abbildung 13 gepunktet in der
Mitte dargestellt. Werden solche fehlerhaften Zustandswechsel detektiert, gehen
bei der Abtastung Zustände verloren, da laut Abbildung 14 z.B. nach einem „01“-
Pegel je nach Fahrtrichtung immer entweder der Zustand „00“ oder „11“
auftreten muss. Dies bedeutet, dass die Drehgeschwindigkeit der Schiebe zu
groß für die gewählte Abtastrate ist und die Abtastfrequenz erhöht werden muss.
Abbildung 13: Zustände und Zustandsübergänge der
Finite State Machine
- 20 -

21. Software
Die Zustandswechsel erfolgen immer nach folgendem Schema: 00 -> 10 / 01 ->
11 -> 01 / 10 -> 00
Abbildung 14 zeigt die vom Distanzsensor erzeugten Impulsfolgen und die
entsprechenden Zustände der FSM.
Abbildung 14: Ausgangssignale der Gabellichtschranke und
entsprechende Zustände der Finite State Machine
III.2.2.3 Geschwindigkeitsmessung
Die höchste messbare Geschwindigkeit ist begrenzt durch die maximal
auswertbare Frequenz des Fotointerrupters, die laut Datenblatt 20kHz beträgt.
Die hier verwendete Geberscheibe ist in 120 Segmente eingeteilt, d.h. es sind
maximal 20000/120 = 166 komplette Umdrehungen der Scheibe pro Sekunde
detektierbar. Bei einer Montage der Scheibe direkt auf der Welle und damit einer
Übersetzung von 1:1 ist die höchste messbare Geschwindigkeit, abhängig vom
166π d
Raddurchmesser d: v = . Der Raddurchmesser des Modellautos beträgt 6.5
1s
cm, womit sich eine maximal messbare Geschwindigkeit von
cm m km
166π ⋅ 6.5 = 33.9 = 122 ergibt.
s s h
Die Phasenverschiebung der beiden Ausgangssignale des Fotointerrupters
beträgt im Idealfall 90°. Aufgrund von Abweichungen der Position der
Geberscheibe von den Idealpositionen in allen drei Raumrichtungen innerhalb
des Fotointerrupters und aufgrund einer erhöhten Umgebungstemperatur,
verursacht durch die Verlustleistung des Fotointerrupters, kann es in der Praxis
zu einer höheren Phasenverschiebung kommen. Dies kann zusammen mit einer
niedrigen Duty Ration (Anteil des High-Pegels eines Impulses an der Gesamt-
Impulsdauer) der Ausgangssignale zu einer nur noch sehr kleinen „Überlappung“
der beiden Signale führen, was die Detektion der verschiedenen Zustände
- 21 -

22. Software
erschwert und damit die Abtastrate erhöht werden muss. Aufgrund dieser
Tatsache wird sicherheitshalber eine etwas höhere Abtastrate gewählt.
Die maximal auswertbare Frequenz des Fotointerrupters beträgt 20 kHz, jedem
Impuls entsprechen 4 Zustände der FSM wie Abbildung 14 zu entnehmen ist.
Nach dem Abtasttheorem ergibt sich damit eine untere Abtastfrequenz von
2 ⋅ 4 ⋅ 20 kHz = 160 kHz .
Aufgrund der oben genannten größeren Phasenverschiebung sollte die
Abtastfrequenz jedoch höher gewählt werden. Für das Modellauto ist eine
maximale Geschwindigkeit von 5km/h ausreichend, was ungefähr einer Frequenz
von 1.2kHz entspricht und damit einer Abtastfrequenz von mindestens 9.6kHz.
Aufgrund der oben erwähnten Phasenverschiebung wird hier zur Sicherheit eine
Abtastfrequenz von 25kHz gewählt.
Die Auswertung der FSM erfolgt durch einen Interrupt. Während der
Initialisierung wird ein Timer gestartet, der alle 40 s einen Interrupt auslöst. In
diesem Interrupt-Handler werden die Zustände der beiden Signalpegel des
Fotointerrupters abgetastet und so die Zustände der FSM bestimmt. Der
Programmablaufplan dieses Interrupt-Handlers ist in Abbildung 15 dargestellt.
Der Quellcode der FSM-Auswertung aus Abbildung 15 befindet sich in Anhang
A2.I unter „Auswertung der FSM“.
Aufgrund der später im Abschnitt V.I beschriebenen Probleme mit der
Gabellichtschranke wurde versucht, den Code für die Auswertung möglichst
robust gegen Störungen zu gestalten. Neben der Überprüfung des aktuellen
Zustandsüberganges werden auch die vier vorherigen Zustandsübergänge auf
Gültigkeit überprüft. Eine Zeitmessung wird nur dann gestartet, wenn eine
gültige Folge von Zustandsübergängen 00 -> 01 -> 11 –> 10 -> 00 bzw. 00 ->
10 -> 11 –> 01 -> 00 vorliegt. Beim Auftreten eines oder mehrerer ungültiger
Zustandsübergänge wird die Zeitmessung abgebrochen und erst bei einem
neuen gültigen Impuls neu gestartet.
- 22 -

23. Software
Abbildung 15: Programmablaufplan der FSM-Auswertung
Der zweite Interrupt für die Auswertung der Gabellichtschranke ist der Overflow-
Interrupt des Counters. Mit Hilfe dieses Counters wird die Zeit zwischen zwei
aufeinanderfolgenden Impulsen gemessen. Der Zählerstand des Counters wird
zurückgesetzt, sobald ein neuer gültiger Impuls der Gabellichtschranke auftritt.
Bewegt sich das Fahrzeug jedoch nicht mehr, so werden keine weiteren Impulse
generiert und der Zählerstand erreicht sein Maximum. Da es sich bei dem
Counter um einen 16Bit-Counter handelt, ist dieser Maximalwert bei 65535
erreicht. Beim Überlauf des Counters wird ein Overflow-Flag gesetzt und die
entsprechende Interrupt-Service-Routine gestartet. In dieser wird der
Zählerstand auf den Maximalwert 65535 gesetzt (siehe Abbildung 16).
Da der Counter des Mikrocontrollers in 4 s-Schritten zählt und sein Maximalwert
65535 beträgt, ergibt sich eine maximal messbare Zeitspanne von 0.26s.
Zwischen zwei Impulsen wird eine Strecke von 1.7mm zurückgelegt. Damit
- 23 -

24. Software
ergibt sich eine minimale messbare Geschwindigkeit von 6.5mm/s. Jede
Geschwindigkeit kleiner 6.5 mm/s wird also als stehendes Fahrzeug interpretiert.
Abbildung 16: Programmablaufplan der ISR „Timer1_Overflow“
Der zur Abbildung 16 gehörige Quellcode befindet sich in Anhang A2.I unter
„Erkennung stehendes Fahrzeug: ISR_Timer1_Overflow“.
III.2.3 Abstandsmessung
Die Abstandsmessung erfolgt aufgrund der bereits bei der
Geschwindigkeitsmessung genannten Einschränkungen des Mikrocontrollers
ebenfalls in zwei Teilabschnitten. Die von den beiden Abstandssensoren
generierten Spannungspegel werden vom Mikrocontroller AD-gewandelt und auf
Anfrage des Mastersystems per RS232-Schnittstelle gesendet.
Dort werden die digitalisierten Spannungswerte dann anhand der in Abschnitt
III.3.1.1 beschriebenen Routine in einen Abstand umgerechnet.
Die Auswertung der Infrarotsensoren erfolgt wie die Auswertung des
Geschwindigkeitssensors interruptgesteuert. Durch einen Timer wird eine
Zeitbasis erzeugt, die alle 500 s einen Interrupt generiert. Innerhalb der in
Abbildung 17 dargestellten Interrupt-Serviceroutine wird dann eine neue AD-
Wandlung gestartet. Der Quellcode dieser ISR befindet sich in Anhang A2.II
unter „ISR AD-Wandlung“.
- 24 -

25. Software
Abbildung 17: Programmablaufplan der AD-Wandlung
Das Ende eines AD-Wandlungszyklusses wird durch einen Interrupt signalisiert
und die in Abbildung 18 dargestellte Interrupt-Serviceroutine ausgeführt, deren
Quellcode in Anhang A2.II unter „ISR ADC_Interrupt“ zu sehen ist. Um
Schwankungen abzuglätten wird eine Mittelwertbildung der letzten vier
gemessenen Distanzwerte durchgeführt. Der Mittelwert wird mit vier Werten
gebildet, da damit einerseits Schwankungen der Messung ausreichend
ausgeglichen werden, andererseits kann bei einer Mittelwertbildung mit vier
Werten die Division durch den Faktor 4 durch eine einfache Schiebeoperation
ausgeführt werden und so eine rechenzeitintensive Division vermieden werden.
Abschließend wird der Kanal gewechselt, um den Spannungswert des anderen
Distanzsensors zu digitalisieren.
- 25 -

26. Software
Abbildung 18: Programmablaufplan der ISR „ADC_Interrupt“
Bei den Mikrocontrollern der ATMega-Serie, die einen AD-Wandler beinhalten,
gibt es drei Möglichkeiten der Referenzspannungswahl. Der ATMega32 bietet
eine interne 2.54V-Spannungsreferenz. Da hier allerdings Spannungswerte bis
zu 3V auftreten können, kann diese nicht genutzt werden. Außerdem kann eine
externe Spannungsreferenz angeschlossen werden. Diese bietet oft die höchste
Genauigkeit, allerdings steigt damit die Größe und Komplexität der Schaltung.
Als letzte Möglichkeit kann als Referenz die Versorgungsspannung des analogen
Netzes verwendet werden. Die Spannung des analogen Netzes beträgt wie die
Spannung des digitalen Netzes 5V, ist jedoch durch einen Tiefpass von diesem
entkoppelt, um Spannungsschwankungen durch schnelle digitale Schaltvorgänge
auszufiltern. Diese Versorgungsspannung wurde als Referenzspannung für die
AD-Wandlungen verwendet.
Laut Datenblatt [4] ergibt sich folgendes Ergebnis in Abhängigkeit der
Referenzspannung:
VIN ⋅ 1024
ADC = = VIN ⋅ 204.8
VREF
III.2.4 Kommunikation mit dem Mastersystem
Die Kommunikation mit dem Mastersystem erfolgt über die RS232-Schnittstelle.
Um hier das Rad nicht neu erfinden zu müssen, wird auf die bereits
vorhandenen, sehr guten und von einer großen Community getesteten Routinen
- 26 -

27. Software
von Peter Fleury [8] zurückgegriffen. In diesen Routinen ist u.a. ein FIFO-
Ringbuffer implementiert, der sicherstellt, dass Zeichen, die noch nicht gesendet
werden können, da das USART-Interface noch mit der Übertragung vorheriger
Zeichen beschäftigt ist, zwischengespeichert werden und nicht verloren gehen.
Die Kommunikation erfolgt im Polling-Verfahren, d.h. das Mastersystem fragt die
Sensordaten zyklisch ab. Dies funktioniert im Falle der Geschwindigkeit indem
die Zeichenfolge „GESP“ gesendet wird, woraufhin der Controller den aktuellen
Zählerstand des Counters sendet. Analog funktioniert die Abfrage der Distanzen
mit den Befehlen „GEDF“ und „GEDR“ für die Abfrage des vorderen bzw. hinteren
Distanzsensors. Die Übertragung der Werte erfolgt im ASCII-Format.
Der Programmablaufplan ist in Abbildung 19 dargestellt und der Quellcode, der
diese Funktion implementiert in Anhang A2.III unter „Übertragungsroutine
Send_Check“.
- 27 -

28. Software
Abbildung 19: Programmablaufplan der Routine „Send_Checkquot;
III.3 Software des Mastersystems
Die Software des Mastersystems besteht neben dem ACC-Regelungsalgorithmus
noch aus den Routinen zur Geschwindigkeits- und Distanzberechnung aus den
Sensorrohdaten.
- 28 -

29. Software
III.3.1 Berechnung der Sensordaten
III.3.1.1 Berechnung der Distanz
Abbildung 20 zeigt den Zusammenhang zwischen Ausgangsspannungswert des
Infrarotsensors und dem detektierten Abstand. Da diese Kennlinie stark nicht-
linear ist, muss diese für eine Umrechnung der Spannungswerte in Distanzwerte
linearisiert werden.
Abbildung 20: Spannungs-Distanz-Kennlinie aus dem Datenblatt
Die Kennlinie wird innerhalb der in Tabelle 1 angegebenen Intervalle mit
Geradenstücken approximiert:
Tabelle 1: Intervall-Einteilung
Die Kennlinie gibt die Ausgangsspannung als Funktion des Abstandes an,
benötigt wird allerdings der Abstand als Funktion der Spannung. Deshalb werden
die beiden Achsen getauscht. Um außerdem einen gültigen funktionalen
- 29 -

30. Software
Zusammenhang zu erhalten, wird der Kennlinienabschnitt zwischen 0 und 3cm
entfernt. Das Ergebnis zeigt Abbildung 21:
Abbildung 21: linearisierte Kennlinie
Der Achsenabschnitt sowie die Steigung der Geradenstücke können aus den
beiden Punkten, die durch die Intervallgrenzen gegeben sind, berechnet werden.
Gegeben sind die beiden Punkte P1(x1 | y1) und P2(x2 | y2) und gesucht ist die
Gerade y = m ⋅ x + t , die durch diese beiden Punkte verläuft.
Setzt man beide Punkte in die Geradengleichung ein, ergeben sich die beiden
Gleichungen
y1 = m ⋅ x1 + t
y2 = m ⋅ x2 + t
Ineinander eingesetzt und nach m bzw. t aufgelöst ergeben sich die
Bestimmungsgleichungen für die Steigung m bzw. den Achsenabschnitt t:
y2 − y1
m=
x2 − x1
x2 ⋅ y1 − x1 ⋅ y2
t=
x2 − x1
- 30 -

31. Software
III.3.1.2 Berechnung der Geschwindigkeit
Der Raddurchmesser des Modellautos beträgt 6.5cm und damit der Radumfang
u = π ⋅ d = 20.42cm . Die Impulsgeberscheibe ist in 120 Segmente eingeteilt. Damit
u
ergibt sich ein zurückgelegter Weg von = 1.7mm zwischen zwei detektierten
120
Impulsen. Der Counter des Mikrocontrollers zählt in 4 s-Schritten und
übermittelt seinen Zählerstand per RS232-Schnittstelle an das Mastersystem.
Damit ergibt sich eine Geschwindigkeit von
u
x 120
v= =
t 4µs ⋅ countervalue
III.3.2 ACC
III.3.2.1 ACC – Spezifikationen
1. Allgemeines Verhalten
1.1 Das ACC-System kann ein- und ausgeschaltet werden.
1.2 Bei Inbetriebnahme des Systems ist das ACC ausgeschaltet und die
Wunschgeschwindigkeit auf einen bestimmten Ausgangswert gesetzt,
beispielsweise 0 km/h (stehendes Fahrzeug).
1.3 Die Wunschgeschwindigkeit des Autos kann über die Steuerung in einem
bestimmten Bereich (beispielsweise –2km/h bis 5 km/h) in festen
Schritten (z.B. 0,5 km/h) erhöht und erniedrigt werden.
2. Fahrverhalten, falls kein Objekt im Fahrschlauch (Geschwindigkeitsregelung)
2.1 Wenn das ACC eingeschaltet wird, beschleunigt (bremst) das Auto
solange, bis die Wunschgeschwindigkeit erreicht ist.
2.2 Solange das ACC eingeschaltet ist, soll die Wunschgeschwindigkeit
gehalten werden.
2.3 Wird die Wunschgeschwindigkeit geändert, während das ACC
eingeschaltet ist, muss die neue Wunschgeschwindigkeit eingenommen
werden.
3. Fahrverhalten, falls Objekt im Fahrschlauch (Abstandsregelung)
- 31 -

32. Software
3.1 Wurde ein Objekt erkannt, muss mindestens ein vorgegebener Abstand
zum vorausfahrenden Objekt gehalten werden.
3.2 Die Abstandsregelung hat höhere Priorität als die
Geschwindigkeitsregelung, d.h. ggf. wird die eingegebene
Wunschgeschwindigkeit unterschritten, falls der Mindestabstand sonst
nicht gewährleistet wäre.
3.3 Sobald das Objekt den Fahrschlauch verlassen hat, wird wieder gemäß
der Geschwindigkeitsregelung (ACC Funktionalität) gefahren.
4. Rückwärtsfahren
4.1 Das Fahrzeug kann rückwärts fahren, indem eine negative
Wunschgeschwindigkeit eingegeben wird.
4.2 Das Rückwärtsfahren kann erst aktiviert werden, wenn das Fahrzeug
vollständig steht, d.h. die Ist-Geschwindigkeit 0 ist. (z.B. nach „Nothalt“
oder durch Einstellen von Wunschgeschwindigkeit = 0.
III.3.2.2 ACC - Regelungsalgorithmus
Abbildung 22 zeigt den Programmablaufplan des ACC-Systems.
Standardmäßig ist das ACC-System deaktiviert und die gewünschte
Geschwindigkeit wird ohne Regelung direkt an den Motor weitergegeben. Bei
aktiviertem ACC werden die benötigten Sensordaten „aktuelle Geschwindigkeit“
und „aktuelle Distanz“ eingelesen und der ACC-Regelungsalgorithmus
ausgeführt. Je nach Bewegungsrichtung des Fahrzeuges wird entweder der
Abstand zu einem Objekt im vorderen oder hinteren Fahrschlauch des
Fahrzeuges eingelesen.
Ist der Abstand kleiner als ein minimal erlaubter Sicherheitsabstand wird sofort
ein „emergency brake“, ein Nothalt , ausgeführt, der das Fahrzeug zum
sofortigen Stillstand bringt. Ist der Abstand größer als dieser minimale
Sicherheitsabstand, aber kleiner als der im Normalbetrieb einzuhaltende
Abstand, wird die Geschwindigkeit so lange heruntergeregelt, bis dieser
gewünschte Abstand eingehalten wird. In diesen beiden Fällen hat also die
Regelung der Distanz eine höhere Priorität als die Regelung der Geschwindigkeit,
es erfolgt eine Abstandsregelung.
- 32 -

33. Software
Abbildung 22: Programmablaufplan des ACC-Systems
Ist der aktuell gemessene Abstand größer als der im Normalbetrieb geforderte
Sicherheitsabstand, erfolgt eine Geschwindigkeitsregelung. Ist die aktuelle
Geschwindigkeit des Fahrzeugs geringer als die vom Benutzer gewünschte
Geschwindigkeit, wird das Fahrzeug so lange beschleunigt, bis sich das Fahrzeug
mit der vom Benutzer gewünschten, vorgegeben Geschwindigkeit bewegt. Ist die
Geschwindigkeit größer als die vom Benutzer gewünschte Geschwindigkeit,
erfolgt eine Reduzierung der Geschwindigkeit bis die gewünschte
Wunschgeschwindigkeit erreicht ist.
Um eine zu abrupte Beschleunigung bzw. Verzögerung zu vermeiden, erfolgt die
Geschwindigkeitsanpassung in 5%-Schritten. Eine Ausnahme bildet hier der sog.
„Emergency Stop“, der bei einer Unterschreitung einer minimalen
Sicherheitsdistanz möglichst schnell ausgeführt werden soll.
Den Programmablaufplan des Regelungsalgorithmus zeigt Abbildung 23.
- 33 -

34. Software
Abbildung 23: ACC-Regelungsalgorithmus
Der Regelungsalgorithmus ist universell für positive, wie auch für negative
Geschwindigkeiten anwendbar wie anhand der Unterscheidung folgender acht
Fälle deutlich gemacht werden soll.
Regelungsalgorithmus: new_speed = act_speed + 0.95 (desired_speed –
act_speed)
Fall 1: beide Geschwindigkeiten > 0
Fall 1a: act_speed < desired_speed (Die aktuelle Geschwindigkeit ist kleiner als
die Wunschgeschwindigkeit)
Der Ausdruck in der Klammer ist > 0 und damit die neue
Geschwindigkeit größer als die aktuelle Geschwindigkeit, das Fahrzeug
wird beschleunigt.
Fall 1b: act_speed > desired_speed (Die aktuelle Geschwindigkeit ist größer als
die Wunschgeschwindigkeit)
Dann ist der Ausdruck in der Klammer < 0 und somit die neue
Geschwindigkeit kleiner als die aktuelle Geschwindigkeit, da ein
negativer Wert zur aktuellen Geschwindigkeit addiert wird, es kommt
zur gewünschten Geschwindigkeitsreduzierung.
- 34 -

35. Software
Fall 2: beide Geschwindigkeiten < 0
Fall 2a: | act_speed | < | desired_speed |
Ist die aktuelle Geschwindigkeit betragsmäßig kleiner als die
Wunschgeschwindigkeit, so bleibt der Ausdruck in der Klammer <0.
Betragsmäßig vergrößert sich die Geschwindigkeit, das negative
Vorzeichen jedoch bleibt erhalten.
Fall 2b: | act_speed | > | desired_speed |
Ist die aktuelle Geschwindigkeit betragsmäßig größer als die
Wunschgeschwindigkeit, wird der Ausdruck in der Klammer positiv.
Dieser positive Betrag verringert den Betrag, nicht aber das Vorzeichen
der negativen Ausgangsgeschwindigkeit.
Fall 3: beide Geschwindigkeiten haben unterschiedliches Vorzeichen
Fall 3a: act_speed < 0 < desired_speed; | act_speed | < | desired_speed |
Die aktuelle Geschwindigkeit ist < 0, das Fahrzeug fährt also noch
rückwärts, die Wunschgeschwindigkeit ist jedoch > 0. Damit ist der
Ausdruck in der Klammer ebenfalls > 0 und damit wird die negative
Ausgangsgeschwindigkeit betragsmäßig kleiner, bis sie irgendwann
leicht positiv wird. Ab dort tritt Fall 1a) in Kraft und die Geschwindigkeit
wird weiter erhöht, bis die Wunschgeschwindigkeit erreicht ist.
Fall 3b: act_speed > 0 > desired_speed; | act_speed | < | desired_speed |
Dies entspricht genau dem Gegenteil von Fall 3a). Das Fahrzeug fährt
noch vorwärts, die neue Wunschgeschwindigkeit jedoch ist < 0. Der
Ausdruck in der Klammer ist < 0 und damit wird die aktuelle
Geschwindigkeit reduziert bis diese schließlich negativ wird. Ab hier
erfolgt eine Regelung nach Fall 1b), bis die Wunschgeschwindigkeit
erreicht ist.
Fall 3c: act_speed < 0 < desired_speed; | act_speed | > | desired_speed |
Der Ausdruck in der Klammer ist positiv, die Ausgangsgeschwindigkeit
jedoch < 0. Dadurch erfolgt eine betragsmäßige Reduktion der
negativen Geschwindigkeit, bis diese positiv wird und in eine Regelung
nach Fall 1a) übergeht.
Fall 3d: act_speed > 0 > desired_speed; | act_speed | > | desired_speed |
- 35 -

36. Software
Hier ist der Ausdruck in der Klammer negativ und somit erfolgt eine
Reduzierung der positiven Ausgangsgeschwindigkeit bis diese negativ
wird und in eine Regelung nach Fall 1b) übergeht.
- 36 -

37. COLA – The Component Language
Kapitel IV COLA – The Component Language
IV.1 Beschreibung der Sprache COLA
Bei der Component Language COLA handelt es sich um eine Sprache für das
Design und die Entwicklung integrierter Systeme, die auf synchronem Datenfluss
basiert und mit der komplexe Softwaresysteme modelliert werden können. Diese
Modellierung kann sowohl textbasiert als auch graphisch erfolgen. Die
Möglichkeit der graphischen Modellierung und der damit verbundenen
automatischen Code-Generierung ist nicht nur für den Benutzer wesentlich
komfortabler in der Anwendung und damit auch weniger zeitintensiv, sondern
bietet außerdem den Vorteil, dass Systeme mit automatischen „Model-Checkern“
direkt überprüft und verifiziert werden können. Neben der vollautomatischen
Generierung von C-Code ist natürlich auch die automatische Generierung von
Code in anderen Sprachen, wie z.B. VHDL denkbar. Die Modellierungskonzepte
ähneln denen anderer bekannter Modellierungssprachen wie z.B.
MATLAB/Simulink oder UML, kombinieren diese jedoch mit einer strikten
Semantik. Im Gegensatz zu ähnlichen Projekten unterstützt COLA die
Modellierung bis zur Implementierungsebene mit einem einzigen Formalismus,
was die funktionelle Verifikation eines Modells ermöglicht. Außerdem ist mit
COLA die Modellierung kompletter verteilter Systeme möglich, die Aufteilung der
Ressourcen, d.h. z.B. die Aufteilung der anfallenden Rechenprozesse auf die
verschiedenen Prozessoren geschieht vollautomatisch.
Bei der Modellierung wird das System so lange hierarchisch in Untersysteme
zerlegt, bis das Gesamtsystem schließlich nur noch aus einigen wenige
Grundkomponenten wie z.B. Konstanten und arithmetischen Grundoperationen
zusammengesetzt werden kann.
Ein COLA-System besteht aus sog. „units“, Einheiten. Diese Einheiten stellen die
Basisblöcke eines COLA-Systems dar und bilden somit die atomaren Bausteine
eines COLA-Systems. Diese Einheiten können zu komplexeren Einheiten, sog.
„composed units“, zusammengesetzten Einheiten, kombiniert werden und damit
Netzwerke und Automaten erstellt werden. Jede Einheit hat eine gewisse Anzahl
an Ein- und Ausgängen und beschreibt die Anhängigkeit der Ausgangssignale
- 37 -

38. COLA – The Component Language
von den Eingangssignalen. Die Ein- und Ausgänge der verschiedenen Units sind
durch sog. „Channels“, Kanäle verbunden.
Das COLA-System auf der höchsten Ebene enthält alle im System auftretenden
Sensoren und Aktuatoren und hat weder Ein- noch Ausgänge.
COLA basiert auf synchronem Datenfluss und geht von perfekter Synchronität
aus, d.h. alle Berechnungen und die Kommunikation zwischen den Units geht
unendlich schnell, benötigt also keinerlei Zeit. Die einzelnen Elemente innerhalb
des Datenflusses arbeiten parallel und die Bearbeitung der Ein- und
Ausgangssignale erfolgt zu diskreten Zeitpunkten. Diese diskreten Zeitpunkte,
„Ticks“ (Augenblicke) genannt, bilden eine diskrete, einheitliche Zeitbasis. Diese
Zeitbasis erlaubt eine deterministische Beschreibung nebenläufiger Prozesse.
Realzeitanforderungen werden bezogen auf diese diskrete, einheitliche Zeitbasis
ausgedrückt.
IV.2 Modellierung des ACC-Systems in COLA
Das ACC-System besteht auf der höchsten Ebene aus den Units „Speed“,
„Distance“, „User Interface“, „ACC“ und „Motor“ (Abbildung 24). In den Units
„Speed“ und „Distance“ befinden sich die entsprechenden Sensoren, sowie die
arithmetischen Blöcke zur Berechnung der für das ACC-System benötigten
Sensordaten „Abstand“ und „Geschwindigkeit“. Über das User-Interface kann das
ACC ein- und ausgeschaltet werden und die gewünschte Wunschgeschwindigkeit
vorgegeben werden. Die Geschwindigkeitsregelung erfolgt in der Unit „ACC“, die
die neue Geschwindigkeit an die Unit „Motor“ weitergibt, die den Motor als
Aktuator enthält.
Abbildung 24: ACC-System auf höchster Ebene
- 38 -

39. COLA – The Component Language
Da eine vollständige Beschreibung aller Units den Rahmen sprengen würde,
werden im Folgenden nur die beiden Units „ACC“ und „Distance“ exemplarisch
beschrieben.
IV.2.1 Die Unit „Distance“
Die Unit „Distance“ ist in Abbildung 25 dargestellt.
Da eine Regelung durch das ACC-System auch bei rückwärts fahrendem
Fahrzeug möglich sein soll, hat die Unit „Distance“ die Geschwindigkeit als
Eingangsgröße. Mittels des in Abbildung 26 dargestellten Automaten
„Distance_Automaton“ wird überprüft, ob die Geschwindigkeit größer oder
kleiner als Null ist. Ist die Geschwindigkeit größer Null, wird der Distanzwert des
Infrarotsensors an der Fahrzeugfront an die Unit „ACC“ weitergegeben, ist die
Geschwindigkeit kleiner Null wird die Distanz zu einem Objekt hinter dem
Fahrzeug übermittelt.
Abbildung 25: Die Unit „Distance“
Die Sources „ADC_Front_Value“ bzw. „ADC_Rear_Value“ enthalten die vom AD-
Wandler digitalisierten Spannungswerte. Diese Spannungswerte werden anhand
der in Abschnitt III.3.1.1 dargestellten Kennlinie in Distanzwerte umgerechnet.
Diese Umrechnung geschieht im Block „Calc_Distance“.
- 39 -

40. COLA – The Component Language
Abbildung 26: Automat „Distance_Automaton“
Für die Linearisierung der Kennlinie aus Abschnitt III.3.1.1 gibt es verschiedene
Möglichkeiten:
1. Verwendung eines (geschachtelten) Automaten
2. Verwendung von if-Blöcken
3. Kombination eines Automaten mit if-Blöcken
4. Verwendung spezieller „Nirvana“-Transitionen
Methode 1 ist die am wenigsten elegante, da sehr viele Zustände gebraucht
werden und sie damit sehr unübersichtlich wird. Da jedoch für die if-Blöcke noch
kein Code-Generator existiert und für die Erzeugung der Nirvana-Transitionen
bisher noch die Löschung der Quelle erforderlich ist, was die momentan zur
Verfügung stehende Version des COLA-GUI noch nicht erlaubt, wird diese hier
trotzdem vorgestellt und auch für die Modellierung verwendet.
Der für die Linearisierung verwendete Automat besteht aus einem
geschachtelten Automaten, d.h. ein Zustand des Automaten ist wiederum ein
neuer Automat dessen Zustand wieder ein Automat ist usw. Es gibt so viele
Automaten, wie es Teilintervalle laut Tabelle 1 in Abschnitt III.3.1.1 gibt. Die
erste Stufe besteht aus einem Automaten der überprüft, ob der AD-gewandelte
Wert größer oder kleiner bzw. gleich der ersten Intervallgrenze (72) ist. Der
zweite Automat überprüft dann, ob der Wert innerhalb des Intervalls ] 72 ; 88 ]
liegt, der dritte Automat, ob der Wert im Intervall ] 88 ; 143 ] liegt usw. bis alle
Teilintervalle laut Tabelle 1 aus Abschnitt III.3.1.1 abgedeckt sind. Den
Automaten der ersten Stufe zeigt Abbildung 27, die zugehörigen
Zustandsübergänge sind in Abbildung 28 dargestellt.
- 40 -

41. COLA – The Component Language
Abbildung 27: Automat Stufe 1
Abbildung 28: Zustandsübergänge der beiden Transitionen des Automaten
der Stufe 1
Der Zustand „dist_gt_72“ des Automaten der Stufe 1 entspricht wiederum einem
Automaten, hier Automat der Stufe 2 genannt, der ebenfalls aus zwei Zuständen
besteht (Abbildung 29).
Abbildung 29: Automat Stufe 2
Dieser Automat überprüft, ob der AD-gewandelte Wert innerhalb des Intervalls
] 72 ; 88 ] liegt. Ist der Wert größer als 88, wird weiter verzweigt in den
Automaten der nächsten Stufe, der überprüft, ob der Wert innerhalb des
Intervalls ] 88 ; 143 ] liegt.
Liegt der Wert jedoch innerhalb des Intervalls ] 72 ; 88 ], wird mit Hilfe der
beiden Parameter Steigung und Achsenabschnitt der AD-gewandelte Wert in
- 41 -

42. COLA – The Component Language
einen Abstand (in cm) umgerechnet. Diese Berechnung ist in Abbildung 30
dargestellt.
Abbildung 30: Berechnung der Steigung m und des Achsenabschnittes t
der Teilgeraden
Die eleganteste Methode ist allerdings die Verwendung spezieller, sog.
„Nirvana“-Transitionen. Hierbei entspricht jedem Intervall ein Zustand, wie
bereits unter Punkt 1 gezeigt. Das Besondere hier ist jedoch, dass die Zustände
untereinander nicht verbunden sind. Jeder Zustand erhält eine eingehende
Transition, die jedoch keine Quelle hat. Daher auch der Name „Nirvana“-
Transition. Hierbei muss allerdings streng darauf geachtet werden, dass sich die
Bedingungen der Transitionen nicht überschneiden und so nicht-
deterministisches Verhalten ausgeschlossen ist.
IV.2.2 Die Unit „ACC“
Das Herzstück des ACC-Systems bildet die Unit „ACC“. Sie besteht aus dem
Automaten „ACC_Automaton“, mit den beiden Zuständen „ACC_on“ bzw.
„ACC_off“ sowie den Konstanten „dist_emergency“ und „dist_safety“, in denen
die beiden sicherheitsrelevanten Mindestabstände „Notabstand“ und
„Sicherheitsabstand“ gespeichert sind. Diese betragen im konkreten Beispiel
15cm bzw. 30cm.
Die Unit „ACC“ ist in Abbildung 31 dargestellt und der Automat
„ACC_Automaton“ in Abbildung 32. Standardmäßig ist das ACC-System
deaktiviert, der Initialzustand ist also „ACC_off“, es erfolgt hier keine
- 42 -

43. COLA – The Component Language
automatische Regelung und der Geschwindigkeitswert wird direkt an die Unit
„Motor“ weitergegeben (Abbildung 32 rechts).
Abbildung 31: Die Unit „ACC“
Abbildung 32: Automat „ACC_Automaton“ und Zustand „ACC_off“
Wird über das User-Interface das boolesche Signal „ACC_active“ gesetzt,
wechselt der Zustand von „ACC_off“ in den aktiven Zustand „ACC_on“.
Der Zustand „ACC_on“ besteht wieder aus einem Automaten mit den beiden
Zuständen „dist_leq_emergency“ und „dist_gt_emergency“ (Abbildung 33) Die
Abkürzungen stehen für „actual distance lower or equal emergency distance“
bzw. „actual distance greater emergency distance“.
- 43 -

44. COLA – The Component Language
Ist der gemessene Abstand kleiner (oder gleich) dem vorgegebenen Notabstand
wird ein sofortiger Nothalt des Fahrzeugs initiiert, d.h. die neue Geschwindigkeit
wird auf 0 gesetzt (Abbildung 33 rechts).
Abbildung 33: Zustand „ACC_on“ (links) und Nothalt (rechts)
Ist der Abstand größer als dieser Notabstand, wird in den Zustand
„dist_gt_emergency“ gewechselt, der wiederum aus einem Automaten mit den
beiden Zuständen „dist_leq_safety“ bzw. „dist_gt_safety“ besteht (Abbildung
34). Hier stehen die Abkürzungen analog zu den oben genannten Abkürzungen
für „actual distance lower or equal safety distance“ bzw. „actual distance greater
safety distance“.
Abbildung 34: Zustand „dist_gt_emergency“
- 44 -

45. COLA – The Component Language
Ist der aktuelle Abstand kleiner als der geforderte Sicherheitsabstand, wird die
Geschwindigkeit laut Abbildung 35 in 5%-Schritten verringert, bis der geforderte
Sicherheitsabstand wieder eingehalten wird.
Abbildung 35: Zustand „dist_leq_safety“:
Reduzierung der Geschwindigkeit um 5%
Ist der aktuelle Abstand größer als der geforderte Sicherheitsabstand erfolgt eine
automatische Regelung der Geschwindigkeit nach dem bereits in Abschnitt
III.3.2.2 vorgestellten Algorithmus, dessen Modellierung Abbildung 36 zeigt:
Abbildung 36: Zustand „dist_gt_safety“: Regelung der
Wunschgeschwindigkeit
Der Regelungsalgorithmus entspricht exakt dem Algorithmus aus Abschnitt
III.3.2.2 und ist deshalb für positve und negative Geschwindigkeiten universell
anwendbar.
- 45 -

46. Ergebnisse
Kapitel V Ergebnisse
V.1 Geschwindigkeitsmessung
Als sehr problematisch erwies sich die Geschwindigkeitsmessung. Schon bei sehr
kleinen Abweichungen im Bereich von wenigen Zehntel Millimetern von der
Idealposition der Geberscheibe innerhalb der Gabellichtschranke kommt es zu
großen Verfälschungen der Signale aufgrund der zunehmenden
Phasenverschiebung und des kleiner werdenden Duty-Cycles (Anteil des High-
Pegels an der Gesamt-Periodendauer eines Impulses) der Rechtecksignale. Eine
korrekte Auswertung wird so unmöglich.
Eine direkte Montage der Geberscheibe auf der Antriebsachse des Fahrzeuges ist
auch bei theoretisch perfekter Positionierung der Scheibe innerhalb der
Gabellichtschranke zwecklos, da das Spiel der Antriebsachse schon einige
Millimeter beträgt und damit weit größer als die tolerierbare Abweichung ist.
Nachdem ein erster Test der Geschwindigkeitsmessung im Modellauto leider
komplett fehlschlug, wurden die Ausgangssignale der Gabellichtschranke mit
Hilfe eines Oszilloskopes analysiert. Ein Softwarefehler konnte ausgeschlossen
werden, da ein Test mit idealen Testsignalen, die mittels eines Pattern-
Generators erzeugt wurden, erfolgreich war und korrekte Ergebnisse lieferte.
Durch die Betrachtung der Signalverläufe mit Hilfe des Oszilloskopes bestätigte
sich die enorme Empfindlichkeit des Sensors und die Notwendigkeit einer sehr
präzisen Ausrichtung der Geberscheibe innerhalb der Gabellichtschranke.
Deshalb wurde eine kleine Testanordnung aufgebaut, mit deren Hilfe die Scheibe
möglichst präzise innerhalb der Gabellichtschranke positioniert werden kann und
ohne auftretendes Achsialspiel durch diese rotieren kann. Hierbei ergab sich
jedoch ein weiteres Problem: Selbst bei weitestgehend idealer Positionierung der
Scheibe und damit idealen Impulsfolgen, werden statt einem Impuls pro
Inkrement mehrere Impulse erzeugt. Leider verändert sich die Anzahl der
erzeugten Impulse pro Inkrement mit der Drehgeschwindigkeit, so dass eine
sinnvolle Auswertung enorm schwierig wird. Die Ursache für dieses Verhalten
konnte bis zuletzt leider nicht ermittelt werden, liegt jedoch wohl an der immer
noch nicht präzise genug rotierenden Schiebe auch wenn optisch keine großen
Schwankungen mehr feststellbar sind. Die Verwendung mehrerer
- 46 -

47. Ergebnisse
Gabellichtschranken und unterschiedlicher Encoderscheiben sowie
unterschiedlicher Widerstände und damit unterschiedlicher Fotoströme brachte
ebenso wenig eine Verbesserung wie die Stabilisierung der
Versorgungsspannung des Sensors durch Kondensatoren.
Eine Verbesserung kann durch eine Mittelwertbildung der letzten gemessenen
Zeitwerte erreicht werden, eine perfekte Lösung stellt das allerdings immer noch
nicht dar, da der Sensor einfach ein fehlerhaftes Signal liefert. Durch die
Abhängigkeit der Impulsanzahl von der Drehgeschwindigkeit wird die
Mittelwertbildung außerdem zusätzlich erschwert. Eine Genauigkeit der
Geschwindigkeitsmessung, deren Toleranz kleiner als 10% ist, ist auf diesem
Weg kaum zu erreichen, aufgrund praktischer Erfahrungen muss eher mit
Schwankungen bis zu 20% gerechnet werden.
V.2 Distanzmessung
Problemlos funktioniert die Abstandsmessung. Anfänglich auftretende
Schwankungen der Sensorwerte konnten durch die Einführung einer
Mittelwertbildung der vier letzten Sensorwerte gut ausgeglichen werden.
V.3 Testumgebung
Für Debugging-Zwecke wurde eine Testumgebung für das ACC-Programm unter
Microsoft Windows erstellt. Der Quellcode dieser Testumgebung befindet sich in
Anhang 4. In der Testumgebung wird nach der Initialisierung der RS232-
Schnittstelle das ACC-Programm initialisiert. Während dieser Initialisierung
werden sämtlichen Automaten ihre Anfangszustände zugewiesen. Anschließend
wird in einer Endlosschleife das ACC-Programm gestartet. Die Ausführung kann
durch Drücken der Taste „ESC“ beendet werden. Das ACC-System kann durch
Drücken der Taste „A“ aktiviert und durch erneutes Drücken der Taste „A“
wieder deaktiviert werden, die gewünschte Wunschgeschwindigkeit kann mit den
Tasten „+“ bzw. „-„ in 0.5cm/s-Schritten im Bereich –100 cm/s und + 200 cm/s
eingestellt werden.
Die Abfrage der Sensorwerte erfolgt durch eine Middleware-Routine. Die darin
verwendeten Zugriffe auf die serielle Schnittstelle verwenden die „ComTools“-
Kommunikationsroutinen von Anton Zechner [10]. Der Quellcode der
Middleware-Routine befindet sich ebenfalls in Anhang 4.
- 47 -

48. Ergebnisse
V.4 Automatisch generierter Quellcode
Der gesamte vom automatischen Code-Generator erzeugte Quellcode befindet
sich in Anhang 3.
Die Regelungsalgorithmen sowie die Gleichung zur Berechnung der
Geschwindigkeit wurden vom Code-Generator in exakt dieselben Gleichungen
überführt, wie sie auch manuell geschrieben wurden. Hier hat der Code-
Generator perfekte Arbeit geleistet.
Der restliche Code besteht im Wesentlichen aus Automaten, die mittels „switch“-
Anweisungen realisiert wurden. Besonders die Routinen zur Berechnung der
Distanz sind durch die Verwendung der vielen Automaten sehr lange. Das liegt
jedoch nicht am Code-Generator, sondern an der etwas ungünstigen Wahl der
Linearisierungsmethode. Eine Verwendung der bereits genannten „Nirvana“-
Transitionen bzw. einer Kombination mit if-Blöcken sollte helfen, etwas
knapperen Code zu generieren. Ein gewisser Overhead wird sich jedoch bei einer
automatischen Code-Generierung nie vollständig vermeiden lassen und ist in der
Regel auch nicht schlimm, wenn insgesamt die genannten Vorteile wie schneller
erzeugbarer, sicher nachvollziehbarer und leichter testbarer Code überwiegen.
Insgesamt arbeitet der automatische Code-Generator sehr gut und ist in der
Lage funktionierenden, eleganten und relativ knappen Code zu generieren.
- 48 -

49. Zusammenfassung und Ausblick
Kapitel VI Zusammenfassung und Ausblick
In dieser Arbeit wurde ein System für eine automatische Geschwindigkeits- und
Abstandsregelung (Adaptive Cruise Control - ACC) entwickelt und mit
Einschränkungen bei der Geschwindigkeitsmessung erfolgreich getestet.
Außerdem wurden einige Kernkonzepte und Vorteile der Sprache COLA erläutert
und das ACC-System mit Hilfe dieser Sprache modelliert und der vom
automatischen Code-Generator erzeugte Quellcode betrachtet. Als Ergebnis kann
hier festgehalten werden, dass der automatische Code-Generator von COLA in
der Lage ist eleganten, funktionierenden Code zu generieren, was jedoch
natürlich nicht ganz ohne Overhead möglich ist.
Aufgrund der Probleme mit der Gabellichtschranke sollte die Sensorik zur
Geschwindigkeitsmessung noch einmal von Grund auf neu überdacht werden.
Eine alternative und wesentlich genauere Methode der
Geschwindigkeitsbestimmung wäre wünschenswert, diese sollte jedoch die
Möglichkeit der Drehrichtungsbestimmung beinhalten. Eventuell könnte eine
mechanisch weniger anspruchsvolle Gabellichtschranke in Kombination mit einer
Geberscheibe mit weniger Inkrementen verwendet werden, da eine geringere
Auflösung akzeptabel ist.
Außerdem wäre es eine weitere Verbesserung, wenn das Sensorsystem die
Geschwindigkeit und die Distanzen direkt berechnet, so dass das Mastersystem
diese ohne weitere Berechnungen direkt nutzen kann. Möglichkeiten dies zu
bewerkstelligen wären entweder einfach einen schnelleren Prozessor oder einen
Prozessor der über Fließkommaoperationen verfügt, zu verwenden.
- 49 -

50. Abbildungsverzeichnis
Abbildungsverzeichnis
Abbildung 1: Blockschaltbild des bestehenden Systems .................................. 7
Abbildung 2: Blockschaltbild des erweiterten Systems .................................... 8
Abbildung 3: Gumstix-Modul mit Erweiterungsboard ...................................... 9
Abbildung 4: Gabellichtschranke GP1A038RBK mit Impulsgeberscheibe...........10
Abbildung 5: Impulsfolgen der beiden Ausgänge der Gabellichtschranke mit
Drehrichtungsumkehr..........................................................................11
Abbildung 6: Schaltplan der Gabellichtschranke............................................12
Abbildung 7: Infrarotsensor GP2D120 .........................................................13
Abbildung 8: Mikrocontroller-Platine: Vorderseite .........................................14
Abbildung 9: Mikrocontroller-Platine: Rückseite ............................................15
Abbildung 10: Sequentieller Programmablauf ...............................................17
Abbildung 11: Interruptgesteuerte Programmausführung mit zugehöriger
Interrupt-Serviceroutine ......................................................................17
Abbildung 12: Programmablaufplan des Hauptprogramms .............................18
Abbildung 13: Zustände und Zustandsübergänge der ....................................20
Abbildung 14: Ausgangssignale der Gabellichtschranke und entsprechende
Zustände der Finite State Machine ........................................................21
Abbildung 15: Programmablaufplan der FSM-Auswertung ..............................23
Abbildung 16: Programmablaufplan der ISR „Timer1_Overflow“ .....................24
Abbildung 17: Programmablaufplan der AD-Wandlung...................................25
Abbildung 18: Programmablaufplan der ISR „ADC_Interrupt“ .........................26
Abbildung 19: Programmablaufplan der Routine „Send_Checkquot; ......................28
Abbildung 20: Spannungs-Distanz-Kennlinie aus dem Datenblatt....................29
Abbildung 21: linearisierte Kennlinie ...........................................................30
Abbildung 22: Programmablaufplan des ACC-Systems...................................33
Abbildung 23: ACC-Regelungsalgorithmus ...................................................34
Abbildung 24: ACC-System auf höchster Ebene ............................................38
Abbildung 25: Die Unit „Distance“...............................................................39
Abbildung 26: Automat „Distance_Automaton“ .............................................40
- 50 -

51. Abbildungsverzeichnis
Abbildung 27: Automat Stufe 1 ..................................................................41
Abbildung 28: Zustandsübergänge der beiden Transitionen des Automaten der
Stufe 1 ..............................................................................................41
Abbildung 29: Automat Stufe 2 ..................................................................41
Abbildung 30: Berechnung der Steigung m und des Achsenabschnittes t der
Teilgeraden........................................................................................42
Abbildung 31: Die Unit „ACC“ .....................................................................43
Abbildung 32: Automat „ACC_Automaton“ und Zustand „ACC_off“ ..................43
Abbildung 33: Zustand „ACC_on“ (links) und Nothalt (rechts) ........................44
Abbildung 34: Zustand „dist_gt_emergency“................................................44
Abbildung 35: Zustand „dist_leq_safety“: ....................................................45
Abbildung 36: Zustand „dist_gt_safety“: Regelung der Wunschgeschwindigkeit45
- 51 -

52. Literaturverzeichnis
Literaturverzeichnis
[1] http://www.gumstix.com/products.html
[2] Sharp Corporation, Datasheet GP1A038RBK
[3] Sharp Corporation, Datasheet GP2D120
[4] Atmel Corporation, Datasheet ATMega32
[5] http://193.196.117.23/projekte/rundheit/data/inkrementalgeber.pdf
[6] http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial
[7] http://www.mikrocontroller.net/articles/Drehgeber
[8] http://homepage.hispeed.ch/peterfleury/group__pfleury__uart.html
[9] S. Kugele, M. Tautschnig, A. Bauer, C. Schallhart, S. Merenda, W. Haberl,
C. Kühnel, F. Müller, Z. Wang, D. Wild, S. Rittmann, and M. Wechs. COLA
– The component language. Technical Report TUM-I0714, Technische
Universität München, Sept. 2007
[10] http://members.inode.at/anton.zechner/az/Seriell.htm
- 52 -