Masterarbeit - HAW Startseite: HAW Hamburg · Zustandsautomat für die ... Dieses beinhaltet die funktionalen Anforderungen sowie eine nach Kriterien für eine modulare Software entwickelte

Masterarbeit

Automatischer Bremsassistent auf Basis einer Laserscanner-Abstandserfassung für ein fahrerloses

Transportsystem

Stefan Cordes

Fakultät Technik und Informatik Faculty of Engineering and Computer Science Studiendepartment Informatik Department of Computer Science

Stefan Cordes

Automatischer Bremsassistent auf Basis einer

Laserscanner-Abstandserfassung für ein fahrerloses

Transportsystem Masterarbeit eingereicht im Rahmen der Masterprüfung im Studiengang Master Informatik am Studiendepartment Informatik der Fakultät Technik und Informatik der Hochschule für Angewandte Wissenschaften Hamburg Betreuender Prüfer: Prof. Dr.-Ing Bernd Schwarz Zweitgutachter: Prof. Dr. Gunter Klemke

Stefan Cordes Thema der Masterarbeit Automatischer Bremsassistent auf Basis einer Laserscanner-Abstandserfassung für ein fahrer-loses Transportsystem Stichworte Kollisionsvermeidungssystem, Bremsassistent, fahrerloses Transportsystem, Objekterken-nung, Laserscanner, Moving-Average-Filter, GEME 2000 Embedded Box PC, CAN-Bus, Umgebungsmodell Kurzzusammenfassung In der Masterarbeit wird ein automatischer Bremsassistent für ein fahrerloses Transportsystem entwickelt. Dieser erkennt aus den Entfernungswerten eines Laserscanners bevorstehende Kollisionen mit Hindernissen in der Fahrzeugumgebung und vermeidet im letztmöglichen Moment den Aufprall durch das Einleiten einer Notbremsung. Der Funktionsnachweis des entwickelten Systems wird mit Simulations- und Versuchsergebnissen erbracht. Stefan Cordes Title of the paper Automatic break assistant based on a laser scanner distance acquisition for an automated guided vehicle system Keywords Collision Avoidance System, Automatic Break Assistant, Automated Guided Vehicle System, Object Recognition, Laser Scanner, Moving-Average-Filter, GEME 2000 Embedded Box PC, CAN-Bus, Context Model Abstract In the master thesis an automatic brake assistant for an automated guided vehicle system is developed. This recognizes collisions with obstacles in the vehicle environment from the dis-tance values of a laser scanner and avoids in the lastly possible moment the impact by intro-ducing an emergency break. The acceptance trial of the developed system is furnished with simulation and test results.

Stefan Cordes Inhaltsverzeichnis

- 1 -

Inhaltsverzeichnis

1. Einleitung ........................................................................................................................... 2 2. Konzept für einen Bremsassistenten .................................................................................. 5

2.1. Funktionsübersicht ..................................................................................................... 6 2.2. Systemstruktur............................................................................................................ 8

3. Erweiterung des FAUST-Systems ................................................................................... 11 3.1. HW-SW-Plattform ................................................................................................... 11 3.2. CAN-Bus-Konfiguration anhand des zu übertragenden Datenvolumens ................ 13 3.3. Konfiguration des Laserscanners ............................................................................. 16 3.4. Threadkonzept zur Integration des Bremsassistenten .............................................. 18 3.5. Visualisierung der Laserscannerdaten auf dem QNX-Rechner ............................... 19

4. Umgebungsanalyse zur Bestimmung der Aufpralldaten.................................................. 21 5. Auswertung des berechneten Bremsstatus zur Fahrzeugsteuerung.................................. 27 6. Objekterkennung zur Umgebungsklassifizierung ............................................................ 34

6.1. Datenfilterung zur Rauschunterdrückung ................................................................ 34 6.2. Erkennung von Segmenten aus zusammenhängenden Entfernungswerten ............. 40 6.3. Objektverfolgung über mehrere Scanprofile............................................................ 42 6.4. Aktualisierung der Umgebungsdaten mit den Eigenbewegungsparametern............ 46

7. Fahrzeugtests und Auswertung ........................................................................................ 50 7.1. Fahrzeugspezifische Parametrisierung..................................................................... 50 7.2. Funktionstest des Bremsassistenten ......................................................................... 55 7.3. Auswertung .............................................................................................................. 60

8. Systemerweiterungen ....................................................................................................... 61 8.1. Berechnung des Ausweichstatus .............................................................................. 61 8.2. Zustandsautomat für die Reaktionsentscheidung..................................................... 64

9. Zusammenfassung............................................................................................................ 66 10. Literaturverzeichnis.......................................................................................................... 67 11. Anhang ............................................................................................................................. 68

11.1. Gleichungen ............................................................................................................. 68 11.1.1. Aufprallzeiten................................................................................................... 68 11.1.2. Ausweichzeit und -strecke ............................................................................... 68 11.1.3. Klotoidengleichung .......................................................................................... 70

11.2. Code-Listing............................................................................................................. 70 11.2.1. MA-Filter in LDComm.c ................................................................................. 70 11.2.2. Initialisierung des Laserscanners ..................................................................... 70 11.2.3. My_Draw.c....................................................................................................... 71 11.2.4. Aufprallerkennung.c......................................................................................... 73 11.2.5. Bremsermittlung.c ............................................................................................ 77 11.2.6. Segmentgenerierung......................................................................................... 79

11.3. CD ............................................................................................................................ 82 12. Abbildungsverzeichnis ..................................................................................................... 83 13. Tabellenverzeichnis.......................................................................................................... 85 14. Symbolverzeichnis ........................................................................................................... 86

Stefan Cordes Einleitung

- 2 -

1. Einleitung

Die EU-Kommission hat mit ihrem eSafety-Programm das Ziel definiert bis 2010 die Zahl der Verkehrstoten zu halbieren [8]. Um dieses zu erreichen soll durch die Entwicklung von Fah-rerassistenzsystemen der Unfallhäufigkeit und der Unfallschwere entgegen gewirkt werden. Die Entwicklung von Assistenzsystemen ist jedoch schon lange ein Thema im Automobilbau. Zu den ersten Systemen können der Bremskraftverstärker oder der elektronisch aktivierte An-lasser gezählt werden. Diese sollten dem Fahrer die Fahrzeugführung erleichtern, damit dieser sich besser auf den Verkehr konzentrieren kann.

In der zweiten Generation wurden fahrzeuginterne Zustandsinformationen ausgewertet, um eine entsprechende Assistenzreaktion herzuleiten. Hierzu gehört das Ende der 70er Jahre ent-wickelte Antiblockiersystem, welches durch eine Regelung des Bremsdruckes in Intervallen den Bremsweg verkürzt. Aus den Unfallstatistiken der vergangenen Jahre wird deutlich dass diese Assistenzsysteme die Sicherheit im Straßenverkehr erhöhen (vgl. Abb. 1). Obwohl die Anzahl der Automobile in den vergangenen Jahren stetig zugenommen hat, ist die Zahl der Verkehrstoten sogar leicht gesunken.

Abb. 1: Entwicklung der Verkehrsleistung und Unfallzahlen in der Bundesrepublik Deutschland [18]

Die heutige Generation von Assistenzsystemen bezieht zusätzlich mit zahlreichen Sensoren unterschiedlicher Technologien Informationen über Hindernisse in der Fahrzeugumgebung in die Entscheidungsfindung ein, um eine der Fahrsituation angestrebte Reaktion herzuleiten. Die Reaktion des Systems reicht von einem Warnsignal an den Fahrer bis hin zum aktiven Eingriff in die Fahrzeugdynamik. Erste Entwicklungen wie der „site assist“ von Audi werden schon heute in der gehobenen Klasse verkauft [16]. Der „site assist“ überwacht mit einem


- 3 -

Radarsensor den toten Winkel und signalisiert dem Fahrer mittels einer LED in dem Seiten-spiegel, wenn sich ein Fahrzeug während eines Spurwechsels in dem vom Fahrer nicht einzu-sehenden Bereich befindet. Eine weitere beispielhafte Entwicklung ist der „Park Mate“ von Siemens VDO, der mittels Radar Parklücken erfasst und dem Fahrer signalisiert, ob die Park-lücke groß genug ist, und ihn zusätzlich beim Einparken unterstützt [17].

In dem FAUST-Projekt des Departments für Informatik wurden mit Master- und Bache-lorstudenten Entwicklungs- und Forschungsprojekte zu Fahrerlosen autonomen Transportsys-temen durchgeführt. In diesem Rahmen wurde in dem Informatik Masterstudiengang ein fah-rerloses Transportsystem entwickelt, welches sich drahtlos über einen PC-Leitstand steuern lässt. Grundlage für dieses Projekt war ein von der Firma E&K aufgebautes Laborfahrzeug. Auf dieses Fahrzeug wurde in zwei Semestern von der Projektgruppe ein Netzwerk von meh-reren Rechnerkomponenten installiert (vgl. Abb. 2). Das verteilte System besteht aus einem Leitstand, der per WLAN-Verbindung mit dem Fahrzeug kommuniziert, sowie vier weiteren Fahrzeugkomponenten. Als Kommunikationsmedium auf dem Fahrzeug ist das eigens für den Datenaustausch zwischen Steuergeräten in dem Automobil entwickelte CAN-Bus-System installiert [13]. Die Komponenten auf dem Fahrzeug setzen sich aus dem Kommunikations-rechner, der die WLAN-Nachrichten auf den CAN-Bus übersetzt, dem Koordinierungsrechner und zwei µController für die geregelte Ansteuerung der Fahrzeugmotoren zusammen. Der Koordinierungsrechner dient als Übersetzungseinheit zwischen dem Leitstand und den µCont-rollern. Auf dieser Entwicklungsplattform sollen in weiteren Projekten und Abschlussarbeiten Entwicklungsziele, wie Fahrerwarnsysteme, die Fahrzeugstabilisierung durch ein Gyroskop, oder die Parkbuchterkennung implementiert werden.

Koordinierungs-Rechner

Regelung Vorne

Regelung Hinten

Kommunikations-Rechner

CAN-Bus

Fahrzeug

FAUST-Projekt

WLAN-Router Kamera

Ethernet

Fahr/Lenkmotoren

Sensorik

WLAN

Leitstand

Abb. 2: Struktureller Aufbau des FAUST-Projektes

Im Rahmen der Masterarbeit soll ein fahrerloses Transportsystem um einen automatischen Bremsassistenten erweitert werden. Der zu entwickelnde Bremsassistent zählt zu den Kollisi-onsvermeidungssystemen, die einen bevorstehenden Aufprall erkennen und kollisionsvermei-dende Reaktionen einleiten. Die Umgebungserfassung erfolgt hierbei über einen Laserscan-ner, da dieser aufgrund seiner messtechnischen Eigenschaften ein großes Potential zur Reali-sierung von Fahrerassistenzsystemen bietet [8]. Solche aktiv in das Fahrverhalten eingreifen-


- 4 -

de Systeme werden in näherer Zukunft nicht im Straßenverkehr eingesetzt, da der geforderte Zuverlässigkeitsgrad nicht erfüllt wird [7].

Ein Ziel dieser Arbeit ist es bei der Realisierung des Assistenten eine Umgebungserkennung zu implementieren. Diese muss ein Umgebungsmodell generieren, das alle Information für die Analyse der Fahrsituation bereitstellt. Die Analyse erfolgt anschließend auf der Grundlage von Forschungsarbeiten an einem Kollisionsvermeidungssystem, welches mit der Echtzeitsi-mulationsumgebung MATLAB verifiziert wurde [1]. Die Umsetzung des Assistenten erfolgt auf einem Embedded Box PC und dient damit der Realisierung auf einer praxisnäheren Platt-form. Nach Abschluss der Arbeit kann die Software auf der µController-Plattform von Flex-ray-Knoten mit 32 Bit-Prozessoren mit 24 MHz umgesetzt werden.

Für die Umsetzung wurde im ersten Schritt das in Kapitel 2 beschriebene Konzept für einen Bremsassistenten erarbeitet. Dieses beinhaltet die funktionalen Anforderungen sowie eine nach Kriterien für eine modulare Software entwickelte Struktur der zu realisierenden Soft-ware.

In Kapitel 3 werden die erforderlichen Anpassungen zur Integration des Bremsassistenten an dem bestehenden System beschrieben. Neben der Konfiguration des CAN-Bus und des Laser-scanners ist hier das Threadkonzept beschrieben, mit dem die Assistenzsoftware in den Koor-dinierungsrechner integriert werden soll. Für die Entwicklung des Assistenten ist eine grafi-sche Oberfläche implementiert, mit der die Umgebungsinformationen visualisiert werden, die dem System vorliegen (s. Kap.3.5).

In den folgenden drei Kapiteln sind die wesentlichen Funktionsgruppen aus der Software-struktur detailliert dargestellt. In Kapitel 4 und 5 werden die für den Bremsstatus notwendigen Berechnungen zur Ermittlung der Daten des nächsten Aufpralls und des einzuleitenden Bremsmanövers beschrieben. Die Gleichungen basieren hierbei auf einem in der Dissertation von Ameling [1] vorgestellten Umgebungsmodell. Neben den mathematischen Grundlagen wird jeweils die funktionale Umsetzung in den Funktionsgruppen beschrieben.

In Kapitel 6 ist die Funktionsgruppe zur Ermittlung des Umgebungsmodells dargestellt. Diese verarbeitet die einzelnen Entfernungswerte des Laserscanners zu einem Umgebungsmodell, welches für die Berechnung der Aufprall- und Bremsdaten benötigt wird. Hierfür werden die Entfernungswerte mittels Filterung aufbereitet und anschließend Segmente erkannt, aus denen die geschwindigkeitsbehafteten Objekte generiert werden. Damit bei einem fehlerhaften Scan die Objektdaten nicht verloren gehen, werden diese intern aufgrund der Eigenbewegung des Fahrzeuges extrapoliert. Die Berechnung dieser Aktualisierung ist in Kapitel 6.4 beschrieben.

Kapitel 7 beschreibt die fahrzeugspezifischen Parameter und die durchgeführten Funktions-tests, mit denen die Funktionalität des Bremsassistenten nachgewiesen wird. Abschließend werden in dem Kapitel die Tests ausgewertet und weitere Entwicklungsschritte vorgestellt, mit denen der Bremsassistent zu optimieren ist.

In Kapitel 8 wird eine Erweiterung des Bremsassistenten um die Reaktion eines Ausweich-manövers beschrieben. Die Berechnung für den in dem erweiterten Kollisionsvermeidungs-system benötigten Ausweichstatus ist in Kapitel 8.1 beschrieben. Für die Priorisierung der einzelnen Reaktionsanforderungen des Assistenten ist in Kapitel 8.2 ein Zustandsautomat beschrieben.

Abschließend werden die Ergebnisse der einzelnen Arbeitsschritte in Kapitel 9 zusammenge-fasst.

Stefan Cordes Konzept für einen Bremsassistenten

- 5 -

2. Konzept für einen Bremsassistenten

Der in der Arbeit realisierte Bremsassistent dient als Sicherheitssystem zur Kollisionsvermei-dung des Fahrzeuges mit Hindernissen. Er soll im letztmöglichen Zeitpunkt eingreifen und Kollisionen verhindern, die durch den Bediener an dem Leitstand nicht mehr vermieden wer-den können. Damit wird gewährleistet, dass der Assistent den Fahrer nicht im kollisionsfreien Normalbetrieb übersteuert. Im folgenden Kapitel werden die strukturellen Grundlagen, als auch die funktionalen Zusammenhänge für einen solchen Bremsassistenten beschrieben. Es wird nach der Einordnung der Funktionen des Bremsassistenten in die von Forschungsinitia-tiven entwickelten Softwarestrukturen von Assistenzsystemen die modulare Softwarearchitek-tur des entwickelten Bremsassistenten dargestellt.

Betrachtet man den zeitlichen Ablauf eines Bremsvorgangs im PKW nach [11], so setzt sich dieser aus den in Abb. 3 dargestellten Phasen zusammen. Aufgrund der menschlichen Reakti-onszeit liegt zwischen der objektiven Bremsaufforderung und der ersten Reaktion des Fahrers eine Zeit T0 von 0,4 s bis 1,5 s. In der nächsten Phase wechselt der Fahrer den Fuß von Gas- auf das Bremspedal. In dem FAUST-System entfällt diese Zeit T1, da der Fahrer mit der Wegnahme des Fußes vom Gaspedal das Fahrzeug bremst, in dem er eine Sollgeschwindig-keit v = 0 m/s vorgibt. Statt der Wechselzeit liegt in dem Transportsystem zwischen der Reak-tion des Fahrers und der des Fahrzeuges die Zeit, die für die Übermittlung der Anforderung per WLAN an das Fahrzeug benötigt wird. Diese Zeit beträgt ca. 500 ms. Die letzten beiden Phasen beschreiben die Zeit in der das Fahrzeug abgebremst wird. Hier wird zwischen der Schwellzeit T2, in der die Bremsbeschleunigung steigt, und der Vollbremszeit T3, mit einer konstanten Bremsbeschleunigung, unterschieden. Zwischen der objektiven Reaktionsauffor-derung und der Reaktion des Fahrzeuges liegen demnach maximal zwei Sekunden.

Zeit

Reak

tions

-au

fford

erun

g

Weg

nahm

e de

s

Fuße

s vo

m G

aspe

dal

Berü

hren

des

Brem

sped

als

Begi

nn d

er

Fahr

zeug

verz

öger

ung

Max

imal

e Fa

hrze

ugve

rzög

erun

gSt

illsta

nd d

es

Fahr

zeug

es

T0 = 0,4-1,5s T1 = 0,2-0,45s T2 = 0,2s T3

Abb. 3: Zeitlicher Ablauf eines Bremsvorganges nach [11]

Die Reaktionszeit des Bremsassistenten, der zyklisch den Bremsstatus ermittelt, ist durch die Abtastrate definiert. Da der Assistent direkt auf dem Fahrzeug eingreifen kann, benötigt die-ser nicht die Zeit tu = 0,5 s für die Datenübertragung vom Leitstand zum Transportsystem. Bei einem System, welches alle 50 ms die Umgebung auswertet, beträgt die maximale Reaktions-zeit anstatt zwei Sekunden nur 50 ms. Durch diese deutlich geringere Reaktionszeit kann der Bremsassistent Kollisionen vermeiden, die der Fahrer nicht mehr verhindern kann.


- 6 -

Für den strukturellen Aufbau eines solchen Assistenzsystems schlägt die Forschungsinitiative INVENT [4] eine Drei-Ebenen-Struktur vor. INVENT ist ein Konsortium aus 23 Unterneh-men aus der Automobilbranche, die sich in mehreren Projekten mit Themen von Sensordaten-erfassung bis hin zu Verkehrsregelungssystemen befassen. Die Struktur sieht eine Untertei-lung in Situationserkennung, Situationsanalyse und Aktionsausführung vor (vgl. Abb. 4). In der ersten Ebene wird die Fahrzeugumgebung, als auch der Fahrzeugzustand erfasst. Mit Hil-fe verschiedener Sensoren werden Informationen über die Fahrzeugumgebung bestimmt und in einer Datenfusion aufbereitet. In der zweiten Ebene werden die ermittelten Daten interpre-tiert, d.h. es werden beispielsweise Kollisionszeiten aus den gewonnenen Daten ermittelt und eine Reaktion ausgewählt, die von der jeweiligen Situation abhängt. In der dritten Ebene wird diese Reaktion ausgeführt. Diese kann von einer akustischen bzw. visuellen Warnung bis zu dem aktiven Eingriff in das Bremssystem oder Lenkung reichen.

Situationserkennung

Sensorbasierte Erkennung von

Umgebungssituation und Fahrzeugsituation

Situationsanalyse und

Aktionsentscheidung

Erkennung von Situationen mit

anschließender Wahl der einzuleitenden Reaktion

Aktionsausführung

Ansteuerung der Fahrzeugmotoren bzw.

Fahrzeugelektronik

Abb. 4: Drei-Ebenen-Struktur eines Assistenzsystems nach INVENT

Da in dem zu entwickelnden System ausschließlich ein Umgebungssensor zum Einsatz kommt, ist keine Sensordatenfusion notwendig. Die Situationserkennung enthält in dem Bremsassistenten das Einlesen der Laserscannerdaten und die anschließende Aufbereitung. Die zweite Ebene ist ein wesentlicher Bestandteil des Assistenten, in dem die Umgebung aus-gewertet und die Entscheidung ermittelt wird, ob ein Bremseingriff erfolgen muss. Die Akti-onsausführung steuert die Fahrmotoren direkt an, und reduziert damit die Fahrzeuggeschwin-digkeit bei einem Bremseingriff bis zum Stillstand. In dem folgenden Kapitel wird die entwi-ckelte Softwarearchitektur für einen solchen automatischen Bremsassistenten und dessen Ab-lauf beschrieben.

2.1. Funktionsübersicht

Das Bremssystem arbeitet von dem Einlesen der Entfernungswerte bis zum Bremsmanöver komplett sequenziell. Dieser sich zyklisch wiederholende Ablauf berechnet, ob der letztmög-liche Zeitpunkt erreicht ist, in dem durch eine Vollbremsung die Kollision mit dem Objekt vermieden werden kann. Ist dies der Fall so wird das Bremsmanöver anhand des bestimmten Bremsstatus mit maximaler Bremsbeschleunigung eingeleitet. Der Ablauf des Bremsassisten-ten ist in dem Aktivitätsdiagramm nach [6] in Abb. 5 dargestellt.

Die in dem Zusammenhang mit der Entwicklung des Bremsassistenten auftretenden Fachbeg-riffe werden in Tab. 1 erläutert.


- 7 -

Begriff Begrifferklärung Kollisions- oder Aufprallzeit Die Zeit, bis zur detektierten Kollision mit dem Hindernis

Kollisions- oder Aufprallweg Der Weg, zwischen der aktuellen Position und dem Punkt an dem die Kollision erfolgt

Aufprallpunkt x- und y-Koordinaten, an dem die Kollision erfolgt.

Bremszeit Die Zeit des Bremsmanövers, durch das die Kollision mit dem Hindernis vermieden werden kann.

Bremsweg Der Weg, der bei dem Bremsmanöver zurückgelegt wird, mit dem die Kollision vermieden wird.

Bremsstatus Der Status gibt an ob ein Bremsmanöver eingeleitet werden muss.

Segment Aus benachbarten Entfernungswerten eines Scans erkanntes zusammenhängendes Hindernis.

Objekt Aus den Segmentinformationen zwei aufeinander folgender Scans generiertes Objekt mit zugehöriger Geschwindigkeit.

Tab. 1: Auf den Bremsassistenten bezogene Begriffdefinitionen

Die von dem Laserscanner gelieferten Entfernungswerte durchlaufen eine Aufbereitungsphase (vgl. Datenaufbereiten in Abb. 5), bevor sie analysiert werden. Dabei werden fehlerhafte Messergebnisse herausgefiltert, um Fehlinterpretationen in der Situationsanalyse zu vermei-den. Fehlerhafte Messwerte sind Werte, die bedingt durch das Messverfahren des Laserscan-ners von dem Entfernungs-Ist-Wert abweichen. Im nächsten Schritt werden die Umgebungs-daten auf einzelne Segmente bzw. Objekte reduziert, die zusammenhängende Gegenstände in der Umgebung darstellen. Nach dieser Datenreduktion liegen von den Segmenten nur noch Informationen über vier Punkte vor. Der rechte und linke Begrenzungspunkt, der Punkt mit dem geringsten Abstand zum eigenen Fahrzeug und der Schwerpunkt des Segmentes. Da-durch werden der Speicherbedarf und der Rechenaufwand der folgenden Programmteile ver-ringert. Werden in dieser Funktion keine Objekte erkannt, so kann es auch zu keiner Kollision kommen, d.h. es muss kein Bremsmanöver eingeleitet werden.

Daten aufbereiten

Objekte erkennen

Aufprall-daten ermitteln

Brems-status ermitteln

CA_System.c

LaserscannerRohdaten

Brems-status

Status auf FALSE setzen

[Objekte]

[keine Objekte]

[keine Kollision]

[Kollision]

Objekterkennung.c Aufprallerkennung.c Bremsermittlung.c

Situationserfassung Situationsanalyse + Aktionsentscheidung

Abb. 5: Aktivitätsdiagramm des Bremsassistenten

Für jedes erkannte Objekt wird in der Aufprallermittlung die Aufprallzeit ermittelt, die angibt, nach welcher Zeit es zur Kollision mit dem Objekt kommt. Zusätzlich werden die Koordina-ten jeder Kollision bestimmt. Abschließend wird in der Aufprallermittlung das Objekt mit der geringsten Aufprallzeit ermittelt. Wenn keine Kollision mit einem der Objekte erkannt wurde, muss der Bremsassistent nicht eingreifen. In der Bremsstatusermittlung werden anhand der


- 8 -

Objektdaten der zugehörige Bremsweg und die Bremszeit berechnet. Hierbei wird das Objekt als zum eigenen Fahrzeug quer- und längsbewegtes Objekt interpretiert, um die geringste Bremszeit zu bestimmen. Sind der berechnete Bremsweg und die Bremszeit größer als die Aufpralldaten des Objektes, so muss ein Bremsmanöver ausgeführt werden. Diese Informati-on über das Einleiten des Bremsmanövers wird der Umgebung mit einem binären Bremsstatus übergeben.

Zustand des Bremsstatus Bedeutung

0 Es muss kein Bremsmanöver eingeleitet werden, da keine Kollision vorliegt oder der Fahrer ausreichend Zeit für eine Reaktion hat.

1 Es muss eine Vollbremsung eingeleitet werden, da der letztmögliche Zeitpunkt, in dem der Fahrer die Kollision hätte vermeiden können

erreicht ist Tab. 2: Bedeutung der Zustände des zyklisch ermittelten Bremsstatus

Anhand des ermittelten Bremsstatus muss in der jeweiligen Softwareumgebung die entspre-chende Reaktion eingeleitet werden. Die Aktivierung der Vollbremsung durch das Senden einer Notbremsungsnachricht an den Steuerautomaten des Koordinierungsrechners ist in Ka-pitel 3.4 beschrieben. Zusätzlich zu dem Bremsstatus kann bspw. ein Ausweichstatus ermit-telt werden, der den letztmöglichen Zeitpunkt signalisiert, in dem durch ein Ausweichmanö-ver die Kollision vermieden werden kann. Eine Berechnung dieses Zustandes ist in Kapitel 8.1 beschrieben. Bei mehreren Assistenzfunktionen muss für die Priorisierung der verschie-denen Reaktionsanforderungen eine Entscheidungslogik implementiert werden. Eine Variante ist ein Entscheidungsautomat, der jeden Status der Assistenzfunktionen mit der jeweiligen Fahrzeugsituation abgleicht und das gewünschte Fahrmanöver einleitet. Ein solcher Entschei-der für das beschriebene System ist in dem Kapitel 8.2 dargestellt.

2.2. Systemstruktur

Die beschriebene Funktion des Bremsassistenten ist in den Koordinierungsrechner des beste-henden FAUST-Systems zu integrieren. Da dieses System in verschiedenen Projekten weiter entwickelt und erweitert wird, soll die Funktionalität des Bremsassistenten modular realisiert werden. Damit bleibt das System erweiterbar und es können verschiedene Funktionen unab-hängig voneinander umgesetzt werden. Das Softwaremodul wurde nach den folgenden Krite-rien von [15] entwickelt:

• Modulare Kombinierbarkeit: Die Module sind so aufgebaut, dass sie ohne Programmieraufwand in anderen Syste-men eingesetzt werden können.

• Modulare Verständlichkeit: Die Module sind für den Betrachter auch ohne das umgebene System verständlich.

• Modulare Stetigkeit: Bei Änderung der Problemspezifikation ist die Änderung lediglich in einem Modul notwendig. Es muss nicht die gesamte Architektur überarbeitet werden.

• Modulgeschütztheit: Bei Fehlerfällen bleibt der Ausnahmefall innerhalb des Moduls und pflanzt sich nicht auf umliegende Module fort.


- 9 -

Eine nach diesen Kriterien entworfene Software zeichnet sich durch eine hohe Transparenz und gute Testbarkeit aus. Damit wird eine niedrige Fehlerrate der Software erreicht und die Einarbeitung in die bestehende Software erleichtert.

Die gesamte Funktionalität des Bremsassistenten ist in dem Modul CA_System.c (Collision Avoidance System) implementiert. Das CA_System selber ist in weitere Funktionsgruppen untergliedert, um die genannten Kriterien der Modularisierung zu erfüllen (vgl. Abb. 6). Es ist in die folgenden Funktionsgruppen separiert:

• LD_Comm.c: Diese Funktionsgruppe wertet die Informationen der über den CAN-Bus empfangenen Nachrichten des Laserscanners aus. Das durch die Messung des Laser-scanners überlagerte Rauschen auf den Entfernungswerten wird hier mittels eines Mo-ving-Average-Filter unterdrückt (s. Kap. 6.1). Der Umgebung werden die Entfer-nungswerte mit der Funktion get_LDdata() bereitgestellt (vgl. Abb. 6).

• Objekterkennung.c: Diese Funktionsgruppe erzeugt aus den aufbereiteten Entfer-nungswerten Objekte. Hierfür werden im ersten Schritt in der Funktion segmen-te_generieren() die Segmente aus benachbarten Entfernungswerten erzeugt (s. Kap 6.2). Mit Hilfe von den Segmenten aus zwei aufeinander folgenden Scans werden an-schließend Objekte mit der zugehörigen Objektgeschwindigkeit generiert (vgl. objek-te_generieren() in Abb. 6). Zusätzlich werden bei fehlerhaften Scans Objekte extrapo-liert, die in dem aktuellen Scan nicht erfasst wurden. D.h. die Position der Objekt-punkte wird aufgrund vorangegangener Objektinformationen intern unter Berücksich-tigung der Eigengeschwindigkeit berechnet (s. Kap. 6.4). Die Objekterkennung wird der Umgebung in der Funktion get_objektdaten() zur Verfügung gestellt.

• Aufprallerkennung.c: Diese Funktionsgruppe wertet in der Funktion get_aufpralldaten() die Objektinformationen mit dem aktuellen Fahrzeugzustand aus, und ermittelt die Aufpralldaten. Hierfür wird mit Hilfe der Differenzgeschwindigkeit zum Objekt die Kollisionszeit, als auch der Weg bis zur Kollision berechnet. Hierfür werden erst die Kollisionsdaten der einzelnen Objektpunkte (get_punktData()) be-rechnet und anschließend die Daten der Objekte.

• Bremsermittlung.c: Diese Funktionsgruppe berechnet die Bremsdaten, bezogen auf das Objekt, mit dem die nächste Kollision erfolgt. Für diese Berechnung wird das Fahrzeug als quer- und längsbewegtes Fahrzeug interpretiert. Diese Bremsdaten, be-stehend aus der Bremszeit und dem benötigten Bremsweg, werden abschließend mit den Kollisionsdaten verglichen und der Bremsstatus bestimmt. Die beschriebene Funktionalität wird in der Funktion get_bremsstatus() der Umgebung zur Verfügung gestellt.

Die Berechnung der Aufprall und Bremsdaten erfolgt auf Basis der in [1] vorgestellten Ma-thematik. Die Berechnung wurde auf das Fahrzeug angepasst und funktional gegliedert, damit sie entsprechend dem Softwarekonzept implementiert werden können (vgl. Kap.4 und 5).

Das entwickelte Verfahren, mit dem die Entfernungsdaten des Laserscanners ausgewertet werden, um ein Umgebungsmodell zu erzeugen, ist in dem Kapitel 6 beschrieben. Das Umge-bungsmodell muss hierbei die von den Funktionsgruppen zur Aufprall- und Bremsermittlung benötigten Umgebungsparameter zur Verfügung stellen. Neben den Algorithmen zur Generie-rung des Umgebungsmodells wird hier die Umsetzung der Funktionsgruppe beschrieben.


- 10 -

get_

Ldda

ta()

segm

ente

_gen

erie

ren(

)ob

jekt

e_ge

nerie

ren(

)

obje

kte_

aktu

alis

iere

n()

get_

punk

tDat

a()

get_

obje

ktD

ata(

)

get_

aufp

ralld

aten

()ge

t_ob

jekt

date

n()

get_

brem

ssta

tus(

)

get_

brem

sdat

en()

inte

rpre

tLae

ngs(

)in

terp

retQ

uer(

)

ca_s

yste

m_t

hrea

d()

CA

_Sys

tem

.c

Auf

pral

lerk

ennu

ng.c

Obj

ekte

rken

nung

.cLD

_Com

m.c

Bre

mse

rmitt

lung

.c

Obj

ekte

Aufp

ralld

aten

Bre

mss

tatu

s

Entfe

rnun

gs-

wer

teO

bjek

te

Akt

ualis

ierte

O

bjek

te

Pun

kt-

Auf

pral

ldat

enO

bjek

t-Au

fpra

lldat

enB

rem

sdat

en

Läng

s-in

terp

retie

rte

Brem

sdat

en

Que

r-in

terp

retie

rte

Bre

msd

aten

Entfe

rnun

gs-

wer

teSe

gmen

te

Obj

ekte

Obj

ekt-

punk

te

Aufp

ralld

aten

Aufp

ralld

aten

Aufp

rall-

date

nAu

fpra

lldat

en

Nic

ht g

esca

nnte

O

bjek

te

Segm

ente

Abb. 6: Modulare Softwarestruktur des Bremsassistenten

Stefan Cordes Erweiterung des FAUST-Systems

- 11 -

3. Erweiterung des FAUST-Systems

Der beschriebene Bremsassistent soll in das von dem TI-Projekt des Masterstudienganges entwickelte fahrerlose Transportsystem FAUST integriert werden [14]. Die dafür notwendi-gen Anpassungen und Erweiterungen des bestehenden Systems sind im Folgenden dargestellt. Im ersten Kapitel wird die bestehende Hardware-Software-Plattform beschrieben. Ebenso wird erläutert, wie sie um den Laserscanner für die Umgebungserfassung erweitert wird. Die durch die Kommunikation mit dem Laserscanner übermittelten Datenmengen werden in dem Kapitel 3.2 zur Konfiguration des CAN-Busses berechnet. In Kapitel 3.3 sind die in zwei Phasen ablaufende Kommunikation zu dem Laserscanner und das umzusetzende Kommuni-kationsprotokoll beschrieben. Die für die Integration notwendigen Anpassungen des auf dem Koordinierungsrechner implementierten Threadkonzepts sind in dem Kapitel 3.4 dargestellt. Zusätzlich ist auf dem Koordinierungsrechner eine grafische Oberfläche zu implementieren, die die erfasste Umgebung visualisieren soll (s. Kap. 3.5). Damit können Fehler schneller er-kannt und behoben werden.

3.1. HW-SW-Plattform

Das Fahrzeugsystem besteht aus zwei ARM7-TDMI Mikrocontrollern mit 32 MHz, sowie zwei GEME-2000 x86 Rechnern mit 650 MHz. Für die Fahrzeuginterne Kommunikation ist ein CAN-Bus mit einer Baudrate von 250 KBit/s integriert (vgl. Abb. 7).

GEME 2000650 MHz/128MB RAM

QNXKoordinierung

ARM7 TDMI32 MHz/16 Bit

Regelung Vorne

ARM7 TDMI32 MHz/16 Bit

Regelung Hinten

GEME 2000 650 MHz/128MB RAM

SUSE 9.1Kommunikation

CAN-Bus

FAUST-Fahrzeug

FAUST-Projekt

ASUS WL-500g WLAN-Router

D-LINK DCS-2100+ Kamera

Ethernet

Fahr/Lenkmotoren

Sensorik

WLAN

PC1,2GHz/512MB RAM

WINDOWS XPLeitstand

SICK LD OEM Laserscanner

Abb. 7: FAUST-Fahrzeugaufbau

Auf den beiden ARM7-µControllern sind jeweils die Lenk- und Fahrregelung eines Rades implementiert. Ein GEME-Rechner dient als Kommunikationsschnittstelle zwischen CAN-Bus und WLAN. Der zweite GEME-Rechner dient als Koordinierungsrechner. Dieser be-rechnet aus den Fahrbefehlen des Leitstandes (PC) die Lenkwinkel und Geschwindigkeiten der beiden Radmotoren und leitet diese an die ARM7-Controller weiter. In der anderen Rich-


- 12 -

tung wertet der Koordinierungsrechner die Ist-Daten der beiden Controller aus, und berechnet die Geschwindigkeit und den Lenkwinkel des Fahrzeuges. Dieser Rechner läuft unter dem Echtzeitbetriebssystem QNX. Für die Realisierung dieser Funktionalität wurde ein Steuerau-tomat entwickelt und mit einer Laufzeitumgebung für reaktive Systeme implementiert.

Die Funktion des Bremsassistenten ist in dem Koordinierungsrechner realisiert, da er über sämtliche Informationen des Fahrzeugzustandes verfügt und einen kurzen Kommunikations-weg zu den ARM7-µControllern hat. Für die benötigten Informationen über die Fahrzeugum-gebung, sowie den Bremsassistenten, wird der Laserscanner LD-OEM mit einem Scanbereich von 360° von der Firma Sick auf dem Fahrzeug installiert. Dieser verfügt über eine Reichwei-te von bis zu 100 Metern, eine max. Winkelauflösung von 0,125° und scannt mit einer konfi-gurierbaren Frequenz von 5 Hz bis 20 Hz. Der Scanner kann sowohl über eine RS232- Schnittstelle, als auch über den CAN-Bus konfiguriert werden. Aufgrund der höheren Baudra-te und des bestehenden CAN-Busses auf dem Fahrzeug, wurde der CAN-Bus als Schnittstelle gewählt. Die detaillierte Konfiguration des Laserscanners ist in Kapitel 3.3 beschrieben.

Laserscanner LD-OEMGEME-2000

Embedded Box PC

KameraDCS-2100+ARM7-µController

Abb. 8: Das FAUST-Fahrzeug mit installiertem Laserscanner

Damit der Sichtbereich des Laserscanners nicht durch das Fahrzeug eingeschränkt wird, muss dieser an der höchsten Position auf dem Fahrzeug installiert sein. Aus diesem Grund ist der Laserscanner auf einem erhöhten Fuß an der linken vorderen Fahrzeugecke befestigt. Die Spannungsversorgung erfolgt über dieselbe Klemmleiste, an der auch die µController, sowie die GEME-Rechner angeschlossen sind. Diese wird über den Schlüsselschalter aktiviert und kann nicht durch die Bumperleiste unterbrochen werden. Die Bumperleiste trennt die Strom-versorgung der Motoren bei Kollisionen, damit das Fahrzeug zum Stehen kommt und eine potentielle Überlastung der Motoren vermieden wird. Durch die unterbrechungsfreie Span-nungsversorgung des Laserscanners muss der Koordinierungsrechner den Spannungsausfall nicht erkennen, um daraufhin den Laserscanner neu zu initialisieren.


- 13 -

3.2. CAN-Bus-Konfiguration anhand des zu übertragenden Datenvolumens

Der Datenaustausch zwischen dem Laserscanner und dem Koordinierungsrechner soll über den CAN-Bus realisiert werden (vgl. Abb. 7). Die Kommunikation kann auf dem bestehenden Bussystem mit verschiedenen Übertragungsraten, sowie einem separaten Bus umgesetzt wer-den. In dem folgenden Kapitel wird erläutert, weshalb die zusätzliche Kommunikation mit dem bestehenden Bussystem bei einer Baudrate von 250 KB/s realisiert ist.

Bei der Konfiguration des CAN-Busses muss die zu übertragende Datenmenge des bestehen-den Systems und die des Laserscanners berücksichtigt werden. Diese wurde mit Hilfe des CANalysers, einem Analysewerkzeug für Netzwerke und verteilte Systeme erfasst. Eine Mes-sung des bestehenden Systems ohne CA-System hat eine Auslastung von 7,5 % ergeben. Die durch die Kommunikation mit dem Laserscanner entstehende Datenmenge lässt sich durch das Einstellen des Winkelbereiches, der Winkelauflösung sowie der Scannfrequenz variieren. Es gilt zu ermitteln, welche Daten für das System des Bremsassistenten erforderlich sind.

Die Scanfrequenz kann am Laserscanner in einem Bereich von 5 Hz bis 20 Hz eingestellt werden. Unter Berücksichtigung der maximalen Geschwindigkeit des Fahrzeuges von 1,4 m/s ergeben sich für die beiden Grenzfrequenzen die in Tab. 3 dargestellten maximalen Entfer-nungsänderungen zwischen zwei Abtastzyklen.

Frequenz f Max. Geschwindigkeit vmax 5 Hz 20 Hz

1,4 m/s 0,28 m 0,07 m Tab. 3: Entfernungsdifferenz bei maximaler Geschwindigkeit vmax und einer Abtastfrequenz f

von 5 Hz und 20 Hz

Bei einem entgegengesetzt bewegten Objekt, welches sich ebenfalls mit maximaler Ge-schwindigkeit bewegt, ergibt sich bei 5 Hz eine Änderung von 0,56 m. Da das System ein möglichst aktuelles Abbild der Umgebung benötigt, muss die maximal verfügbare Frequenz des Laserscanners von 20 Hz ausgewählt werden. Damit wird der interne Fahrzeugzustand so dicht wie möglich an der realen Umgebung gehalten. Mit dem Nyquist-Shannonschen Abtast-theorem lässt sich belegen, dass diese Frequenz ausreicht, um das Ursprungssignal, d.h. die aktuellen Entfernungen ohne Informationsverlust zu erfassen. Dieses besagt, dass ein Ur-sprungssignal ohne Informationsverlust erfasst werden kann, wenn die Abtastfrequenz dop-pelt so groß ist, wie die maximale Frequenz des Ursprungssignals. Es muss gelten:

Fahrzeugabtast ff max,*2> ( 3.1 )

Bei der vorgegebenen Abtastfrequenz von 20 Hz dürfen die Entfernungswerte maximal mit einer Frequenz von 10 Hz behaftet sein. Solch hochfrequente Schwingungen sind jedoch auf-grund der Fahrzeugträgheit unrealistisch. Die Abtastrate von 20 Hz reicht demnach aus, um die Umgebung zu erfassen.

Der Bremsassistent soll Kollisionen mit der Fahrzeugfront erkennen und vermeiden. Auf-grund dieser Tatsache sind die Umgebungsinformationen neben und hinter dem Fahrzeug für das System nicht relevant. Es wird ausschließlich der Bereich von 180° vor dem Fahrzeug benötigt, da sich der Laserscanner an der Fahrzeugfront befindet.

Der letzte zu setzende Konfigurationsparameter ist die Winkelauflösung des Laserscanners. Diese kann in einem Bereich von 0,125° bis 2° eingestellt werden. Abhängig von dieser Auf-lösung und dem Abstand zum Scanner ändern sich die tangentialen Abstände der Entfer-


- 14 -

nungswerte (a in Abb. 9). Diese lassen sich mit Hilfe der trigonometrischen Funktion am rechtwinkligen Dreieck berechnen. Zerlegt man das, sich aus zwei benachbarten Entfer-nungswerten b und c und dem Abstand a der beiden Werte entstehenden Dreieck in zwei rechtwinklige Dreiecke, so kann der Abstand wie folgt berechnet werden:

=

2sin**2 αba ( 3.2 )

α2α

Laserscanner

a/2a

c=bb=c

Abb. 9: Zwei benachbarte Entfernungswerte dargestellt als gleichschenkliges Dreieck bei einer Winkel-

auflösung von α

Berechnet man die Lücken, zwischen den einzelnen Winkelpulsen, die bei den verschiedenen Winkelauflösungen entstehen, ergibt sich Tab. 4:

Entfernung b Winkelauflösung α 1 m 10 m 100 m

0,25° 0,00346 m 0,04363 m 0,346 m

0,5° 0,00873 m 0,0692 m 0,873 m

1° 0,01745 m 0,1746 m 1,745 m

2° 0,03491 m 0,349 m 3,491 m Tab. 4: Abstand a zwischen zwei Entfernungswerten in Abhängigkeit von der Entfernung b und der Win-

kelauflösung α

Durch die Testumgebung mit Abständen von maximal b = 10 m, ist die Lücke a selbst bei der geringsten Auflösung α von 2° auf ca. a = 35 cm beschränkt. Um dennoch ein etwas genaue-res Umgebungsumfeld zu erhalten wird eine Winkelauflösung von einem Grad gewählt.

Parameter Eingestellter Wert

Winkelauflösung α 1°

Scanfrequenz fabtast 20 Hz

Scanbereich ε 180 ° Tab. 5: Parametrisierungsgrößen des Laserscanners


- 15 -

Im Folgenden soll die Datenmenge betrachtet werden, die bei der in Tab. 5 dargestellten Kon-figuration über den CAN-Bus übermittelt wird. Bei einer Winkelauflösung α von einem Grad und den bestimmten Scanparametern müssen alle 50 ms 181 Scanwerte mit jeweils 2 Byte übertragen werden. Zu diesen Daten muss der Overhead des CAN- und des Laserscannerpro-tokolls addiert werden. Eine Nachricht des CAN-Protokolls besteht aus 8 Byte Nutzdaten und 46 Bit Overhead. In den 8 Byte sind der Overhead des Laserscannerprotokolls und die oben genannten Nutzdaten enthalten (vgl. Abb. 10). Das Protokoll des Laserscanners sieht pro ge-sendetes Profil einen 12 Byte Header vor, sowie eine Nachrichtennummer, die ab der zweiten Nachricht mit jeweils 2 Byte übertragen werden muss.

27 Bit19 Bit 8 Byte

2 Byte 4 Byte 2 Byte

CAN-Protokoll CAN-ProtokollLaserscanner Protokoll Header

Protokoll Header DatenNachrichtennummer

27 Bit19 Bit

CAN-Protokoll CAN-Protokoll

Abb. 10: Aufbau der ersten beiden CAN-Nachrichten einer Profilnachricht des Laserscanners ( vgl. [9] )

Um die endgültige Datenmenge ermitteln zu können, ist die Anzahl der Nachrichten zu be-rechnen, die für ein Profil benötigt werden. In den ersten beiden Nachrichten ist der Header und der erste Entfernungswert enthalten (vgl. Abb. 10). Die weiteren 180 Entfernungswerte benötigen 60 Nachrichten mit jeweils 6 Byte. Ein Profil kann demnach in 62 Nachrichten übertragen werden. Es ergibt sich folgender Overhead der Protokolle:

Daten Statische Länge Länge pro Nachricht Länge pro Profil (mit 62 Nachrichten)

Entfernungswerte 181 Word - 2896 Bit CAN-Overhead - 46 Bit 2852 Bit

LD-Header 12 Byte - 96 Bit LD-Overhead 2 Word (ab der 2. Nachricht) 976 Bit

Gesamte Daten-menge 6820 Bit

Tab. 6: Datenmengen der Nutzdaten und des Overheads von CAN- und Laserscannerprotokoll

Addiert man die Werte der Nutzdaten und des Overhead, so erhält man die Datenmenge, die pro 50 ms übertragen werden muss. Hier raus lässt sich die erforderliche Baudrate errechnen.

skBit

msBit 4,136

506820

= ( 3.3 )

Diese benötigte Übertragungsrate ließe sich mit dem bestehenden Bussystem mit 250 KB/s realisieren. Bei der gegebenen Baudrate entspricht die Übertragungsrate der Laserscanner-kommunikation einer Last von 54,5 %. D.h. bei einer Integration in das bestehende System liegt die gesamte Buslast bei 54,5 % + 7,5 % = 62 %.

Bei einer höheren Winkelauflösung (<1°), oder einem größeren Sichtwinkel, wird ein Bussys-tem mit einer höheren Baudrate benötigt. Um den bestehenden Bus auf die höhere Baudrate


- 16 -

umzukonfigurieren, müssen alle Teilnehmer an dem Bus umprogrammiert werden. D.h. es müssen beide ARM7-µController, der Kommunikationsrechner und der Koordinierungsrech-ner auf die neue Baudrate umgestellt werden. Ist eine Baudrate von 1 MBit/s erforderlich, so muss zusätzlich die Verkabelung des Busses ausgetauscht werden, da bisher keine geschirm-ten Kabel verwendet wurden. Bei diesen Kabeln ist aufgrund der möglichen Reflexion der Signale bei hohen Übertragungsraten keine sichere Datenübertragung mehr gewährleistet [13]. Dieser Aufwand kann vermieden werden, wenn mit dem Laserscanner über einen sepa-raten Bus kommuniziert wird. In diesem Fall muss das bestehende System nicht umkonfigu-riert werden. Hierfür wird neben der Softwareanpassung auf dem Koordinierungsrechner ein zusätzlicher CAN-Controller des GEME-2000 benötigt.

Realisiert wurde die Kommunikation auf dem bestehenden System, um den Hardwareauf-wand gering zu halten. Mit einer Buslast von 62 % ist der bestehende Bus nicht überlastet und kann daher ohne Änderungen verwendet werden.

3.3. Konfiguration des Laserscanners

Der Laserscanner LD-OEM der Firma Sick wird über den CAN-Bus konfiguriert (vgl. Kap. 3.1). Für die Kommunikation ist ein Protokoll vorgesehen, welches in den 8 Byte Daten der CAN-Nachrichten übertragen werden muss. Dieses Steuerprotokoll besteht aus Service-Requests und Responses. Auf jedes vom Anwender geschickte Request antwortet der Laser-scanner mit einem Response, mit der Information über den Status oder Entfernungsdaten [9]. Jede dieser Nachrichten wir durch einen 2 Byte Service-Code identifiziert (vgl. Abb. 11). Die-sem Code folgen die Parameter mit dem der Laserscanner konfiguriert werden soll, bzw. der Status über den aktuellen Zustand des Laserscanners. Die verwendeten Service Codes werden in die folgenden drei Klassen unterteilt:

• Configuration: Konfiguration des Laserscanners

• Measurement: Auslesen der Scanwerte

• Working: Inbetriebnahme des Laserscanners

CRC EOFIDDLC

START

RTR

IDE

ACK

CRC EOFACK

CRC EOFACK

IDDLC

START

RTR

IDE

IDDLC

START

RTR

IDE

Sequenzflag Paket-ID Dest.-ID Service CODE

Paket-ID Profil-ID Layer/Sektor DATA

Paket-ID DATA DATA DATA

CAN-Protokoll CAN-ProtokollLaserscanner Protokoll Herader

Protokoll Herader Entfernungsdaten

Entfernungsdaten

2 Byte2 Byte2 Byte2 Byte19 Bit 27 Bit

Nachrichtennummer

Nachrichtennummer

Abb. 11: Aufbau der CAN-Nachrichten des Response auf ein GET-PROFILE Request ( vgl. [9] )

Überschreiten Nachrichten die Länge einer CAN-Nachricht, so werden sie auf mehrere ver-teilt, und durch eine laufende Paket-ID identifiziert (vgl. Abb. 11). In der ersten Nachricht


- 17 -

steht in der Paket-ID die Zahl der benötigten Nachrichten. Die Destination-ID in der ersten Nachricht gibt die Adresse des Empfängers an. Der Aufbau ist anhand der Response-Nachricht eines GET-PROFILE-Befehls in Abb. 11 dargestellt. Hier werden in der zweiten Nachricht zu der Paket-ID zusätzlich die Profilnummer und die Nummer des aktuellen Lay-ers, bzw. Scansektors übertragen.

Die Kommunikation mit dem Laserscanner erfolgt in zwei Phasen. In der ersten, der Konfigu-rationsphase, wird der Laserscanner auf die Anwendung parametriert. Die zweite Phase dient der Übertragung des Entfernungswertes des Laserscanners. Bei der Konfiguration werden mehrere Configuration-Codes abgeschickt und die zugehörigen Responses des Laserscanners ausgewertet. In dieser Phase wird die Winkelauflösung, die Sektorbreite, die Frequenz als auch die CAN-Konfiguration an dem Laserscanner vorgenommen. Der im Folgenden be-schriebene Ablauf der Initialisierung ist in Abb. 12 dargestellt. Mit dem Kommando SET_FUNCTION wird der Sektor, d.h. der Scanbereich auf die 180° vor dem Fahrzeug defi-niert. Hierfür wird der gesamte Scanbereich von 360° in zwei Bereiche unterteilt. In dem Sek-tor von 90° bis -90° wird gescannt und von -91° bis 89° werden keine Entfernungswerte er-mittelt. Anschließend wird mit dem SET_CONFIG Befehl sowohl der CAN-Bus, als auch die Scannfrequenz und die Winkelauflösung eingestellt.

Koordinierungsrechner Laserscanner

SET_FUNCTION

Response

SET_CONFIG

Response

TRANS_ROTATE

TRANS_MESSURE

Response

Response

GET_PROFILE

Response

Response

Setzen der zu scannenden Bereiche

Konfiguration der Scan-frequenz, Winkelauf-lösung Baudrate des CAN-Bus,...

Begin der Rotation des Laserscanners

Starten der Messung

Anforderung der unbefristeten Übermittlung der Scandaten

Kontrolle der Statusantwort vom Laserscanner

Verarbeitung der Scannwerte

Pha

se 1

Phas

e 2

Abb. 12: Sequenzdiagramm der Initialisierung des Laserscanners

Nach der Konfiguration wird der Laserscanner mit dem Befehl TRANS_ROTATE in Rotati-on versetzt. Mit dem Befehl TRANS_MESSURE wird die Entfernungsmessung des Laser-scanners gestartet. Mit dem GET_PROFILE-Befehl wird danach die Übertragung der Entfer-nungswerte ausgelöst. Hierbei wird die Anzahl der Profile vorgegeben, die jeweils einen kompletten Scan enthalten. Sollen die Profile unbefristet verschickt werden, so wird eine An-zahl von Null vorgegeben. Eine detaillierte Darstellung des Aufbaus der jeweiligen Request


- 18 -

und Response-Nachrichten ist in [10] beschrieben. Der Ablauf der Initialisierung ist in dem Sequenzdiagramm in Abb. 12 dargestellt.

Mit dem Empfangen der ersten Nachricht der Entfernungsdaten ist die erste Phase der Kom-munikation mit dem Laserscanner abgeschlossen. In der zweiten Phase werden ausschließlich Nachrichten vom Laserscanner mit den Scandaten verschickt, die von dem Koordinierungs-rechner ausgewertet werden.

Die komplette Initialisierung wird beim Starten des Empfangsthread der Laserscannernach-richten LD_Recv ausgeführt (vgl. Abb. 13). Nach der Initialisierung verweilt der Thread in einer While-Schleife, in der blockierend auf empfangene Laserscannernachrichten gewartet wird. Ein Ausschnitt Initialisierungsfunktion ist dem Code-Listing im Anhang zu entnehmen (vgl. Kap.11.2.2)

3.4. Threadkonzept zur Integration des Bremsassistenten

Der Bremsassistent soll auf dem Koordinierungsrechner parallel zu dem Steuerautomat ausge-führt werden, der die bisherigen Funktionen bereitstellt. Er muss demnach bei der Initialisie-rung des Koordinierungsrechners in einem eigenen Thread gestartet werden.

In dem bestehenden System existieren fünf Threads, wovon zwei für das Empfangen und Senden der CAN-Nachrichten zuständig sind (vgl. Abb. 13). Der Empfang einer Nachricht wird durch einen Hardware-Interrupt signalisiert, auf das der Empfangsthread blockierend wartet. Damit während der Wartezeit die anderen Funktionen des Steuerautomaten ausgeführt werden können, sind die Empfangs- und Sendefunktion der CAN-Nachrichten in jeweils ei-genen Threads implementiert. Die drei weiteren Threads sind Bestandteil des Steuerautoma-ten. Sie bestehen aus einem Timertick- und TimerExecution-Thread für die Timer-Funktionen des Automaten, sowie dem Reaktions- Thread des Steuerautomaten (vgl. Abb. 13).

Für die Kommunikation zwischen den Threads sind Messagequeues (MQ) bereit gestellt. Die-se nach dem Erzeuger-Verbraucher-Prinzip definierten Schnittstellen sind über Semaphoren gegen einen zeitgleichen Zugriff abgesichert. Der Thread, der lesend auf die Messagequeue zugreift, wird blockiert, bis eine Nachricht in die Liste geschrieben wurde.

Main

CAN-sendCAN-recv SteuerautomatCA-System

LD-RecvTime-Tick Time-Exe

MQ3

MQ1 MQ2SIG

Abb. 13: Thread-Architektur des Koordinierungsrechners mit integriertem CA-System

Für die Integration des Assistenzsystems muss eine Messagequeue für die Kommunikation zu dem Thread zum Empfangen der CAN-Nachrichten (CAN-recv) eingerichtet werden. In diese Liste trägt der Empfangsthread alle empfangenen Nachrichten ein, die von dem Laserscanner geschickt wurden. Diese zusätzliche Messagequeue (MQ3 in Abb. 13) dient dazu, die beiden Systeme des Steuerautomaten und des Bremsassistenten unabhängig voneinander zu imple-


- 19 -

