Gutachter: Prof. Dr. rer. nat. A. SchürrBetreuer: Erhan Leblebici, M.Sc.

ProjektseminarEchtzeitsystemeSchriftliche Ausarbeitung von Team*Seminar eingereicht vonRobert Nitsch, Sven Peldszus, David Bug, Zijo Kenjaram 31. März 2014

Real-Time Systems Lab

Department of Electrical Engineeringand Information Technology (FB18)

Adjunct Member Department ofComputer Science (FB20)

Prof. Dr. rer. nat. A. SchürrMerckstraße 2564283 Darmstadt

www.es.tu-darmstadt.de

Zusammenfassung

In dieser Ausarbeitung beschreiben wir die Umsetzung und Implementierung der imProjektseminar Echtzeitsysteme gestellten Aufgaben. Dazu führen wir die verwendeteHardware ein und erläutern die Aufgabenstellungen. Unsere Lösungen werden anhandvon Konzeptgrafiken und Implementierungsbeispielen erklärt. Abschließend bewertenwir unsere Lösungen und geben Ansatzpunkte für eine Weiterentwicklung an.

Inhaltsverzeichnis

1 Einleitung 1

2 Grundlagen 12.1 CarToCar Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2 Die verwendeten Autos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

3 Konfiguration 43.1 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1.1 Konfiguration (Autoseitig) . . . . . . . . . . . . . . . . . . . . . . . . . 53.1.2 Behandlung ungültiger Werte . . . . . . . . . . . . . . . . . . . . . . . 6

4 Adaptive Cruise Control 74.1 Bestimmung der Position des Autos . . . . . . . . . . . . . . . . . . . . . . . . 7

4.1.1 Bestimmung des Abstands zur Wand . . . . . . . . . . . . . . . . . . . 74.1.2 Bestimmung der tatsächlich gefahrenen Strecke . . . . . . . . . . . . 8

4.2 Seitenabstandsregelung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.2.1 Bestimmung des Sollabstands . . . . . . . . . . . . . . . . . . . . . . . 104.2.2 Einschub: Kurze Einführung zu Regelungen und PID-Regler . . . . 114.2.3 Aufbau und Funktionsweise der Kaskadenregelung . . . . . . . . . . 124.2.4 Instabilität eines einzelnen PID-Reglers . . . . . . . . . . . . . . . . . 144.2.5 Messung des Seitenabstands . . . . . . . . . . . . . . . . . . . . . . . . 164.2.6 Messung der Seitwärtsgeschwindigkeit . . . . . . . . . . . . . . . . . 16

4.3 Tempomat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Car2Car Kommunikation 20

6 Verkehrssituationen 226.1 Verkehrsstau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226.2 Ausweichen von Krankenwagen . . . . . . . . . . . . . . . . . . . . . . . . . . 226.3 Erkennen und kommunizieren von vereisten Fahrbahnen . . . . . . . . . . 23

6.3.1 Erkennen einer vereisten Fahrbahn . . . . . . . . . . . . . . . . . . . . 236.3.2 Reaktion auf eine vereiste Fahrbahn . . . . . . . . . . . . . . . . . . . 236.3.3 Reaktion auf Eismeldungen . . . . . . . . . . . . . . . . . . . . . . . . 24

7 Einparken 25

8 Tabellarischer Überblick der implementierten Funktionen 26

9 Sonstiges 279.1 WirelessExport-Modul und Plotter . . . . . . . . . . . . . . . . . . . . . . . . . 27

9.1.1 Beispiel: Export der Ultraschallsensor-Daten . . . . . . . . . . . . . . 279.1.2 Abhängigkeiten des Plotters installieren . . . . . . . . . . . . . . . . . 27

i

9.2 Recovery-Modus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289.2.1 Auslösung und Beendigung des Recovery-Modus . . . . . . . . . . . 29

10 Fazit und Ausblick 3110.1 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

ii

1 Einleitung

Dies ist die schriftliche Ausarbeitung von team* für das Projektseminar Echtzeitsystemeim Wintersemester 13/14 an der TU Darmstadt.

Im Zentrum des Projektseminars stand die Mikrocontroller-Programmierung für Fu-jitsu Modellautos (Student Model Car) zur Umsetzung verschiedener Car2Car Com-munication Szenarien (kurz: Car2Car). Bei Car2Car Communication geht es um denAustausch von Informationen zwischen Verkehrsteilnehmern. Bei Unfällen können zumBeispiel nachfolgende Verkehrsteilnehmer gewarnt werden, die dann ihr Tempo früh-zeitig reduzieren können.

Folgende Car2Car Szenarien sollten umgesetzt werden:

• Adaptive Cruise Control umfasst das Spurhalten/Geradeausfahren im Flur sowiedie Abstandhaltung zu vorausfahrenden Fahrzeugen.

• Avoidance of traffic jams Wenn ein Stau bemerkt wird, werden andere Fahrzeugeüber den Stau informiert, sodass diese auf eine andere Route ausweichen können(Spurwechsel).

• Im Emergency Vehicle Szenario spielt ein Fahrzeug die Rolle eines Krankenwa-gens. Die anderen Fahrzeuge sollen dem Krankenwagen Platz machen (Spurwech-sel).

• Bei Location warning geht es darum, dass sich die Fahrzeuge gegenseitig vor ver-eisten Stellen warnen. Nachfolgende Fahrzeuge sollen rechtzeitig ihre Geschwin-digkeit reduzieren.

• Parking spot bedeutet, dass die Fahrzeuge selbstständig eine Parklücke zwischenanderen Fahrzeugen finden und einparken sollen.

Hierbei ist hervorzuheben, dass das Spurhalten eine zwingende Voraussetzung für dieanderen Szenarien darstellt. Schließlich kann man diese Szenarien erst dann angehen,wenn die Fahrzeuge geradeaus fahren und Spuren wechseln können. Einzige Ausnah-me hiervon ist das Parking spot Szenario, welches man auch ohne diese Funktionalitätumsetzen kann.

2 Grundlagen

In diesem Kapitel werden wir wichtige Grundlagen vermitteln, die zum Verständnisunserer Lösungen notwendig sind.

2.1 CarToCar Kommunikation

Als CarToCar Kommunikation bezeichnet man die automatische Kommunikation vonFahrzeugen untereinander, mit dem Ziel die Sicherheit zu erhöhen und die allgemeineReisedauer zu verkürzen. Anwendungsszenarien sind die Warnung vor Unfällen oderanderen Gefahren.

1

Abbildung 2.1: Bild eines der verwendeten Autos

2.2 Die verwendeten Autos

Für das Projektseminar wurden mehrere Mikrocontroller-gesteuerte Autos zur Verfü-gung gestellt. Diese wurden von vorangehenden Jahrgängen mit einem Betriebssystemund Interfaces zur Ansteuerung der verfügbaren Hardware ausgestattet. Jedes Autoverfügt über folgende, in Abbildung 2.2 dargestellte, Hardware:

1. Elektrischer Antrieb

2. Lenkung

3. 3 Ultraschallsensoren

4. 1 Odometer am Hinterrad

5. 5 Infrarotsensoren an der Unterseite des Autos

6. Funkmodul

Der elektrische Antrieb lässt sich stufenweise regeln. Dabei werden die Stufen −10 bis10 angeboten. Für das Praktikum wurde empfohlen nicht schneller als Stufe 5 zu fahren.An diese Empfehlung haben wir uns gehalten. Ein negatives Vorzeichen bedeutet, dassdas Fahrzug rückwärts fährt.

An den Seiten des Autos sowie in der Front ist je einer der drei Ultraschallsensorenangebracht. In dieser Ausarbeitung werden diese Sensoren entsprechend ihrer Positionam Fahrzeug, als USl inks, USrechts und US f ront , bezeichnet.

Das Odometer basiert auf einer Hallsonde und misst die vom Fahrzeug zurückgelegteStrecke auf Basis der Anzahl an Umdrehungen eines Hinterrades.

Die Infrarotsensoren ermöglichen es die Helligkeit des Bodens vor dem Fahrzeug zubestimmen.

2

Das Funkmodul beherrscht die Funksandrads Bluetooth und eine proprietären Stan-dard im 868 MHz Band.

3

3 Konfiguration

Die Konfiguration des Autos erfolgt über die Android-App “BlueConfig“, welche Blue-tooth zur Datenübertragung nutzt. Das Auto startet erst wenn es eine gültige Konfigura-tion empfangen hat und danach Button INT1 (PDR07_P1) betätigt wurde. Zuerst mussin den Android-Bluetooth-Einstellungen das jeweilige Auto mit dem Handy gekoppeltwerden. Der hierzu benötigte PIN-Code lautet “1234“. Dann wird die App gestartet undsich mit dem zu konfigurierenden Fahrzeug verbunden:

Abbildung 3.1: Auswahl des zu konfigurierenden Autos

Wurde die Verbindung erfolgreich hergestellt, wird zu dem Tab “BlueConfig“ gewech-selt wo man die verschiedenen Konfigurationsparameter einstellen kann:

