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

Erklärung

- 2 -

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

Danksagung

- 3 -

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.

Inhalt

- 4 -

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

Inhalt

- 5 -

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.

Inhalt

- 6 -

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.

Einführung

- 7 -

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

Einführung

- 8 -

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.

Hardware

- 9 -

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

Hardware

- 10 -

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

Hardware

- 11 -

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 cmdu 27.20==π .

Damit berechnet sich die Geschwindigkeit, unter der Annahme, dass pro

Inkrement genau ein gültiger Impuls erzeugt wird, folgendermaßen:

t

u

t

xv 120==

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.

Hardware

- 12 -

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

Ω=−

= 34511

2.15

mA

VVR

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.

Hardware

- 13 -

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.

Hardware

- 14 -

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.

Hardware

- 15 -

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.

Software

- 16 -

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.

Software

- 17 -

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

Software

- 18 -

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

Software

- 19 -

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

Software

- 20 -

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

Software

- 21 -

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

Raddurchmesser d: s

dv

1

166π= . Der Raddurchmesser des Modellautos beträgt 6.5

cm, womit sich eine maximal messbare Geschwindigkeit von

h

km

s

m

s

cm1229.335.6166 ==⋅π ergibt.

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

Software

- 22 -

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

kHzkHz 1602042 =⋅⋅ .

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.

Software

- 23 -

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

Software

- 24 -

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

Software

- 25 -

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.

Software

- 26 -

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:

8.2041024

⋅=⋅

= INREF

IN VV

VADC

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

Software

- 27 -

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

Software

- 28 -

Abbildung 19: Programmablaufplan der Routine „Send_Check"

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.

Software

- 29 -

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

Software

- 30 -

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 txmy +⋅= , die durch diese beiden Punkte verläuft.

Setzt man beide Punkte in die Geradengleichung ein, ergeben sich die beiden

Gleichungen

txmy +⋅= 11

txmy +⋅= 22

Ineinander eingesetzt und nach m bzw. t aufgelöst ergeben sich die

Bestimmungsgleichungen für die Steigung m bzw. den Achsenabschnitt t:

12

12

xx

yym

−

−=

12

2112

xx

yxyxt

−

⋅−⋅=

Software

- 31 -

III.3.1.2 Berechnung der Geschwindigkeit

Der Raddurchmesser des Modellautos beträgt 6.5cm und damit der Radumfang

cmdu 42.20=⋅=π . Die Impulsgeberscheibe ist in 120 Segmente eingeteilt. Damit

ergibt sich ein zurückgelegter Weg von mmu

7.1120

= zwischen zwei detektierten

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

uecountervals

u

t

xv

⋅==

µ4120

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)

Software

- 32 -

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.

Software

- 33 -

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.

Software

- 34 -

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.

Software

- 35 -

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 |

Software

- 36 -

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.

COLA – The Component Language

- 37 -

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

COLA – The Component Language

- 38 -

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

COLA – The Component Language

- 39 -

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

COLA – The Component Language

- 40 -

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.

COLA – The Component Language

- 41 -

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

COLA – The Component Language

- 42 -

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

COLA – The Component Language

- 43 -

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

COLA – The Component Language

- 44 -

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“

COLA – The Component Language

- 45 -

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.

Ergebnisse

- 46 -

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

Ergebnisse

- 47 -

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.

Ergebnisse

- 48 -

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.

Zusammenfassung und Ausblick

- 49 -

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.

Abbildungsverzeichnis

- 50 -

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_Check" ......................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

Abbildungsverzeichnis

- 51 -

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

Literaturverzeichnis

- 52 -

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