mentieren. Damit wird vermieden, dass der jeweils lesende Thread prüfen muss, ob die Nach-richt auszuwerten ist. In dem Steuerautomat muss damit keine Auswertung implementiert werden. Zusätzlich würde die Handhabung der Listenstruktur ohne zusätzliche MQ deutlich rechenaufwendiger, da die auszuwertenden Nachrichten nicht immer am Ende der Liste ste-hen. Bei dem Auslesen einer Nachricht, die nicht am Ende der Liste steht, muss der Vorgän-ger- mit dem Nachfolgereintrag verknüpft werden. Mit einer zweiten Messagequeue stehen in den Queues der Thread nur Nachrichten die auszuwerten sind. Es werden weiterhin nur die letzten Listeneinträge gelesen und gelöscht. Ausgelesen werden die Nachrichten der MQ3 von dem LD_Recv-Thread. Dieser wertet nach der Initialisierungsroutine (vgl. Kap. 3.3) die Nachrichten aus, filtert die Entfernungswerte und stellt sie dann dem CA-System zur Verfü-gung.

Ist ein Profil komplett ausgewertet, so wird ein Signal (SIG in Abb. 13) ausgelöst, auf welches das CA-System blockierend wartet. Nach diesem Signal kann der Thread mit dem Assistenz-system den sequenziellen Ablauf abarbeiten. Die Separierung der Auswertung der Entfer-nungswerte und dem Assistenzsystem dient der unabhängigen Bearbeitung. Damit können schon während der Berechnungen des Assistenzsystems die Entfernungswerte des nächsten Profils ausgewertet werden. Für das Auslösen des Bremsmanövers muss das CA-System dem Steuerautomat die Information der Notbremsung übermitteln. Dies kann durch das Schreiben einer Bremsmanövernachricht in die Empfangs-Liste MQ2 des Steuerautomaten realisiert werden. Hierfür muss der neue Nachrichtentyp der Notbremsung definiert werden.

Der Aufrufzyklus des Steuerautomaten ist durch den Zyklus definiert, mit dem die Ist-Werte der ARM7-µController bzw. die Sollvorgaben des Leitstandes gesendet werden. Da der Thread blockierend auf die Nachrichten wartet, wird der Thread im Mittel alle 25 ms abgear-beitet (vgl. Abb. 14).

CAN_recv

LD_recv

CA_System

Steuerautomat

CAN_send

Entfernungswerte (Laserscanner)

Ist-Werte (ARM)

50 ms

Sollwerte (Komm.Rechner)

Abb. 14: Zeitlicher Ablauf der Threads auf dem Koordinierungsrechner

Der Thread des CA-Systems wartet auf die komplett aufbereiteten Profilinformationen des LD_recv-Threads. Da der Laserscanner die Profile mit einer Frequenz von 20 Hz sendet, kann der CA_System-Thread ebenfalls nur alle 50ms ausgeführt werden (vgl. Abb. 14). Die Threads für den Empfang und das Senden der CAN-Nachrichten werden durch die einzelnen CAN-Nachrichten, die über den CAN-Bus empfangen werden, bzw. die in der MQ2 anliegen, getriggert. Durch das Blockieren der Threads wird gewährleitstet, dass der Prozessor im Nor-malbetrieb nicht zu 100 % ausgelastet ist.

3.5. Visualisierung der Laserscannerdaten auf dem QNX-Rechner

Die empfangenen Entfernungswerte und das daraus generierte Umfeldmodell soll für die wei-tere Entwicklung des Assistenten auf einer grafischen Oberfläche visualisiert werden. Damit


- 20 -

werden fehlerhafte Entfernungswerte oder Berechnung schnell erkannt und können somit be-hoben werden. Die Oberfläche ist in einem zweidimensionalen Koordinatensystem mit den jeweilig empfangenen Entfernungswerten, sowie den zu berechnenden Objektinformationen darzustellen.

Die Darstellung wurde direkt auf dem QNX-Rechner umgesetzt, da sie nur in der Entwick-lung genutzt wird. Der Aufwand für die Umsetzung sollte gering gehalten werden. Entwickelt wurde mit dem von der Entwicklungsumgebung Momentics bereitgestellten Tool „Photon Appbuilder“ für grafische Oberflächen. Die Visualisierung erfolgt in einem separaten Thread. Dieser Thread wird aufgrund der Scanfrequenz des Laserscanners alle 50 ms aufgerufen und aktualisiert die Oberfläche. Diese besteht aus einem Panel welches ein Koordinatensystem darstellt. In diesem Panel werden die einzelnen Entfernungswerte durch Pixel an der entspre-chenden Position visualisiert (vgl. Abb. 15). Hierfür werden die Entfernungswerte in kartesi-sche Koordinaten umgerechnet, damit sie anhand der x- und y-Position auf dem Bildschirm dargestellt werden können.

Abb. 15: Visualisierung des Umgebungsmodells auf dem Koordinierungsrechner

Die Information über die Position der Entfernungswerte muss dem Visualisierungsthread mit der Funktion set_werte() übergeben werden. Der Übergabeparameter stellt hierbei das Array mit den Entfernungswerten dar. Zusätzlich können dem Thread auch Objektinformationen mit der Funktion set_objekte() übergeben werden. Mit den in einer Liste übergebenen Objektin-formationen mit Position, Geschwindigkeit und ID werden dann ebenfalls in dem Koordina-tensystem dargestellt. Die Aktualisierung der Oberfläche erfolgt mit der Funktion My_Draw(), in der die einzelnen Pixel, Linien und Beschriftungen neu Positioniert werden. Die Implementierung der bereitgestellten Funktionen zur Visualisierung sind dem Anhang in 11.2.3 zu entnehmen.

Stefan Cordes Umgebungsanalyse zur Bestimmung der Aufpralldaten

- 21 -

4. Umgebungsanalyse zur Bestimmung der Aufpralldaten

Der Bremsassistent soll den letztmöglichen Zeitpunkt erkennen, in dem durch eine Notbrem-sung mit maximaler Bremsbeschleunigung eine Kollision mit einem der, in der vorangegan-genen Umgebungsanalyse, ermittelten Objekte vermieden werden kann. Um diesen Zeitpunkt erkennen zu können, gilt es die Zeit und den Weg bis zur Kollision, sowie die Koordinaten des Kollisionspunktes zu ermitteln. Von jedem Objekt müssen diese Aufpralldaten berechnet, und die potentielle Kollision mit dem Objekt erkannt werden. Die Berechnung der Kollisi-onsdaten ist in dem CA-System in einer separaten Funktionsgruppe, der Aufprallerkennung, implementiert. In diesem Kapitel ist die Berechnung der genannten Kollisionsdaten nach [1] beschrieben, die in der Funktionsgruppe Aufprallermittlung.c aus Abb. 6 realisiert ist.

Als Eingangswert werden dem Modul die Daten der detektierten Objekte übergeben. Die Be-rechnung dieser Objekte ist in Kapitel 6 beschrieben. Mit diesen Daten erhält das Modul die Informationen über die drei Grenzpunkte sowie die Geschwindigkeit des Objektes (vgl. Abb. 18). In dem folgenden Struktogramm ist der Ablauf des Moduls beschrieben.

Für alle Objekte berechne:

Kollisionsdaten des linken Objektpunktes

Kollisionsdaten des rechten Objektpunktes

Kollisionsdaten des dichtesten Objektpunktes

Aus den Daten der Punkte die Kollisionsdaten des Objektes

Ermittle die Kollisionsdaten des Objektes mit der geringsten Aufprallzeit

Gebe die ermittelten Objektkollisionsdaten an die aufrufende Funktion zurück

Abb. 16: Nassi-Schneiderman-Diagramm des Moduls zur Aufprallermittlung

Die Berechnung der Kollisionszeit der einzelnen Objekte erfolgt über die Ermittlung der Kol-lisionszeiten der jeweiligen Objektpunkte in der Funktion get_punktData(). Anschließend werden in der get_objektData-Funktion die Kollisionsdaten der einzelnen Objekte ermittelt. Nach dieser Berechnung wird das Objekt mit der geringsten Aufprallzeit ermittelt und die berechneten Aufpralldaten an die aufrufende Funktion zurückgegeben. Der beschriebne Ab-lauf der Aufprallermittlung ist in dem Blockschaltbild in Abb. 17 beispielhaft mit zwei detek-tierten Objekten dargestellt.


- 22 -

get_

punk

tDat

a()

get_

punk

tDat

a()

get_

punk

tDat

a()

get_

punk

tDat

a()

get_

punk

tDat

a()

get_

punk

tDat

a()

get_

obje

ktD

ata(

)

get_

objk

etD

ata(

)G

ET

get_

aufp

ralld

aten

()

Abb. 17: Blockschaltbild in der get_aufpralldaten-Funktion bei zwei erkannten Objekten


- 23 -

L K

R

vx0

Sensor

Fahrzeug

Objekt

Linkes Objektsegment

Rechtes Objektsegment

srsl

sv

sh

X

Y

sxo

vy0

syo

Abb. 18: Objektdarstellung im Fahrzeugbezogenen Koordinatensystem

In dem Umgebungsmodell wird von konstant bewegten Objekten ausgegangen, da keine In-formation über die Beschleunigungen vorliegt. Die Kollisionszeit eines Punktes wird aus dem Abstand zum Objektpunkt sx0, sowie der aktuellen Differenzgeschwindigkeit vx0 berechnet. Da die Kollision auf Höhe der Fahrzeugfront sv erfolgt, die nicht im Koordinatenursprung liegt, muss die Entfernung von Hinterachse zur Fahrzeugfront sv von der Entfernung zum Objektpunkt sx0 subtrahiert werden. Es ergibt sich folgende Gleichung:

( )0

0

x

vxxv v

sst

−−= ( 4.1 )

Für die Koordinaten des Kollisionspunktes muss lediglich die y-Koordinate bestimmt werden, da die x-Koordinate durch die Fahrzeugfront vorgegeben ist. Die y-Koordinate sy berechnet sich aus der Strecke, die der Punkt in y-Richtung von der aktuellen Position sy0 in der Zeit txv zurücklegt. Für die y-Koordinate der Kollision gilt:

( )0

0

00

00

*

*

yx

xvy

yxvyy

sv

ssv

stvs

+−

=

+=

( 4.2 )

( 4.3 )

Die Berechnung dieser Aufpralldaten erfolgt in der Aufpralldatenermittlung in der Funktion get_punktData() (vgl. Abb. 19). Dieser Funktion werden die Punktkoordinaten, sowie die


- 24 -

Geschwindigkeiten in x- und y-Richtung übergeben. Der Rückgabewert ist eine Struktur mit der Kollisionszeit txy, und der y-Koordinate des Aufprallpunktes sy.

+1

-1

+-1

+1Division1Division1

+1

+1

++1

+10ys

xvt

yvs

0xv

0xs

vs

0yv

Abb. 19: Blockschaltbild der Funktion get_punktData()

Nach der Ermittlung der Kollisionsdaten aller Objektpunkte muss aus diesen Informationen die Zeit und die Aufprallkoordinate des gesamten Objektes ermittelt werden. Grundsätzlich bestehen zehn Möglichkeiten, wie die drei Objektpunkte angeordnet sein können. Diese sind ohne Berücksichtigung der zeitlichen Zusammenhänge in Abb. 20 dargestellt.

Fall123456789

10

sl sr

KL R

1, 35, 31, 5

1, 5, 21, 24, 21, 4

1

Abb. 20: Anordnungen der Kollisionspunkte eines Objektes mit der Fahrzeugfront

Mit Ausnahme der ersten beiden Situationen kommt es immer zu einer Kollision mit dem Objekt. Reduziert man die Begegnungsvarianten durch Fallunterscheidungen bezogen auf die Fahrzeuggrenzen, sowie die Objektsegmente, die durch zwei benachbarte Objektpunkte be-grenzt sind, so ergeben sich folgende fünf Fälle (vgl. Abb. 20):


- 25 -

1. Der Schnittpunkt mindestens einer der Objektpunkte liegt zwischen den Fahrzeug-grenzen

2. Die linke Fahrzeugbegrenzung durchstößt das linke Objektsegment

3. Die linke Fahrzeugbegrenzung durchstößt das rechte Objektsegment

4. Die rechte Fahrzeugbegrenzung durchstößt das linke Objektsegment

5. Die rechte Fahrzeugbegrenzung durchstößt das rechte Objektsegment

Tritt der Fall 1. ein, und ist einer der Punkte der zwischen den Fahrzeuggrenzen liegt der Punkt mit der geringsten Aufprallzeit, so definiert dieser die Kollisionszeit mit dem Objekt. In allen anderen Fällen findet die Kollision an einer der Fahrzeuggrenzen statt, und die Kollisi-onszeit muss mit Hilfe des Strahlensatzes berechnet werden. Wie in Abb. 21 ersichtlich wird, kann eine Kollision mit dem Fahrzeug erfolgen, auch wenn keiner der Kollisionspunkte zwi-schen den Fahrzeuggrenzen liegt. In der dargestellten Situation liegt die Kollisionszeit T zwi-schen der Zeit tyv,k und tyv,l.

Objektpunkt Kürzester Abstand Linker Rechter

Schnittzeit mit der vor-deren Fahrzeugbe-

grenzung txv,k txv,l txv,r

Schnittpunkt mit der vorderen Fahrzeugbe-

grenzung syv,k syv,l syv,r

Aufprallzeiten

Fall 2: linke Fahrzeug-begrenzung durchstößt linkes Objektsegment

Fall 3: linke Fahrzeug-begrenzung durchstößt rechtes Objektsegment

Fall 4: rechte Fahr-zeugbegrenzung

durchstößt linkes Ob-jektsegment

Fall 5: rechte Fahr-zeugbegrenzung

durchstößt rechtes Objektsegment

Txv,ll Txv,lr Txv,rl Txv,rr Tab. 7: Bezeichnung der Variablen der Schnittzeiten und -punkte sowie der Aufprallzeiten der Kollisions-

fälle

Abb. 21: Kollision mit dem linken Objektsegment mit tyv,l < tyv,k


- 26 -

Der Fall 2. tritt ein, wenn der Kollisionspunkt des linken Objektpunktes syv,l links von der lin-ken Fahrzeugbegrenzung sl und der Objektpunkt mit dem geringsten radialen Abstand syv,k rechts der linken Fahrzeugbegrenzung sl liegt. Die Aufprallzeit Txv,ll berechnet sich mittels des Strahlensatzes nach:

2

1min, *

ssttT llxv ∆

∆∆+=

mit:

( )kyvlyv

lyvkyvll

lxvkxv

kxvlxv

sss

ssss

ttt

ttt

,,2

,,

,,

,,min

,min

),min(

−=∆

−=∆

−=∆

=

( 4.4 )

( 4.5 )

( 4.6 )

( 4.7 )

( 4.8 )

Hieraus folgt für die Aufprallzeit llxvT , :

( ) ( ) ( )

( ) ( ) ( )

∞

<<∧>−

−−+

<<∧≤−

−−+

=

sonst

sssttfürssss

ttt

sssttfürss

ssttt

T lyvlkyvlxvkxvkyvlyv

llyvlxvkxvlxv

lyvlkyvlxvkxvkyvlyv

kyvlkxvlxvkxv

llxv ,,,,,,

,,,,

,,,,,,

,,,,

, *

*

( 4.9 )

Analog zu dieser Gleichung werden die Aufprallzeiten der Fälle 3 bis 5 berechnet. Es wird bei dem entsprechenden Fall die zugehörige Fahrzeuggrenze und die Objektpunkte, die das Ob-jektsegment des Falles begrenzen in die Gleichung eingesetzt. Die Gleichungen sind im An-hang in Kapitel 11.1.2 dargestellt.

Nach der Berechnung der fünf Aufprallzeiten der Kollisionsfälle, wird die kürzeste berechne-te Zeit als Kollisionszeit für das Objekt ausgewählt.

Die beschriebene Berechnung der Kollisionsdaten eines Objektes ist in der Funktion get_objektData() realisiert. Dieser Funktion werden die Aufpralldaten der Objektpunkte, so-wie die zugehörige Objektnummer übergeben. Die Implementierung der beschriebenen Funk-tion ist dem Code-Listing im Anhang (s. Kap. 11.2.4) zu entnehmen.

Alle auf die beschriebene Weise berechneten Kollisionsdaten der Objekte werden in einer verketteten Liste hinterlegt und das Objekt mit der geringsten Aufprallzeit ermittelt. Die Auf-pralldaten des Objektes, bestehend aus der Aufprallzeit T und der Entfernung sx. Sie werden am Ende der Funktion an die aufrufende Funktion zurückgegeben.

Stefan Cordes Auswertung des berechneten Bremsstatus zur Fahrzeugsteuerung

- 27 -

5. Auswertung des berechneten Bremsstatus zur Fahrzeugsteue-rung

Die Ermittlung des Bremsstatus erfolgt aufgrund der berechneten Kollisionsdaten, sowie der Informationen über die Fahrzeugbewegung. Die in [1] vorgestellte Berechnung des Status zum Auslösen der Notbremsung soll Information darüber geben, ob der letztmögliche Zeit-punkt erreicht ist, in dem eine Kollision mit einem Objekt vermieden werden kann. Ein Bremsassistent, der aufgrund dieser Information eingreift, hat die Möglichkeit, den Schaden der Kollision zu reduzieren. Da der umzusetzende Assistent die Kollision komplett vermeiden soll, muss das Signal vor dem genannten Zeitpunkt ausgelöst werden. In diesem Kapitel wird die Berechnung des Bremsstatus beschrieben, der durch den Bremsweg, und die Bremszeit bestimmt ist.

Um den letztmöglichen Zeitpunkt eines kollisionsvermeidenden Bremsmanövers zu erkennen, kann die Bewegung des kollidierenden Objektes auf zwei Arten interpretiert werden. Es kann als längs- und querbewegtes Objekt betrachtet werden. Bei jeder Interpretation werden eine Bremszeit und ein Bremsweg berechnet. Aus diesen beiden Wertepaaren wird anschließend das Paar mit dem geringeren Bremsweg an die aufrufende Funktion zurückgegeben. Für die Berechnung werden die Aufpralldaten mit der Kollisionszeit T und Kollisionspunkt sy, die Objektparameter mit den Geschwindigkeitsvektoren vx und vy und dem Abstand sx, als auch die Fahrzeugeigenschaften mit der Eigengeschwindigkeit ve, der Bremsbeschleunigung a und der linken Fahrzeugbegrenzung sl übergeben..

Min1

min()

xv

ev

a

ys

yv

T

xs

ls

bs

bt

bxs

bxt

bys

byt

Abb. 22: Blockschaltbild der getBremsdaten-Funktion

Bei einem stehenden längsinterpretierten Objekt muss das eigene Fahrzeug bis zum Stand abgebremst werden. Bewegt sich das Objekt, so wird das Fahrzeug soweit abgebremst, dass die Differenzgeschwindigkeit Null beträgt, bevor es die Position des Objektes erreicht. Die Situation mit einem entgegenkommenden Objekt, d.h. mit negativer Geschwindigkeit soll


- 28 -

hier nicht betrachtet werden, da die Kollision in dem Fall nicht durch ein Bremsmanöver ver-mieden werden kann. Bei einem querbewegten Objekt muss die Geschwindigkeit nur soweit reduziert werden, dass das Objekt die eigene Fahrspur verlassen hat, wenn sich das eigene Fahrzeug auf Höhe des Objektes befindet. Das heißt, dass das eigene Fahrzeug auch nach dem Passieren des Objektes zum Stehen kommen kann. Eine Interpretation als längsbewegtes Ob-jekt ist in Abb. 23 dargestellt.

vxve v02

sbx

sb1

sb2

Fz Fz 2

sxo - sv l2

l2

sb2

Abb. 23: Kollision mit einem längsbewegten Objekt

Eine Kollision tritt ein, wenn die Eigengeschwindigkeit ve größer als die Geschwindigkeit v02 des Fahrzeuges Fz 2 ist. Damit ist der eigene Bremsweg sb1 entsprechend länger, als der Bremsweg sb2 von Fahrzeug Fz 2. Bei einer Vollbremsung beider Fahrzeuge kommt es zu keiner Kollision, wenn die Differenz der Bremswege sbx kleiner als der Abstand der beiden Fahrzeuge ist. Es muss also gelten:

vxbbbx sssss −≤−= 021 ( 5.1 )

Die Gleichung für die zurückgelegte Strecke eines negativ beschleunigten Körpers ist durch das Integral der Geschwindigkeitsgleichung definiert:

tvta

tvts

vtatv

**21

)()(

*)(

02

0

+−=

=

+−=

∫ ( 5.2 )

( 5.3 )

Wobei t die Zeit bis zum Stillstand des jeweiligen Fahrzeuges ist (vgl. Abb. 24). Die Ge-schwindigkeit v0 beschreibt die Startgeschwindigkeit des jeweiligen Fahrzeuges. Im speziel-len sind dies die Geschwindigkeit des eigenen Fahrzeuges ve und die des detektierten Fahr-zeuges v02. Die Bremszeit t berechnet sich aus der Differenz der aktuellen zu der Sollge-schwindigkeit und der Bremsbeschleunigung a. Bei einem Bremsmanöver mit vsoll = 0 m/s gilt:

av

avvt soll 00 =

−−

= ( 5.4 )

Der Verlauf der Geschwindigkeiten beider Fahrzeuge während eines Bremsvorganges ist in Abb. 24 dargestellt.


- 29 -

t

v

ve

v02

tb2 tb1

a

atvtv ee −=)(

atvtv −= 0202 )(

vx

t

Auslösezeitpunkt des

Bremsmanövers

Abb. 24: v-t-Diagramm der Fahrzeuggeschwindigkeiten bei Notbremsung

Setzt man nun die Anfangsgeschwindigkeiten der Fahrzeuge mit der Annahme gleicher Bremsbeschleunigung a in die Gleichungen zur Berechnung der Bremswege, in ( 5.1 ) ein, so erhält man:

+=

+=−

=

−−−=

−

+

−

−

−

+

−

=

+−+=

−=

exx

bx

xee

e

ee

e

eee

bbbx

vvavs

vvvmitavv

av

av

avv

ava

av

vav

a

tvtatvta

sss

2

*2

*2*2

**21**

21

**21**

21

2

222

22

2

22

22

2

222

22

21

( 5.5 )

( 5.6 )

( 5.7 )

( 5.8 )

( 5.9 )

( 5.10 )

Die Berechnung des Bremsweges allein reicht nicht zur eindeutigen Identifizierung des letzt-möglichen Bremszeitpunktes. Wenn der Bremsweg größer dem Abstand zu dem Fahrzeug, bzw. Objekt ist, steht möglicherweise noch ausreichend Zeit zur Verfügung, um die Kollision bspw. durch ein Ausweichmanöver zu vermeiden. Ein Fahrzeug, welches mit einer Ge-schwindigkeit von 20 m/s und einer Bremsbeschleunigung von 1 m/s² auf ein Hindernis in 160 m Entfernung zufährt, kann die Geschwindigkeit innerhalb von 20 s auf einer Strecke von 200 m auf Null reduzieren. Damit ist der Bremsweg 40 m länger als die Entfernung zu dem Hindernis. In diesem Fall hat der Fahrer ungebremst noch 8 s um die Kollision durch ein Ausweichmanöver zu vermeiden, obwohl der Bremsweg größer als der Kollisionsweg ist. Aus diesem Grund wird zusätzlich die Bremszeit berechnet. Für die Bremszeit gilt:


- 30 -

av

avvtt soll

bx00 =

−−

== ( 5.11 )

Die beschriebene Berechnung des Bremsweges und der Zeit erfolgt in der Funktionsgruppe Bremsermittlung.c in der Funktion interpretLaengs(). Dieser Funktion werden die Differenz-geschwindigkeit vx und die Eigengeschwindigkeit ve übergeben. Der Rückgabewert ist eine Struktur, die den Bremsweg sbx und die Bremszeit tbx enthält.

Division1Division1

+1

+1

++1

+1Division1Division1

k=1

Gain1

a

ev

xv

bxs

bxt

Abb. 25: Blockschaltbild der interpretLaengs-Funktion

Betrachtet man das Objekt als querbewegtes Objekt, so ist es nicht notwendig, dass Fahrzeug vor dem erreichen der x-Koordinate des Objektes zum Stillstand abzubremsen. Es reicht aus, wie in Abb. 26 dargestellt, die Geschwindigkeitsdifferenz vx soweit zu reduzieren, dass das Objekt bei erreichen der x-Koordinate den eigenen Pfad, d.h. die Fahrzeugbegrenzung schon passiert hat (Abb. 26b).

Fz 2

Fz

vx0

x

y

Fz 2

Fz

vxred

x

yvy

vy

syrsl

syr

b)a)

vy vy

Abb. 26: Kollision mit einem querbewegten Hindernis a) und die Vermeidung durch

Geschwindigkeitsreduktion b)


- 31 -

Damit die Kollision vermieden wird, muss das Fahrzeug um eine definierte Zeit später an der vermeidlichen Kollisionskoordinate ankommen. Diese berechnet sich aus der Strecke, die das Fahrzeug Fz 2 in y-Richtung zurücklegen muss. Diese ergibt sich aus dem Abstand der y-Koordinate des Aufpralls syv,r zu der Fahrzeugbegrenzung sl (vgl. Abb. 26b).

y

lryvg v

sst

|||| , +=∆ ( 5.12 )

Da die Verzögerung nur durch eine Vollbremsung erfolgen darf, bleibt die Fahrzeugge-schwindigkeit konstant bei v0, bis das Bremsmanöver zum zu ermittelnden Zeitpunkt tbq ein-tritt, und das Fahrzeug mit der Beschleunigung a abgebremst wird (vgl. Abb. 27). Die Strecke bis zum Aktivieren der Bremse beträgt:

bqtvs *00 = ( 5.13 )

und der Weg des Bremsmanövers:

20 *

2* tatvsby ∆+∆= ( 5.14 )

Abb. 27: Zeitverlauf für Geschwindigkeit (oben) und Weg (unten) während eines Bremsmanövers für ein

querbewegtes Hindernis


- 32 -

Daraus ergibt sich die Gleichung für den Weg bis zum Fahrzeug Fz 2:

2000 *

2** tatvtvsss bqyx ∆+∆+=+= ( 5.15 )

Mit :

bqg ttTt −∆+=∆ ( 5.16 )

erhält man nach Umformung die folgende Gleichung.

( ) ( )200 *

2** bqgbqgbqx ttTattTvtvs −∆++−∆++= ( 5.17 )

Um die Zeit tbq aus der Gleichung zu entfernen, substituiert man die Gleichung mit:

bqby tTt −= ( 5.18 )

Man erhält anschließend nach der Umstellung der Gleichung nach tby die Zeit des Bremsma-növers.

ggx

by ta

tTvst ∆−