Abbildung 3.2: Einstellung der Konfigurationsparameter

4

1. Richtung (Start Direction)

Hier wird die Richtung eingestellt, in der das Auto gestartet wird. “normal“ für dieStandardrichtung und “opposite“ für die entgegengesetzte Richtung des Flurs, wo-bei die Startpunkte für “normal“ und “opposite“ ca. 17 Meter voneinander entferntsein müssen.

2. Gegenverkehr

Der ToggleButton mit der Aufschrift “One Direction“ bzw. “Both Directions“ be-stimmt, ob es Fahrbahnen in nur eine oder in beide Richtungen gibt.

3. Startspur (Start Lane)

Hier wird die Startspur eingegeben. Die Spuren zählen aus Sicht der Normalrich-tung von links nach rechts von 0 an hoch.

4. Anzahl der Spuren pro Richtung (Lanes per Direction)

Bestimmt, wie viele Spuren es pro Richtung gibt. Falls also hier die 1 ausgewähltwird und beide Richtungen aktiviert sind (siehe 2), existieren 2 Spuren und Spur0 ist die Gegenrichtung und Spur 1 die Normale. Hierbei muss darauf geachtetwerden, dass eine gültige Startspur (siehe 3) ausgewählt wird, da das Auto sonstnicht startet.

5. Maximale Geschwindigkeit (Max Speed)

Setzt die Geschwindigkeit, die das Auto maximal fahren darf.

6. Krankenwagen (Ambulance)

Bestimmt, ob das Auto einen Krankenwagen darstellen soll. Hierbei wird die ma-ximale Geschwindigkeit automatisch auf 5 gestellt. Dies geschieht auf dem Autowährend der Konfiguration, nicht durch die App.

7. Senden (Send)

Zum Schluss wird über den Sendbutton die Konfiguration an das Auto geschickt.

3.1 Kommunikation

Das von der App an das Auto gesendete Datenpaket ist folgendermaßen aufgebaut:

Alle Felder sind jeweils 1 Byte groß.

3.1.1 Konfiguration (Autoseitig)

Wenn das Auto eingeschaltet wird, initialisiert es zuerst nur die API-Funktionen (alsounter anderem auch die Wirelessfunktionalitäten) und registriert einen Handler, der aufeine Drahtlosnachricht vom Typ MSG_EMERGENCY wartet (was der durch “BlueConfig“gesendeten ID entspricht). Sobald das Auto eine solche Nachricht empfängt, wird derHandler aufgerufen und alle internen Variablen werden entsprechend gesetzt, falls die

5

Index Inhalt Erläuterung0 Ambulance? true (1)/ false (0)1 Start Lane Startspur (0..3)2 Direction normal -> 0, opposite -> 13 both Directions? true (1)/ false (0)4 max Speed max. Geschw. (1..4)

Tabelle 3.1: Aufbau eines Konfigurationspakets

Werte gültig sind. Wenn dies nicht der Fall ist, wird auf der 7-Segment-Anzeige eine 8ausgegeben und das Auto kann nicht gestartet werden. Sind alle Werte gültig, fällt dasAuto in einen Wartezustand. Erst wenn der Button INT1 gedrückt wird startet das Autoalle weiteren Tasks.

3.1.2 Behandlung ungültiger Werte

Möglich Fehler, bei denen die 7-Segment-Anzeige eine Acht anzeigt, sind Parameteraußerhalb des belegten Wertebereichs. Dies kann theoretisch durch Übertragungsfehlerauftreten.

Eine weitere Fehlerquelle sind Autos, die die Anweisung bekommen, als Geisterfahrerim Gegenverkehr zu fahren. Empfängt ein Auto solch eine Konfiguration darf es nichtlosfahren.

Es muss überprüft werden, ob die gewählte Fahrbahn gültig für die gewählte Stre-ckenkonfiguration und Fahrtrichtung ist. Wir nummerieren die zur Verfügung stehen-den Spuren aus Sicht eines Beobachters von links nach rechts beginnend mit null durch.Dabei gibt es drei gültige Bereiche:

• Es gibt nur eine Fahrtrichtung und es wird vom Beobachter weggefahren: AlleFahrbahnen sind möglich

• Es wird in zwei Richtungen gefahren

– Das Auto fährt vom Beobachter weg: Die rechte Hälfte der Spuren ist gültig(Nummern größer oder gleich der Hälfte)

– Das Auto fährt auf den Beobachter zu: die linke Hälfte der Spuren ist gültig(Nummern kleiner der Hälfte)

6

4 Adaptive Cruise Control

Adaptive Cruise Control stellt die minimale Ausbaustufe dar. Die Autos sollen auf einerSpur im Flur geradeaus fahren können. Außerdem sollen Spurwechsel möglich seinund der Abstand zu voraus fahrenden Fahrzeugen soll einen vorgegebenen Abstandnicht unterschreiten (Sicherheitsabstand).

Wir haben diese Funktionen als drei getrennte Komponenten implementiert:

• Die Position des Autos wird in einer separaten Komponente bestimmt, da diesenicht nur zur Navigation, sondern auch zur Erfüllung der weitergehenden Szena-rien benötigt wird.

• Eine Seitenabstandsregelung ist zuständig für Spurhalten und Spurwechsel.

• Ein Tempomat ist zuständig für die Einhaltung des Sicherheitsabstands nach vor-ne.

Diese Komponenten werden in den folgenden Abschnitten detailliert beschrieben.

4.1 Bestimmung der Position des Autos

Zur Bestimmung der Position des Autos wird über den Flur, in dem gefahren wird einzweidimensionales Koordinatensystem gelegt. In diesem Koordinatensystem entsprichtdie Y-Koordinate dem Abstand von der linken Wand des Flures. Die X-Koordinate ent-spricht der gefahrenen Flurlänge.

Die Positionsbestimmung setzt sich aus der Bestimmung des aktuellen Abstands zurlinken Wand, der aktuellen Y-Koordinate, und der, um gefahrene Kurven bereinigten,zurückgelegten Strecke, welche der aktuellen X-Koordinate entspricht, zusammen.

4.1.1 Bestimmung des Abstands zur Wand

Da die Messwerte des linken Sensors am Auto nur dem Abstand zur linken Wand ent-spricht, wenn das Auto exakt parallel zu den Wänden fährt, können die gemessenenDaten nicht direkt verwertet werden.

Es muss eine Möglichkeit gefunden werden auch bei einer Neigung des Autos denorthogonalen Abstand zur linken Wand zu messen.

Die Notwendigkeit eines solchen Ansatzes wird in Abbildung 4.1 visualisiert. Zu er-kennen ist ein Auto, welches den Flur entlangfährt. Da dieses nicht exakt parallel zuden Wänden fährt, ist eine deutliche Diskrepanz zwischen dem gemessenen Abstandzur Wand l inksgemessen und dem tatsächlichen Abstand zur Wand l inkstatschl ich erkenn-bar.

Diese Diskrepanz wird umso größer, desto größer die Neigung des Autos ist und führtzum Beispiel beim Wechsel der Spur, bei dem stark eingelenkt wird, zu einer völligenFehleinschätzung der eigenen Position.

Um dies zu ermöglichen werden zusätzlich die Messdaten des rechten Ultraschallsen-sors ausgewertet. Auf der Grundlage des Strahlensatzes wird aus der gemessenen Breitedes Flures und aus der tatsächlichen Breite des Flures auf den tatsächlichen Abstand zurlinken Wand geschlossen.

7

Abbildung 4.1: Bestimmung des Abstands zur linken Wand

Diese Berechnung wird in Gleichung 1 gezeigt. Dabei wird das Verhältnis der gemes-senen Breite des Flures zur tatsächlichen Breite des Flures Brei tetat mit dem Verhältnisvon gemessenen linken Abstand zur Wand Ygem sowie dem tatsächlichen Abstand zurlinken Wand Ytat gleichgesetzt. Der gemessene Abstand zur linken Wand entspricht da-bei dem Wert des linken Ultraschallsensors USl inks. Die gemessene Breite des Fluresist die Summe aus den Messdaten der beiden seitlichen Ultraschallsensoren und desAbstandes zwischen diesen.

Diese Gleichung wurde zur Berechnung der unbekannten Variable Ytat umgestellt. Indieser Notation wird dies in Gleichung 1 dargestellt.

Ytat = Ygem ∗Brei tetat

Brei tegem= USl inks ∗

Brei tetat

USl inks + AutoBrei te + USrechts(1)

4.1.2 Bestimmung der tatsächlich gefahrenen Strecke

Da das Auto nicht immer nur genau in X-Richtung fährt, sondern, zum Beispiel beieinem Spurwechsel, auch eine Y-Komponente in die gefahrene Strecke einfließt, ist esnicht möglich die überwundene Distanz im Flur direkt aus dem Odometers des Autoszu bestimmen. Die Y-Komponente muss aus der gefahrenen Strecke heraus gerechnetwerden.

Dazu bedienen wir uns der Vektoraddition.Die gefahrene Strecke zu einem Zeitpunkt t, welche wir als odometer(t) bezeichnen,

