BACHELORARBEIT
       AM LEHRSTUHL FÜR INTEGRIERTE SYSTEME




   An Embedded System for
    Adaptive Cruise Control


   ...
Erklärung




Erklärung


Hiermit versichere ich, dass die vorliegende Bachelorarbeit mit dem Thema „An
Embedded System fo...
Danksagung




Danksagung


Ich danke Herrn Prof. Herkersdorf, dass ich diese Arbeit an seinem Lehrstuhl
anfertigen durfte...
Inhalt




Inhalt


ERKLÄRUNG                                                               2


DANKSAGUNG                ...
Inhalt



III.3.1    BERECHNUNG DER SENSORDATEN                                        29
III.3.2    ACC                  ...
Inhalt



A2.II ROUTINEN ZUR DISTANZ-ERFASSUNG    FEHLER! TEXTMARKE NICHT DEFINIERT.
A2.III ÜBERTRAGUNGS-ROUTINE          ...
Einführung



Kapitel I             Einführung


I.1 Motivation und Ziele der Arbeit

Im Rahmen eines Fahrerassistenzsyste...
Einführung



Die Hardware des Fahrerassistenzsystem ist jedoch bereits stark ausgelastet, so
dass   für   eine   Implemen...
Hardware




Kapitel II           Hardware


II.1 Gumstix-Module

Bei den Gumstix-Modulen handelt es sich um leistungsstar...
Hardware



II.2 Geschwindigkeitssensor

II.2.1 Auswahl der Messmethode

Eine    Möglichkeit   der   Geschwindigkeitsmessu...
Hardware



des Fahrzeugs werden so Rechteck-Impulsfolgen unterschiedlicher Frequenz
generiert. Die Abstände zwischen den ...
Hardware




Schaltplan und Anschlussbelegung des Fotointerrupters:




                 Abbildung 6: Schaltplan der Gabel...
Hardware



II.3 Abstandssensor

Im Modellauto kommen für die Distanzmessungen sowohl Infrarotsensoren als
auch Ultraschal...
Hardware



Programmierbar ist der Controller neben der SPI-Schnittstelle auch über das
JTAG-Interface, das neben der Prog...
Hardware




              Abbildung 9: Mikrocontroller-Platine: Rückseite



Alle Widerstände und Kondensatoren, außer de...
Software




Kapitel III           Software


III.1 Allgemeine Erläuterungen

Alle   Software-Routinen       sind   in   C...
Software




              Abbildung 10: Sequentieller Programmablauf




      Abbildung 11: Interruptgesteuerte Programm...
Software



beiden Distanzsensoren werden durch zwei weitere Interrupt-Serviceroutinen
ausgewertet, die in Abschnitt III.2...
Software



III.2.2 Geschwindigkeitsmessung

III.2.2.1 Einführung

Zur      Berechnung      der      Geschwindigkeit      ...
Software



anderen Methoden wird hier eine Auswertung beider Spuren mit fester
Abtastfrequenz durchgeführt. Hierbei werde...
Software



Die Zustandswechsel erfolgen immer nach folgendem Schema: 00 -> 10 / 01 ->
11 -> 01 / 10 -> 00

Abbildung 14 z...
Software



erschwert und damit die Abtastrate erhöht werden muss. Aufgrund dieser
Tatsache wird sicherheitshalber eine et...
Software




         Abbildung 15: Programmablaufplan der FSM-Auswertung



Der zweite Interrupt für die Auswertung der G...
Software



ergibt sich eine minimale messbare Geschwindigkeit von 6.5mm/s. Jede
Geschwindigkeit kleiner 6.5 mm/s wird als...
Software




            Abbildung 17: Programmablaufplan der AD-Wandlung



Das Ende eines AD-Wandlungszyklusses wird dur...
Software




         Abbildung 18: Programmablaufplan der ISR „ADC_Interrupt“



Bei den Mikrocontrollern der ATMega-Seri...
Software