∆+−=

))(*(*2 0 ( 5.19 )

Nun muss noch berücksichtigt werden, dass von der Strecke sx die vordere Fahrzeugbegren-zung sv abgezogen wird, da der Koordinatenursprung auf der Hinterachse des Fahrzeuges liegt.

Der Bremsweg ergibt sich aus der Beschleunigungsgleichung, in der für die Zeit die Brems-zeit tby eingesetzt wird.

bybyby tvtas **21

02 += ( 5.20 )

Die Berechnung der Bremsdaten bei querinterpretiertem Objekt, wird in der Funktionsgruppe Bremsermittlung.c in der Funktion interpretQuer() realisiert (vgl. Abb. 28). Dieser werden die Eigengeschwindigkeit ve und die Aufpralldaten mit den Aufprallkoordinaten der Objektpunk-te, den Differenzgeschwindigkeitsvektoren vx und vy sowie der Zeit T bis zur Kollision über-geben. Der Rückgabewert ist eine Bremsdaten-Struktur, die die Bremszeit tby und den Brems-weg sby enthält.


- 33 -

Abs1

abs

Division1Division1

+1

+1

++1

+1

+1

-1

+-1

+1

Division1Division1

-1

+1

++1

-1

k=1

Gain1

sqrt

+1

-1

+-1

+1

+1

+1

++1

+1

k=1

Gain1

+1

+1

++1

+1

k=2

k=0,5

interpretQuer()

ls

ev

ys

yv

xs

a

bys

byt

T

t∆bqt

Abb. 28: Blockschaltbild der interpretQuer-Funktion

Nach der Berechnung der Bremswege bei quer- und längsinterpretiertem Objekt wird der Kleinere für die Generierung des Bremsstatus ausgewählt. Damit wird der letztmögliche Zeit-punkt zur Kollisionsvermeidung erfasst.

Damit der zu generierende Status den Zeitpunkt vor dem letztmöglichen Zeitpunkt zur Kolli-sionsvermeidung signalisiert, wird auf den Bremsweg ein Sicherheitsabstand sd aufaddiert. Die Größe dieses Abstandes wird in Kapitel 7 beschrieben. Auf die berechnete Bremszeit wird entsprechend die Zeit aufaddiert, in der der Sicherheitsabstand bei der aktuellen Ge-schwindigkeit zurückgelegt wird. Es gilt:

0vs

tt dbb +=+ ( 5.21 )

Vergleicht man nun die Bremsdaten mit den Aufpralldaten, so kann aus dem Größenverhält-nis der Bremsstatus ermittelt werden. Sind sowohl Bremszeit, als auch Bremsweg größer als die Aufprallzeit bzw. des Aufprallweges, so wird der Status auf aktiv gesetzt. Sind die Brems-daten kleiner, so bleibt der Status inaktiv, d.h. auf Null (s. Kap. 2.1). Die Implementierung der Funktionsgruppe Bremsermittlung.c ist dem Code-Listing im Anhang zu entnehmen (s. Kap. 11.2.5).

Stefan Cordes Objekterkennung zur Umgebungsklassifizierung

- 34 -

6. Objekterkennung zur Umgebungsklassifizierung

Der Bremsassistent soll auf Basis der ausgewerteten Entfernungswerte des Laserscanners Kollisionen erkennen und vermeiden. Diese Kollisionen erfolgen mit Hindernissen, in dem Umfeld des Fahrzeuges, deren Entfernungswerte dieselbe Differenzgeschwindigkeit zum ei-genen Fahrzeug vermitteln. Damit nicht jeder eingescannte Entfernungswert separat auf Kol-lisionen überprüft werden muss, werden in der Fahrzeugumgebung Objekte ermittelt. Die Umgebungsinformationen können daraufhin auf wesentliche Objektinformationen reduziert werden, für die die Berechnung der Kollisionsdaten erfolgt. Da das Assistenzsystem auch auf µControllern mit geringerer Rechenleistung implementiert werden soll wird damit der Re-chenbedarf so gering wie möglich gehalten.

In Kapitel 6.1 ist die Aufbereitung der Entfernungswerte beschrieben, die für die Objekter-kennung erforderlich ist. Die Abstandswerte des Laserscanners müssen mit einem Filter auf-gewertet werden, da diese mit einem durch die Messung bedingten Rauschen behaftet sind. Die Objektgenerierung aus diesen aufbereiteten Werten erfolgt in zwei Schritten. In dem ers-ten Schritt werden aus den Entfernungswerten in der Segmentierung benachbarte Abstands-werte mit geringer Entfernungsdifferenz zu Segmenten zusammengefasst (s. Kap. 6.2). In dem zweiten Schritt werden aus den Segmenten mehrerer Scans Objekte generiert, die zusätz-lich Informationen über die Geschwindigkeit des Gegenstandes enthalten. Diese Objektgene-rierung ist in dem Kapitel 6.3 beschrieben.

Bei Auftreten eines messbedingten Fehlscans werden die Objekt- und Segmentinformationen intern für den nächsten Abtastzyklus berechnet (s. Kap. 6.4). Durch diese Berechnung kann das Objekt in dem folgenden Scan wieder erkannt, und genauere Umgebungsinformationen berechnet werden. Nach dem entwickelten Verfahren liegen dem System zuverlässige Objekt-informationen vor, anhand derer das Assistenzsystem Kollisionsdaten, als auch Bremsdaten berechnen kann.

6.1. Datenfilterung zur Rauschunterdrückung

Die Abstandswerte, die der Laserscanner an den Koordinierungsrechner schickt, enthalten ein Störsignal, da sie auf Messwerten basieren. Dieses Rauschen führt in der Analyse der Daten zu Fehlinterpretationen und muss daher durch eine vorgeschaltete Filterung des Eingangssig-nals unterdrückt werden. Es gilt das Störsignal zu quantifizieren, damit das Filter an das über-lagerte Rauschen angepasst werden kann. Diese Analyse und die Wahl des geeigneten Filters sind in dem folgenden Abschnitt beschrieben.

Für die Auswertung des Störanteils im Abstandssignal wird der Scanbereich des Laserscan-ners auf einen Winkel reduziert. Als Kenngrößen des Rauschens sind die maximale Abwei-chung umax, sowie die Standardabweichung σ gewählt worden. Mittels dieser Kenngrößen können in der weiteren Bearbeitung der Messwerte Toleranzen bestimmt werden, durch die die Aussagekraft der Entfernungswerte bestimmt wird.

Bei der Erfassung dieser Kenndaten wurde die zu ermittelnde Entfernung auf mehrere stati-sche Abstände von zwei, vier, und sechs Metern gestellt. Hierfür wurde der Laserscanner in dem jeweils vorgegebenen Abstand zur Wand positioniert. Zusätzlich wurden Messwerte mit konstanten Geschwindigkeiten von 0,2 m/s, 1 m/s und 1,4 m/s erfasst, um die Unabhängigkeit des Rauschens auf Entfernungsänderungen zu prüfen. Die aus der Geschwindigkeit resultie-rende Entfernungsänderung wurde berechnet, um die Messwerte vergleichen zu können. Die


- 35 -

Ergebnisse der Messungen sind in Tab. 8 dargestellt. Die maximale Abweichung umax beträgt 8 cm.

Konst. Abstand und Geschwin-

digkeit

Max. negative Abweichung

Max. positive Abweichung

Betrag der max. Abweichung

Standard-Abweichung σ

2 Meter -0,055 m 0,055 m 0,055 m 0,018 m 4 Meter -0,055 m 0,062 m 0,062 m 0,019 m 6 Meter -0,051 m 0,055 m 0,055 m 0,018 m 0,2 m/s -0,061 m 0,079 m 0,079 m 0,023 m 0,6 m/s -0,070 m 0,080 m 0,080 m 0,022 m 1,4 m/s -0,064 m 0,050 m 0,064 m 0,019 m

Tab. 8: Entfernungsabweichung der Laserscannerdaten bei verschiedenen konstanten Abständen und Geschwindigkeiten

Die aus der Anzahl der Messungen N, den jeweiligen Entfernungswerten xi und dem arithme-tischen Mittel der Entfernungswerte x̄ berechnete Standardabweichung σ (vgl. Gl. ( 6.1 )) lag bei allen Messungen im Bereich von 1,8 cm. Nimmt man nun das Rauschen als eine Normal-verteilte Störung an, so ergibt sich aus den Messergebnissen die in Abb. 29 dargestellte Nor-malverteilung f(σ).

∑=

−−

=N

ii xx

N 1

2)(1

1σ ( 6.1 )

-0.08 -0.06 -0.04 -0.02 0 0.02 0.04 0.06 0.080

5

10

15

20

25Normalverteilung des Messwertes

Abweichung / m

Wah

rsch

einl

ichk

eit i

n %

Abb. 29: Normalverteilung der Messabweichung des Laserscanners LD OEM

Das analysierte Rauschen soll für die weitere Bearbeitung unterdrückt werden, um Fehlinter-pretationen zu vermeiden. Hierfür wird das Eingangssignal mit einem Finiten Impulse Res-ponse Filter (FIR-Filter) gedämpft. Eine wesentliche Eigenschaft des Filters ist der lineare Phasengang. Die Linearphasigkeit bedeutet, dass das System eine konstante Gruppenlaufzeit aufweist, was z.B. eine verzögerungsfreie Übertragung ermöglicht [5]. Das als Tiefpass aus-gelegte Filter soll die Störamplitude reduzieren.

Das FIR-Filter berechnet den gefilterten Messwert anhand einer Anzahl N Faktoren an voran-gegangenen Messwerten, die mit jeweils einem Faktor gewichtet werden. Eine spezielle Vari-


- 36 -

ante des FIR-Filters ist das Moving-Average-Filter, bei dem alle Messwerte mit dem Faktor 1/(N+1) multipliziert werden.

Die Gruppenlaufzeit beider Filter ist durch die folgende Gleichung definiert:

2*TNTg = ( 6.2 )

wobei T die Abtastrate des diskreten Systems ist. Je größer N gewählt wird, umso stärker wird die Abstandsstöramplitude des neu eingelesenen Messwertes unterdrückt. Nachteilig ist, dass die Gruppenlaufzeit ebenfalls steigt und damit das System sehr träge wird. Als Kompromiss soll der Wert auf N = 9 gesetzt werden. Die Gruppenlaufzeit beträgt somit 225 ms in dem System mit einer Abtastrate T von 50 ms.

Im Folgenden sollen nun die beiden Filtervarianten betrachtet werden. Damit diese viele Stör-frequenzen herausfiltern, muss eine niedrige Eckfrequenz gewählt werden, die angibt, ab wel-cher Frequenz das Eingangssignal nicht mehr verstärkt wird. Diese Frequenz kann nur bei dem FIR-Filter durch die Wahl der Faktoren der Messwerte bestimmt werden. Da nur sehr niederfrequente Signale durchgelassen werden sollen, wird eine Eckfrequenz von 1 Hz ge-wählt. Es ergeben sich die in Abb. 30a dargestellten Amplitudengänge für die beiden Filterva-rianten.

0 2 4 6 8 100

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1Amplitudengang der Filter

Frequenz / Hz

Am

plitu

de

MA-FilterFIR-Filter

0 1 2 3 4 51.82

1.84

1.86

1.88

1.9

1.92

1.94Filtervergleich

Zeit / s

Abs

tand

/ m

MesswertMA-FilterFIR-Filter

Abb. 30: Amplitudengang des FIR- und MA-Filters (a) und der Vergleich des Eingangssignals mit den

Ausgangswerten beider Filter (b)

Der Abb. 30a ist zu entnehmen, dass das FIR-Filter einen deutlich glatteren Amplitudengang hat, und damit die hohen Frequenzen deutlich besser unterdrückt.

Betrachtet man das Verhalten der Filter bei einer Sprungantwort (vgl. Abb. 31a) so bestätigt sich, dass die beiden Filter nach der Gleichung ( 6.2 ) dieselbe Gruppenlaufzeit haben. Diese Eigenschaft ist daher nicht ausschlaggebend für die Wahl des Filters. Das FIR-Filter reagiert im Vergleich zum MA-Filter später, dafür übernimmt es die Änderung schneller.


- 37 -

0 0.1 0.2 0.3 0.4 0.50

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1Sprungantwort

Zeit / s

Am

plitu

de

MA-FilterFIR-Filter

0 0.1 0.2 0.3 0.4 0.50

0.05

0.1

0.15

0.2

0.25Impulsantwort

Zeit / s

Am

plitu

de

MA-FilterFIR-Filter

Abb. 31: Sprung- (a) und Impulsantwort (b) der Filter mit N = 9 , T = 50 ms

Der Impulsantwort beider Filter ist zu entnehmen, dass das MA-Filter den Impuls deutlich stärker unterdrückt (vgl. Abb. 31b). Die Amplitude des Ausgangssignals ist im Vergleich zum FIR-Filter um den Faktor zwei geringer, da die Abtastwerte der Impulsantwort bei einem FIR-Filter den Filterkoeffizienten entsprechen. Die Länge der Impulsantwort ist durch die Filter-ordnung N definiert. Für die Länge L gilt: L = N+1

Vergleicht man abschließend direkt die Wirkung beider Filter auf die Messwerte einer kon-stanten Entfernung, so zeigt sich, dass das MA-Filter das Signal stärker dämpft, als das FIR-Filter (vgl. Abb. 30b). Zusätzlich ist der Rechenaufwand des FIR-Filters höher, als der des MA-Filters, da bei diesem jeder einzelne gespeicherte Wert mit einem Faktor multipliziert werden muss. Bei dem MA-Filter folgt nach der Addition der Werte lediglich eine Division. Aufgrund der höheren Dämpfung, und um den Rechenaufwand gering zu halten, ist ein MA-Filter realisiert worden. Im Folgenden wird die Verzögerung des Filters, das heißt die zeitli-che Differenz zwischen dem Eingangs- und Ausgangssignal des Filters und dessen Auswir-kungen ermittelt. Die durch das Filter verursachte Differenz zwischen Ist- und Ausgangswert wird anhand der Systemgleichung des MA-Filters ermittelt.

∑=

−+=

N

kknn u

Ny

0*

11 ( 6.3 )

Mit einem Speicher von N = 9 ergibt sich die Gleichung:

( )987654321*101

−−−−−−−−− +++++++++= nnnnnnnnnnn uuuuuuuuuuy ( 6.4 )

Die maximale Entfernungsdifferenz entsteht, wenn sich das erfasste Objekt mit maximaler Geschwindigkeit von 1,4 m/s, entgegengesetzt zum maximal beschleunigten Fahrzeug be-wegt. Die resultierende Differenzgeschwindigkeit ist demnach

smvvvvvv oe 8,2*2 maxmaxmax ==+=+=∆ ( 6.5 )

Das System misst mit einer Frequenz von 20 Hz neue Entfernungswerte. Damit ergibt sich eine maximale Abstandsänderung pro Abtastintervall von:


- 38 -

mHz

sm

fvTvs 14,0

20

8,2* ====∆ ( 6.6 )

Setzt man diesen Wert in die Gleichung ( 6.4 ) ein, so erhält man:

( ) ( ) ( ) ( )( ) ( ) ( ) ( ) ( )

( )

mu

usu

sususususususususuu

y

n

nn

nnnnn

nnnnnn

63,0

14,0*5.445*10*101

98765432

*101

−=

−=∆−=

∆−+∆−+∆−+∆−+∆−

+∆−+∆−+∆−+∆−+=

( 6.7 )

Es resultiert eine maximale Differenz von Δsm = 63 cm, um die sich bei bewegten Objekten der Ausgangswert von dem aktuellen Eingangswert unterscheidet. Diese Differenz muss in der Berechnung des Bremsweges für die Bestimmung des Bremsstatus berücksichtigt werden (siehe Kap.7.1). Bei einem sich nähernden Fahrzeug ist der Entfernungswert des Filteraus-gangs y größer der gemessenen Entfernung des Laserscanners u (vgl. Abb. 32b). Damit der Bremsassistent dennoch rechtzeitig auf die bevorstehende Kollision reagiert, muss die be-rechnete maximale Abweichung auf den Sicherheitsabstand addiert werden. Bei geringeren Geschwindigkeiten als der maximalen Differenzgeschwindigkeit ist die durch das Filter be-dingte Abweichung geringer. Das Fahrzeug kommt mit größerem Abstand zum Hindernis zum stehen.

Die zeitliche Differenz, die zwischen dem aktuellen Eingangswert und dem Erreichen des gemittelten Wertes dieses Abstandes liegt, ergibt sich aus der Zeit, die bei der maximalen Geschwindigkeit benötigt wird, um die Strecke Δsm zurückzulegen.

msHzHzmm

vst 22520

15,420*14,0

63,0===

∆=∆ ( 6.8 )

Die zeitliche Differenz von Eingangs- und Ausgangswert beträgt demnach 225 ms. Diese Zeit ist aufgrund der durch das Filter erreichten höheren Qualität der Entfernungswerte zu tolerie-ren.

Abb. 32: Rampenantwort für sich entfernende Fahrzeuge a) und aufeinander zufahrende Fahrzeuge b)


- 39 -

Bewegt sich ein Objekt quer zum Fahrzeug, so entstehen hohe Sprünge in den gemessenen Entfernungen des Laserscanners. Mit dem oben beschriebenen Filter würde die vollständige Änderung erst erkannt, wenn das komplette Abtastwerte-Array mit den neuen Werten be-schrieben wurde. Das würde bei dem MA-Filter mit N = 9 bei einer Abtastfrequenz von 20 Hz 450 ms dauern. Um diese sprungartigen Änderungen schneller zu detektieren, ist ein By-pass implementiert, der den Filter-Speicher komplett mit dem neu gemessenen Wert füllt, wenn dieser einen Abstandswert zur gemittelten Entfernung überschreitet. Der Schwellwert ist durch die Summe der maximalen Abstandsänderung Δs pro Abtastintervall und der maxi-malen Messabweichung umax definiert.

mmmussschwelle 2,005,015,0max =+=+∆= ( 6.9 )

Bei einer Abstandsänderung, die größer als der Schwellwert ist, muss sich ein Objekt tangen-tial zum Laserscanner bewegt haben. Eine Messung des Ausgangs des MA-Filters mit der integrierten Bypass-Funktion ist in Abb. 33 dargestellt.

0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5

0.8

1

1.2

1.4

1.6

1.8

2MA-Filter mit Bypass

Zeit / s

Abs

tand

/ m

MesswertMA-Fliter

Mittelwertbildung bei konstantem

Entfernungswert

Durch den Bypass ausgelöster Sprung auf den aktuellen Abstand

Rampenantwort mit verzögertem

Ausgangswert

Abb. 33: MA-Filter mit integrierter Bypass-Funktion

Bei einem Objekt welches sich von dem eigenen Fahrzeug entfernt, ist die Entfernung des Ausgangswertes des MA-Filters geringer der gemessenen Entfernung. Das Ausgangssignal ist jedoch deutlich gedämpfter. Bei einer großen Entfernungsänderung von 90 cm, die nur durch eine seitliche Bewegung des Objektes aus dem Scannbereich bedingt sein kann, wird die Än-derung ohne einen zeitlichen Versatz erkannt. Die Implementierung des beschriebenen Filters ist dem Code-Listing im Anhang zu entnehmen (s. Kap. 11.2.1).


- 40 -

6.2. Erkennung von Segmenten aus zusammenhängenden Entfernungswerten

In der Objekterkennung müssen im nächsten Schritt aus den aufbereiteten Entfernungswerten Segmente erkannt werden. Aus diesen Segmenten werden anschließend die Objekte generiert. Als Grundlage für die Segmenteigenschaften dient die in [1] dargestellte Objektdarstellung mittels drei Begrenzungspunkten. In dem folgenden Kapitel sind die Bestandteile der zu er-kennenden Segmente und der Algorithmus dargestellt, nach dem sie aus den Entfernungswer-ten generiert werden.

Für die Darstellung der Umgebung mit Hilfe der durch das Filter aufbereiteten Entfernungs-werte wird diesen jeweils ein Winkel zugewiesen. Aufgrund der definierten Reihenfolge der gescannten Abstandswerte, kann iterativ jedem Entfernungswert ein Winkel von 90 ° bis -90° zugewiesen werden. Diese Polarkoordinaten werden mittels einer anschießenden Segmentie-rung unterteilt. Die Segmente werden anhand von benachbarten Abstandswerten, die eine geringe Entfernungsdifferenz aufweisen, identifiziert. Der Abstand zwischen zwei Segmenten muss abhängig von der jeweiligen Umgebung und den Anforderungen an die Objekterken-nung definiert werden.

Bei einem Umgebungserfassungssystem, welches in einer Umgebung mit großen Objekten wie bspw. Containern eingesetzt wird, muss der Abstand zur Segmentdifferenzierung größer gewählt werden, als bei einem System mit kleinen Objekten.

Punkt mit dem geringsten Abstand Rechter BegrenzungspunktLinker BegrenzungspunktMittelpunkt

12

3

1 Identifikationsnummer Entfernungswert

xo x

x+

+

+

oo

ox

+

Abb. 34: Darstellung der Umgebung durch Entfernungswerte und der interpretierten Segmente

In der Testumgebung des Fahrzeuges mit Objekten in der Größe von einem halben Kubikme-ter und geringeren Entfernungen, ist ein geringerer Abstand einzustellen, da sonst die Seg-mente nicht separat erkannt werden können. Es wurde eine Differenz von 20 cm gewählt. Die einzelnen Segmente werden auf folgende Segmentinformationen reduziert, um den Rechen-aufwand und den Speicherbedarf des Bremsassistenten möglichst gering zu halten.

• Koordinate mit dem geringsten Abstand zum eigenen Fahrzeug

• Koordinate, die am weitesten links liegt

• Koordinate, die am weitesten rechts liegt,


- 41 -

• Gemittelte Koordinate aus allen Entfernungswerten des Segmentes

• Anzahl an erlaubten Fehlsichtungen

• Eindeutige Identifikationsnummer

Die Koordinaten der Segmente bestehen aus vier Segmentpunkten. Zwei Punkte beschreiben die linke und rechte Segmentbegrenzung, einer gibt den Punkt mit dem kürzesten Abstand zum eigenen Fahrzeug an und der vierte stellt den Mittelwert aller Entfernungswerte des Segmentes dar. Die ersten drei Punkte beschreiben die für das Bremssystem relevanten Seg-mentgrenzen, mit Hilfe derer die Aufpralldaten, als auch der Bremsstatus berechnet wird. Der gemittelte Wert dient in der Objektgenerierung der Geschwindigkeitserkennung. Durch die Mittelung aller Entfernungswerte des Segmentes werden hohe Frequenzen, d.h. schnelle Ent-fernungsänderungen gedämpft. Dadurch erhält man einen stabilen Entfernungswert für das Segment, der für die Geschwindigkeitsermittlung genutzt wird. Die Reduktion der Informati-on des Segmentes auf die vier Punkte wirkt sich nicht negativ auf Funktion des Bremsassis-tenten aus (s. [1], S. 22).

Zusätzlich zu den Koordinaten besitzt jedes Segment eine eindeutige ID die zur Identifikation des Segmentes dient. Jedes Segment, welches das erste Mal erkannt wird, bekommt eine ID zugewiesen, die durch einen fortlaufenden Zähler definiert wird. Für den Fall, dass ein Seg-ment in einem Scan aufgrund von Messfehlern nicht erkannt wurde, wird der Zähler der ma-ximalen Fehlsichtungen des Segmentes dekrementiert. Dieser gibt an, in wie viel Scans das Segment nicht erkannt werden darf, bis es endgültig gelöscht wird. Dadurch, dass die Seg-mente bei Fehlsichtungen nicht gelöscht werden, erreicht die Segmenterkennung eine höhere Wiedererkennungsrate der Segmente. Diese wird für die Objektverfolgung benötigt, um kor-rekte Aussagen über den Verlauf der Bewegung eines Objektes machen zu können.

Nächster Scanwert P

Neues Segment S

Setze kürzesten Segmentpunkt S.k auf P

Setze rechten Segmentpunkt S.r auf P

[ P.abstand != 0 ] [ P.abstand == 0 ]

[ P.winkel == erster Wert ][ P.winkel != erster Wert ]

[ (P.abstand - S.r) > 20 cm ][ (P.abstand - S.r) <= 20 cm ]

[ P.abstand < S.k ][ P.abstand >= S.k ]

[ P.winkel >= -90 ] [ P.winkel < -90 ]

Sichere altes Segment

Setze linken Segmentpunkt S.l auf P

segmente_generieren

V1

V2

V3

V4

V5

Abb. 35: Aktivitätsdiagramm der Segmentgenerierung


- 42 -

Im Folgenden wird der Algorithmus beschrieben, mit dem die genannten Informationen über die Segmente aus den Entfernungsdaten ermittelt werden. Jedem Entfernungswert wird der zugehörige Winkel zugewiesen. Hierbei wird mit dem ersten Entfernungswert ein neues Seg-ment angelegt (vgl. V3 in Abb. 35). Beträgt ein Entfernungswert Null, so wird dieser über-sprungen (V2), da ein Messfehler aufgetreten ist [9]. Alle Segmentpunkte werden auf den ers-ten Entfernungswert gesetzt.

Mit jedem folgenden Entfernungswert wird geprüft, ob die Entfernungsdifferenz kleiner der definierten maximalen Differenz von 20 cm zwischen zwei Segmenten liegt (V4). Ist dies der Fall, so wird die Entfernung mit dem kürzesten Punkt verglichen. Ist der Abstand geringer, so werden der kürzeste und der rechte Segmentpunkt mit dem neuen Entfernungswert über-schrieben. Ist der Abstand größer, so wird lediglich der rechte Punkt auf den neuen Punkt ge-setzt. Ist die Differenz des neuen Entfernungswertes zu dem rechten Segmentpunkt größer als 20 cm, so wird ein neues Segment erzeugt. Sobald alle Entfernungswerte verarbeitet wurden, d.h. der Winkel kleiner als -90 ° ist, wird die Segmentierung beendet.

Die Entfernungswerte der äußersten Segmentpunkte sind sehr instabil. Dies ist durch Reflek-tionsstörung basierend auf dem Winkel der Objektoberfläche bedingt [10]. Da der Puls nur teilweise reflektiert wird, interpoliert der Laserscanner zwischen den benachbarten Entfer-nungswerten. Aufgrund der dadurch möglichen sprunghaften Entfernungsänderungen kann dieser Wert nicht in die Segmentierung einbezogen werden. Aus diesem Grund werden der linke und rechte Segmentpunkt um einen Entfernungswert nach innen verschoben. Dies wird realisiert, in dem beim Erzeugen eines neuen Segmentes ein Scanwert übersprungen, und wenn das Ende des Segmentes erkannt wurde, der rechte Segmentpunkt auf den vorherigen Scanwert verschoben wird. Nachdem alle Segmente erkannt und deren Grenzen ermittelt wur-den, folgt die Berechnung des Schwerpunktes. Hierfür wird aus den Entfernungswerten und deren Winkel das arithmetische Mittel gebildet.

Da der Koordinatenursprung auf der Rotationsachse des Fahrzeuges, d.h. der Position des Hinterrades liegen soll, müssen alle Segmentpunkte abschießend verschoben werden. Hierfür werden die x- und y-Koordinaten der Punkte berechnet, auf die der Abstand zwischen Laser-scanner und Hinterrad aufaddiert wird. Nach der Translation werden die Koordinaten wieder in Polarkoordinaten umgerechnet, da für die Objektverfolgung der Winkel und die Entfernung zum Fahrzeug benötigt werden. Die Implementierung der segmente_generieren-Funktion ist im Anhang in 11.2.6 dargestellt.

6.3. Objektverfolgung über mehrere Scanprofile

Aus den Segmenten werden anschließend Objekte generiert, die zusätzliche Information über die Geschwindigkeit des Objektes enthalten. Hierfür werden die Segmente aus zwei aufeinan-der folgenden Scans benötigt. Die Objektpunkte werden nicht wie die Segmentpunkte als Po-larkoordinaten sondern im kartesischen Koordinatensystem dargestellt. In der Umgebungs-analyse, in der die Aufpralldaten berechnet werden, können somit ohne Umwandlung der Darstellung die x- und y-Koordinaten des Aufpralls berechnet werden. Ein Objekt besteht aus den folgenden Attributen:

• x- und y-Koordinate des linken Begrenzungspunktes

• x- und y-Koordinate des rechten Begrenzungspunktes

• x- und y-Koordinate des dichtesten Begrenzungspunktes


- 43 -

• x- und y-Komponente der Relativgeschwindigkeit

• eindeutige Objekt Identifikationsnummer

• Zähler für die erlaubten Fehlsichtungen

Eine Funktion der Objektverfolgung ist die Wiedererkennung von Segmenten. Nur wenn die Segmente aus zwei Scans einander zugeordnet werden können, kann auch die Geschwindig-keit ermittelt werden. Die Identifikation der Segmente erfolgt durch die Position des dichtes-ten Begrenzungspunktes K eines Segmentes. Durch die bekannte Position in dem vorange-gangenen Scan kann mit dem Ausschlussverfahren ein Bereich AK definiert werden, in dem das Segment im neuen Scan liegen muss (vgl. Abb. 36a). Alle neu eingescannten Segmente werden auf diese Bereiche geprüft und können damit den Segmenten des alten Scans zuge-ordnet werden. Aufgrund der Eigenbewegung müssen in der Berechnung des Bereiches zwei Koordinatensysteme berücksichtigt werden. Zum einen das System zum Zeitpunkt des ersten Scans, und zum anderen das Koordinatensystem zum Zeitpunkt des aktuellen Scans.

x

y

y’

altL

altKaltR

Rα

Lα

α

ρ

γ

K

γρ−

altα

x’

y’

xy

1K

2K

4KAK

a) b)

3K

Abb. 36: Gültigkeitsbereich des dichtesten Segmentpunkte bei dem nächsten Abtastzyklus (a) und die

geometrische Darstellung (b)

Der gültige Winkelbereich des neuen dichtesten Punktes K ist durch die Winkel der linken und rechten Begrenzungspunkte Lalt und Ralt des alten Segmentes begrenzt, da der Punkt sonst zu einem anderen Objekt gehören würde. Für den Vergleich der Winkel muss der neue Punkt K in das alte Koordinatensystem umgerechnet werden. Die Entfernung ralt und der Winkel αalt des Punktes K aus Sicht des alten Koordinatensystems berechnen sich mit Hilfe des Kosinus-satzes (vgl. Abb. 36b).