entspricht dem Betrag eines Vektors von der Ausgangsposition des Autos zur neuenPosition des Autos. Dieser Vektor setzt sich aus einer X und einer Y-Komponente zu-sammen. Dabei entspricht die Y-Komponente dem Abstand zur linken Wand und dieX-Komponente der im Flur überwundenen Distanz.

Dies wird in Gleichung 2 gezeigt.

8

Abbildung 4.2: Komponenten der tatsächlich im Flur zurückgelegten Strecke

odometer = | ~v |= |(X tat − X ′tat , Ytat − Y ′tat)T | (2)

Da nicht die Veränderung zum Ursprung des verwendeten Systems, sondern seit derletzten Messung betrachtet werden soll wird die Veränderung zwischen aktuellen undgespeicherten Werten betrachtet. Dabei steht ein Strich für den gespeicherten Wert derletzten Messung.

Diese Gleichung kann zur Berechnung der seit Beginn der Fahrt überwundenen Di-stanz X tat umgestellt werden. Die Berechnung von X tat wird in Gleichung 3 gezeigt.

X tat = X ′tat −Æ

odometer2 + (Ytat − Y ′tat)2 (3)

Ist die Position des Autos zum Zeitpunkt t = 0 bekannt lässt sich die Position desAutos zum Zeitpunkt t = t x berechnen. Dazu wird die in der Zeit t überwundenenStrecke entsprechend der Fahrtrichtung zum letzten Y-Wert addiert oder von diesemsubtrahiert. Dafür muss die Länge des Flures bekannt sein.

4.2 Seitenabstandsregelung

Die Funktionen zum Spurhalten und Spurwechsel werden in unserer Implementierungvon einer Kaskadenregelung bereitgestellt. Der Kaskadenregelung wird ein Soll-Abstandzur linken Wand vorgegeben und sie bringt das Auto mit geeigneten Lenkbewegungenauf diese Spur. Dabei wird anhand der berechneten Position im Flur bestimmt, ob nachlinks oder nach rechts gefahren werden muss.

Hervorzuheben ist, dass bei uns ein und dieselbe Regelung für Spurhalten und Spur-wechsel verwendet wird. Bei einem Spurwechsel ändern wir lediglich den Soll-Abstandund die Regelung stellt sich sofort darauf ein. Im Gegensatz zu anderen Gruppen muss-ten wir nämlich für den Spurwechsel keine extra Lösungen entwickeln wie z.B. zustand-sabhängige oder hardgecodete Verhaltensweisen, da unsere Kaskadenregelung stabil

9

ist. Das heißt unsere Regelung kann beliebige Änderungen des Soll-Abstands zu belie-bigen Zeitpunkten handhaben. Aus diesem Grund eignet sie sich auch für Spurwechsel.Es ist auch möglich die Spurwechsel zu jedem beliebigen Zeitpunkt abzubrechen odergar im Slalom zwischen zwei Spuren zu fahren.

Nachteilig an der konsequenten Verwendung der Regelung ist allerdings die Anfällig-keit gegenüber Störungen bei der Positionsbestimmung, da sich unsere Regelung zu fast100% auf die bestimmte Position verlässt. Dies macht sich oft durch kleine Lenkbewe-gungen bemerkbar, die sich zwar sofort wieder ausgleichen, die aber eigentlich unnötiggewesen wären. Wenn das Auto an Hindernissen vorbeifährt, z.B. an einer Kiste im Flur,kommt es zudem zu einem Schwingen weg von dem Hindernis. Das Auto scheint dabeivon Hindernissen „abgestoßen“ zu werden.

4.2.1 Bestimmung des Sollabstands

Der Sollabstand zur linken Wand wird aus der hinterlegten Zielspur berechnet. Solldas Auto als Gegenvekehr fahren ist die Wand in Fahrtrichtung rechts von dem Autodie entsprechende Referenzwand. Für diese Berechnung wird davon ausgegangen, dassalle Spuren die selbe Breite haben und, dass deren Summe bekannt ist. In unserem Fallentspricht die Summe aller Spuren der Breite des Flures und ist fest codiert.

Da wir davon ausgehen, dass die Spuren von 0 bis n durchnummeriert sind, wobeiSpur 0 direkt an der Referenzwand liegt, können wir die Breite einer einzelnen Spurnach Gleichung 4 berechnen.

Brei tespur =Brei tF lur

AnzahlSpuren(4)

Für die folgenden Berechnungen wollen wir zunächst keinen Gegenverkehr betrach-ten. Entsprechend fahren alle Autos von einem Beobachter weg.

Mit dieser Größe und der Nummer der Spur lässt sich der Abstand von der linkenWand berechnen. Das Fahrzeug soll immer mittig in einer Spur fahren. Entsprechenderrechnet sich der Abstand zur linken Spurbegrenzung AbstandSpur nach Gleichung 5.

AbstandSpur =Brei teSpur − Brei teAuto

2(5)

Entsprechend muss von der Breite der Spur die Breite des Autos subtrahiert werden.Damit das Auto mittig fährt, muss der Abstand rechts und links vom Auto gleich großsein.

Sind mehr, wie eine Spur vorhanden, muss die Summe der Breiten der Spuren linksvon dem Auto zu dem Wert von AbstandSpur addiert werden. Dies ergibt den Sollab-stand tar get_le f t, dessen Berechnung in Gleichung 6 gezeigt wird. Mit lane wird dieSpur bezeichnet, auf der sich das Auto befinden soll.

tar get_le f t = lane ∗ Brei teSpur + AbstandSpur (6)

10

Für den Gegenverkehr können wir die eingeführten Gleichungen direkt weiterver-wenden, Der Wert tar gelle f t muss dafür auf die gegenüberliegende Wand übertragenwerden.

Den entsprechenden Sollabstand erhält man, indem man von der Breite des Flurestar gelle f t und die Breite des Autos subtrahiert.

Soll während der Fahrt die Spur gewechselt werden, muss der Sollabstand anhandder neuen Spurnummer neu berechnet werden. Dabei sind nur die in Kapitel 3.1.2„Behandlung ungültiger Werte“ genannten Regeln für die Spurwahl zu beachten.

4.2.2 Einschub: Kurze Einführung zu Regelungen und PID-Regler

Bei einer Regelung wird eine Regelgröße (Ist-Wert) eines Systems fortlaufend gemes-sen und mit einer Führungsgröße (Soll-Wert) verglichen. Die Aufgabe der Regelung istes, auf das System einzuwirken, sodass der Ist-Wert an den Soll-Wert herangeführt wird.

Üblicherweise hat eine Regelung die in Abbildung 4.3 abgebildete Struktur. Charak-teristisch ist die Rückführung des Ist-Werts und die Differenzbildung mit dem Soll-Wert.Man spricht daher auch von einem Regelkreis. Zu beachten ist, dass der Regler nichtdirekt auf das System einwirkt, sondern hierzu auf ein Stellglied zurückgegriffen wird.

Regler Stellglied Systemu

Messglied

w

Führungsgröße

e y

Regelgröße

−

Abbildung 4.3: Regelkreis. Die Differenz e = w − y ist die Regelabweichung und u istdie Reglerausgangsgröße.

Als Regler werden oft PID-Regler eingesetzt. Die Stellgröße u eines PID-Reglers setztsich aus 3 Teilen zusammen: u= uP + uI + uD

Der P-Anteil ist der wichtigste Teil. Er erzeugt eine Stellgröße uP = KP · e, dieproportional zur Regelabweichung e ist. Beispiel Temperaturregelung: Wenn die Ist-Temperatur y niedriger ist als die Soll-Temperatur w, dann ist e positiv und es wirdgeheizt. Im umgekehrten Fall ist e negativ und es wird gekühlt. Je größer dabei die Re-gelabweichung e ist, desto stärker wird auf das System eingewirkt. Allerdings unterliegtdas Stellglied in der Praxis natürlich einer Stellgrößenbeschränkung (jeder Motor hateine maximale Leistung, jede Lenkung hat einen maximalen Lenkeinschlag usw.).

Der I-Anteil erzeugt eine Stellgröße uI = KI ·∫

e in Abhängigkeit von der Fehlersum-me über die Zeit. I-Anteile bzw. I-Glieder in Regelkreisen ermöglichen stationäre Ge-nauigkeit trotz Störungen. Wenn beispielsweise bei einem Auto die Lenkung aufgrundmechanischer Probleme einen Linksdrall hätte, so würde das Auto normalerweise im-

11

mer ein bisschen zu weit links fahren. Ein I-Anteil gleicht dies über die Fehlersummenach einiger Zeit aus.