von Peter Fleury [8] zurückgegriffen. In diesen Routinen ist u.a. ein FIFO-
Ringbuffer implementiert, der sich...
Software




      Abbildung 19: Programmablaufplan der Routine „Send_Checkquot;




III.3 Software des Mastersystems

Die...
Software



III.3.1 Berechnung der Sensordaten

III.3.1.1 Berechnung der Distanz

Abbildung 20 zeigt den Zusammenhang zwis...
Software



Zusammenhang zu erhalten, wird der Kennlinienabschnitt zwischen 0 und 3cm
entfernt. Das Ergebnis zeigt Abbildu...
Software



III.3.1.2 Berechnung der Geschwindigkeit

Der Raddurchmesser des Modellautos beträgt 6.5cm und damit der Radum...
Software



   3.1 Wurde ein Objekt erkannt, muss mindestens ein vorgegebener Abstand
       zum vorausfahrenden Objekt ge...
Software




             Abbildung 22: Programmablaufplan des ACC-Systems



Ist der aktuell gemessene Abstand größer als...
Software




                   Abbildung 23: ACC-Regelungsalgorithmus



Der Regelungsalgorithmus ist universell für posi...
Software



Fall 2: beide Geschwindigkeiten < 0

Fall 2a: | act_speed | < | desired_speed |

        Ist   die   aktuelle ...
Software



Hier ist der Ausdruck in der Klammer negativ und somit erfolgt eine
Reduzierung der positiven Ausgangsgeschwin...
COLA – The Component Language




Kapitel IV              COLA – The Component Language


IV.1 Beschreibung der Sprache CO...
COLA – The Component Language



von den Eingangssignalen. Die Ein- und Ausgänge der verschiedenen Units sind
durch sog. „...
COLA – The Component Language



Da eine vollständige Beschreibung aller Units den Rahmen sprengen würde,
werden im Folgen...
COLA – The Component Language




                    Abbildung 26: Automat „Distance_Automaton“



Für die Linearisierung...
COLA – The Component Language




                           Abbildung 27: Automat Stufe 1




 Abbildung 28: Zustandsüber...
COLA – The Component Language



einen Abstand (in cm) umgerechnet. Diese Berechnung ist in Abbildung 30
dargestellt.




...
COLA – The Component Language



automatische Regelung und der Geschwindigkeitswert wird direkt an die Unit
„Motor“ weiter...
COLA – The Component Language



Ist der gemessene Abstand kleiner (oder gleich) dem vorgegebenen Notabstand
wird ein sofo...
COLA – The Component Language



Ist der aktuelle Abstand kleiner als der geforderte Sicherheitsabstand, wird die
Geschwin...
Ergebnisse




Kapitel V           Ergebnisse


V.1 Geschwindigkeitsmessung

Als sehr problematisch erwies sich die Geschw...
Ergebnisse



Gabellichtschranken           und         unterschiedlicher          Encoderscheiben             sowie
unter...
Ergebnisse




V.4 Automatisch generierter Quellcode

Der gesamte vom automatischen Code-Generator erzeugte Quellcode befi...
Zusammenfassung und Ausblick




Kapitel VI             Zusammenfassung und Ausblick


In dieser Arbeit wurde ein System f...
Abbildungsverzeichnis




Abbildungsverzeichnis


Abbildung 1: Blockschaltbild des bestehenden Systems ......................
Abbildungsverzeichnis



Abbildung 27: Automat Stufe 1 ..................................................................4...
Literaturverzeichnis




Literaturverzeichnis


[1]    http://www.gumstix.com/products.html

[2]    Sharp Corporation, Dat...
Nächste SlideShare
Wird geladen in …5
×

Ba Acc Gatscher

1.396 Aufrufe

Veröffentlicht am

0 Kommentare
2 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.396
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
27
Aktionen
Geteilt
0
Downloads
7
Kommentare
0
Gefällt mir
2
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Ba Acc Gatscher

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

×