Der Abstand zum alten Koordinatensystem berechnet sich wie folgt:

))(180cos(***222 γρα −−−°−+= mmalt srsrr ( 6.10 )

Der Winkel des Punktes K im alten Koordinatensystem berechnet sich aus:


- 44 -

γα

γα

+

−−−

=

−−+=

altm

altmalt

altmaltmalt

rsrsra

srsrr

**2cos

)cos(***2222

222

( 6.11 )

( 6.12 )

Damit gilt für den Winkel:

LaltR ααα << ( 6.13 )

Der in Abb. 36 dargestellte Punkt K1 liegt außerhalb dieser Grenzen und gehört damit nicht zu dem Segment aus dem vorigen Scan. Für den Abstand des neuen Punktes muss gelten, dass dieser im alten Koordinatensystem größer dem Abstand rK des Punktes Kalt ist. Bei einer ge-ringeren Entfernung hätte der Punkt schon in dem vorangegangenen Scan als kürzester Punkt erkannt werden müssen. Es gilt also:

Kalt rr > ( 6.14 )

Dieses Kriterium wird von den Punkten K1 bis K4 nur von dem Punkt K2 nicht erfüllt. Damit kann dieser Punkt ebenfalls ausgeschlossen werden. Vergleicht man die kürzesten Punkte im neuen Koordinatensystem, so muss der neu eingescannte Wert K einen geringeren Abstand zum Fahrzeug haben als der Punkt Kalt, da dieser sonst im neuen Scan erkannt worden wäre.

Für diesen Vergleich muss die Entfernung des Punktes Kalt zu dem neuen Koordinatensystem mit dem Kosinussatz berechnet werden:

)cos(***222, γα −−+= KmKmKneuK srsrr ( 6.15 )

Damit der neu eingescannte Punkt K zu dem Segment gehört muss also gelten:

rr neuK >, ( 6.16 )

Diese Bedingung wird von dem Punkt K4 in der Abb. 36 nicht erfüllt. Es bleibt demnach nur der Punkt K3 der alle Bedingungen erfüllt. Durch die beschriebenen Grenzen ergibt sich der Bereich AK in dem sich der Punkt K3 in dem neuen Scan befindet (vgl. Abb. 36a). Da sich die Objekte mit einer Geschwindigkeit von maximal 1,4 m/s bewegen können, muss der berech-nete Bereich erweitert werden. Die Breite des Streifens, um den der Bereich ausgedehnt wird, ist durch die Entfernung definiert, die das Objekt während eines Abtastzyklus zurücklegen kann. Wie in Kapitel 6.1 beschrieben beträgt dieser 7 cm. Bei dem Vergleich der Entfernun-gen muss dieser Wert berücksichtigt werden. Für den Vergleich mit dem Winkel muss in Ab-hängigkeit zu der Entfernung der zugehörige Winkel für diese Differenz berechnet werden. Die Gleichung für diesen Winkel erhält man durch das Umstellen der Gleichung ( 3.2 ) nach α:

max*2sin*2 σα ∆=

=

baa ( 6.17 )


- 45 -

Die Ungleichungen, die den Gültigkeitsbereich beschreiben lauten dann:

maxmax

max

max,

σαασα ∆+<<∆−∆+<

∆+<

LaltR

altK

neuK

srrsrr

( 6.18 )

( 6.19 )

( 6.20 )

Jedes neu eingescannte Segment wird mit allen Segmenten aus dem vorangegangenen Scan auf die beschriebene Weise verglichen.

objekte_generieren

objekt_erzeugen( neueSegmente[0], alteSegmente[1] )

new ( neueSegmente[9], neueSegmente[9] )

segmente_vergleichen

segmente_vergleichen( neueSegmente[0], alteSegmente[0] )

nicht erkannt


erkannt


nicht erkannt


nicht erkannt

remove(Objekt1, alteObjekte[] )

objekte_aktualisieren(alteObjecte[], veloVector[] )

markierte_objekte_entfernen(alteObjekte[] )

objekte_verschiebenl( neueObjekte[], alteObjekte[] )

remove(alteSegmente[1])

segmente_verschieben( neueSegmente[], alteSegmente[])

objekt_hinzufügen(Objekt1, neueObjekte[] )

objekt_hinzufügen(Objekt8, neueObjekte[] )

marktierte_segmente_entfernen(alteSegmente[])

Objekt 1

Objekt 8

<1>

<2>

<3>

<4>

<5>

<6>

<7>

Abb. 37: Sequenzdiagramm der Objektgenerierung

Wurde ein Segment erkannt, so wird ein neues Objekt mit der ID des erkannten Segmentes erzeugt. Existiert bereits ein altes Objekt mit der ID in der Objektliste, so wird dieses gelöscht (vgl. Abb. 37, <2>). Das alte Segment aus der Liste mit den Segmenten aus dem vorherigen Scan wird ebenfalls entfernt (vgl. Abb. 37, <1>). Stimmt das neue Segment mit keinem der Segmente aus der Liste überein, so wird ein neues Objekt mit der SegmentID erzeugt (vgl. Abb. 37, <4>). Nachdem alle Objekte generiert wurden wird eine Aktualisierungsfunktion aufgerufen(vgl. Abb. 37, <5>). In dieser werden alle alten Segmente und Objekte, die nicht


- 46 -

erkannt und damit nicht aus den Listen entfernt wurden, mit Hilfe der Eigengeschwindigkeit intern aktualisiert. Bei jedem aktualisierten Objekt, bzw. Segment, wird der Zähler der erlaub-ten Fehlsichtungen dekrementiert. Erreicht dieser den Wert Null, so muss das Segment ge-löscht werden. Dies wird am Ende der Objektgenerierung ausgeführt (vgl. Abb. 37, <6>). Abschließen werden die Listen mit den neuen Objekten und Segmenten in die alten Listen kopiert. Damit sind die neu eingescannten und die intern aktualisierten Objekte und Segmente in den alten Listen für den nächsten Durchlauf gespeichert (vgl. Abb. 37, <7>).

Der beschriebene Ablauf der Objektgenerierung ist in dem Sequenzdiagramm in Abb. 37 vi-sualisiert. Die beschriebene Funktionalität der Objekterkennung ist in der Funktionsgruppe Objekterkennung in der Funktion objekte_generieren() implementiert. Beim Aufruf dieser Funktion wird dieser mit den Übergabeparametern die Liste mit den erkannten Segmenten übergeben. Als Rückgabewert erhält die aufrufende Funktion eine Liste mit den generierten Objekten.

6.4. Aktualisierung der Umgebungsdaten mit den Eigenbewegungsparametern

Die Entfernungsdaten sind mit einem zufälligen Fehler behaftet, da sie auf Messwerten des Laserscanners beruhen (vgl. Kap. 6.1). Aufgrund dessen kann es in einzelnen Scans dazu kommen, dass Segmente nicht erkannt werden. Damit die Segmentinformationen auch bei einem fehlerhaften Scan nicht verloren gehen, werden die Segmente intern aufgrund der In-formationen über die Eigenbewegung aktualisiert. Wird das Segment in dem folgenden Scan wieder erkannt, so kann es wieder, basierend auf den Informationen des Laserscanners, aktua-lisiert werden. Damit erkennt das System, dass es sich um dasselbe Segment handelt und die Identifizierungsnummer des alten Segmentes wird übernommen. Diese Zuordnung der Seg-mente ist für Assistenzsysteme notwenig, wenn diese über einen längeren Zeitraum Objekte verfolgen müssen. Wird während eines Manövers die ID des Segmentes und damit auch des daraus generierten Objektes ausgetauscht, so kann das System die gewünschte Reaktion nicht mehr ausführen. Im Folgenden ist die interne Berechnung der Position der Objekte bei dem nächsten Abtastzyklus basierend auf der Fahrzeugbewegung beschrieben.

Die Transformation der Umgebung basiert sowohl auf einer Translation, als auch auf einer Rotation, da das Fahrzeug sowohl die Position ändert, als sich auch um die eigene Achse dreht. Die beschriebene Translation des Punktes P(Px, Py) wird durch die folgende Abbildung beschrieben [12]:

( ) ( )( ) ( )

++++−+

=

−

=

1)cos(*)sin(*)sin(*)cos(*

1000)cos()sin(0)sin()cos(

1001001

11''

ϕϕϕϕ

ϕϕϕϕ

yyxx

yyxx

y

x

y

x

y

x

TPTPTPTP

TT

PP

PP

( 6.21 )

( 6.22 )

Es gilt demnach die Rotation φ als auch den Translationsvektor T zu bestimmen. Über die Fahrzeugbewegung liegt die Information über die Geschwindigkeit v und den eingeschlage-nen Lenkwinkel α vor. Aufgrund dieser Informationen wird mit Ausnahme eines Lenkwinkels von 0° immer eine Kreisbewegung angenommen. Die Strecke, die das Fahrzeug zurückgelegt hat, liegt demnach auf einer Kreisbahn (vgl. Abb. 38).


- 47 -

γ

ϕβ

ms

rrα

α

l vr

rr

βrr

x

y

x

y

a) b) Abb. 38: Kreisbahn eines frontgelenkten Einspurfahrzeuges

Der Winkel φ, mit dem sich das Fahrzeug um die Hinterachse dreht, ist durch den Winkel definiert, den das Fahrzeug auf der Kreisbahn zurückgelegt hat. Dieser Winkel ist durch fol-gende Gleichung definiert:

t∆= *0ωϕ ( 6.23 )

Die Winkelgeschwindigkeit ω0 ist durch das Verhältnis der Geschwindigkeit v zu dem Radius r, der Kreisbahn definiert:

πω

*2360*0

°

=

rv ( 6.24 )

Die Winkelgeschwindigkeit ist bei Vorder- und Hinterrad gleich. Da bei einem Lenkwinkel von 90° der Radius des Hinterrades rr Null ist, und damit die Winkelgeschwindigkeit undefi-niert ist, soll der Radius und die Geschwindigkeit des Vorderrades für die Rechnung verwen-det werden. Der Rotationsradius des Vorderrades rv wird mit Hilfe der trigonometrischen Funktion am rechtwinkligen Dreieck aus dem Lenkwinkel α und dem Radstand l berechnet (s. Abb. 38a):

)sin(αlrv = ( 6.25 )

Setzt man ( 6.25 ) und ( 6.24 ) in ( 6.23 ) ein, so erhält man folgende Gleichung für den Rota-tionswinkel φ des Fahrzeuges:

tl

vt v ∆

°

=∆= *

*2360*

)sin(**0 π

αωϕ ( 6.26 )

Der Koordinatenursprung wurde so gewählt, dass er auf dem Hinterrad liegt. Damit muss der Translationsvektor T des Hinterrades berechnet werden. Der in Polarkoordinaten beschriebene Vektor besteht aus dem Betrag sm sowie dem Winkel γ. Der Betrag des Vektors lässt sich aus


- 48 -

dem Rotationswinkel φ und dem Radius der Kreisbahn des Hinterrades rr bestimmen. Dieser Radius lässt sich durch Umstellen der Gleichung ( 6.24 ) bestimmen.

πω *2*360*

0

°= rvr ( 6.27 )

Die Geschwindigkeit des Hinderrades vr ist durch den Lenkwinkel und die Geschwindigkeit des Vorderrades vr definiert. Bei einem Lenkwinkel α von 90° beträgt die Geschwindigkeit vr = 0 m/s und bei 0° entspricht sie der Geschwindigkeit des Vorderrades. Es gilt:

vr vv *)cos(α= ( 6.28 )

Zerlegt man das aus sm und rr gespannte gleichschenklige Dreieck (vgl. Abb. 38b) in zwei rechtwinklige Dreiecke so gilt mit der Substitution von ( 6.27 ) und( 6.28 ):

πωαϕϕ

*2*360**)cos(*

2sin*2

*22sin

0

°

=<=>=

v

mr

m vsr

s ( 6.29 )

Der Winkel des Translationsvektors ist durch folgende Gleichung definiert (vgl. Abb. 38b).

βγ −°= 90 ( 6.30 )

Es gilt demnach den Winkel β zu bestimmen. Dieser lässt sich mit Hilfe des gleichschenkli-gen Dreiecks aus sm und rr berechnen. Es gilt:

2180

180ϕ

β

ϕββ−°

=

++=° ( 6.31 )

Setzt man nun ( 6.31 ) in ( 6.30 ) ein, so erhält man folgende Gleichung:

229090 ϕϕ

γ =

−°−°= ( 6.32 )

Die Polarkoordinaten des Translationsvektors müssen mit ( 6.33 ) und ( 6.34 ) in kartesische Koordinaten umgewandelt werden, damit sie in der Matrix verwendet werden können.

)sin(*

)cos(*

γ

γ

my

mx

sT

sT

=

=

( 6.33 )

( 6.34 )

Jeder Punkt der Segmente und Objekte kann nun mittels dieser Gleichung aktualisiert, und damit die Position der Segmente bei dem nächsten Abtastzyklus berechnet werden.


- 49 -

Beispielhaft soll im Folgenden die Berechnung bei einer Geschwindigkeit v von 1,4 m/s mit einem Lenkwinkel α von 45° und einem Radstand l von 0,8m dargestellt werden. Die Berech-neten Bewegungsparameter sind in Tab. 9 dargestellt.

Parameter Gleichung Wert

φ sm

sm 05,0**2

360*8,0

)45sin(*/4,1

°

°=

πϕ 3,54°

sm ππ

*2**2

360*8,0

)45sin(*/4,1360*/4,1*)45cos(*

254,3sin*2

°

°°°

°

=

msm

smsm 0,049 m

γ 254,3 °

=γ 1,77°

Tx )77,1cos(*049,0 °= mTx 0,049 m

Ty )77,1sin(*049,0 °= mTy 0,002 m Tab. 9: Berechnete Aktualisierungsparameter bei v = 1,4 m/s, α = 45° und l = 0,8 m

Ein Objektpunkt, der einen Meter von der Hinterachse des Fahrzeuges und 0,3 m von der mittleren Längsachse des Fahrzeuges entfernt ist, ließe sich mit der Matrix aus ( 6.22 ) dann wie folgt berechnen:

( ) ( )( ) ( )

169,799,4

1)54,3cos(*002,08,0)54,3sin(*049,05,0)54,3sin(*002,08,0)54,3cos(*049,05,0

1000)54,3cos()54,3sin(0)54,3sin()54,3cos(

100002,010049,001

18,05,0

1''

mm

mmmmmmmm

mm

mm

PP

y

x

=

°++°+°+−°+

=

°°°−°

=

( 6.35 )

( 6.36 )

Der Objektpunkt P befindet sich demnach in dem nächsten Abtastzyklus an den Koordinaten von P’.

xP

yP 'yP

0,20,2

0,4

0,20,40,6

0,20,40,60,8

-0,2 -0,4

-0,2 -0,4

0,4

Px’

y’

x

y

Abb. 39: Aktualisierung des Objektpunktes P aufgrund der Fahrzeugbewegung

Stefan Cordes Fahrzeugtests und Auswertung

- 50 -

7. Fahrzeugtests und Auswertung

Der in den vorangegangenen Kapiteln beschriebene Bremsassistent wurde wie beschrieben realisiert und die für die Berechnung des Assistenzsystems erforderlichen fahrzeugspezifi-schen Parameter erfasst. Erste Tests zeigten Differenzen zwischen der dem angenommenen Fahrzeugmodell und dem Fahrzeugverhalten. Aufgrund dieser mussten die Gleichungen zur Berechnung der Bremsdaten korrigiert werden. Die Fahrzeugeigenschaften wurden durch zusätzliche Messungen verifiziert, damit die Berechnung des Bremsstatus an das Fahrzeug-verhalten angepasst werden konnte. Sowohl die durchgeführten Messungen, als auch die Än-derungen der Gleichungen zur Berechnung des Bremsweges sind in dem folgenden Kapitel beschrieben. In Kapitel 7.2 sind die Testergebnisse verschiedener Bremstests mit der ange-passten Software dargestellt, die die Funktionalität des Bremsassistenten verifizieren. Ab-schließend werden in dem Kapitel 7.3 die Testergebnisse ausgewertet und Änderungen zur Verbesserung des Bremsassistenten aufgeführt.

7.1. Fahrzeugspezifische Parametrisierung

Für die Umsetzung des Bremsassistenten werden verschiedene fahrzeugspezifische Parameter benötigt. Hierzu gehören die Fahrzeuggrenzen, die Bremsbeschleunigung für die Berechnung der Aufprallzeit, sowie die Position des Laserscanners (Lx, Ly) und des Radstandes l für die Umgebungserkennung. Die Vermessung des Fahrzeuges hat die in Abb. 40 dargestellten Fahrzeugabmessungen ergeben.

lLx

sv

sh

Ly

sl sr

Laserscanner

Vorderrad

Hinterrad

Linke Fahrzeugbegrenzung

Rechte Fahrzeugbegrenzung

Vordere Fahrzeugbegrenzung

Hintere Fahrzeugbegrenzung

Abstand des Laserscanners zur Hinterachse

Abstand des Laserscanners zur Fahrzeugmitte

Radstand

Parameter Messwert

sl

sr

sv

sh

Lx

Ly

l

50 cm

-50 cm

98 cm

-22 cm

82 cm

31 cm

80 cm

Abb. 40: Systemrelevante Fahrzeugabmessungen

Ein weiterer zu bestimmender Parameter ist der einzuhaltende Sicherheitsabstand sd, der bei der Ermittlung des Bremsstatus berücksichtigt werden muss. Dieser Abstand ist durch die Summe der Abweichungen definiert, die bei der Berechnung der Abstandswerte entsteht. Hierzu gehört die maximale Filterabweichung von 63 cm (vgl. Kap.6.1). Des Weiteren muss berücksichtigt werden, dass die Entfernungswerte alle 50 ms erfasst werden. Um die Kollision sicher vermeiden zu können muss die Entfernungsdifferenz, die sich ein Objekt relativ zum


- 51 -

eigenen Fahrzeug in dieser Zeit zurücklegt, berücksichtigt werden. Diese maximale Entfer-nungsänderung pro Abtastintervall liegt bei 14 cm (vgl. Kap. 6.1). Der aus diesen beiden Größen bestehende Sicherheitsabstand sd beträgt demnach 77 cm. Der Bremsweg sb+ für die Ermittlung des Bremsstatus setzt sich demnach aus dem berechneten Bremsweg sb und dem Sicherheitsabstand sd zusammen. Bei der Bremszeit wird zu der berechneten Bremszeit tb die Zeit addiert, in der das Fahrzeug bei aktueller Geschwindigkeit den Sicherheitsabstand sd zu-rücklegt. Es gilt:

0vs

tttt dbdbb +=+=+ ( 7.1 )

Die Bremsbeschleunigung wurde in mehreren Bremsmanövern ermittelt. Hierbei wurde an-hand der Bremszeit und der Startgeschwindigkeit v0 die Beschleunigung a berechnet. Es gilt:

tva = ( 7.2 )

Geschwindigkeit v in m/s Bremszeit tb in s Beschleunigung a in m/s² 0,2 0,55 - 0,36

0,4 0,5 - 0,8

0,6 0,5 - 1,2

0,8 0,55 - 1,4

1 0,6 - 1,6

1,2 0,65 - 1,8

1,4 0,6 - 2.3 Tab. 10: Bremsbeschleunigung a bei Geschwindigkeiten von 0,2 m/s bis 1,4 m/s

Der Tab. 10 ist zu entnehmen, dass die Bremsbeschleunigung nicht konstant ist. Dies ist durch die Geschwindigkeitsregelung bedingt. Je größer die Regeldifferenz ist, die an dem PID-Regler des Fahrreglers anliegt, umso schneller ändert sich die Stellgröße. Dadurch wird bei einer hohen Differenzgeschwindigkeit das Fahrzeug schneller abgebremst als bei niedri-gen. Als Konstante soll hier die Beschleunigung bei mittlerer Geschwindigkeit von 1 m/s gewählt werden. Damit ist der Bremsweg des Fahrzeuges bei hohen Geschwindigkeiten kür-zer und bei niedrigen Geschwindigkeiten länger als der berechnete Bremsweg. Die Kollision kann trotz dem zu kurz berechneten Bremsweges bei niedrigen Geschwindigkeiten sicher vermieden werden, da der Sicherheitsabstand von 77 cm nur bei maximaler Geschwindigkeit benötigt wird.

Die in Kapitel 5 beschriebene Berechnung für den Bremsstatus basiert darauf, dass das Bremsmanöver ohne Zeitverzug nach Detektierung des notwendigen Bremseingriffes erfolgt (s. Kap. Gl. ( 5.3 )). Dieses Verhalten wurde in ersten Tests mit dem beschriebenen Bremsas-sistenten nicht bestätigt. Das Bremsmanöver wurde erst nach einer Totzeit tf ausgelöst. Diese verspätete Reaktion wirkt sich auf den Bremsweg der Notbremsung aus, und muss daher in der Berechnung berücksichtigt werden. Der Bremsweg des Fahrzeuges verlängert sich um den Weg, den das Fahrzeug in der Totzeit tf bei aktueller Geschwindigkeit v0 zurücklegt. Der ge-samte Bremsweg des Fahrzeuges bis zum Stillstand beträgt demnach:


- 52 -

002 ***

21)( vttvtats f++−= ( 7.3 )

Berücksichtigt man diese Änderung in den Gleichungen ( 5.5 ) bis ( 5.10 ) aus Kapitel 5 zur Berechnung des Bremsweges für die Reduktion der Differenzgeschwindigkeit auf vx = 0 m/s bei längsinterpretierten Objekten, so ergibt sich:

++−=

++−++=

−=

exx

xf

fefe

bbbx

vvavvt

vttvtavttvta

sss

*21

2*

***21***

21

2222

21

( 7.4 )

Die Bremszeit beträgt unter der Berücksichtigung der Totzeit:

avt

avvtttt f

sollffbx

00 +=−

−+=+= ( 7.5 )

Bei der Berechnung des Bremsweges sbx und der Bremszeit tbx bei querinterpretierten Objek-ten ist die Totzeit tf in der Gleichung ( 5.14 ) die den Bremsweg während des Bremsmanövers beschreibt wie folgt zu berücksichtigen:

( ) 20 *

2* tattvs fby ∆++∆= ( 7.6 )

Aus dieser Änderung resultieren die beiden folgenden Gleichungen, die den Bremsweg, und die Bremszeit bei querinterpretierten Objekten definiert:

gfgxvx

by ta

ttTvst ∆−

+∆+−=

)(*(*2 0 ( 7.7 )

fbybyby ttvtas ++= **21

02

( 7.8 )

Die in den Gleichungen berücksichtigte Totzeit tf ist durch Messungen am Fahrzeug bestimmt worden. Hierzu wurde das Fahrzeug durch das Bremssignal abgebremst und die Zeit gemes-sen, bis eine Geschwindigkeitsreduktion von 10 % von dem Steuerautomaten identifiziert wurde. Zusätzlich wurde die Zeit gemessen, die das Fahrzeug ab Beginn der Geschwindig-keitsreduktion bis zum Stillstand benötigt. Die Ergebnisse bei Geschwindigkeiten von 0,2 m/s bis 1,4 m/s sind in Tab. 11 dargestellt.


- 53 -

Geschwindigkeit v in m/s Bremsweg sb in m Bremszeit tb in s

Totzeit tf Bremszeit

0,2 0,07 0,3 0,55 0,4 0,16 0,25 0,5 0,6 0,23 0,3 0,5 0,8 0,23 0,35 0,55 1 0,37 0,3 0,6

1,2 0,44 0,35 0,65 1,4 0,56 0,3 0,6

Tab. 11: Messergebnis von Bremszeit tb und –weg sb bei verschiedenen Geschwindigkeiten

Die Totzeit tf beträgt im Mittel 300 ms. Um zu ermitteln, wie sich diese Zeit zusammensetzt, werden die Zeiten der einzelnen Phasen, von dem Auslösesignal des Bremsassistenten bis zum Auslesen der Geschwindigkeit erfasst (vgl. Abb. 41). Diese Zeitintervalle lauten:

Δt1: Das Bremssignal ist vom Steuerautomaten eingelesen;

Δt2: Die Geschwindigkeitsvorgabe von 0 m/s ist auf den CAN-Bus geschickt;

Δt3: Der ARM7-µController hat die anliegende CAN-Nachricht eingelesen;

Δt4: Der Fahrregler hat die die Geschwindigkeitsvorgabe eingelesen;

Δt5: Das Fahrzeug hat die Geschwindigkeit um 10 % reduziert;

Δt6: Die Geschwindigkeit wird auf den CAN-Bus geschickt;

Δt7: Die Geschwindigkeit wird vom Steuerautomat erkannt.

Abb. 41: Phasen der Totzeit bei einer Notbremsung

Die Zeiten Δt4 und Δt6 sind durch das statische Timing der Tasks auf dem ARM7-µController vorgegeben. Der CAN-Task wird alle 50 ms, und der Fahrregler alle 20 ms aufgerufen. Die zeitliche Differenz Δt4 zwischen dem Aufruf des CAN-Tasks (Empfangen der Sollwerte) und dem des Reglertasks (Fahrregelung) liegt dem Scheduling (Abb. 42) bei 4 ms bzw. 14 ms.


- 54 -

10 20 30 40 50 60 70 80 90 1000

Lenkregelung(delay 8, period 10)

Fahrregelung(delay 2, period 10)

Senden der Istwerte(delay 10, period 25)

Senden der Stati(delay 20, period 25)

Empfangen der Sollwerte(delay 0, period 25)Stati auswerten(delay 5,period 25)

Abb. 42: Taskablaufplan einer Periode des zeitgesteuerten Systems auf dem ARM7-µController [14]

Bis die im Reglertask ermittelte Geschwindigkeit versendet wird vergeht laut dem Scheduling eine Zeit Δt6 von 6 ms bis 46 ms. Die Zeit Δt3, die angibt, wie lange die CAN-Nachricht in dem Receive-Puffer des ARM7-µControllers liegt, kann maximal 50 ms betragen, wenn die Nachricht direkt nach dem letzen einlesen der CAN-Nachrichten eingetroffen ist. Es bleiben die Zeiten Δt1, Δt2, und Δt7 auf dem QNX-Rechner, sowie Δt5 auf dem ARM7-µController zu ermitteln.

Zur Ermittlung der Zeiten auf dem QNX-Rechner wurden die Taktzyklen des Prozessors aus-gelesen, da die Systemzeit eine Auflösung von einer ms beträgt und eine zu geringe Auflö-sung für die Messung hat. Diese geringe Auflösung ist dadurch bedingt, dass mit ihr die Zeit-scheiben der Tasks in dem System definiert werden. Für das Auslesen der Taktzyklen des Prozessors wird die Funktion get_cycles() von dem QNX-Betriebssystem zur Verfügung ge-stellt [21]. Die interessierenden Zeitpunkte ergeben sich dann mit der Division durch die Pro-zessortaktfrequenz von 650 MHz. Gemessen wurden die Taktzyklen beim Start der folgenden Aktionen:

• Abschicken des Bremssignals,

• Einlesen des Steuerautomaten,

• Abschicken der CAN-Nachricht mit der Stillstandvorgabe

Aus der Differenz dieser Werte wurden die Zeiten Δt1 und Δt2 ermittelt. Zehn Messungen ergaben folgende Ergebnisse:

Zeitintervalle Minimale Zeit in ms

Maximale Zeit in ms

Durchschnitt in ms

Δt1: Zeit von Bremsauslösung bis zum einlesen im Steuerautomat 0,44 0, 9 0, 65

Δt2: Zeit vom einlesen des Steuerau-

tomaten der Bremsaktion bis Abschicken der CAN-Nachricht

45 61 46

Tab. 12: Gemessene Zeiten des Steuerautomaten und des CA-Systems bei Bremsauslösung

Die von dem CAN-Thread auf dem Koordinierungsrechner ausgewertete aktuelle Geschwin-digkeit lag bei den Messungen immer erst zwei Zyklen später in dem Steuerautomat vor. Dar-aus ergibt sich bei einer Abtastrate von 50 ms die Zeit Δt7 von 100 ms.

Für die Messung der Zeit Δt5 auf dem ARM7-Controller wurde zur Auswertung die CAN-Sende-Task in dem Fahrreglertask aufgerufen. Damit konnte die Information direkt auf den


- 55 -

CAN-Bus geschickt, und mit dem CANalyser ausgewertet werden. Die Geschwindigkeitsvor-gaben wurden ebenfalls mit dem CANalyser vorgegeben. In dem Empfangstask wird zur Identifizierung des Zeitpunktes, in dem die Sollgeschwindigkeit auf Null reduziert wird, ein Flag gesetzt. Dieses Flag wird zusammen mit der aktuellen Geschwindigkeit in der Fahr-reglertask per CAN-Nachricht verschickt. Durch die Auswertung der CAN-Nachrichten mit-tels des CANalysers kann die Information über die Zeit, vom Verschicken der Geschwindig-keitsänderung per CANalyser, bis zum Einlesen in der CAN-Empfangstask und die Zeit bis zur Geschwindigkeitsreduktion auf 90 % von valt ermittelt werden. Das Messergebnis von Δt5 ist in der Tab. 13 mit den erfassten Intervallzeiten dargestellt.

Zeitintervall Gemittelte Zeit Maximale Zeit Δt1 0, 65 ms 0, 9 ms Δt2 46 ms 61 ms Δt3 25 ms 50 ms Δt4 9 ms 14 ms Δt5 59,4 ms 59,4 ms Δt6 6 ms 46 ms Δt7 100 ms 100 ms

Gesamte Zeit 266,05 ms 331,3 ms Tab. 13: Gemessene Reaktionsintervalle bei einem Bremsmanöver

Die durchschnittliche und maximale Totzeit betragen damit 266 ms und 331 ms bis die Ge-schwindigkeitsreduktion von dem Steuerautomaten detektiert wurde. Da der Steuerautomat alle 50 ms aufgerufen wird, beträgt die Totzeit 300 ms bzw. 350 ms. Die separaten Messun-gen hinterlegen damit die vorangegangenen Messungen der Bremszeiten. Für die Berechnung des Bremsweges ist jedoch nur die Zeit relevant, die zwischen dem Erkennen des Bremssig-nals und der Geschwindigkeitsreduktion auf 90 % liegt. Diese aus den Intervallen Δt1 bis Δt5 bestehende Zeit beträgt maximal 185,3 ms.

7.2. Funktionstest des Bremsassistenten

Im Folgenden sind die Funktionstests und die zugehörigen Messergebnisse dargestellt, mit denen die Leistungsfähigkeit des Bremsassistenten untersucht wurde.

Für die Versuche wurde eine einfache Umgebung mit wenigen Objekten und konstanten Ge-schwindigkeiten gewählt, um spezifische Fahrsituationen zu generieren. Damit konnten die Funktionen anhand der gewonnen Messdaten separat getestet werden. Aus dem Grund der Reproduzierbarkeit wurde in den Versuchen, bei denen eine Kollision mit einem konstant bewegten Hindernis erfolgt, die Umgebung mit Hilfe eines Simulators generiert. Dieser Simu-lator erzeugt anhand vorgegebener Objektdaten zyklisch Entfernungswerte, in dem Format der Abstandswerte des Laserscanners. Damit diese ein präzises Abbild der Entfernungswerte des Laserscanners liefern, sind sie mit einem Signalrauschen überlagert. Die Berechnung der Objektkoordinaten erfolgt in einem separaten Thread, auf Basis der Gleichungen für die in-terne Aktualisierung der Objektdaten (vgl. Kap. 6.4). Die Entfernungswerte schreibt der Si-mulations-Thread in die Messagequeue MQ3, in die im normalen Betrieb der CAN-recv-Thread die empfangenen Abstandswerte des Laserscanners einträgt. Das System des Brems-assistenten bleibt hierbei von der Objekterkennung bis hin zur Bremsstatusberechnung unver-ändert. Aus diesem Grund kann die Funktionalität des Bremsassistenten auch mit den simu-lierten Entfernungswerten verifiziert werden.


- 56 -

Main

CAN-recvCA-System

LD-Recv MQ3

MQ1SIG

Simulator

Abb. 43: Ausschnitt des um den Simulations-Thread erweiterten Treadkonzeptes

Mit dem ersten Funktionstest soll das Auslösen des Bremsassistenten auf Basis des längsin-terpretierten Hindernisses nachgewiesen werden. Hierfür wurde die Berechnung der Bremsda-ten für das querinterpretierte Objekt auskommentiert. Die resultierenden Bremsdaten basieren demnach rein auf der Längsinterpretation. Dieser im Folgenden beschriebene Versuch wurde in realer Umgebung durchgeführt. In dem Test fährt das Fahrzeug frontal auf ein durch einen Karton dargestelltes nicht bewegtes Hindernis mit einer Geschwindigkeit von 0,5 m/s.

b)a)