Der D-Anteil erzeugt eine Stellgröße uD = KD · e in Abhängigkeit von e, der zeitlichenÄnderung der Regelabweichung. Der D-Anteil kann bei vielen Systemen Überschwin-gen reduzieren. Überschwingen heißt einfach gesagt, dass die Regelung über das Zielhinausschießt und sich dann dem Soll-Wert von der anderen Seite nähern muss (abernicht alle Systeme sind anfällig für Überschwingen). Als anschauliches Beispiel kannman sich eine Heizung vorstellen: Würde man die Heizung erst dann abdrehen, wenndie gewünschte Temperatur erreicht wurde, dann wird die Temperatur noch deutlichweiter steigen, da die Heizkörper nicht sofort kalt werden, sondern nachheizen. Bei ei-ner Heizungsregelung wäre also ein D-Anteil angebracht, der die Heizung schon vordem Erreichen der Soll-Temperatur zurückfährt.

Die Parameter KP , KI und KD sind Konstanten, mit denen der Einfluss der verschiede-nen Anteile eingestellt werden kann. Bei einfachen Systemen werden die Werte dieserKonstanten meist experimentell oder mittels sogenannter Faustformelverfahren festge-legt. Es gibt auch sogenannte strukturvariable Regelungen, bei denen die K-Wertekeine Konstanten sind, sondern in Abhängigkeit vom Systemzustand gewählt oder so-gar daraus abgeleitet (berechnet) werden.

Man spricht auch von einem P-Regler, wenn nur der P-Anteil verwendet wird (KI =KD = 0), oder von einem PD-Regler, wenn nur der P- und D-Anteil verwendet werden(KI = 0) usw.

4.2.3 Aufbau und Funktionsweise der Kaskadenregelung

Zunächst sollte noch der Begriff Kaskadenregelung erläutert werden: In einer Kas-kadenregelung sind mehrere Regelkreise ineinander verschachtelt. So kann es zumBeispiel, wie bei uns, einen inneren und einen äußeren Regelkreis geben. Der innereRegelkreis ist dabei in den äußeren eingebettet.

Die Struktur unserer Kaskadenregelung ist in Abbildung 4.4 dargestellt. Diese Re-gelung regelt den Abstand zur linken Wand - ein beliebiger Soll-Abstand kann vonaußen vorgegeben werden (z.B. von anderen Modulen). Hervorzuheben ist, dass dieReglerausgangsgröße uA des äußeren Regelkreises der Führungsgröße wI des innerenRegelkreises entspricht. Anschaulich kann man daher sagen, dass der innere Regelkreiseine Art intelligentes Stellglied für den äußeren Regelkreis darstellt.

Dies ist auch die Kernidee unserer Kaskadenregelung: Der innere Regler regelt le-diglich die Seitwärtsgeschwindigkeit (die Seitwärtsgeschwindigkeit ist die Geschwin-digkeitskomponente relativ zur linken Wand und entspricht damit gerade der zeitlichenÄnderung des Seitenabstands). Der äußere Regler nutzt dies aus, indem er anhand derAbweichung vom Soll-Abstand eine Seitwärtsgeschwindigkeit berechnet, die geeignetist die Abweichung vom Soll-Abstand zügig zu reduzieren. Diese Seitwärtsgeschwindig-keit wird an den inneren Regler weitergegeben - der äußere Regler gibt also quasi einegewisse Seitwärtsgeschwindigkeit „in Auftrag“.

Eine wesentliche Eigenschaft dieser Kaskadenregelung ist, dass ein maximaler Winkelbeim Spurwechsel festgelegt werden kann. Dies wird erreicht, indem die vom äußerenRegler angeforderte Seitwärtsgeschwindigkeit begrenzt wird. In den Abbildungen 4.5

12

P-Regleraußen

P-Reglerinnen

Auto∫uI

SetServo(uI)

MessgliedSeitwärtsgeschw.

MessgliedAbstand

wA

Soll-Abstand

eA y y

Ist-Abstand

−−uA = wI

Soll-Seitwärtsgeschwindigkeit

eI

Abbildung 4.4: Strukturdiagramm der Kaskadenregelung. Für die Lenkung bzw. dasStellglied wurde aus Platzgründen kein eigener Block gezeichnet.

und 4.6 ist der entsprechende Code des äußeren und des inneren Reglers zu sehen, derim Folgenden erläutert wird.

Äußerer Regler (Abb. 4.5):Die Begrenzung der Seitwärtsgeschwindigkeit erfolgt in Abhängigkeit der (absolu-

ten) Geschwindigkeit mittels limit_magnitude und führt dazu, dass das Auto stetsmit einem Winkel von maximal ca. 30◦ einen Spurwechsel vollzieht. Darin ist auch dieStabilität unserer Kaskadenregelung begründet, die ein einzelner P-Regler nicht hätte.Dies wird im nächsten Abschnitt „Instabilität eines einzelnen PID-Reglers“ noch näherbeleuchtet.

Der äußere Regler ist ein eigenständiger Task und hat eine Periode von 100ms.Innerer Regler (Abb. 4.6):Der innere Regler berechnet die Abweichung von der Soll-Seitwärtsgeschwindigkeit

und berechnet daraus seine Reglerausgangsgröße, die an den Servo-Motor der Lenkunggeschickt wird. Bei der Berechnung der Reglerausgangsgröße wird ein KP in Abhängig-keit von der Geschwindigkeit des Autos gewählt. Es handelt sich hierbei also um einestrukturvariable Regelung, bei der anhand des Systemzustands (hier: Geschwindigkeit)zwischen verschiedenen KP ausgewählt wird (siehe auch den Abschnitt 4.2.2 „Einschub:Kurze Einführung zu Regelungen und PID-Regler“). Das Umschalten zwischen verschie-denen KP sorgt in diesem Fall dafür, dass auch bei langsamen Geschwindigkeiten zügigdie angeforderte Soll-Seitwärtsgeschwindigkeit erreicht wird.

Zu beachten ist, dass der innere Regler kein eigenständiger Task ist, sondern verzahntwurde mit dem Task des Tempomaten. Das liegt daran, dass der innere Regler abhängigist von der aktuellen Geschwindigkeit des Autos. Da die Geschwindigkeit aber vomTempomaten kontrolliert bzw. geändert wird, bietet es sich an, den Code des innerenReglers immer direkt im Anschluss an den Tempomaten aufzurufen - damit der Reglermit der richtigen Geschwindigkeit arbeitet.

Der Tempomat hat übrigens eine Periode von 50ms und somit wird der innere Reglerdoppelt so häufig aufgerufen wie der äußere Regler. Dass der innere Regler schnellerausgelegt wird als der äußere, ist bei solchen Kaskadenregelungen üblich. Schließlich

13

könnte es sonst passieren, dass eine vom äußeren Regler generierte Reglerausgangs-größe, die nunmal die Führungsgröße für den inneren Regler darstellt, gar nicht vominneren Regler genutzt wird.

Weitere Anmerkungen:Zum besseren Verständnis der Kaskadenregelung sei angemerkt, dass das Zusammen-

spiel der Regler in unserer Kaskadenregelung vergleichbar ist mit dem Zusammenspielder Schichten im OSI-Schichtenmodell oder im TCP/IP-Modell. Schließlich greifen dortdie höheren Schichten zur Erbringung ihrer Dienste auf die unteren Schichten zurück,ähnlich wie in unserer Regelung der äußere Regler auf den inneren zurückgreift. Mankann dies auch als eine Instanz des Teile-und-Herrsche-Prinzips (divide and conquer)ansehen.� �

1 void runKeepDistance ( void ) {2 portTickType lastWakeTime = os_getTime ( ) ;3 const in t f requency = 100;

5 i n t16_ t e r ro r = 0;6 const i n t 8 _ t K_P = 1;

8 i n t 8 _ t MAX_LEFT_SPEED = 0;

10 for ( ; ; ) {11 os_frequency (&lastWakeTime , frequency ) ;12 i f ( p o s C a l c u l a t i o n I n i t i a l i z e d==1) {13 MAX_LEFT_SPEED = 7 * Drive_Speed ;14 e r ro r = t a r g e t _ l e f t − y_pos ;15 t a r g e t _ l e f t _ s p e e d = −l imit_magnitude (K_P * error , MAX_LEFT_SPEED ) ;16 }17 }18 }� �

Abbildung 4.5: Code des äußeren Reglers der Kaskadenregelung. Die Berechnung vonMAX_LEFT_SPEED ist so ausgelegt, dass bei einem Spurwechsel ein Winkelvon ca. 30 Grad niemals überschritten wird.

In dem Strukturdiagramm aus Abbildung 4.4 gut zu sehen ist auch, dass wir 2 se-parate Messglieder verwenden. Das liegt daran, dass wir bei der Messung der Seit-wärtsgeschwindigkeit nicht einfach die zeitliche Änderung des Seitenabstands neh-men konnten, weil dies zu einer zu starken Störanfälligkeit geführt hätte. Wir habenstattdessen eine Durchschnittsbildung implementiert. Die Messglieder werden detail-liert in den Abschnitten 4.2.5 „Messung des Seitenabstands“ und 4.2.6 „Messung derSeitwärtsgeschwindigkeit“ beschrieben (ab Seite 16).

4.2.4 Instabilität eines einzelnen PID-Reglers