Abb. 44: Versuchaufbau bei Kollision mit einem statischen Hindernis (a) und das Umgebungsmodell der Objekterkennung (b)

Der Karton ist in einer Entfernung von 4 m zum Fahrzeug aufgestellt, so dass ungebremst nach acht Sekunden eine Kollision erfolgt.

Die erfassten Messdaten des Funktionstests mit Aufprall und Bremsdaten, sowie der Eigenge-schwindigkeit sind in dem Diagramm in Abb. 45 dargestellt. In dem Versuch sinkt nach 5,85 s die Aufprallzeit T unter die Bremszeit tb+. Diese setzt sich aus der berechneten Bremszeit tb und der berechneten Zeit für den Sicherheitsabstand td zusammen. Nach 6 s fällt auch der Aufprallweg sx unter den Bremsweg sb+. Dieser setzt sich aus dem berechneten Bremsweg und dem Sicherheitsabstand sd, der zu dem Hindernis eingehalten werden soll, zusammen. Damit ist auch die zweite Bedingung für das Bremsmanöver erfüllt. Die Notbremsung wird eingeleitet. Nach weiteren 950 ms kommt das Fahrzeug 89 cm vor dem Karton zum Stehen. Dieser relativ hohe Abstand zu dem Objekt resultiert aus der geringen Filterabweichung bei geringer Geschwindigkeit.


- 57 -

-1

-0,5

0

0,5

1

1,5

2

2,5

3

3,5

4

4 4,5 5 5,5 6 6,5 7 7,5

Zeit in s

T < tb+

ve

Tsx

sb+

tb+

sx < sb+ ve = 0

Abb. 45: Verlauf der Aufpralldaten und Bremsdaten bei der Anfahrt auf ein stehendes Hindernis

In dem zweiten Versuch soll eine Kollision mit einem längsbewegten Fahrzeug simuliert werden. Hierbei bewegt sich das Objekt mit einer Geschwindigkeit von 0,8 m/s. und die Ei-gengeschwindigkeit liegt bei ve = 1,4 m/s. Bei Versuchsbeginn hat das simulierte Fahrzeug einen Abstand von drei Metern zum eigenen Transportsystem. Bei einer Differenzgeschwin-digkeit von vx = -0,6 m/s kommt es ohne Eingriff des Assistenzsystems nach 5 s zur Kollision. Der Verlauf der Aufprall- und Bremsdaten sind in dem Diagramm in Abb. 46 dargestellt. In dem Funktionstest sind nach 3,15 s beide Bedingungen zum Auslösen des Bremsmanövers erfüllt und die Notbremsung wird eingeleitet. Nach weiteren 0,7 s wechselt die detektierte Differenzgeschwindigkeit ihr Vorzeichen, und das erkannte Fahrzeug beginnt sich zu entfer-nen. Damit wurde mit einem minimalen Abstand zum Hindernis von ca. einem Meter die Kol-lision verhindert. Dem Diagramm in Abb. 46 ist zu entnehmen, dass die Differenzgeschwin-digkeit im Gegensatz zu der Eigengeschwindigkeit aus den gefilterten Entfernungswerten des Laserscanners bzw. des Simulators ermittelt wird. Die direkt eingelesene Eigengeschwindig-keit fällt schon nach 3,5 s unter die Geschwindigkeit des Hindernisses von 0,8 m/s. Der Null-durchgang der Differenzgeschwindigkeit liegt jedoch erst bei 3,85 s. Die Differenz von 250 ms entspricht bei einer Abtastrate von 50 ms der Gruppenlaufzeit des MA-Filters (s. Kap.6.1).

-1

-0,5

0

0,5

1

1,5

2

2,5

3

2,15 2,65 3,15 3,65 4,15 4,65

Zeit in s

T < tb+

ve

vx

Tsx

sby

tby

sx < sb+ ve = 0

Abb. 46: Verlauf der Aufprall- und Bremsdaten bei Kollision mit einem längsbewegten Objekt


- 58 -

Im folgenden Versuch soll das Hindernis rein als querbewegtes Hindernis interpretiert wer-den. Hierfür wurde die Berechnung der Bremsdaten für das länginterpretierte Objekt aus-kommentiert. Das detektierte Fahrzeug bewegt sich in dem Versuch orthogonal zu der eige-nen Fahrtrichtung, d.h. vx = 0 m/s. Das konstant bewegte Fahrzeug wurde hierbei mit dem Simulator generiert. Die Kollision mit dem Fahrzeug erfolgt bei konstanten Geschwindigkei-ten in 4 m Entfernung zur Startposition. Das querbewegte Fahrzeug bewegt sich mit einer Geschwindigkeit von vy = 0,4 m/s, auf das sich das eigene Fahrzeug mit ve = 0,5 m/s zu be-wegt.

b)a)

Abb. 47: Umgebungsmodell bei bevorstehender Kollision mit einem querbewegten Fahrzeug vor (a) und nach dem Bremseingriff (b)

In dem Versuch sinkt nach 5,9 s der Aufprallweg sx unter den Bremsweg sb+ und 2 s vor der bevorstehenden Kollision fällt die Aufprallzeit T unter die Bremszeit tb+. Damit wird nach 6 s das Bremsmanöver eingeleitet. Das Fahrzeug kommt 88 cm vor dem bewegten Hindernis zum Stehen. Dieser Abstand ist wie bei den vorangegangenen Versuchen auf die geringe Ge-schwindigkeit zurück zu führen.

-1

-0,5

0

0,5

1

1,5

2

2,5

3

3,5

4

4,5 5 5,5 6 6,5

Zeit in s

Zeit

in s

/ En

tfern

ung

in m

/ G

esch

win

digk

eit i

n m

/s

T < tb+

ve

Tsx

sb+

tb+

sx < sb+ ve = 0

Abb. 48: Verlauf der Aufprall und Bremsdaten bei der Anfahrt auf ein querbewegtes Fahrzeug


- 59 -

In dem vierten und abschließenden Versuch werden beide Interpretationen aktiviert. Es wird erneut ein querbewegtes Fahrzeug betrachtet, um nachzuweisen, dass das Bremsmanöver durch die Querinterpretation später ausgelöst wird. Das simulierte Fahrzeug bewegt sich mit einer Geschwindigkeit von vy = 0,4 m/s. Die Eigengeschwindigkeit beträgt ve = 0,5 m/s. In dem folgenden Diagramm sind die Bremsdaten beider Interpretationen sowie die Aufprallda-ten und die Eigengeschwindigkeit dargestellt.

-1

-0,5

0

0,5

1

1,5

2

2,5

3

5,35 5,55 5,75 5,95 6,15 6,35 6,55 6,75

Zeit in s

Zeit

in s

/ En

tfern

ung

in m

/ G

esch

win

digk

eit i

n m

/s

ve

Tsx

sbx+

tbx+

sby+

tby+

sx < sby+ ve = 0sx < sbx+ T < tby+

T < tbx+

Abb. 49: Verlauf der Aufprall- sowie längs und querinterpretierten Bremsdaten bei Anfahrt auf ein

querbewegtes Fahrzeug

Die Messung zeigt, dass die Bremsdaten der Querinterpretation unter den der Längsinterpreta-tion liegen. Damit wird das Bremsmanöver erst nach 6,25 s ausgelöst, wenn beide Bremsda-ten der Querinterpretation größer als die Aufpralldaten sind. In diesem Versuch hält das Fahr-zeug mit einem Abstand von 75 cm zum Hindernis, obwohl es sich um dieselbe Umgebungs-situation wie in dem vorigen Versuch handelt. Dies ist durch den im Vergleich zum vorigen Test 250 ms späteren Auslösezeitpunkt bedingt. Die Differenz der Auslösezeitpunkte liegt wiederum an den Entfernungsschwankungen der Abstandswerte des Laserscanners, bzw. des Simulators. Aus diesen Schwankungen resultieren in der Auswertung unterschiedliche Ob-jektgeschwindigkeiten mit denen der Zeitpunkt zum Auslösen des Bremsmanövers berechnet wird.


- 60 -

7.3. Auswertung

Die Funktionstests haben gezeigt, dass der entwickelte Bremsassistent bevorstehende Kollisi-onen erkennt und auch vermeidet. Die Objekterkennung liefert ein realitätsnahes Umge-bungsmodell mit geschwindigkeitsbehafteten Objekten, aus denen Informationen über Auf-prall und Bremsvorgänge gewonnen werden können. Der aus der Situationsanalyse gewonne-ne Bremsstatus signalisiert unter Berücksichtigung der Systemungenauigkeit den letztmögli-chen Zeitpunkt in dem die Kollision vermieden werden kann. In den Funktionstest hatte das Fahrzeug nach dem Eingriff des Bremsassistenten einen Abstand von 75 cm bis 90 cm zum Hindernis. Damit wurde der letztmögliche Zeitpunkt zur Kollisionsvermeidung aufgrund der Systemungenauigkeit nicht erkannt. Damit das System den Eingriffszeitpunkt genauer bestimmen und auch in einer komplexeren Fahrzeugumgebung betrieben werden kann, müs-sen an dem Assistenten Anpassungen vorgenommen werden. Im Folgenden werden Änderun-gen an der Erkennung der Fahrzeugumgebung und dem Fahrzeugmodell vorgestellt.

Die Präzision des Bremsassistenten ist im Wesentlichen definiert durch die Qualität des Um-gebungsmodells, welches dem Bremsassistenten zur Verfügung steht. Je exakter das Abbild der Umwelt, umso genauer kann der letzte Zeitpunkt ermittelt werden, in dem eine Kollision vermieden werden kann. Um dieses Abbild zu optimieren, kann zum einen eine bessere Hard-ware, d.h. ein Laserscanner mit geringerem Signalrauschen und einer höheren Scanfrequenz eingesetzt werden. Zum anderen kann die auswertende Software verbessert werden. Hierbei kann das MA-Filter durch ein Kalman-Filter ersetzt werden. Dieses in [2] realisierte Filter berechnet anhand der vorangegangenen Entfernungswerte stochastisch den Abstand für den nächsten einzuscannenden Entfernungswert [20]. Mit der Verwendung dieses Filters kann die durch das MA-Filter entstandene Abweichung vom maximal 63 cm (vgl. Kap. 6.1) auf Kosten eines höheren Rechenaufwandes reduziert werden.

Des Weiteren ist die angenommene Bremsbeschleunigung in dem System sehr ungenau, da sie entgegen der Messung als konstant definiert ist. Diese könnte durch eine geschwindig-keitsabhängige lineare Kurve ersetzt werden, um sie dem Fahrzeug anzupassen. Damit ent-spricht die angenommene Bremsbeschleunigung der realen Fahrzeugbeschleunigung und der Bremsweg sowie der Auslösezeitpunkt können genauer berechnet werden. Eine weitere Mög-lichkeit diese Abweichung bei der Berechnung des Bremsweges zu beheben wäre, auf den ARM7-µControllern einen überlagerten Beschleunigungsregler über dem Geschwindigkeits-regler zu implementieren. Damit kann in dem System eine konstante Bremsbeschleunigung definiert werden, mit der das Fahrzeug geregelt die Geschwindigkeit reduziert.

Neben der Präzision des Assistenten kann auch die Reaktionszeit optimiert werden. Wie in Kap. 7.1 beschrieben liegt zwischen dem Erkennen des Auslösesignals und der Reaktion des Fahrzeuges 185 ms. Diese Zeit kann reduziert werden, indem der Bremsassistent selber eine hochpriorisierte CAN-Nachricht an die ARM7-µController schickt, um damit die Notbrem-sung auszulösen. Damit muss das Signal nicht auf dem QNX-Rechner zwischen den Threads weitergereicht werden, und die Totzeit kann laut Tab. 13 aus Kapitel 7.2 um 62 ms reduziert werden. Zusätzlich kann durch das Umstellen des Schedulerplans der ARM7-µController die Totzeit verringert werden. Positioniert man den Aufruf der Fahrreglertasks direkt hinter den der CAN-Recv-Tasks, so kann die Totzeit hier um bis zu 13 ms reduziert werden (vgl. Abb. 42). Diese Reduktion der Totzeit von insgesamt 75 ms verkürzt bei maximaler Geschwindig-keit den Bremsweg um ca. 11 cm.

Stefan Cordes Systemerweiterungen

- 61 -

8. Systemerweiterungen

Der beschriebene Bremsassistent wurde modular entwickelt und ist damit leicht erweiterbar. Neben der kollisionsvermeidenden Reaktion einer Notbremsung kann eine Kollision mit ei-nem Hindernis auch durch eine Geschwindigkeitserhöhung, und durch Ausweichmanöver vermieden werden. Bei der Geschwindigkeitserhöhung wird zwar die Kollision vermieden, allerdings steigt das Unfallrisiko nach dem Eingriff bedingt durch die höhere Geschwindig-keit. Da das System die Sicherheit des Fahrzeuges erhöhen soll, wird auf die Geschwindig-keitserhöhung, als kollisionsvermeidende Maßnahme nicht näher eingegangen. In dem fol-genden Kapitel wird die theoretische Erweiterung des Bremsassistenten um eine Ausweichre-aktion betrachtet.

Daten-aufbereitung

Objekt-erkennung

Aufpralldaten-berechnung

Bremsstatus-berechnung

Berechnung des rechten

Ausweichstatus

Entscheider

Berechnung des linken

Ausweichstatus

Abb. 50: Modulkette des Bremsassistenten ergänzt um Module für Ausweichmanöver

Hierfür werden in Kapitel 8.1 die mathematischen Grundlagen nach [1] für die Berechnung eines Ausweichstatus dargestellt. Dieser signalisiert den letztmöglichen Zeitpunkt, in dem durch ein Ausweichmanöver die Kollision vermieden werden kann. Da mit der Integration des Ausweichmanövers mehrere Reaktionen von dem Assistenten zeitgleich aktiv werden können, müssen diese priorisiert werden. In Kapitel 8.2 ist ein Entscheidungsautomat be-schrieben, der die drei Reaktionen „Bremsen“, sowie „Linkes-„ und „Rechtes Ausweichen“ entsprechend der Bedingung priorisiert, dass der Assistent im letztmöglichen Zeitpunkt ein-greift.

8.1. Berechnung des Ausweichstatus

Die im Folgenden beschriebene Berechnung des Ausweichstatus basiert, wie bei dem Brems-status (vgl. Kap. 5), auf dem Vergleich der Kollisionsdaten mit den Daten des Ausweichma-növers. Hierbei wird die Zeit bis zur Kollision mit der benötigten Zeit für ein kollisionsver-meidendes Ausweichmanöver verglichen. Ist die Zeit des Ausweichmanövers größer der Kol-lisionszeit, so muss das Ausweichmanöver eingeleitet werden. Es gilt demnach die Zeit für das Ausweichmanöver zu berechnen.

Die Ausweichzeit hängt im Wesentlichen von der maximal möglichen Querbeschleunigung aqm und der Ausweichbreite yal ab. Die maximale Querbeschleunigung gibt an, wie stark das Fahrzeug seitwärts beschleunigt werden kann, ohne dass die Reifen die Bodenhaftung verlie-ren. Dieser fahrzeugspezifische Parameter kann im ersten Ansatz auf 3 m/s² bis 5 m/s², der maximalen Querbeschleunigung eines VW-Passats gesetzt werden [1].


- 62 -

Fahrzeug1

2

3

4

l1

Fahrzeug

Objektl2 l3

ys

syv,l

sr

yal

sal

x

y

Abb. 51: Ausweichweg konstruiert mit verketteten Parabelabschnitten als Klotoidenersatz

Die Ausweichbreite gibt an, wie weit das Fahrzeug querbewegt werden muss, um dem Hin-dernis auszuweichen. Diese Strecke setzt sich bei einem Ausweichmanöver nach links aus dem Sicherheitsabstand ys der zu dem Hindernis eingehalten werden muss, sowie der rechten Fahrzeugbegrenzung sr und dem linken Begrenzungspunkt des Objektes syvl zusammen (vgl. Abb. 51).

rsyvlal sysy ++= ( 8.1 )

Der Weg, auf dem einem Hindernis ausgewichen werden soll, wird, wie in Abb. 51 darge-stellt, durch die Aneinanderreihungen von vier Klotoiden beschrieben. Diese Kurven besitzen eine konstante Krümmungsänderung und verlaufen damit stetig. Mit ihnen lässt sich ein Ausweichweg modellieren, der keine Sprünge in der Drehgeschwindigkeit an den Übergän-gen besitzt. Damit entsteht ein ruckfreies Ausweichmanöver. Die mathematisch aufwendig zu lösende Klotoidengleichung (vgl. Kap. 11.1.3) soll durch ein Polynom dritten Grades angenä-hert werden, um den Rechenaufwand zu verringern:

62)(

3

3

2

210xcxcxccxy +++= ( 8.2 )

Hierbei entspricht die Konstante c0 der Anfangsabweichung von der Fahrzeugmitte. Die An-fangssteigung c1 entspricht dem Tangens des Drehwinkels (Gierwinkel), und c2 und c3 geben die Krümmung und die Krümmungsänderung an. Damit die vier Klotoiden aneinandergereiht werden können müssen die Position, die Steigung und die Krümmung an dem jeweiligen Ü-bergang berechnet werden. Zu Beginn des Ausweichmanövers sind alle drei Konstanten Null (vgl. Abb. 51) und es muss lediglich die Krümmungsänderung c31 bestimmt werden. Die ge-suchten Übergangsparameter lassen sich durch Einsetzen der Konstanten in ( 8.2 ) sowie de-ren erste und zweite Ableitung bestimmen.


- 63 -

6)(

31

3111l

cly =

2)('

21

3111lcly =

13111 *)('' lcly =

( 8.3 )

( 8.4 )

( 8.5 )

Für die Berechnung der Krümmungsänderungskonstanten c31 dient die Kenntnis, dass am Ende des ersten Klotoidenabschnittes die Krümmung der Ausweichkurve am größten ist (vgl. Abb. 51). Damit wird das Fahrzeug in diesem Moment mit der maximalen Querbeschleuni-gung aqm beschleunigt. Da sich das Fahrzeug an der Position l1 auf einer Kreisbahn befindet, berechnet sich die Querbeschleunigung aus der Eigengeschwindigkeit ve, sowie dem Radius r:

rva e

qm

2

= ( 8.6 )

Die Gleichung der Kreisbahn lautet:

22 xrykreis −= ( 8.7 )

Die zweite Ableitung dieser Gleichung entspricht der Krümmung der Kreisbahn, und ist dem-nach mit der Gleichung ( 8.5 ) gleichzusetzen. Es gilt:

rylcly kreis

1''*)('' 13111 === ( 8.8 )

Substituiert man nun in ( 8.6 ) so erhält man die Gleichung für die Krümmungsänderungskon-stante c31.

1231

1312

*

**

lva

c

lcva

e

qm

eqm

=<=>

=

( 8.9 )

( 8.10 )

Durch das Einsetzen von ( 8.3 ), ( 8.4 ) und ( 8.5 ) in ( 8.2 ) erhält man die Gleichung für den zweiten Klotoidenabschnitt. Da nach dem zweiten Abschnitt die Hälfte der Ausweichstrecke passiert ist, kann aus den Gleichungen der gesamte Ausweichweg sal sowie die Ausweichzeit tal berechnet werden (vgl. Kap. 11.1.2). Es gilt:

eqm

alal v

ays *

2*4=

( 8.11 )

( 8.12 )


- 64 -

02

*4 >= alqm

alal yfür

ayt

Die so berechnete Ausweichzeit wird abschließend mit der Aufprallzeit verglichen. Ist die Zeit kleiner der Kollisionszeit, so muss ein Ausweichmanöver eingeleitet werden, und der Status wird auf 1 gesetzt. Ist die Ausweichzeit größer der Aufprallzeit, so bleibt der Status auf Null.

8.2. Zustandsautomat für die Reaktionsentscheidung

Mit den zusätzlichen Reaktionen der Ausweichmanöver nach links und rechts verfügt das Assistenzsystem über drei kollisionsvermeidende Maßnahmen. Diese müssen nach der jewei-ligen Berechnung des Status priorisiert werden, damit nur die Reaktion ausgeführt wird, die im letzen Moment die Kollision vermeidet. Um dies zu erreichen, erfolgt erst eine Reaktion, wenn zwei von den drei Status aktiv sind und der dritte Status auf aktiv wechselt.

Eine Methode ist, diese Signale mit der Fuzzy-Logik zu priorisieren [3]. Hierbei werden in mehreren Fahrversuchen Messdaten erfasst, und in Kennfeldern dargestellt. Aus diesen Kenn-feldern können anschließend Regeln definiert werden die, angeben, wie sich das Fahrzeug in der jeweiligen Situation zu verhalten hat. In [3] ist die Entscheidungsfindung mit der Fuzzy-Logik erfolgreich realisiert worden. Diese Methode wird sich jedoch aufgrund der unscharfen Logik nicht in der Automobilindustrie durchsetzen [1]. Eine weitere Methode ist die durch einen Zustandsautomaten gesteuerte Priorisierung. Ein solcher Zustandsautomat ist in mehre-re interne Zustände unterteilt, denen jeweils eine Reaktion zugeordnet ist. Die Reaktionen sind in diesem Automat Zustandswechsel oder das Einleiten einer Reaktion zur Kollisions-vermeidung. Im Folgenden wird der durch das Zustandsdiagramm in Abb. 52 dargestellte Automat beschrieben.

Nach der Initialisierung des Fahrzeuges befindet sich der Automat in dem Zustand „Kein Ein-griff“, in dem kein Status aktiv ist (vgl. Abb. 52). Dieser Zustand wird verlassen, sobald eines der Module den Status auf aktiv wechselt. Die drei Status sind in dem Zustandsdiagramm mit B für den Bremsstatus, Al für den Ausweichstatus links und Ar für den Ausweichstatus rechts bezeichnet. In Abhängigkeit von dem Status geht der Automat in den Zustand „Bremsen“, „Links Ausweichen“ oder „Rechts Ausweichen“ über. Jeder dieser Zustände zeichnet sich dadurch aus, dass jeweils ein Modul aktiv ist. Das Einleiten einer Reaktion erfolgt in diesen Zuständen nicht. Wird der jeweilige Status wieder inaktiv, so geht der Automat wieder in den Startzustand. Wechselt ein zweiter Status auf aktiv, wenn sich der Automat in einem der Zu-stände befindet in dem ein Status aktiv ist, so gibt es drei mögliche Zustände die der Automat annehmen kann. In diesen Zuständen „Bremsen und Links Ausweichen“, „Links und Rechts Ausweichen“ und „Bremsen und Rechts Ausweichen“ wird ebenfalls kein Manöver eingelei-tet. Wechselt nun der jeweils letzte Status auf aktiv, so geht der Automat in den entsprechen-den Zustand, in dem die kollisionsvermeidende Maßnahme ausgeführt wird. Aus diesen Zu-ständen wechselt der Automat in den Startzustand, wenn die Eigengeschwindigkeit ve des Fahrzeuges gleich Null ist. Damit sind implizit auch die einzelnen Reaktionsstatus B, Al und Ar inaktiv, da weder ausgewichen noch gebremst werden kann.

Mit dem dargestellten Zustandsautomat können der Bremsstatus und die zusätzlich generier-ten Ausweichstatus priorisiert werden. Damit reagiert das Kollisionsvermeidungssystem wei-terhin erst im letzt möglichen Zeitpunkt, in dem die Kollision vermieden werden kann.


- 65 -

Kein Eingriff

Entry / -

Bremsen

Entry / -

Links Ausweichen

Entry / -

Rechts Ausweichen

Entry / -

Bremsen und Links Ausweichen

Entry / -

Links und Rechts Ausweichen

Entry / -

Bremsen und Rechts Ausweichen

Entry / -

Rechts Ausweichen letzer

Entry / Rechts Ausweichen

Bremsen letzer

Entry / Bremsen

Links Ausweichen letzer

Entry / Links Ausweichen

Ar =1 B =1 Al =1

2

ve = 0

2

1

1

ve = 0

Ein Modul Aktiv

Zwei Module Aktiv

Reaktion ausführen

B = 1 B = 0 Al = 1 Al = 0 Ar = 0Ar = 1

Al = 1 Ar = 1 B = 1

B = 0Ar = 0Al = 0 B = 0

B = 1

Al = 0

Al = 1

Ar = 0

Ar = 1

Ar = 0

Ar = 1

ve = 0 ve = 0

Abb. 52: Zustandsdiagramm des Entscheiders für die Auswahl der kollisionsvermeidenden Maßnahme

Stefan Cordes Zusammenfassung

- 66 -

9. Zusammenfassung

Im Rahmen dieser Masterarbeit wurde ein Bremsassistent für ein fahrerloses Transportsystem entwickelt. Der Assistent generiert auf Basis von Abstandsmesswerten eines Laserscanners ein Umgebungsmodell, anhand dessen der letztmögliche Zeitpunkt ermittelt wird, in dem eine bevorstehende Kollision vermieden werden kann. Als Reaktion greift der Assistent direkt in das Fahrverhalten des Transportsystems ein und führt eine Notbremsung mit maximaler Bremsbeschleunigung aus.

Auf dem Fahrzeug wurde für die Umgebungserkennung der Laserscanner LD-OEM von der Firma Sick integriert. Für die Kommunikation wurde der Laserscanner in das bestehende CAN-Bussystem als zusätzliche Komponente eingebunden. Sämtliche Berechnungen des As-sistenten erfolgen auf dem Koordinierungsrechner des Fahrzeuges, einem GEME-2000 Em-bedded Box PC. Die Umgebungsinformationen visualisiert eine mit dem Momentics Photon Appbuilder entwickelte grafische Oberfläche, die die Beobachtung und Kontrolle weiterer Entwicklungsschritte unterstützt.

Die in die bestehende Steuerungssoftware des Koordinierungsrechners integrierte Software des Bremsassistenten wurde in einem Modul in separaten Funktionsgruppen entwickelt. Hier-für wurde ein Threadkonzept entwickelt, welches die zusätzlichen Tasks des Bremsassisten-ten neben dem Steuerautomaten in dem Koordinierungsrechner eingliedert Die Auswertung der Entfernungswerte erfolgt in drei separaten Funktionsgruppen.

Nach der Datenaufbereitung mittels eines Moving-Average-Filters werden die Entfernungs-werte in der Objekterkennung auf geschwindigkeitsbehaftete Objekte reduziert. Die Funkti-onsgruppe erkennt aus den 181 Entfernungswerten benachbarte Distanzen mit geringer Ab-standsdifferenz, aus denen Segmente definiert werden. Die Segmentinformationen bestehen immer aus drei Begrenzungspunkten, sowie dem Schwerpunkt des Segmentes. Die Generie-rung der geschwindigkeitsbehafteten Objekte erfolgt aus den Segmenten zwei aufeinander folgender Scans. Die Geschwindigkeit wird hierbei aus der Abstandänderung pro definiertes Abtastintervall bestimmt. Um den Zuverlässigkeitsgrad der Objekterkennung zu erhöhen, werden in der Funktionsgruppe die Objekte bei einem fehlerhaften Scan intern unter Berück-sichtigung der Eigengeschwindigkeit des Fahrzeuges extrapoliert, damit sie im folgenden Scan wieder erkannt werden.

Die Berechnung des Bremsstatus und der Aufpralldaten des Objektes mit dem die nächste Kollision erfolgt wurden hierbei in zwei weiteren Funktionsgruppen implementiert. Der Bremsstatus wird durch den Vergleich von Aufprall- und Bremsdaten ermittelt. Bei der Be-rechnung der Bremsdaten werden die detektierten Objekte jeweils als längs- und querbeweg-tes Objekt interpretiert, um den geringsten Bremsweg zu bestimmen.

Nach der Umsetzung des Bremsassistenten wurde die Funktionalität in mehreren Funktions-tests verifiziert. Die Ergebnisse haben gezeigt, dass die Kollision zwar sicher, aber nicht in dem letztmöglichen Zeitpunkt vermieden wird. Aufgrund des hohen, durch die Filterabwei-chung bedingten Sicherheitsabstands kommt das Fahrzeug in den Versuchsreihen mit einem Abstand von ca. 90 cm vor dem jeweiligen Hindernis zum Stehen. In der Auswertung der Testergebnisse sind Software- und Hardwareänderungen vorgestellt, die sowohl die Umge-bungserkennung, als auch die Reaktionszeit des Assistenten optimieren sollen. Abschließend sind Ansätze zur Erweiterung des Assistenten um die Reaktion eines Ausweichmanövers vor-gestellt.

Stefan Cordes Literaturverzeichnis

- 67 -

10. Literaturverzeichnis

[1] Ameling, Christian: Steigerung der aktiven Sicherheit von Kraftfahrtzeugen durch

ein Kollisionsvermeidungssystem, Dissertation, VDI Verlag,2002

[2] Kirchner, Alexander: Sensordatenverarbeitung eines Laserscanners für autonome Fahrfunktionen von Kraftfahrzeugen, Dissertation, VDI Verlag, 2000

[3] Lages, Ulrich S.: Untersuchung zur aktiven Unfallvermeidung von Kraftfahrzeu-gen, Dissertation, VDI Verlag, 2000

[4] www.invent-online.de, 2006, Forschungsinitiative deutscher Unternehmen

[5] Meyer, Martin: Grundlagen der Informationsverarbeitung, Vieweg Verlag, 2002

[6] Oestereich, Bernd: Analyse und Design mit UML 2.1, Oldenbourg Verlag, 2006

[7] Kirchner, Alexander, Krüger, Klaus, Mildner, Frank, Schmidt, Rolf: Ein fortge-schrittenes Kollisionsvermeidungssystem, ATZ 01/2005

[8] Fuerstenberg, Kai, Schulz, Roland: Laserscanner für Fahrerassistenzsysteme, ATZ 09/2005

[9] SICK AG Germany: User Protocol Services for Operating/Configuring the LDOEM Laser Measurement System, 08/2003

[10] SICK AG Germany: Lasermesssystem LD OEM - Betriebsanleitung, 11/2003

[11] Zomotor, Adam. Fahrwerktechnik: Fahrverhalten. Vogel-Fachbuch. Reimpell, Jörnsen, Vogel Buchverlag Würzburg, 1991.

[12] Pöpsel, Josef, Claussen, Ute, Klein, Rolf-Dieter, Plate. Jürgen: Computergrafik Algorithmen und Implementierung, Springer-Verlag, 1994

[13] Etschberger, Konrad: Controller-Area-Network, 3. Auflage, HANSER Verlag, 2002

[14] Cordes, Stefan, Sellentin, Jörn, Tetzlaff, Olaf: Entwicklung, Implementierung und Funktionstests der Embedded HW-/SW-Plattformen für den FAUST Fahrbetrieb mit Remote-Steuerung, 2006

[15] Meyer, Bertrand: Objektorientierte Softwareentwicklung HANSER Verlag, 1990

[16] www.audi.de, 2006, Automobilhersteller

[17] http://www.siemensvdo.de/topics/adas/park-mate , 2006, Automobilzulieferer für Elektronik und Mechatronik

[18] Statistisches Bundesamt: Unfallgeschehen im Straßenverkehr 2005, Juli 2006

[19] Automobil-Elektronik: Milliarden für Fahrerassistenz, Februar 2003

[20] http://www.cs.unc.edu/~welch/kalman/, Tutorials, Referenzen und Forschung be-zogen auf das Kalman Filter von dem Department of Computer Science der University of North Carolina at Chapel Hill

[21] Krten, Rob: Getting started with QNX Neutrino 2, PARSE Software Devices, 2001

http://www.invent-online.de

http://www.audi.de

http://www.siemensvdo.de/topics/adas/park-mate

http://www.cs.unc.edu/~welch/kalman/

Stefan Cordes Anhang

- 68 -

11. Anhang

11.1. Gleichungen

11.1.1. Aufprallzeiten Gleichung zur Berechnung der Aufprallzeit des rechten Objektsegmentes mit der linken Fahr-zeugbegrenzung:

( ) ( ) ( )

( ) ( ) ( )

∞

<<∧>−−

−+

<<∧≤−

−−+

=

sonst

sssttfürssss

ttt

sssttfürss

ssttt

T kyvlryvkxvrxvryvkyv

lkyvkxvrxvkxv

kyvlryvkxvrxvryvkyv

ryvlrxvkxvrxv

lrxv ,,,,,,

,,,,

,,,,,,

,,,,

, *

*

( 11.1 )

Gleichung zur Berechnung der Aufprallzeit des linken Objektsegmentes mit der rechten Fahr-zeugbegrenzung:

( ) ( ) ( )

( ) ( ) ( )

∞

<<∧>−−

−+

<<∧≤−

−−+

=

sonst

sssttfürssss

ttt

sssttfürss

ssttt

T lyvrkyvlxvkxvkyvlyv

rkyvlxvkxvlxv

lyvrkyvlxvkxvkyvlyv

kyvrkxvlxvkxv

rlxv ,,,,,,

,,,,

,,,,,,

,,,,

, *

*

( 11.2 )

Gleichung zur Berechnung der Aufprallzeit des rechten Objektsegmentes mit der rechten Fahrzeugbegrenzung:

( ) ( ) ( )

( ) ( ) ( )

∞

<<∧>−−

−+

<<∧≤−

−−+

=

sonst

sssttfürssss

ttt

sssttfürss

ssttt

T kyvrryvkxvrxvryvkyv

rkyvkxvrxvkxv

kyvrryvkxvrxvryvkyv

kyvrrxvkxvrxv

rrxv ,,,,,,

,,,,

,,,,,,

,,,,

, *

*

( 11.3 )

11.1.2. Ausweichzeit und -strecke Die Gleichung des ersten Klotoidenabschnittes ergibt sich aus ( 8.3 ) und ( 8.10 ):


- 69 -

6*

*)(

31

121

llv

axy

e

qm= ( 11.4 )

Die Konstanten des zweiten Abschnittes ergeben sich aus:

3132112211121102 ),(''),('),( cclyclyclyc −===== ( 11.5 )

Also gilt:

12321

1222

21

1212

31

1202 *

,**

,2

**

,6

** lv

acl

lva

cllv

acl

lva

ce

qm

e

qm

e

qm

e

qm −==== ( 11.6 )

bzw.:

12322222

1122

21

02 *,,

2*

*,

6*

*

lva

cva

cv

lac

vla

ce

qm

e

qm

e

qm

e

qm −==== ( 11.7 )

Durch Einsetzen dieser Konstanten in ( 8.2 ):

6*

*2**

2*

*

6*

*)(

32

12

22

2221

2

21

22l

lval

va

lv

lav

laly

e

qm

e

qm

e

qm

e

qm −++= ( 11.8 )

Die Länge der ersten beiden Klotoiden ist gleich:

421alsll == ( 11.9 )

Und am Ende des zweiten Abschnittes ist der halbe Ausweichweg in y-Richtung passiert.

2)

4(2

alal ysy = ( 11.10 )

Aus ( 11.8 ) folgt mit ( 11.9 ) und ( 11.10 ):

22 )

4(

2al

e

qmal svay

= ( 11.11 )

Daraus folgt die Länge des Teilstückes


- 70 -

eqm

alal v

ays *

2*4= ( 11.12 )

11.1.3. Klotoidengleichung

dLALydL

ALx

LL

∫∫

=

=

02

2

02

2

2sin,

2cos ( 11.13 )

Wobei L die Länge und A die charakteristische Größe der Klotoide ist.

11.2. Code-Listing

11.2.1. MA-Filter in LDComm.c /* Für alle drei Entfernungswerte der CAN-Nachricht, solange nicht alle Werte eingelesen wurden */ for (h=1 ;h<=3 && i < ANZAHL_SCANWERTE;h++) { /* sichere die daten */ entf[k][i] = intData[h]; /*Ist die Differenz zwischen dem Entfernungswert aus dem letzten Scan größer als die Bypassabweichung ?*/ if (abs(entf[(k+9)%PROFILE_PRO_MITTELWERT][i] - entf[k][i]) > (2 * MAX_DELTA_S + MESSUNGENAUIGKEIT)) { /* ja, dann fülle das Array mit dem neuen Wert*/ for(j=0; j<PROFILE_PRO_MITTELWERT+1;j++) { entf[j][i] = entf[k][i]; } } else { /* sonst, Moving Average Filter - gemittelten Wert berechnen */ /* löschen des alten Wertes */ entf[GEMITTELTES_PROFIL][i] = 0; /* addieren der alten Werte */ for(j=0; j<PROFILE_PRO_MITTELWERT;j++) { entf[GEMITTELTES_PROFIL][i] += entf[j][i]; } /* Division durch die Anzahl der Werte */ entf[GEMITTELTES_PROFIL][i] = entf[GEMITTELTES_PROFIL][i] / PROFILE_PRO_MITTELWERT; } i++; }

11.2.2. Initialisierung des Laserscanners void *lddata_recv_thread(){ T_LD_Msg* canMsg; pthread_mutex_init(&scanwerte.sema,NULL); pthread_cond_init(&scanwerte.condvar,NULL); /* Initialisierung des Laserscanners*/ if(!SIMULIERE_SCANDATEN) {


- 71 -

send_DO_RESET(); send_SET_FUNCTION( SECTORNUM_0, SECTORFUNC_NO_MEASURE,

SCANBEREICH_START, 0x0000); send_SET_FUNCTION( SECTORNUM_1, SECTORFUNC_NORMAL_MEASURE,

SCANBEREICH_ENDE, 0x0000); send_SET_CONFIG_CAN(CAN_BAUDRATE_250_KBPS); send_SET_CONFIG_CLOBAL(0x0014, 0x0010); send_DO_RESET(); send_TRANS_IDLE(); send_TRANS_ROTATE(); send_TRANS_MEASURE(); send_GET_PROFILE(); recv_CAN_response(&canMsg,1); } /* zyklische Auswertung der empfangenen Abstandswerte*/ while (TRUE) { recv_CAN_response(&canMsg,1); } return NULL; } /*------------------------------------------------------------------------------ * send_SET_FUNCTION : * Diese Funktion setzt einen Scanbereich, des Laserscanners. *----------------------------------------------------------------------------*/ int send_SET_FUNCTION(short sectornum, short sectorfunc, short sectorstop, short flashflag) { T_LD_Msg* canMsg; short resp_code; short resp_sectornum; short resp_sectorfunc; short resp_sectorstop; void * p; short data[] = {REQ_SET_FUNCTION, sectornum, sectorfunc, sectorstop, flashflag}; /* Senden der Nachricht */ send_CAN_Request(data,sizeof(data)/sizeof(data[0])); /* Kontrolle des Response-Codes */ if(recv_CAN_response(&canMsg,1) == EXIT_SUCCESS){ p = canMsg->DATA+6; memcpy((void*)&resp_code,p, 2); if(resp_code == (short)RESP_SET_FUNCTION) { if(recv_CAN_response(&canMsg,0) == EXIT_SUCCESS){ p = canMsg->DATA+2; memcpy((void*)&resp_sectornum,p, 2); p = canMsg->DATA+4; memcpy((void*)&resp_sectorfunc,p, 2); p = canMsg->DATA+6; memcpy((void*)&resp_sectorstop,p, 2); if( resp_sectornum == sectornum && resp_sectorfunc == sectorfunc && resp_sectorstop == sectorstop ){ return EXIT_SUCCESS; } } } } printf("Response Error: %.2hhX%.2hhX %.2hhX%.2hhX %.2hhX%.2hhX %.2hhX%.2hhX \n", canMsg->DATA[0],canMsg->DATA[1], canMsg->DATA[2],canMsg->DATA[3], canMsg->DATA[4],canMsg->DATA[5], canMsg->DATA[6],canMsg->DATA[7] ); return EXIT_FAILURE; }

11.2.3. My_Draw.c /* Standard headers */ #include <stdio.h> #include <stdlib.h>


- 72 -

#include <unistd.h> #include <string.h> #include <Objekterkennung.h> #include <LDComm.h> #include <Fahrzeugkonstanten.h> #include <Utils.h> /* Local headers */ #include "ablibs.h" #include "abimport.h" #include "proto.h" #define METER 85 static unsigned short* werte; T_List *obj; /*------------------------------------------------------------------------------ * set_werte : * Diese Funktion setzt die Scannwerte. *----------------------------------------------------------------------------*/ void set_werte(unsigned short* scanwerte) { werte = scanwerte; } /*------------------------------------------------------------------------------ * set_objekte : * Diese Funktion setzt die Objekte. *----------------------------------------------------------------------------*/ void set_objekte(T_List *objekte) { obj = objekte; } /*------------------------------------------------------------------------------ * MyDraw : * Diese Funktion wird aufgerufen, wenn das widget neu gezeichnet werden soll. *----------------------------------------------------------------------------*/ void MyDraw( PtWidget_t *widget, PhTile_t *damage ) { static int first = 1; int i = 0; int winkel = 90; PhPoint_t p1 = { 450, 450 }; PhPoint_t p2 = { 0, 0 }; char nummer[4] = {0,0,0,0}; T_List_iterator * obj_it; Objekt *akt_objekt; obj_it = (T_List_iterator*) malloc(sizeof (T_List_iterator)); /* Aufruf der Super-Funktion */ PtSuperClassDraw( PtBasic, widget, damage ); PgSetStrokeColor( Pg_GREY ); p2.x =METER/2; p2.y =METER/2; PgDrawEllipse( &p1, &p2, Pg_DRAW_STROKE ); for(i = 0; i < 10;i++) { p2.x =p2.x + METER/2; p2.y =p2.y + METER/2; PgDrawEllipse( &p1, &p2, Pg_DRAW_STROKE ); } /* Zeichnen des Koordnatensystems */ PgSetStrokeColor( Pg_BLACK ); PgDrawILine( 0,450,900,450); PgDrawILine( 450,0,450,600); /* Fahrzeuggrenzen */ PgDrawILine( 408,367,492,367); PgDrawILine( 408,467,492,467); PgDrawILine( 408,367,408,467); PgDrawILine( 492,367,492,467); /* Beim ersten durchlauf, und wenn keine Werte vorliegen soll nicht * gezeichnet werden*/


- 73 -

if (first || werte == NULL) { first = 0; } else { /* Zeichnen der Punkte */ PgSetStrokeColor( Pg_BLACK ); for(i = 0; i< ANZAHL_SCANWERTE ; i++) { PgDrawIPixel(-((sindeg(winkel)*werte[i-1])+SCANNER_HINTERRAD_Y)/3 +450, -((cosdeg(winkel)*werte[i-1])+SCANNER_HINTERRAD_X)/3 +450); winkel--; } /* Zeichnen der Objekte */ akt_objekt = (Objekt*) list_get_first(obj,obj_it); while(akt_objekt != NULL) { /* Linkes Objektsegment */ PgSetStrokeColor( Pg_RED ); p1.x = -(akt_objekt->Links.Y)/3+450; p1.y = -(akt_objekt->Links.X)/3+450; p2.x = -(akt_objekt->Kurz.Y)/3+450; p2.y = -(akt_objekt->Kurz.X)/3+450; PgDrawLine(&p1,&p2); /* Rechtes Objektsegment */ PgSetStrokeColor( Pg_GREEN ); p1.x = -(akt_objekt->Kurz.Y)/3+450; p1.y = -(akt_objekt->Kurz.X)/3+450; p2.x = -(akt_objekt->Rechts.Y)/3+450; p2.y = -(akt_objekt->Rechts.X)/3+450; PgDrawLine(&p1,&p2); /* Geschwindigkeitsvektor */ PgSetStrokeColor( Pg_BLUE ); p1.x = -(akt_objekt->Kurz.Y)/3+450; p1.y = -(akt_objekt->Kurz.X)/3+450; p2.x = -(akt_objekt->Kurz.Y)/3+450 - (akt_objekt->v_y[10] / 3); p2.y = -(akt_objekt->Kurz.X)/3+450 - (akt_objekt->v_x[10] / 3); PgDrawLine(&p1,&p2); /* Objektnummer */ nummer[0] = (akt_objekt->ID%1000)/100+48; nummer[1] = (akt_objekt->ID%100)/10+48; nummer[2] = akt_objekt->ID%10+48; PgSetFont( "helv12b" ); PgSetTextColor( Pg_BLACK ); PgDrawText( &nummer, 3, &p1, 0 ); akt_objekt = (Objekt*) list_get_next(obj_it); } } }

11.2.4. Aufprallerkennung.c /*+++++++++++++++++++++ Importierte Header +++++++++++++++++++++++++++++++++++*/ #include <stdlib.h> #include <stdio.h> #include <limits.h> #include <math.h> #include <list.h> #include <Objekterkennung.h> #include <Fahrzeugkonstanten.h> /*+++++++++++++++++++++ Exportierte Header +++++++++++++++++++++++++++++++++++*/ #include <Aufprallerkennung.h> /*+++++++++++++++++++++ Interne Typen ++++++++++++++++++++++++++++++++++++++++*/ typedef struct { double yKoordinate; double zeit; }PunktAufprallDaten;


- 74 -