Ein einzelner PID-Regler für die Seitenabstandsregelung führt zu einer instabilen Re-gelung. Zur Illustration soll Abbildung 4.7 dienen. Sie zeigt die von einem P-Reglergenerierte Stellgröße in Abhängigkeit von der Position im Flur (der Einfachheit hal-

14

� �1 i n t16_ t kp i _e r ro r = 0;2 i n t 8 _ t kpi_K_P = 10;3 void doKeepDistanceInner ( i n t 8 _ t Drive_Speed ) {4 // S t e e r i n g depends on the c u r r e n t speed .5 // At low sp e ed s the s t e e r i n g must be s t r o n g e r than at high sp e ed s .6 i f ( Drive_Speed == 1) {7 kpi_K_P = 10;8 } else i f ( Drive_Speed == 2) {9 kpi_K_P = 7;

10 } else i f ( Drive_Speed == 3) {11 kpi_K_P = 5;12 } else i f ( Drive_Speed == 4) {13 kpi_K_P = 4;14 } else i f ( Drive_Speed == 5) {15 kpi_K_P = 3;16 } else i f ( Drive_Speed == 6) {17 kpi_K_P = 2;18 } else i f ( Drive_Speed >= 7) {19 kpi_K_P = 1;20 }

22 kp i _e r ro r = c u r r e n t _ l e f t _ s p e e d − t a r g e t _ l e f t _ s p e e d ;23 Drive_SetServo ( l imit_magnitude ( kpi_K_P * kp i_er ror , 100));24 }� �

Abbildung 4.6: Code des inneren Reglers der Kaskadenregelung.

ber werden I- und D-Anteil weggelassen). Wie man gut sehen kann, ist die Stellgrößeproportional zur Abweichung vom Soll-Abstand.

Bei sehr großen Regelabweichungen wird also sehr stark eingelenkt. Ist die Lenkbe-wegung aber zu stark, fährt das Auto in einer Kreisbahn gegen die Wand, oder vollführtgar eine Wendung. „Viel hilft viel“ gilt bei diesem System also nicht. Das System istnämlich nichtlinear. Vereinfacht ausgedrückt: Stärkere Lenkbewegungen führen nichtimmer schneller zum Ziel. Das ist ganz anders als bei einer Heizung (lineares System) -dort wird stärker geheizt, je mehr man die Heizung aufdreht.

Unsere Kaskadenregelung löst dieses Problem gewissermaßen mit dem Teile-und-Herrsche-Prinzip: Der innere Regler kann eine beliebige Seitwärtsgeschwindigkeit her-beiführen. Der äußere Regler fordert entsprechend der Abweichung vom Soll-Abstandeine geeignete Seitwärtsgeschwindigkeit an - allerdings wird der Betrag der Seitwärts-geschwindigkeit begrenzt, sodass ein Übersteuern vermieden wird. Ein Winkel von ca.30 Grad wird bei Spurwechseln somit niemals überschritten. Auf diese Weise wird dieNichtlinearität des Systems von unserer Kaskadenregelung handhabbar gemacht.

Fazit: Aus regelungstechnischer Sicht ist die Regelung mit einem einzelnen PID-Reglerinstabil, da sie nicht mit beliebigen Änderungen der Führungsgröße umgehen kann. Eineinzelner PID-Regler eignet sich daher bestenfalls für das Spurhalten. Für Spurwechselhingegen kann ein solcher Regler nur begrenzt eingesetzt werden - z.B. könnte manviele kleine Spurwechsel nacheinander durchführen oder man könnte die Verstärkung

15

abhängig machen vom Betrag der Regelabweichung. Dies führt allerdings zwangsläufigzu einer sehr langsamen Regelung: Der Soll-Abstand wird erst nach einer langen Zeiterreicht.

Abbildung 4.7: Stellgröße eines P-Reglers in Abhängigkeit von der Position im Flur. Dierote gestrichelte Linie stellt den Soll-Abstand dar. Die blaue durchgezo-gene Linie zeigt, wie das Auto übersteuert, wenn die Abweichung vomSoll-Abstand zu groß ist und deshalb zu stark eingelenkt wird.

4.2.5 Messung des Seitenabstands

Das Messglied für den Seitenabstand verwendet einfach den von der Positionsbestim-mung berechneten Abstand (Y ).

4.2.6 Messung der Seitwärtsgeschwindigkeit

Wie bereits zu Beginn des Abschnitts erwähnt, wäre der einfachste Ansatz, die Differenzzwischen dem letzten Seitenabstand und dem aktuellen Seitenabstand zu berechnen.Schließlich entspricht die Seitwärtsgeschwindigkeit gerade der zeitlichen Änderung desSeitenabstands. Allerdings ist dieser Ansatz extrem anfällig für Messrauschen: Durch dieBeschaffenheit der Wände, der Flurleisten und auch wegen der Türrahmen kommt esimmer wieder zu Sprüngen in dem gemessenen Abstand. Die Seitwärtsgeschwindigkeitwürde bei einem naiven Ansatz in solchen Fällen deutlich überschätzt und es würdeschnell zu extremen Lenkausschlägen kommen.

16

� �1 #define MEASURE_LEFT_SPEED_ITEMS 62 void runMeasureLeftSpeed ( void ) {3 portTickType lastWakeTime = os_getTime ( ) ;4 const in t f requency = 50;

6 i n t16_ t c y c l i c _ b u f f e r [MEASURE_LEFT_SPEED_ITEMS ] ;7 u in t8_ t i = 0;

9 i n t 8 _ t k = 0;10 i n t16_ t sum = 0;

12 // I n i t i a l i z e c y c l i c _ b u f f e r .13 for (k = 0; k < MEASURE_LEFT_SPEED_ITEMS ; ++k) {14 c y c l i c _ b u f f e r [k] = 0;15 }

17 for ( ; ; ) {18 os_frequency (&lastWakeTime , frequency ) ;

20 c a l c u l a t e C u r r e n t P o s i t i o n ( ) ;21 c y c l i c _ b u f f e r [ i % MEASURE_LEFT_SPEED_ITEMS] = y_pos_prev−y_pos ;22 i = i + 1;

24 // C a l c u l a t e c u r r e n t speed .25 sum = 0;26 for (k = 0; k < MEASURE_LEFT_SPEED_ITEMS ; ++k) {27 sum = sum + c y c l i c _ b u f f e r [k ] ;28 }29 c u r r e n t _ l e f t _ s p e e d = (( f l o a t )sum) / MEASURE_LEFT_SPEED_ITEMS30 * (1000.0 / frequency ) ;31 }32 }� �

Abbildung 4.8: Code des Messglieds zur Messung der Seitwärtsgeschwindigkeit mittelsDurchschnittsbildung.

17

Daher führen wir stattdessen eine gewisse Anzahl der letzten/jüngsten Differenzenmit und bilden den Durchschnitt. Der Vorteil ist, dass sich das Messrauschen nichtmehr so stark auswirkt. Nachteilig ist allerdings, dass sich Änderungen der Seitwärts-geschwindigkeit erst nach einigen Zeitschritten voll auswirken. Die Messung der Seit-wärtsgeschwindigkeit wird also stärker verzögert als zuvor. In der Praxis zeigt sich al-lerdings ein sehr gutes, gleichmäßiges Fahrverhalten.

Der Code des Messglieds ist in Abbildung 4.8 zu sehen. Die Anzahl der mitgeführtenDifferenzen ist konfigurierbar über das Macro MEASURE_LEFT_SPEED_ITEMS, damit manden Tradeoff zwischen Robustheit und Schnelligkeit der Messung beliebig einstellenkann.

4.3 Tempomat

Da bei dem Tempomat im Gegensatz zu der Seitenabstandsregelung weniger Variablenbetrachtet werden müssen, kann die verwendete Regelung deutlich einfacher und Res-sourcen schonender ausfallen. Deshalb haben wir uns für eine Stufen basierte Regelungentschieden.

Entsprechend des Abstands zu dem voraus fahrenden Fahrzeugs wird eine Geschwin-digkeitsstufe gewählt.

Je größer der Abstand ist, desto schneller darf das Auto fahren. Dabei wurden vonuns zwei Stufen fest definiert:

• Mindestabstand unterschritten -> stehen bleiben (Zeile 3 bis 9 in Abbildung 4.9)

• Freie Fahrt -> maximale Geschwindigkeit erlaubt (Zeile 12 bis 14 in Abbildung4.9)

Die restlichen Stufen wurden aus dem gemessenen Frontabstand errechnet. DieseDefinition der beiden genannten Stufen erleichtert die Aufstellung einer Formel zur Be-rechnung der weiteren Stufen. Zudem wird die Reaktionszeit bei einem Unterschreitendes Mindestabstands verkürzt, da die Stufe nicht dynamisch errechnet werden mussund ganz am Beginn des Regelprozesses überprüft werden kann.

Der Bremsweg eines Autos verlängert sich mit steigender Geschwindigkeit. Um aufnicht vorhersehbare Ereignisse, wie einen Unfall, bei dem das voraus fahrende Fahrzeugsofort steht, reagieren zu können muss der Abstand zu dem voraus fahrenden Fahrzeugentsprechend mit steigender Geschwindigkeit verlängert werden.

Die Implementierung der stufenweisen Regelung führt automatisch zu diesem ge-wünschten Verhalten, da der notwendige Abstand zum voraus fahrenden Fahrzeug um-so größer wird, desto höher die Geschwindigkeitsstufe gewählt wird.

Bei unseren Autos verwenden wir 6 Geschwindigkeitsstufen. Dabei entspricht Stufe 0einem stehenden Auto und Stufe 5 der maximalen Geschwindigkeit.

Stufe 5 stellt dabei eine obere Grenze für alle Autos dar. Für ein einzelnes Auto kanneine geringere Höchstgeschwindigkeit gewählt werden. Diese wird während der Pro-grammierung des Autos in der Variable maxSpeed gespeichert. Die minimale Geschwin-digkeit ist immer Stufe 0. Entsprechend wird in Abbildung 4.9 nur für Abstände größerdes Mindestabstands diese Variable überprüft.

18

� �1 i f ( Us_Data . Front_DataVal id && p o s C a l c u l a t i o n I n i t i a l i z e d==1) {2 f r o n t = Us_Data . Front_Dis tance ;3 i f ( f r o n t >= 0 && f r o n t < 40) {4 doKeepDistanceInner (1 ) ;5 i f ( Drive_Speed > 3) {6 Drive_SetMotor (−2);7 doKeepDistanceInner (1 ) ;8 os_wait (50) ;9 }

10 Drive_SetMotor (0 ) ;11 } else {12 i f ( f r o n t > 80 && maxSpeed>=5) {13 Drive_SetMotor (maxSpeed ) ;14 doKeepDistanceInner (5 ) ;15 } else {16 f r o n t = div (( f ront −40) , 10) . quot ;17 i f ( f ront>maxSpeed) f r o n t = maxSpeed ;18 i f ( f r o n t > 0 && f r o n t <= 4) {19 Drive_SetMotor ( f r o n t ) ;20 doKeepDistanceInner ( f r o n t ) ;21 }22 }23 }24 } else {25 doKeepDistanceInner ( Drive_Speed ) ;26 }27 }� �

Abbildung 4.9: Code zur Frontabstandsregelung

In Zeile 12 darf die Maximalgeschwindigkeit nur direkt gesetzt werden, wenn diesenicht limitiert wurde.

In Zeile 17 wird die berechnete Geschwindigkeitsstufe auf das erlaubte Maximumreduziert, falls dieses überschritten wurde.

Eine Besonderheit des von uns implementierten Tempomaten ist eine aktive Brems-funktion. Diese wird ausgelöst, wenn das Auto bei einem Unterschreiten des Mindestab-standes zu schnell fährt. Dies geschieht, wenn plötzlich ein Objekt vor dem Auto auf-taucht. Ein Beispiel dafür ist ein Fußgänger, der von der Seite vor das Auto läuft. Zusehen ist dies in den Zeilen 5 bis 9 der Abbildung 4.9. Dort werden die Elektromotorenfür eine kurze Zeit rückwärts laufen gelassen.

Da die Seitenabstandsregelung geschwindigkeitsabhängig ist, ist es sinnvoll die Len-kung an die Regelung des Geschwindigkeit zu koppeln. Bei jeder Ausführung derFrontabstandsregelung, deren Quellcode in Abbildung 4.9 gezeigt wird, wird die Len-kung in Form eines Aufruf der Methode doKeepDistanceInner, welche in Abbildung4.6 erläutert wird, ausgeführt.

19

5 Car2Car Kommunikation

Für die Kommunikation zwischen den Fahrzeugen nutzen wir ein Protokoll, das aus-schließlich auf Broadcastnachrichten beruht. Ein Nachrichtenpaket setzt sich aus denMetadaten, die durch die API vorgegeben sind, und einen Nachrichteninhalt, der im-mer das gleiche Format aufweist, zusammen.

PaketMetadaten DatendestinationId currentLanesourceId destinationLanetype xPositiondataLengthpriority

Tabelle 5.1: Aufbau eines Nachrichtenpakets

Der Nachrichteninhalt besteht lediglich aus der aktuellen Fahrbahn des Fahrzeugs(currentLane), der geplanten Zielfahrbahn (destinationLane) und der aktuellen Positionauf der Fahrbahn (xPosition). Die Informationen werden dabei vom Modul CarState be-reitgestellt. Da wir nur mit Broadcastnachrichten arbeiten, ist die destinationId immer255. Für die Kommunikation zwischen einzelnen Fahrzeugen wäre auch eine direkteKommunikation mit den Fahrzeug-IDs möglich, doch für die Umsetzung der Szenarienwurde dies nicht gebraucht.Das Unterscheiden der Nachrichten geschieht über den Nachrichtentyp in den Metada-ten. Dieser gibt der Nachricht eine Bedeutung, da der Inhalt der Nachrichten wie bereitsgesagt, immer die gleichen Informationen enthält.

NachrichtentypenSchlüssel Wert BedeutungMSG_EMERGENCY 61 KrankenwagenMSG_CONGESTION 62 StaumeldungMSG_CONGESTIONEND 72 StauauflösungMSG_DANGER 63 HindernisMSG_ICE 64 EismeldungMSG_POSITIONREQUEST 65 PositionsanforderungMSG_POSITIONRESPONSE 66 PositionsantwortMSG_CONFIGURATION 67 Konfiguration

Tabelle 5.2: Nachrichtentypen und ihre Bedeutung

Abhängig vom Nachrichtentyp der Nachricht findet im Modul MessageControl eineentsprechende Behandlung statt. Näheres dazu wird im anschließenden Kapitel erläu-tert.

20

Das Verschicken der Nachrichten geschieht über unsere Communication Schnittstelle,die mit den Funktionen der API arbeitet. Außerdem wird hier festgelegt, dass lediglichdas AMB8420 Funkmodul zur Kommunikation genutzt wird.

21

6 Verkehrssituationen

Alle CarToCar Szenarien basieren auf dem Ansatz Erkennen einer Gefahr und den dar-auf folgenden Teilen dieser Information. In diesem Abschnitt werden die einzelnenUmsetzungen beschrieben, die in den Modulen TrafficControl, MapChecker und Mes-sageControl implementiert sind.

6.1 Verkehrsstau

Das Erkennen von Stau und anderen Hindernissen auf einer Fahrbahn geschieht überdie Frontsensoren. Wie bereits erwähnt, stoppt der Tempomat das Fahrzeug, wenn einMindestabstand nach vorne nicht mehr eingehalten wird. Sobald das Fahrzeug nun län-ger als drei Sekunden steht, hat es einen Stau erkannt und schaltet in den Staumodus. Indiesem Zustand pausiert das Fahrzeug alle Fahrfunktionen außer den Tempomaten, dadieser zum Erkennen der Stauauflösung benötigt wird. Weiterhin verschickt das Fahr-zeug nun in Intervallen von einer Sekunde Nachrichten vom Typ MSG_CONGESTION,um andere Fahrzeuge zu warnen.

Andere Fahrzeuge, die die Broadcastnachricht empfangen, prüfen anschließend mit-hilfe der Paketinformationen, ob die folgenen Bedingungen für sie zutreffen:

• Das Fahrzeug fährt auf der gemeldeten Fahrbahn

• Das Fahrzeug befindet sich vor dem Stau und hat einen Abstand von weniger alszwei Meter zum Stau

Wenn diese zwei Bedingungen erfüllt sind und sofern es mehrere Spuren in dieselbeFahrtrichtung gibt, leitet das Fahrzeug einen Spurwechsel ein. Dafür übergibt es derSeitenabstandsregelung den entsprechenden Soll-Abstand für die neue Fahrbahn, aufdie dann zugelenkt wird.

Die Auflösung eines Verkehrsstaus erkennt das Fahrzeug ebenfalls über die Frontsen-soren. Es reaktiviert alle seine Fahrfunktionen, meldet eine Stauauflösung und setztdann seine Fahrt fort.

6.2 Ausweichen von Krankenwagen

Ein Krankenwagen sendet während seiner Fahrt in Intervallen von einer Sekunde eineNachricht vom Typ MSG_EMERGENCY. Andere Fahrzeuge, die die Broadcastnachrichtempfangen, prüfen anschließend mithilfe der Paketinformationen, ob die folgenen Be-dingungen für sie zutreffen:

• Das Fahrzeug fährt auf der gemeldeten Fahrbahn

• Das Fahrzeug befindet sich vor dem Krankenwagen und hat einen Abstand vonweniger als zwei Meter zum Krankenwagen

Wie auch bei der Umfahrung von Verkehrsstaus, leitet das Fahrzeug bei Erfüllungder beiden Bedingungen einen Spurwechsel ein, um dem Krankenwagen freie Fahrt zugewähren. Auch in diesem Fall muss für einen Spurwechsel eine weitere Fahrbahn indie Fahrtrichtung gegeben sein.

22

6.3 Erkennen und kommunizieren von vereisten Fahrbahnen