typedef struct { unsigned short ID; double yKoord; double yKoordL; double yKoordR; double zeit; }ObjektAufprallDaten; /*+++++++++++++++++++++ Interne Daten ++++++++++++++++++++++++++++++++++++++++*/ /*+++++++++++++++++++++ Interne Konstanten +++++++++++++++++++++++++++++++++++*/ /*++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ * Interne Funktionen *++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*/ /*------------------------------------------------------------------------------ * Funktionsname : get_punktData * Diese Funktion berechnet die Zeit und die y-Koordinate der Kollision des * Punktes. Wenn keine Kollision vorliegt, dann werden die Werte auf max * gesetzt. *----------------------------------------------------------------------------*/ PunktAufprallDaten *get_punktData(ObjektPunkt p, double veloX, double veloY) { /* Initialisierung der Aufpralldaten des Punktes */ PunktAufprallDaten * pktdata; pktdata = (PunktAufprallDaten*) malloc(sizeof(PunktAufprallDaten)); /* Liegt der Punkt vor dem Fahrzeug, und hat eine Geschwindigkeit * in Fahrzeugrichtung ?*/ if ((veloX < 0) && (p.X > GRENZE_VORN)) { /* Dann berechne die Aufprallzeit, * sowie die y-Koordinate der Kollision */ pktdata->zeit = (p.X - GRENZE_VORN)/fabs(veloX); pktdata->yKoordinate = (veloY * pktdata->zeit) + p.Y; } else { /* sonst, setze die Zeit auf dem maximalen Wert*/ pktdata->zeit = UINT_MAX; pktdata->yKoordinate = 0; } return pktdata; } /*------------------------------------------------------------------------------ * Funktionsname : get_objektData * Diese Funktion ermittelt die Aufpralldaten eines Objektes aus den * Informationen der 3 Objektpunkte L,K und R. Findet keine Kollision statt * ist der Rückgabewert NULL. *----------------------------------------------------------------------------*/ ObjektAufprallDaten *get_objektData(unsigned short ID, PunktAufprallDaten* links, PunktAufprallDaten* kurz, PunktAufprallDaten* rechts) { ObjektAufprallDaten * objdata; /* Aufprallzeiten der 5 Fälle */ double AufprallZeiten[5] = {UINT_MAX,UINT_MAX,UINT_MAX,UINT_MAX,UINT_MAX}; /* Aufprallkoordinaten der 5 Fälle */ double AufprallYKoord[5] = {0,0,0,0,0}; double Tmin,Tdelta,s1,s2 = 0 ; unsigned int i,I = 0; /* Speicherreservierung der Objektdaten */ objdata = (ObjektAufprallDaten*)malloc(sizeof(ObjektAufprallDaten)); /* Liegt einer der Kollisionspunkte zwischen den Fahrzeugbegrenzungen ? */ if( (GRENZE_RECHTS < links->yKoordinate) && (GRENZE_LINKS > links->yKoordinate)) { AufprallZeiten[0] = links->zeit; AufprallYKoord[0] = links->yKoordinate; } if ((GRENZE_RECHTS < kurz->yKoordinate) && (GRENZE_LINKS > kurz->yKoordinate ))


- 75 -

{ /* Ist die Aufprallzeit geringer der bisherigen Zeit */ if ( AufprallZeiten[0] > kurz->zeit ) { AufprallZeiten[0] = kurz->zeit; AufprallYKoord[0] = kurz->yKoordinate; } } if ((GRENZE_RECHTS < rechts->yKoordinate)&& (GRENZE_LINKS > rechts->yKoordinate)) { /* Ist die Aufprallzeit geringer der bisherigen Zeit */ if ( AufprallZeiten[0] > rechts->zeit ) { AufprallZeiten[0] = rechts->zeit; AufprallYKoord[0] = rechts->yKoordinate; } } /* Schneidet die linke Fahrzeugbegrenzung das linke Objektsegment ? */ if((GRENZE_LINKS > kurz->yKoordinate) && (GRENZE_LINKS < links->yKoordinate)) { Tmin = fmin(links->zeit,kurz->zeit); Tdelta = fabs(links->zeit - kurz->zeit); s1 = fabs(GRENZE_LINKS -fmin(links->yKoordinate,kurz->yKoordinate)); s2 = links->yKoordinate - kurz->yKoordinate; AufprallZeiten[1] = Tmin + Tdelta* s1/s2; AufprallYKoord[1] = GRENZE_LINKS; } /* Schneidet die rechte Fahrzeugbegrenzung das linke Objektsegment ? */ if((GRENZE_RECHTS > kurz->yKoordinate) && (GRENZE_RECHTS < links->yKoordinate)) { Tmin = fmin(links->zeit,kurz->zeit); Tdelta = fabs(links->zeit - kurz->zeit); s1 = fabs(GRENZE_RECHTS - fmin(links->yKoordinate,kurz->yKoordinate)); s2 = links->yKoordinate - kurz->yKoordinate; AufprallZeiten[2] = Tmin + Tdelta* s1/s2; AufprallYKoord[2] = GRENZE_RECHTS; } /* Schneidet die linke Fahrzeugbegrenzung das rechte Objektsegment ? */ if((GRENZE_LINKS > rechts->yKoordinate) && (GRENZE_LINKS < kurz->yKoordinate)) { Tmin = fmin(rechts->zeit,kurz->zeit); Tdelta = fabs(kurz->zeit - rechts->zeit); s1 = fabs(GRENZE_LINKS - fmin(kurz->yKoordinate,rechts->yKoordinate)); s2 = kurz->yKoordinate - rechts->yKoordinate; AufprallZeiten[3] = Tmin + Tdelta* s1/s2; AufprallYKoord[3] = GRENZE_LINKS; } /* Schneidet die rechte Fahrzeugbegrenzung das rechte Objektsegment ? */ if((GRENZE_RECHTS > rechts->yKoordinate) && (GRENZE_RECHTS < kurz->yKoordinate)) { Tmin = fmin(rechts->zeit,kurz->zeit); Tdelta = fabs(kurz->zeit - rechts->zeit); s1 = fabs(GRENZE_RECHTS - fmin(kurz->yKoordinate,rechts->yKoordinate)); s2 = kurz->yKoordinate - rechts->yKoordinate; AufprallZeiten[4] = Tmin + Tdelta* s1/s2; AufprallYKoord[4] = GRENZE_RECHTS; } /* Ermittlung der kürzesten Zeit */ for (i = 0;i < 5;i++) { if (AufprallZeiten[I] > AufprallZeiten[i]) { I = i; } } /* Wurde keine Aufprallzeit ermittelt */ if (AufprallZeiten[I] == UINT_MAX) { /* Dann setzte die Daten auf NULL */


- 76 -

objdata = NULL; } else { /*Sonst setze die berechneten Zeiten */ objdata->zeit = AufprallZeiten[I]; objdata->yKoord = AufprallYKoord[I]; objdata->yKoordL = links->yKoordinate; objdata->yKoordR = rechts->yKoordinate; objdata->ID = ID; } return objdata; } /*++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ * Externe Funktionen *++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*/ /*------------------------------------------------------------------------------ * Funktionsname : get_aufpralldaten * Diese Funktion ermittelt das Objekt mit der gerinsten Aufprallzeit und * berechnet Aufprallinformationen, wie Zeit und y-Koordinate der Kollision. *----------------------------------------------------------------------------*/ Aufpralldaten* get_aufpralldaten(T_List* objekte ) { Aufpralldaten* pdata; /*Rückgabewert -Pointer auf die Kollisionsdaten */ PunktAufprallDaten *linksData; /* Pointer auf die Aufpralldaten */ PunktAufprallDaten *kurzData; /* der Objektpunkte */ PunktAufprallDaten *rechtsData; Objekt* obj; /* Variablen für den iterativen */ T_List_iterator* obj_it; /* durchlauf der Objekte */ T_List* objektData; /* Variablen für den iterativen */ ObjektAufprallDaten* objData; /* durchlauf der */ T_List_iterator* objdata_it; /* ObjektAufpralldaten */ /******* Initialisierung ************************************************/ pdata = (Aufpralldaten*) malloc(sizeof(Aufpralldaten)); /* der Kollisionsdaten */ pdata->zeit = UINT_MAX; list_init(&objektData); /* der Aufpralldatenliste */ obj_it = (T_List_iterator*) malloc(sizeof (T_List_iterator)); /* der Iteratoren */ objdata_it = (T_List_iterator*) malloc(sizeof (T_List_iterator)); /* Berechnung der Objekt-Aufpralldaten **********************************/ obj = (Objekt*) list_get_first(objekte,obj_it); while(obj != NULL) { /* Ermittlung der Kolisionsdaten der einzelnen Punkte */ linksData = get_punktData( obj->Links, obj->v_x[MITTEL_GESCHW], obj->v_y[MITTEL_GESCHW]); kurzData = get_punktData( obj->Kurz, obj->v_x[MITTEL_GESCHW], obj->v_y[MITTEL_GESCHW]); rechtsData = get_punktData( obj->Rechts, obj->v_x[MITTEL_GESCHW], obj->v_y[MITTEL_GESCHW]); /* Ermittlung der Kollisionsdaten eines Objektes */ objData = get_objektData(obj->ID,linksData,kurzData,rechtsData); /* Findet eine Kollision mit dem Ojekt statt? */ if (objData != NULL) { /* ja, dann füge die Daten in die Liste */ list_add (objektData, objData,-1); } else { /* sonst, gebe den Speicherbereich frei */ free(objData); } /* gebe den Speicherbereich der Objektpunktdaten frei */ free(linksData); free(kurzData); free(rechtsData); /* Neues Objekt einlesen */


- 77 -

obj = (Objekt*) list_get_next(obj_it); } /* Wurde eine Kollision mit einem Objekt erkannt ? */ if(objektData->size > 0) { /* ja, dann ermittle das Objekt mit der geringsten Aufprallzeit */ objData = (ObjektAufprallDaten*) list_get_first(objektData,objdata_it); while(objData != NULL) { /*Ist die Aufprallzeit kleiner der bisherigen Aufprallzeit? */ if ((objData->zeit < pdata->zeit)) // (objData->zeit > 0) && { /* ja, dann sichere die Daten */ pdata->zeit = objData->zeit; pdata->ID = objData->ID; pdata->yKoordinate = objData->yKoord; pdata->yKoordL = objData->yKoordL; pdata->yKoordR = objData->yKoordR; } /* Einlesen des neuen Objektes */ objData = (ObjektAufprallDaten*) list_get_next(objdata_it); } /* Ermittlung der zugehörigen Objektdaten */ obj = (Objekt*) list_get_first(objekte,obj_it); while(obj != NULL) { if (obj->ID == pdata->ID) { pdata->veloX = obj->v_x[MITTEL_GESCHW]; pdata->veloY = obj->v_y[MITTEL_GESCHW]; } obj = (Objekt*) list_get_next(obj_it); } } else { pdata = NULL; } /* Freigabe des Speichers der Iteratoren und der Objektliste */ free(objektData); free(obj_it); free(objdata_it); return pdata; }

11.2.5. Bremsermittlung.c /*+++++++++++++++++++++ Importierte Header +++++++++++++++++++++++++++++++++++*/ #include <globals.h> #include <stdlib.h> #include <limits.h> #include <math.h> #include <automat.h> #include <Fahrzeugkonstanten.h> #include <Objekterkennung.h> #include <Aufprallerkennung.h> /*+++++++++++++++++++++ Exportierte Header +++++++++++++++++++++++++++++++++++*/ #include <Bremsermittlung.h> /*+++++++++++++++++++++ Interne Daten ++++++++++++++++++++++++++++++++++++++++*/ typedef struct { double weg; double zeit; }Bremsdaten; /*+++++++++++++++++++++ Interne Konstanten +++++++++++++++++++++++++++++++++++*/ /*++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ * Interne Funktionen *++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*/ /*------------------------------------------------------------------------------ * Funktionsname : interpretLaengs * Diese Funktion berechnet die Bremszeit, sowie den Bremsweg anhand der


- 78 -

* Differenzgeschwindigkeit in Längsrichtung. *----------------------------------------------------------------------------*/ Bremsdaten* interpretLaengs(double ve,double vx ) { Bremsdaten *brLaengs; brLaengs = (Bremsdaten*)malloc(sizeof(Bremsdaten)); brLaengs->weg = -TOTZEIT*vx + (vx/BREMSBESCHLEUNIGUNG)*(vx/2 + ve); brLaengs->zeit = TOTZEIT + vx/BREMSBESCHLEUNIGUNG; return brLaengs; } /*------------------------------------------------------------------------------ * Funktionsname : interpretQuer * Diese Funktion berechnet die Bremszeit, sowie den Bremsweg unter * Berücksichtigung der Querbewegung des Objektes. *----------------------------------------------------------------------------*/ Bremsdaten* interpretQuer(double ve,Aufpralldaten *aufprallDaten ) { Bremsdaten *brQuer; double Tdelta=0; double s_gl,s_gr =0; brQuer = (Bremsdaten*)malloc(sizeof(Bremsdaten)); if (aufprallDaten->veloY != 0) { /* Berechnung des zu gewinnenden Weges */ s_gl = GRENZE_LINKS - aufprallDaten->yKoordR; /* nach links */ s_gr = GRENZE_RECHTS - aufprallDaten->yKoordL; /* nach rechts */ Tdelta = max( s_gl/aufprallDaten->veloY, s_gr/aufprallDaten->veloY); brQuer->zeit = sqrt((2*(-(aufprallDaten->zeit*aufprallDaten->veloX)- ve*(aufprallDaten->zeit + Tdelta + TOTZEIT))) /BREMSBESCHLEUNIGUNG) - Tdelta; brQuer->weg = BREMSBESCHLEUNIGUNG/2 * pow(brQuer->zeit,2) + ve*brQuer->zeit + ve*TOTZEIT; /* wenn der Wert kleiner Null, dann gilt die Bedingung: * dt = Taufprall + Tdelta -tbq * nicht mehr.*/ if (brQuer->zeit < 0) { brQuer->zeit = INT_MAX; brQuer->weg = INT_MAX; } } else { brQuer->zeit = 0; brQuer->weg = 0; } return brQuer; } /*------------------------------------------------------------------------------ * Funktionsname : get_bremsdaten * Diese Funktion berechnet die Bremszeit, sowie den Bremsweg zu dem * Kollisiondobjekt *----------------------------------------------------------------------------*/ Bremsdaten* get_bremsdaten(Aufpralldaten *aufprallDaten) { Bremsdaten* brData; Bremsdaten* brTemp; brData = (Bremsdaten*)malloc(sizeof(Bremsdaten)); brData = interpretLaengs(eigenbewegung.ve, aufprallDaten->veloX); brTemp = interpretQuer(eigenbewegung.ve, aufprallDaten); if (brTemp->weg < brData->weg) { brData = brTemp; free(brTemp); } else


- 79 -

{ free(brTemp); } return brData; } /*++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ * Externe Funktionen *++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*/ /*------------------------------------------------------------------------------ * Funktionsname : get_bremsstatus * Diese Funktion ermittelt den Bremsstatus, anhand der Aufpralldaten. * Ist der Status TRUE, so ist der letzte Zeitpunkt erreicht, in dem die * Kollision durch eine Vollbremsung vermieden werden kann. *----------------------------------------------------------------------------*/ unsigned char get_bremsstatus(Aufpralldaten *aufprallDaten) { Bremsdaten* bremsDaten; unsigned char Status = FALSE; /* Tritt eine Kollision auf, und das eigene Fahrzeug ist in Bewegung */ if((aufprallDaten != NULL) && (eigenbewegung.ve != 0)) { /* dann, berechne die Bremsdaten */ bremsDaten = get_bremsdaten(aufprallDaten); /* Ist der Bremsweg, und die -Zeit größer der Aufprallzeit bzw. des Weges ?*/ if ((bremsDaten->weg >=

-(aufprallDaten->zeit*aufprallDaten->veloX)-SICHERHEITS_ABSTAND) &&

(bremsDaten->zeit >= (aufprallDaten->zeit-(SICHERHEITS_ABSTAND/(-aufprallDaten->veloX)))))

{ /* Dann setze den Status auf TRUE */ Status = TRUE; } else { /* Sonst ist der Status FALSE */ Status = FALSE; } } return Status; }

11.2.6. Segmentgenerierung /*------------------------------------------------------------------------------ * segmente_generieren : * Diese Funktion generiert aus den übergebenen Scandaten Segmente. *----------------------------------------------------------------------------*/ T_List* segmente_generieren(unsigned short scanwerte[]) { short i = 0; short uebersprungen = 0; short winkel = START_WINKEL; T_List *segmente; Segment *akt_segment; unsigned char first = TRUE; double Xneu,Yneu; T_List_iterator * seg_it; seg_it = (T_List_iterator*) malloc(sizeof (T_List_iterator)); list_init(&segmente); akt_segment = (Segment*)malloc(sizeof(Segment)); for(i=0;i<ANZAHL_SCANWERTE;i++) { /*Scanwerte gleich Null werden übersprungen -> messfehler */ while (scanwerte[i] == 0 && i < ANZAHL_SCANWERTE) { uebersprungen++; winkel--; i++; } /*ist es erster scanwert?*/


- 80 -

if(first) { /*ja, dann setze alle segmentwerte auf ersten Abstandswert*/ akt_segment->Links.abstand = scanwerte[i]; akt_segment->Links.winkel = winkel; akt_segment->Kurz.abstand = scanwerte[i]; akt_segment->Kurz.winkel = winkel; akt_segment->Rechts.abstand = scanwerte[i]; akt_segment->Rechts.winkel = winkel--; first = FALSE; uebersprungen = 0; } else { /* ist die Differenz zwischen rechtem Abstandswert und neuem * Scanwert kleiner als definierter Schwellwert?*/ if( abs(akt_segment->Rechts.abstand - scanwerte[i]) < SEGMENT_SCHWELLWERT ) { /* ist Abstandswert kleiner als gespeicherter kürzester?*/ if(akt_segment->Kurz.abstand > scanwerte[i]) { /*ja, dann setze kürzesten neu und rechtesten neu*/ akt_segment->Kurz.abstand = scanwerte[i]; akt_segment->Kurz.winkel = winkel; akt_segment->Rechts.abstand = scanwerte[i]; akt_segment->Rechts.winkel = winkel--; } else { /*nein, dann setzte rechten neu */ akt_segment->Rechts.abstand = scanwerte[i]; akt_segment->Rechts.winkel = winkel--; } /*handelt es sich um den letzten scanwert?*/ if (i == ANZAHL_SCANWERTE-1) { /*ja, dann segment der segmentliste hinzufügen*/ segment_hinzufuegen(segmente,akt_segment); } } else { /* Zurücksetzen des Rechten Punktes */ /* Besteht das segment aus mehr als einem Punkt? */ if((akt_segment->Links.winkel - akt_segment->Rechts.winkel + uebersprungen) > 1) { /* Ist der rechteste auch der kürzeste Punkt */ if(akt_segment->Kurz.winkel == akt_segment->Rechts.winkel) { /* Schiebe den Kürzesten zurück */ akt_segment->Kurz.winkel = winkel + 2 + uebersprungen; akt_segment->Kurz.abstand = scanwerte[i-2-uebersprungen]; } /* Schiebe den Rechtesten zurück */ akt_segment->Rechts.winkel = winkel + 2 + uebersprungen; akt_segment->Rechts.abstand = scanwerte[i-2-uebersprungen]; } /*aktuelles segment der segmentliste hinzufügen*/ segment_hinzufuegen(segmente,akt_segment); /*neues segment anlegen*/ akt_segment = (Segment*)malloc(sizeof(Segment)); /* Da der erste übersprungen werden soll weiter zählen */ if(i < ANZAHL_SCANWERTE) { i++; winkel--; } /*dann setze alle segmentwerte auf ersten Abstandswert*/ akt_segment->Links.abstand = scanwerte[i]; akt_segment->Links.winkel = winkel; akt_segment->Kurz.abstand = scanwerte[i]; akt_segment->Kurz.winkel = winkel; akt_segment->Rechts.abstand = scanwerte[i]; akt_segment->Rechts.winkel = winkel--;


- 81 -

uebersprungen = 0; /*handelt es sich um den letzten scanwert?*/ if (i == ANZAHL_SCANWERTE-1) { /*ja, dann aktuelles segment der segmentliste hinzufügen*/ segment_hinzufuegen(segmente,akt_segment); } } } } /* Bestimmung des Schwerpunktes */ akt_segment = (Segment*) list_get_first(segmente,seg_it); while(akt_segment != NULL) { akt_segment->Schwerpunkt.abstand = 0; for (i = abs(akt_segment->Links.winkel-90); i <= abs(akt_segment->Rechts.winkel-90); i++) { akt_segment->Schwerpunkt.abstand += scanwerte[i]; } akt_segment->Schwerpunkt.abstand = akt_segment->Schwerpunkt.abstand / (akt_segment->Links.winkel - akt_segment->Rechts.winkel); akt_segment->Schwerpunkt.winkel = ( akt_segment->Links.winkel + akt_segment->Rechts.winkel) /2; akt_segment = (Segment*) list_get_next(seg_it); } /* Verschieben des Koordinatenursprunges auf die Hinterachse */ akt_segment = (Segment*) list_get_first(segmente,seg_it); while(akt_segment != NULL) { /* Translation des linken Punktes */ /* Berechnung der neuen X-Koordinate */ Xneu = akt_segment->Links.abstand * cosdeg(akt_segment->Links.winkel) + SCANNER_HINTERRAD_X; /* Berechnung der neuen Y-Koordinate */ Yneu = akt_segment->Links.abstand * sindeg(akt_segment->Links.winkel) + SCANNER_HINTERRAD_Y; /* Berechnung des neuen Betrags */ akt_segment->Links.abstand = sqrt(pow(Xneu,2)+pow(Yneu,2)); /* Berechnung des neuen Winkels */ /* da nur der Bereich vor den Fahrzeug eingesehen wird kann der neue * X-Wert nicht 0 werden, und damit die division durch 0 nicht auftreten.*/ akt_segment->Links.winkel = atandeg(Yneu,Xneu); /* Translation des kürzesten Punktes */ Xneu = akt_segment->Kurz.abstand * cosdeg(akt_segment->Kurz.winkel) + SCANNER_HINTERRAD_X; Yneu = akt_segment->Kurz.abstand * sindeg(akt_segment->Kurz.winkel) + SCANNER_HINTERRAD_Y; akt_segment->Kurz.abstand = sqrt(pow(Xneu,2)+pow(Yneu,2)); akt_segment->Kurz.winkel = atandeg(Yneu,Xneu); /* Translation des rechten Punktes */ Xneu = akt_segment->Rechts.abstand * cosdeg(akt_segment->Rechts.winkel) + SCANNER_HINTERRAD_X; Yneu = akt_segment->Rechts.abstand * sindeg(akt_segment->Rechts.winkel) + SCANNER_HINTERRAD_Y; akt_segment->Rechts.abstand = sqrt(pow(Xneu,2)+pow(Yneu,2)); akt_segment->Rechts.winkel = atandeg(Yneu,Xneu); /* Translation des Schwerpunktes */ Xneu = akt_segment->Schwerpunkt.abstand * cosdeg(akt_segment->Schwerpunkt.winkel) + SCANNER_HINTERRAD_X; Yneu = akt_segment->Schwerpunkt.abstand * sindeg(akt_segment->Schwerpunkt.winkel) + SCANNER_HINTERRAD_Y; akt_segment->Schwerpunkt.abstand = sqrt(pow(Xneu,2)+pow(Yneu,2)); akt_segment->Schwerpunkt.winkel = atandeg(Yneu,Xneu); akt_segment = (Segment*) list_get_next(seg_it); } free(seg_it); return segmente; }


- 82 -

11.3. CD

• Ausarbeitung

o Masterarbeit • SW-Projekt

o Kompletter Code des Softwareprojektes • Dokumente

o SICK User Protocol Services o SICK Betriebsanleitung LD-OEM o Unfallgeschehen im Straßenverkehr 2005 o Zeitungsartikel aus Fachzeitschriften

Stefan Cordes Abbildungsverzeichnis

- 83 -

12. Abbildungsverzeichnis

Abb. 1: Entwicklung der Verkehrsleistung und Unfallzahlen in der Bundesrepublik Deutschland [18]....................................................................... 2 Abb. 2: Struktureller Aufbau des FAUST-Projektes ................................................................. 3 Abb. 3: Zeitlicher Ablauf eines Bremsvorganges nach [11]...................................................... 5 Abb. 4: Drei-Ebenen-Struktur eines Assistenzsystems nach INVENT ..................................... 6 Abb. 5: Aktivitätsdiagramm des Bremsassistenten.................................................................... 7 Abb. 6: Modulare Softwarestruktur des Bremsassistenten ...................................................... 10 Abb. 7: FAUST-Fahrzeugaufbau ............................................................................................. 11 Abb. 8: Das FAUST-Fahrzeug mit installiertem Laserscanner ............................................... 12 Abb. 9: Zwei benachbarte Entfernungswerte dargestellt als gleichschenkliges Dreieck bei einer Winkelauflösung von α ................................................................................ 14 Abb. 10: Aufbau der ersten beiden CAN-Nachrichten einer Profilnachricht des Laserscanners ( vgl. [9] ) .................................................................................... 15 Abb. 11: Aufbau der CAN-Nachrichten des Response auf ein GET-PROFILE Request ( vgl. [9] ) .......................................................................... 16 Abb. 12: Sequenzdiagramm der Initialisierung des Laserscanners.......................................... 17 Abb. 13: Thread-Architektur des Koordinierungsrechners mit integriertem CA-System ....... 18 Abb. 14: Zeitlicher Ablauf der Threads auf dem Koordinierungsrechner ............................... 19 Abb. 15: Visualisierung des Umgebungsmodells auf dem Koordinierungsrechner ................ 20 Abb. 16: Nassi-Schneiderman-Diagramm des Moduls zur Aufprallermittlung ...................... 21 Abb. 17: Blockschaltbild in der get_aufpralldaten-Funktion bei zwei erkannten Objekten ... 22 Abb. 18: Objektdarstellung im Fahrzeugbezogenen Koordinatensystem................................ 23 Abb. 19: Blockschaltbild der Funktion get_punktData()......................................................... 24 Abb. 20: Anordnungen der Kollisionspunkte eines Objektes mit der Fahrzeugfront.............. 24 Abb. 21: Kollision mit dem linken Objektsegment mit tyv,l < tyv,k............................................ 25 Abb. 22: Blockschaltbild der getBremsdaten-Funktion........................................................... 27 Abb. 23: Kollision mit einem längsbewegten Objekt .............................................................. 28 Abb. 24: v-t-Diagramm der Fahrzeuggeschwindigkeiten bei Notbremsung .......................... 29 Abb. 25: Blockschaltbild der interpretLaengs-Funktion ......................................................... 30 Abb. 26: Kollision mit einem querbewegten Hindernis a) und die Vermeidung durch Geschwindigkeitsreduktion b)..................................... 30 Abb. 27: Zeitverlauf für Geschwindigkeit (oben) und Weg (unten) während eines Bremsmanövers für ein querbewegtes Hindernis......... 31 Abb. 28: Blockschaltbild der interpretQuer-Funktion ............................................................ 33 Abb. 29: Normalverteilung der Messabweichung des Laserscanners LD OEM ..................... 35 Abb. 30: Amplitudengang des FIR- und MA-Filters (a) und der Vergleich des Eingangssignals mit den Ausgangswerten beider Filter (b)......... 36 Abb. 31: Sprung- (a) und Impulsantwort (b) der Filter mit N = 9 , T = 50 ms ........................ 37 Abb. 32: Rampenantwort für sich entfernende Fahrzeuge a) und aufeinander zufahrende Fahrzeuge b) ....................................................................... 38 Abb. 33: MA-Filter mit integrierter Bypass-Funktion ............................................................. 39 Abb. 34: Darstellung der Umgebung durch Entfernungswerte und der interpretierten Segmente ..................................................................................... 40 Abb. 35: Aktivitätsdiagramm der Segmentgenerierung........................................................... 41 Abb. 36: Gültigkeitsbereich des dichtesten Segmentpunkte bei dem nächsten Abtastzyklus (a) und die geometrische Darstellung (b) ............................................ 43 Abb. 37: Sequenzdiagramm der Objektgenerierung ................................................................ 45

Stefan Cordes Abbildungsverzeichnis

- 84 -

Abb. 38: Kreisbahn eines frontgelenkten Einspurfahrzeuges .................................................. 47 Abb. 39: Aktualisierung des Objektpunktes P aufgrund der Fahrzeugbewegung ................... 49 Abb. 40: Systemrelevante Fahrzeugabmessungen ................................................................... 50 Abb. 41: Phasen der Totzeit bei einer Notbremsung ............................................................... 53 Abb. 42: Taskablaufplan einer Periode des zeitgesteuerten Systems auf dem ARM7-µController [14] .............................................................................. 54 Abb. 43: Ausschnitt des um den Simulations-Thread erweiterten Treadkonzeptes ............... 56 Abb. 44: Versuchaufbau bei Kollision mit einem statischen Hindernis (a) und das Umgebungsmodell der Objekterkennung (b)...................................................... 56 Abb. 45: Verlauf der Aufpralldaten und Bremsdaten bei der Anfahrt auf ein stehendes Hindernis....................................................................................... 57 Abb. 46: Verlauf der Aufprall- und Bremsdaten bei Kollision mit einem längsbewegten Objekt .............................................................................. 57 Abb. 47: Umgebungsmodell bei bevorstehender Kollision mit einem querbewegten Fahrzeug vor (a) und nach dem Bremseingriff (b) ........... 58 Abb. 48: Verlauf der Aufprall und Bremsdaten bei der Anfahrt auf ein querbewegtes Fahrzeug ................................................................................. 58 Abb. 49: Verlauf der Aufprall- sowie längs und querinterpretierten Bremsdaten bei Anfahrt auf ein querbewegtes Fahrzeug.............................................................. 59 Abb. 50: Modulkette des Bremsassistenten ergänzt um Module für Ausweichmanöver ........ 61 Abb. 51: Ausweichweg konstruiert mit verketteten Parabelabschnitten als Klotoidenersatz.. 62 Abb. 52: Zustandsdiagramm des Entscheiders für die Auswahl der kollisionsvermeidenden Maßnahme......................................... 65

Stefan Cordes Tabellenverzeichnis

- 85 -

13. Tabellenverzeichnis

Tab. 1: Auf den Bremsassistenten bezogene Begriffdefinitionen.............................................. 7 Tab. 2: Bedeutung der Zustände des zyklisch ermittelten Bremsstatus ..................................... 8 Tab. 3: Entfernungsdifferenz bei maximaler Geschwindigkeit vmax und einer Abtastfrequenz f von 5 Hz und 20 Hz ................................................................. 13 Tab. 4: Abstand a zwischen zwei Entfernungswerten in Abhängigkeit von der Entfernung b und der Winkelauflösung α ....................................................... 14 Tab. 5: Parametrisierungsgrößen des Laserscanners................................................................ 14 Tab. 6: Datenmengen der Nutzdaten und des Overheads von CAN- und Laserscannerprotokoll ......................................................................... 15 Tab. 7: Bezeichnung der Variablen der Schnittzeiten und -punkte sowie der Aufprallzeiten der Kollisionsfälle .......................................................................... 25 Tab. 8: Entfernungsabweichung der Laserscannerdaten bei verschiedenen konstanten Abständen und Geschwindigkeiten................................... 35 Tab. 9: Berechnete Aktualisierungsparameter bei v = 1,4 m/s, α = 45° und l = 0,8 m ............ 49 Tab. 10: Bremsbeschleunigung a bei Geschwindigkeiten von 0,2 m/s bis 1,4 m/s ................. 51 Tab. 11: Messergebnis von Bremszeit tb und –weg sb bei verschiedenen Geschwindigkeiten 53 Tab. 12: Gemessene Zeiten des Steuerautomaten und des CA-Systems bei Bremsauslösung 54 Tab. 13: Gemessene Reaktionsintervalle bei einem Bremsmanöver ....................................... 55

Stefan Cordes Symbolverzeichnis

- 86 -

14. Symbolverzeichnis

a Bremsbeschleunigung aqm Maximale Querbeschleunigung f Frequenz FIR Finite Impulse Response K Objektpunkt mit dem geringsten radialen Abstand Kalt Dichtester Objektpunkt aus dem vorangegangenen Scan L Linker Begrenzungspunkt des Objektes l Radstand l1 Übergang vom erstem zum zweiten Klotoidenabschnitt l2 Übergang vom zweiten zum dritten Klotoidenabschnitt l3 Übergang vom dritten zum vierten Klotoidenabschnitt Lalt Linker Objektpunkt aus dem vorangegangenen Scan N Filterordnung Px X-Koordinate des Punktes P Px’ X-Koordinate des Punktes P im nächsten Scan Py Y-Koordinate des Punktes P Py’ Y-Koordinate des Punktes P im nächsten Scan R Rechter Begrenzungspunkt des Objektes r Betrag des Vektors dichtesten Objektpunkt Ralt Rechter Objektpunkt aus dem vorangegangenen Scan ralt Betrag des Vektors zum dichtesten Objektpunkt im alten Koordinatensystem

rK Betrag des Vektors zum dichtesten Objektpunkt des vorangegangenen Scans

rK,neu Betrag des Vektors zum dichtesten Objektpunkt des vorangegangenen Scans im neuen Koordinatensystem

rL Betrag des Vektors zum linken Objektpunkt

rR Betrag des Vektors zum rechten Objektpunkt

rr Radius der Kreisbahn des Hinterrades rv Radius der Kreisbahn des Vorderrades s0 Weg bis zum aktivieren des Bremsmanövers sal Strecke des Ausweichmanövers sb Bremsweg sb1 Bremsweg des eigenen Fahrzeugs sb2 Bremsweg des detektierten Objektes sbx Bremsweg bei längsinterpretiertem Hindernis sby Bremsweg bei querinterpretiertem Hindernis


- 87 -

sh Hintere Fahrzeugbegrenzung sl Linke Fahrzeugbegrenzung sm Betrag des Bewegungsvektors sr Rechte Fahrzeugbegrenzung sschwelle Schwellwert für die Segmenterkennung sv Vordere Fahrzeugbegrenzung sx Weg bis zum Objekt sx0 Aktueller Abstand zum Objektpunkt sy Y-Koordinate der Kollision mit einem Objekt sy,k Y-Koordinate der Kollision mit dem dichtesten Objektpunkt sy,l Y-Koordinate der Kollision mit dem linken Objektpunkt sy,r Y-Koordinate der Kollision mit dem rechten Objektpunkt sy0 Aktuelle y-Position des Objektpunktes syv Y-Koordinate der Kollision mit einem Punkt T Aufprallzeit tal Zeit des Ausweichmanövers tb Bremszeit tbq Zeitpunkt an dem das Bremsmanöver eingeleitet wird tbx Bremszeit bei längsinterpretiertem Objekt tby Bremszeit bei querinterpretiertem Objekt tf Totzeit Tg Gruppenlaufzeit Tx X-Wert des Translationsvektors txv Kollisionszeit mit einem Punkt txv,k Kollisionszeit des dichtesten Objektpunktes mit der Fahrzeugfront txv,l Kollisionszeit des linken Objektpunktes mit der Fahrzeugfront Txv,ll Kollisionszeit des linken Objektsegmentes mit der linken Fahrzeugbegrenzung Txv,lr Kollisionszeit des linken Objektsegmentes mit der rechten Fahrzeugbegren-

zung txv,r Kollisionszeit des rechten Objektpunktes mit der Fahrzeugfront Txv,rl Kollisionszeit des rechten Objektsegmentes mit der linken Fahrzeugbegren-

zung Txv,rr Kollisionszeit des rechten Objektsegmentes mit der rechten Fahrzeugbegren-

zung Ty Y-Wert des Translationsvektors umax Maximale Abstandänderung pro Intervall un Aktueller Abstandswert v0 Aktuelle Geschwindigkeit


- 88 -

v02 Objektgeschwindigkeit ve Eigengeschwindigkeit vsoll Sollgeschwindigkeit vx Differenzgeschwindigkeit in x-Richtung vx,red Reduzierte Differenzgeschwindigkeit vx0 Aktuelle Differenzgeschwindigkeit in x-Richtung vy Differenzgeschwindigkeit in y-Richtung vy0 Aktuelle Differenzgeschwindigkeit in y-Richtung yal Ausweichbreite yn Aktueller Ausgangswert des Filters

ys Sicherheitsabstand α Lenkwinkel αalt Winkel des dichtesten Punktes K im alten Koordinatensystem αL Winkel des linken Objektpunktes αR Winkel des rechten Objektpunktes γ Winkel des Bewegungsvektors Δs Maximale Messabweichung Δs1 Y-Abstand zwischen Kollisionspunkt und Objektpunkt k Δs2 Y-Abstand zwischen den Begrenzungspunkten des Objektsegmentes Δsmax Maximaler Betrag der Fahrzeugbewegung

Δt1 Zeit, bis das Bremssignal von dem Steuerautomaten eingelesen wurde; Δt2 Zeit, bis die Sollgeschwindigkeit von 0 m/s auf den CAN-Bus geschickt wird

Δt3 Zeit, bis der ARM7-µController eine anliegende CAN-Nachricht einließt

Δt4 Zeit, bis der Fahrregler die Geschwindigkeitsvorgabe einliest

Δt5 Zeit , bis das Fahrzeug die Geschwindigkeit um 10 % reduziert hat Δt6 Zeit, bis die Geschwindigkeit auf den CAN-Bus geschickt wird

Δt7 Zeit, bis die Geschwindigkeit von Steuerautomat erkannt wird

Δtg Zu gewinnende Zeitdifferenz bei querinterpretiertem Hindernis Δσmax Maximale Winkelabweichung ρ Rotationswinkel σ Standardabweichung φ Rotation des Koordinatensystems ω0 Rotationsgeschwindigkeit

Stefan Cordes Versicherung über die Selbständigkeit

- 89 -

Hiermit versichere ich, dass ich die vorliegende Arbeit im Sinne der Prüfungsordnung nach §22(4) ohne fremde Hilfe selbständig verfasst und nur die angegebenen Hilfsmittel benutzt habe. Hamburg, 02. Oktober 2006 Stefan Cordes

Documents

Masterarbeit - HAW Startseite: HAW Hamburg · Zustandsautomat für die ... Dieses beinhaltet die funktionalen Anforderungen sowie eine nach Kriterien für eine modulare Software entwickelte