Das Erkennen und Kommunizieren einer vereisten Fahrbahn gliedert sich in mehrereSchritte.

1. Ein Fahrzeug erkennt, dass es über eine vereiste Fahrbahn fährt.

2. Das Fahrzeug reagiert auf die vereiste Fahrbahn

a) Das Fahrzeug verlangsamt seine Geschwindigkeit

b) Das Fahrzeug sendet die Position der vereisten Fahrbahn an alle anderen Fahr-zeuge

3. Die anderen Fahrzeuge empfangen die Meldung und speichern diese ab

4. Alle Fahrzeuge prüfen zusätzlich zu den Infrarotsensoren, ob sie sich an einer Po-sition befinden, an der Eis gemeldet wurde.

5. Die gemeldete Position wird erreicht

a) Das Auto verlangsamt seine Geschwindigkeit

6.3.1 Erkennen einer vereisten Fahrbahn

Um eine vereiste Fahrbahn zu erkennen haben wir uns entschieden die Infrarotsensorenan der Unterseite der Autos auszuwerten. Diese werden genutzt, um weiße Flächen, dieEis darstellen sollen zu detektieren.

Jedes Auto verfügt über sechs Infrarotsensoren. Sobald mindestens zwei dieser Sen-soren eine Fläche erkennen, die heller, wie ein definierter Schwellwert sind, wird ange-nommen, dass eine vereiste Fahrbahn vorliegt.

6.3.2 Reaktion auf eine vereiste Fahrbahn

Jedes mal, wenn eine vereiste Fahrbahn erkannt wird, wird die Reaktion auf diese aus-gelöst. Dies führt dazu, dass ein Auto mehrfach auf eine Eisfläche reagiert und bis zumVerlassen der Eisfläche seine Position an die anderen Autos sendet.

Dies ermöglicht den anderen Autos den Beginn und das Ende einer vereisten Fahrbahnzu bestimmen.

Diese wird nicht auf dem Auto, welches die Eisfläche detektiert ausgeführt, da durchdie kontinuierliche Übertragung der eigenen Position der Gegenverkehr reagieren kann,obwohl das detektierende Auto die Eisfläche noch nicht verlassen hat.

Die erste Reaktion des Autos besteht jedoch darin, dass die eigene Geschwindigkeitreduziert wird, so lange das Auto sich auf Eis befindet. Dies geschieht, indem in der Ge-schwindigkeitsregelung ein oberes Limit gesetzt wird. Geschwindigkeitsstufen oberhalbdieses limits könne nicht mehr gewählt werden.

Die zweit Reaktion besteht in dem bereits erwähnten Versenden einer Broadcastnach-richt mit dem Typ MSG_ICE. Dazu wird das Nachrichtenschema 5.1 verwendet.

23

6.3.3 Reaktion auf Eismeldungen

Das Modul Mapchecker ist zuständig für die Verwaltung von empfangenden Eismeldun-gen. Wenn das Fahrzeug eine Nachricht des Typs MSG_ICE empfängt, wird in einemArray, das den Flur abbildet, die gemeldete Position eingetragen.

Während der Fahrt prüft das Mapchecker-Modul, ob sich das Fahrzeug Eisstellen nä-hert, die im Array gespeichert sind. Sobald das Fahrzeug in eine Nähe des Gefahrenbe-reichs gelangt, findet eine Geschwindigkeitsreduzierung statt. Die weiteren Reaktionensind bereits vom Detektieren von Eis bekannt. Es wird ebenfalls eine obere Schrankefür die Geschwindigkeitsstufen gesetzt. Diese wird wieder zurückgenommen, wenn derGefahrenbereich verlassen wurde.

Eine erneute Warnung an die anderen Autos wird nicht versendet, da diese die War-nung bereits bei der ersten Detektion empfangen haben. Außerdem wird nach demVerlassen des Gefahrenbereichs die Eismeldung aus dem Array gelöscht.

24

7 Einparken

Da die Aufgabe ein automatisiertes Einparken zu implementieren als Bonusaufgabe ge-stellt wurde, haben wir uns, obwohl die anderen Aufgaben als erfüllt angesehen werdenkonnten dazu entschieden dieses Szenario nicht zu implementieren.

Wir konnten uns nicht damit zufrieden geben eine mehr oder weniger gute Lösung fürdie Pflichtaufgaben abzugeben und eine eventuell funktionierende Bonusaufgabe abzu-geben. Stattdessen haben uns dafür entschieden die Pflichtaufgaben so zu optimieren,dass diese unter allen noch so widrigen Umständen funktionieren.

25

8 Tabellarischer Überblick der implementierten Funktionen

Modul KurzbeschreibungTeam4 Das Startmodul unserer Implementierung. Initialisiert

den CarState und startet den CarConfigurator.CarConfigurator Der CarConfigurator bearbeitet die empfangene Nach-

richt der Konfigurationsapp. Je nach Konfigurationwerden hier die benötigten Module gestartet und ein-gestellt.

CarState Das Modul, dass sich um den Zustand des Fahrzeugsdreht. Liefert Informationen für die Steuerung undKommunikation.

MovementController Beeinhaltet alle Fahrfunktionen wie die Seitenab-standsregelung, den Tempomaten, die Positionsbestim-mung sowie die Recover Funktion.

TrafficControl TrafficControl analysiert die Verkehrssituationen undist zuständig für das Melden von Eisgefahren und Ver-kehrstaus.

MessageControl Hier werden empfange Verkehrsnachrichten bearbeitetund situationabhängige Reaktionen eingeleitet.

MapChecker Der MapChecker ist zuständig für das Speichern undLöschen von Eismeldungen.

Communication Bietet einen Schnittstelle zum Verschicken von Ver-kehrsmeldungen.

Constants Konstanten, die in unsereren Implementierungen ge-nutzt werden, werden in diesem Modul angegeben.

Defines In Defines können Zusatzfunktionalitäten wie das Wi-relessExport Modul oder die Recoveryfunktion akti-viert werden.

WirelessExport Ein Zusatzmodul, dass Datensenken definiert um überFunk effizient Messreihen zu übertragen.

Util Bietet Hilfsfunktionen für unserer Implementierungen.

Tabelle 8.1: Übersicht über alle Module in unserer Implementierung

26

9 Sonstiges

9.1 WirelessExport-Modul und Plotter

Das WirelessExport-Modul ermöglicht es Datensenken zu definieren, in die von allenanderen Modulen Daten geschrieben werden können. Diese Daten werden innerhalbdes WE-Moduls gebuffert. Erst wenn genügend Daten in einer Datensenke gesammeltwurden, um eine Funknachricht komplett zu füllen, werden die Daten gesendet und derBuffer geleert. Dieses Vorgehen schont das Funkmodul und ermöglicht so eine effizienteÜbertragung von Messreihen.

Zu dem Modul gehört auch ein in Python geschriebener Plotter, der die übertrage-nen Messreihen der verschiedenen Datensenken auf einem Computer analyiseren unddarstellen kann (für den Empfang muss unser modifiziertes GPSConfig-Tool verwen-det werden). Für jeden neuen Typ von Datensenke kann man den Plotter um einenSinkHandler erweitern, der die serialisierten Daten analysiert und daraus einen Ploterstellt.

Um den normalen Betrieb nicht zu stören ist das WirelessExport-Modul normalerwei-se komplett deaktiviert.

Um es zu verwenden muss das Makro T4_ENABLE_WIRELESS_EXPORT definiert sein.

9.1.1 Beispiel: Export der Ultraschallsensor-Daten

An einem Beispiel soll die Verwendung des Moduls illustriert werden. Siehe dazu denCode in Abbildung 9.1, der im Folgenden erläutert wird.

Das WirelessExport-Modul wurde zur Analyse der Seitenabstandsregelung verwendet.Dazu wird im MovementController in der Funktion initMovementController eine Da-tensenke mit dem Namen US definiert. In der Funktion calculateCurrentPositionwerden dann ständig die aktuellen Sensordaten in die Datensenke geschrieben.Dazu wird die Funktion int we_export(char* sinkname, char* data, uint16_tdataLen) verwendet.

Das WirelessExport-Modul buffert diese Daten und schickt sie gebündelt in großenPaketen per Funk an den Rechner. Unsere modifizierte Variante des GPSConfig-Toolsschreibt alle Funknachrichten in eine Datei test.txt. Mit einem Aufruf des Plotters wiez.B. plotter.py test.txt 4 werden dann schließlich die Messreihen von dem Auto mitID 4 geplottet. Ein solcher Plot mit den Ultraschallsensor-Daten ist in Abbildung 9.2dargestellt. Der obere Graph stellt die Daten des linksseitigen Sensors dar, der Graphin der Mitte die Daten des rechtsseitigen Sensors und der Graph unten zeigt die Datendes Frontsensors. Zu beachten ist, dass in den mittleren Graph hereingezoomt wurde -die Plots sind nämlich interaktiv und man kann so beliebige Teile der Plots in den Fokusrücken und näher betrachten.

9.1.2 Abhängigkeiten des Plotters installieren

Der Plotter ist in Python 3.3 geschrieben und benötigt zudem einige Python-Libs:

• matplotlib: http://matplotlib.org/

27

� �1 void in i tMovementContro l ler ( void ) {2 // . . .

4 #i f d e f T4_ENABLE_WIRELESS_EXPORT5 #i f d e f T4_ENABLE_WE_SINK_US6 we_addSink ( "US" ) ;7 #endif8 #endif9 }

11 // . . .

13 void c a l c u l a t e C u r r e n t P o s i t i o n ( void ){14 // . . .

16 #i f def ined (T4_ENABLE_WIRELESS_EXPORT) && def ined (T4_ENABLE_WE_SINK_US)17 in t r e t ;18 uint16_t data [3] ;19 data [0] = Us_Data . Le f t _D i s t ance ;20 data [1] = Us_Data . R ight_Dis tance ;21 data [2] = Us_Data . Front_Dis tance ;22 r e t = we_export ( "US" , data , 6) ;23 #endif

25 // . . .26 }� �

Abbildung 9.1: Verwendung des WirelessExport-Moduls zum Export derUltraschallsensor-Daten. Dies ist ein Extrakt aus der QuelldateiMovementController.c.

• numpy: http://www.scipy.org/scipylib/download.html

• dateutil: http://www.lfd.uci.edu/~gohlke/pythonlibs/#python-dateutil

• pyparsing: http://www.lfd.uci.edu/~gohlke/pythonlibs/#pyparsing

• six: http://www.lfd.uci.edu/~gohlke/pythonlibs/#six

9.2 Recovery-Modus

Der Recovery-Modus ermöglicht das automatische Spurfinden in „verfahrenen“ Situa-tionen. Also bspw. wenn das Auto frontal vor einer Wand des Flurs steht.

Für solche Fälle ist ein Wendemanöver vorgesehen: Zuerst wird der Rückwärtsgangmit maximalem Lenkausschlag in eine Richtung eingelegt. Sobald das Auto 50cm vonder Wand entfernt ist, wird in die andere Richtung gelenkt und das Auto fährt nachvorne. Auf diese Weise richtet sich das Auto wieder in Richtung des Flurs aus und kannseine reguläre Fahrt fortsetzen.

28

Abbildung 9.2: Plot der Ultraschallsensor-Daten. Auf der vertikalen Achse sind jeweilsdie gemessenen Abstände in cm aufgetragen. Auf der x-Achse ist dieZeit in Sekunden aufgetragen.

9.2.1 Auslösung und Beendigung des Recovery-Modus

Abbildung 9.3 enthält ein detailliertes StateChart.

Der Recovery-Modus wird ausgelöst, wenn das Auto mehrere Sekunden lang stillstehtund die links und rechts gemessenen Abstände etwas größer sind als die Flurbreite. Letz-teres Kriterium ist außerordentlich wichtig, damit der Recovery-Modus nicht ausgelöstwird, wenn das Auto in einem normalen Stau steht.

29

Normaler Betrieb

Recovery Rückwärts

Recovery Vorwärts

[FRONT >= 50] [FRONT < 50]

[waitingTime >= 2 &&

(LEFT + RIGHT) > 240][LEFT + RIGHT < 220]

Abbildung 9.3: Statechart des Recovery-Modus. waitingTime entspricht der Stillstand-zeit in Sekunden. LEFT, RIGHT und FRONT sind die gemessenen Abstän-de in cm. Seitenabstandsregelung und Tempomat sind nur im normalenBetrieb aktiv.

Der Recovery-Modus wird beendet sobald die links und rechts gemessenen Abständewieder der Flurbreite entsprechen.

Für die Dauer des Recovery-Modus sind Seitenabstandsregelung und Tempomat kom-plett deaktiviert.

30

10 Fazit und Ausblick

Zusammenfassend sind wir mit unserer Arbeit sehr zufrieden. Wir bieten eine voll auto-matisierte und stabile Regelung, die ohne hart codierte Sequenzen auskommt. UnsereImplementierung ist sehr modular gehalten und ermöglicht eine einfache Anpassungan viele weitere Szenarien. Besonders stolz sind wir auch auf unsere Bluetooth-App zurKonfiguration der Autos. Diese hat sich als außerordentlich wertvoll in der Test- undDemonstrationsphase erwiesen, da man in schneller Abfolge und viele unterschiedlicheSzenarien testen kann, ohne dass die Software auf den Autos auch nur ein einziges Malverändert werden müsste. Das ist sehr zeitsparend und komfortabel.

Insgesamt war das Projektseminar für uns sehr herausfordernd und war dadurch miteinem hohen Erkenntnisgewinn verbunden. Die selbständige und freie Arbeit an densehr interessanten Aufgabenstellungen ließ nur wenige Motivationslücken aufkommen.Besonders viel dürfte unsere Gruppe im Bereich des Projekt- und Team-Managementsgelernt haben. Das Projektseminar war für die meisten Mitglieder das erste Projekt, dasin einer größeren Gruppe bearbeitet werden musste. Unsere Aufgabenverteilung wardaher zu Beginn nicht optimal. Relativ früh gab es Spannungen wegen der sehr unter-schiedlich wahrgenommenen Arbeitsleistungen im Team. Dies wurde in einem Gesprächmit unserem Betreuer besprochen, woraufhin sich die Situation deutlich verbessert hat.Wir haben dabei gelernt, dass man in einem Team möglichst früh zur Sprache bringensollte, wenn man mit etwas unzufrieden ist.

Es gibt von unserer Seite auch Feedback zu der bereitgestellten Hardware und Soft-ware. So gab es beispielsweise zu Beginn nur 2 Funkadapter (später wurden dann 2weitere nachbestellt). Dies war sehr frustrierend, da sehr häufig nicht genug Adapterfür alle Gruppen da waren. Ebenfalls wurden zu wenig Akkus bereitgestellt - unsereGruppe hat dann aus eigener Tasche 2 weitere Akkus bestellt und mit den anderenGruppen geteilt; sogar nach diesem Schritt sind uns noch einige Male die Akkus aus-gegangen. Auch gab es einige Bugs in der bereitgestellten API, die erst im Laufe desProjektseminars gefixt wurden. Daneben gibt es noch andere Mängel an der API, wiezum Beispiel das Odometer, welches nicht oft genug aktualisiert wird. Außerdem hatsich gegen Ende des Projektseminars herausgestellt, dass die API an einigen Stellenviel genauer arbeiten könnte: Die Abstandsmessung mit den Ultraschallsensoren arbei-tet beispielsweise mit einer Genaugikeit von nur 1cm. Dabei wäre ohne Weiteres eineGenauigkeit von 1mm möglich, was sämtliche Abstandsregelungen deutlich flüssigermachen würde. Ganz ähnlich verhält es sich mit der Feinheit der Motorsteuerung. DieAPI sieht nur die Stufen von -10 bis +10 vor. Allerdings wäre es von Seiten der Hardwa-re möglich tausende Stufen zu unterscheiden - dies hätte unseren Tempomaten ebenfallsdeutlich flüssiger gemacht. Leider haben wir von diesen Möglichkeiten erst gegen Endeerfahren und es war keine Zeit mehr, unsere Implementierung anzupassen.

31

10.1 Ausblick

Für die Zukunft bietet unsere Implementierung unserer Ansicht nach eine gute Grund-lage für weitere Projekte. Wir haben uns auch einige Verbesserungen für die Zukunftüberlegt:

• Die feste Verbindung mit dem Testflur kann aufgehoben werden, indem die Flur-breite nicht mehr hart codiert wird, sondern als die minimale gemessene Breitedes Flures der letzten Messungen gewählt wird. Lediglich die Länge der Streckemuss noch vorgegeben werden.

• Experimente haben gezeigt, dass mit Parameteranpassungen und wenigen Subrou-tinen auch eine kontrollierte Kurvenfahrt möglich sein sollte.

• Aus regelungstechnischer Sicht wäre es sinnvoll, eine Systemidentifikation durch-zuführen, also die Differentialgleichungen der Autos aufzustellen um eine Rege-lung auf analytische Weise herzuleiten (statt heuristisch vorzugehen). Dann wä-re es auch möglich, Störungen in der Positionsbestimmung zu erkennen und dasAuto kürzere Strecken gewissermaßen „blind“ fahren zu lassen. Die Position imFlur kann nämlich mit den richtigen Gleichungen nahezu exakt berechnet wer-den. Eine erfolgreiche Systemidentifikation würde daher zahlreiche Vorteile mitsich bringen. Leider haben uns hierzu die notwendigen Kenntnisse der technischenMechanik gefehlt.

Eine interessante Idee für weitere Projekte mit den Fahrzeugen sind „Road-Trains“.Dieser Begriff steht für Kolonnen von autonomen Fahrzeugen, die sich selbst organi-sieren, um Strecken schneller oder effizienter zusammen zu fahren. Wir finden, dassdies eine gute Erweiterung für die bisherigen Implementierungen der Regelungs- undKommunikationskomponenten darstellt.

32