scispace - formally typeset

Proceedings ArticleDOI

A hardware and software framework for cognitive automobiles

04 Jun 2008-pp 1080-1085

TL;DR: The hardware and software framework of AnnieWAY, an autonomous vehicle successfully competing at all qualification stages up to the finals of the DARPA Urban Challenge 2007 competition, proves to be flexible, expandable, and robust at the same time.

AbstractThis paper describes the hardware and software framework of AnnieWAY, an autonomous vehicle successfully competing at all qualification stages up to the finals of the DARPA Urban Challenge 2007 competition. Besides the hardware premises for by-wire steering, braking, throttle control and sensors, two frameworks for high-level decision making and low-level control are described in detail. Furthermore, this contribution points out AnnieWAYpsilas safety features for both unmanned competition runs and manned testing. The system proves to be flexible, expandable, and robust at the same time.

Topics: Software framework (58%)

Summary (4 min read)

Introduction

  • For the latter, an experimental vehicle based on a VW Passat platform has been equipped with actuators, computers, microcontrollers and sensors (see also [4], [5]).
  • This paper gives a detailed description of the hardware and software framework that the different algorithms [6] for the competition were integrated into.
  • II, the system architecture is presented in Sec. III which the interaction of the hardware and software components is based on.
  • Sec. VI concludes this contribution with a description of the realized safety features.

II. HARDWARE COMPONENTS

  • For the sake of reliability and time constraints a Volkswagen Passat Variant 2.0 FSI was chosen to be directly equipped with by-wire steering, braking, and throttle control by the manufacturer (Fig. 1).
  • This includes amongst others the installation of an electric steering motor a new prototype power brake unit an accelerator value simulator a larger alternator a LIN interface (e. g. turning lights).
  • All components are unobtrusively integrated into the car interior lining and communicated with through a CAN gateway which provides additional information available on the series CAN-BUS.
  • The manufacturer’s safety system also allows for a quick and safe changeover from automatic to manual control and vice-versa.
  • Since pulling into and backing out of a parking spot as well as K-turns are required in the competition, an additional longitudinal actuator was integrated into the selector lever case of the automatic transmission in order to engage drive, rear, and neutral gear.

B. Computing system hardware

  • The on-board computing system hosts all software for perception and decision making.
  • All opteron processors are interconnected by HyperTransport (HT) at a speed of 3.2 GByte/s each.
  • Due to the employed high-efficent (HE) CPUs, the system requires about 350W in total from the DC/DC power supply.
  • For the unlikely case of a disk failure, another protection feature comes into effect:.

C. Real-time microcontroller and distribution box

  • Since high level decision making runs at soft real time at best, a hard real time capable rapid prototyping environment, namely dSpace’s Autobox, is used for the vehicle’s lateral and longitudinal control.
  • The Autobox’ digital I/Os are connected to the distribution box, which converts the TTL level into 12V via relay and provides enough space for reliable connectors.

D. DGPS/INS and wheel speed sensor

  • The RT3003 Inertial and GPS Navigation System (IMU) is a six-axis inertial navigation strap down system that incorporates an L1/L2 RTK GPS receiver for position and a second GPS receiver for accurate heading measurements.
  • Additional wheel speed input taken directly from the Passat’s series wheel speed sensor in combination with the OmniSTAR correction signal, the system delivers better than 0.02m positioning and 0.1◦ heading under dynamic conditions.
  • The Velodyne HDL-64E comprises 64 lasers that are mounted on upper and lower blocks of 32 lasers each and the entire unit spins at 10Hz.
  • This allows to acquire information from visual textures, like lane marker information, similar to monoscopic image analysis.
  • Two additional Sick LMS 291 1D lidar scanners are mounted horizontally both on the front and rear bumper in order to observe obstacles that are too close to the vehicle for tracking by the Velodyne lidar.

F. E-stop system and warning devices

  • To ensure safe operation in autonomous mode, DARPA required every team to implement several safety features such as audible and visible warning signals and emergency stop devices.
  • Additionally, the DGCSR provides an ENABLE/DISABLE signal for emergency stop purposes which can also be triggered manually by two emergency stop buttons at both sides of the vehicle.
  • The authors solution makes use of the manufacturer-equipped immobilizer system, which immediately switches off the engine when no ignition key is present.
  • When triggered at higher speeds, it automatically activates all vehicle brakes via the antilock brake system until the button is released or the vehicle has come to a complete stop [8].

G. Power unit

  • In order to handle the increased power consumption of the vehicle, a larger alternator (220A) and a power unit was installed.
  • The latter comprises 2 batteries, DC/AC and DC/DC converters, a charging device, fuses, and buffer condensators.
  • Even for hours of testing with a shut down engine.

III. SYSTEM ARCHITECTURE AND DATA TRANSMISSION

  • In order to avoid extensive cabling between sensors, controllers, and actuators, a BUS system can be found in every modern vehicle.
  • The raw data is stored into the RTDB with the help of dedicated I/O modules.
  • All algorithms from obstacle recognition to decision making [6] are executed on the computing system.
  • In turn, the Autobox sends vehicle sensor data paired with controller status information back.
  • The CAN signal is sent to a gateway, which filters the messages for safety reasons.

IV. REAL-TIME CONTROLLER FRAMEWORK

  • Since there is also a scientific focus on dynamic vehicle control, a universal real-time framework has been implemented in a MATLAB/SIMULINK environment as depicted in Fig. 6 which different control algorithms can be integrated into.
  • For offline simulations the physical vehicle is automatically substituted by a veDYNA model [7], a highly accurate simulation of vehicle dynamics.
  • The framework comprises of a RTDB-interface, interfaces to the actuators and vehicle sensors, cascaded control algorithms, safety and debugging features.
  • Through the RTDB-interface information about the desired vehicle movement as well as LIN commands (e. g. 1082 Authorized licensed use limited to: Universitatsbibliothek Karlsruhe.
  • Restrictions apply. turning signal) is transferred to the Autobox.

V. REAL-TIME DATABASE

  • The real-time database for cognitive automobiles [2] acts as the central communication framework for high-level decision making on the computing system.
  • For interprocess communication the following method is applied: .
  • All processes have at least one logical database connection .
  • The sending process inserts an object with the relevant data into the RTDB Tracked obstacles are inserted as individual objects, updated with each lidar rotation and removed when they are lost Due to the efficient implementation of the real-time database, it takes only 8.3µs to update an object and 6.4µs to retrieve it.

A. Simulation and logging

  • Using the KogMo-RTDB architecture facilitates the exchange of arbitrary software modules.
  • As long as the exchanged modules write the same objects into the RTDB, the other modules will not notice the difference.
  • To test the AI modules, simulation modules were introduced that compute the dynamic motion of the own vehicle according to the lowlevel lateral and longitudinal control strategy and write the result into the vehicle status and position objects that would be written by the Autobox UDP bridge and the I/O processes from the GPS receiver.
  • Afterwards, the data log can be replayed in real-time or with a different speed into another RTDB, giving several options for simulation: 1083 Authorized licensed use limited to: Universitatsbibliothek Karlsruhe.

VI. SAFETY CONCEPTS

  • The most frequently activated safety measure that proved an important feature for testing has been the seamless switching between autonomous mode and manual interaction by a safety driver.
  • As soon as either the gas or the brake pedal is applied, or the deviation between desired and measured steering angle exceeds a certain threshold, the system automatically switches to manual mode.
  • To ensure safe operation when no safety driver is present, such as in the actual competition, several additional safety measures were implemented.

A. Manual hardware override

  • The manufacturer’s emergency system allows a safety driver to regain control over the vehicle in two different ways:.
  • First, all actuators are designed so that they can always be overridden by a human operator.
  • In case this is not sufficient, there are two easily accessible emergency buttons - one in the center console and another one next the brake pedal - which completely switch off all actuators and return control to the driver.
  • As this system was already integrated by the manufacturer, it is highly safe and reliable.
  • In manual control, operation does not differ from a series-production car, so the vehicle can be used legally on the street.

B. Hardware emergency stop

  • For operation without a safety driver, a remotely controlled emergency system based on the DARPA-supplied Omnitech DGCSR is used.
  • When activated, the vehicle has to come to a complete stop and, according to DARPA rules, shut off the engine.
  • The authors solution is based on the electronic parking brake and the electronic immobilizer system.
  • This solution makes use of vendor-supplied components only, thus it does not need any additional hardware except for some relays and a time delay circuit and is therefore highly reliable.
  • As another advantage, the vehicle can easily be recovered from DISABLE mode by simply removing the ignition key and restarting the engine.

C. Software emergency stop

  • In addition to the hardware emergency stop, the DGCSR signals is delivered to the Autobox, which itself also triggers the brakes via the CAN BUS when receiving a PAUSE or DISABLE signal.
  • Thus even in the unlikely case of an error in the hardware emergency stop, the Autobox would ensure that the vehicle comes to a safe stop.
  • Additionally, if no valid data is received from the main computing system for a certain amount of time, the Autobox internally switches to PAUSE state and thus brings the vehicle to a controlled stop.
  • As soon as the main computer is sending valid data again, the system switches back to RUN mode and the vehicle continues its mission.

D. Software monitoring

  • In case of a detectable software misbehavior, it is safer for the unmanned vehicle to stop itself automatically rather than being ultimately e-stopped by the remote control, which inevitably leads to a disqualification in the competition.
  • The monitoring system in Fig. 7 consists of several components: 1) Data watchdog:.
  • It indirectly watches the processes by looking at the data objects they write into the RTDB.
  • By looking at all process objects the watchdog can notice dead processes and restart them.
  • If a check fails, the RTDB watchdog immediately stops the whole software system and triggers an emergency brake maneuver using the stop sender.

VII. RESULTS AND CONCLUSIONS

  • The proposed framework has been implemented in the vehicle base and has been extensively tested in simulations.
  • In particular, the seamless migration capabilities of software from simulation to in-the-loop testing and to on-vehicle operation without necessity for any software changes was found to expedite the engineering process and increase the robustness of the experiments.
  • It finally came to a software deadlock situation that still lead AnnieWAY into a safe mode but caused its stop.
  • That situation had required rebooting of the main computer which was not admitted.

Did you find this useful? Give us your feedback

...read more

Content maybe subject to copyright    Report

A Hardware and Software Framework for Cognitive Automobiles
Moritz Werling
1
, Matthias Goebl
3
, Oliver Pink
2
, and Christoph Stiller
2
1
Institute of Applied Computer Science/Automation
2
Institut f
¨
ur Mess- und Regelungstechnik
University of Karlsruhe (TH), 76128 Karlsruhe, Germany
3
Institute for Real-Time Computer Systems
Technical University of Munich (TU), 80333 Munich, Germany
moritz.werling@iai.fzk.de goebl@rcs.ei.tum.de {pink, stiller}@mrt.uka.de
Abstract This paper describes the hardware and software
framework of AnnieWAY, an autonomous vehicle successfully
competing at all qualification stages up to the finals of the
DARPA Urban Challenge 2007 competition. Besides the hard-
ware premises for by-wire steering, braking, throttle control
and sensors, two frameworks for high-level decision making
and low-level control are described in detail. Furthermore, this
contribution points out AnnieWAY’s safety features for both
unmanned competition runs and manned testing. The system
proves to be flexible, expandable, and robust at the same time.
Index Terms hardware framework, software framework,
autonomous, cognitive automobile, AnnieWAY, DARPA Urban
Challenge
I. INTRODUCTION
In 2006 the German Research Foundation (DFG)
started the Transregional Collaborative Research Center
28 - Cognitive Automobiles interconnecting research of
Universities and research centers in Karlsruhe and Munich.
Its main objective is the development of new methods for
machine perception and machine behavior for automobiles
- not only in theory but also in extensive simulation and in
practice. For the latter, an experimental vehicle based on
a VW Passat platform has been equipped with actuators,
computers, microcontrollers and sensors (see also [4], [5]).
In the DARPA Urban Challenge 2007 competition, the
vehicle was put to a first test by Team AnnieWAY, a spin-off
of the Collaborative Research Center, and made it into the
finals.
This paper gives a detailed description of the hardware
and software framework that the different algorithms
[6] for the competition were integrated into. The focus
of the framework lies on the clarity of the architecture,
the decoupling of components, interchangeability and
expandability of algorithms, and by-passing of the hardware
components for simulation and in-the-loop testing purposes.
The remainder of this paper is organized as follows: After
a brief overview on the hardware components in Sec. II,
the system architecture is presented in Sec. III which the
interaction of the hardware and software components is based
on. In Sec. IV the controller framework is described that
transfers high-level decision into low-level actuator com-
mands. As AnnieWAY’s algorithms only communicate via
a real-time database, Sec. V introduces its main features.
Sec. VI concludes this contribution with a description of the
realized safety features.
II. HARDWARE COMPONENTS
A. Vehicle platform and actuators
For the sake of reliability and time constraints a Volks-
wagen Passat Variant 2.0 FSI was chosen to be directly
equipped with by-wire steering, braking, and throttle control
by the manufacturer (Fig. 1). This includes amongst others
the installation of
an electric steering motor
a new prototype power brake unit
an accelerator value simulator
a larger alternator
a LIN interface (e. g. turning lights)
All components are unobtrusively integrated into the
car interior lining and communicated with through a CAN
gateway which provides additional information available
on the series CAN-BUS. The manufacturer’s safety system
also allows for a quick and safe changeover from automatic
to manual control and vice-versa.
Since pulling into and backing out of a parking spot as
well as K-turns are required in the competition, an additional
longitudinal actuator was integrated into the selector lever
case of the automatic transmission in order to engage drive,
rear, and neutral gear.
B. Computing system hardware
The on-board computing system hosts all software for
perception and decision making. It has to provide sufficient
computing power and at the same time high data rates for
sensor data acquisition and low latencies for interprocess
communication. To fulfill these requirements a multicore
multiprocessor computer system using opteron processors
has been chosen. All opteron processors are interconnected
by HyperTransport (HT) at a speed of 3.2 GByte/s each.
This configuration can be regarded as a cluster-in-a-box, yet
infrastructure components like disks and power supply are
needed once only. Due to the employed high-efficent (HE)
CPUs, the system requires about 350W in total from the
DC/DC power supply.
2008 IEEE Intelligent Vehicles Symposium
Eindhoven University of Technology
Eindhoven, The Netherlands, June 4-6, 2008
978-1-4244-2569-3/08/$20.00 ©2008 IEEE. 1080
Authorized licensed use limited to: Universitatsbibliothek Karlsruhe. Downloaded on July 2, 2009 at 02:50 from IEEE Xplore. Restrictions apply.
First published in:
EVA-STAR (Elektronisches Volltextarchiv – Scientific Articles Repository)
http://digbib.ubka.uni-karlsruhe.de/volltexte/1000011964

Fig. 1. Hardware components
For persistent storage, system data and logging data are
distinguished: The system files that seldom undergo changes
are kept on a shock-proof flash disk. In contrast, for logging
purposes a very fast raptor harddisk is used, providing 44-91
MB/s and sustaining accelerations up to 3g. For the unlikely
case of a disk failure, another protection feature comes into
effect: The disks are connected by hot-plug capable serial
ATA (SATA) links. In contrast to parallel ATA, a hardware
failure does not disturb the mainboard hardware function,
but generates only software signals. In our arrangement, if
the logging disks fail or the connection gets loose, only the
logger process dies, leaving the rest of the software running
and keeping the vehicle on course.
To cool the computing system, cold air from the standard air
condition system is supplied, filtered by tissue-pads before
entering the computer case.
C. Real-time microcontroller and distribution box
Since high level decision making runs at soft real time
at best, a hard real time capable rapid prototyping environ-
ment, namely dSpace’s Autobox, is used for the vehicle’s
lateral and longitudinal control. In addition to the processor
board DS1005, the Autobox’ setup provides reliable inter-
face boards for digital I/Os (DS4002), CAN (DS4302), and
ethernet (DS4502Eth).
The Autobox’ digital I/Os are connected to the distribution
box, which converts the TTL level into 12V via relay and
provides enough space for reliable connectors.
D. DGPS/INS and wheel speed sensor
The RT3003 Inertial and GPS Navigation System (IMU) is
a six-axis inertial navigation strap down system that incorpo-
rates an L1/L2 RTK GPS receiver for position and a second
GPS receiver for accurate heading measurements. Additional
wheel speed input taken directly from the Passat’s series
wheel speed sensor in combination with the OmniSTAR
correction signal, the system delivers better than 0.02m
positioning and 0.1
heading under dynamic conditions.
The wheel speed information is directly taken from the series
sensor by tapping the signaling line and processing it to the
required TTL specification via a simple electric circuit.
E. 2D and 1D lidars
AnnieWAY’s perception mainly relies on three laser scan-
ners: The Velodyne HDL-64E comprises 64 lasers that are
mounted on upper and lower blocks of 32 lasers each and
the entire unit spins at 10Hz. It inherently delivers a 360
horizontal and a 26.8
vertical field of view by providing
about one million points per second with a angular resolution
of 0.09
horizontally and 0.05m in distance. In addition to
the 3D position the sensor signals reflectivity of each point.
This allows to acquire information from visual textures,
like lane marker information, similar to monoscopic image
analysis.
Two additional Sick LMS 291 1D lidar scanners are mounted
horizontally both on the front and rear bumper in order to
observe obstacles that are too close to the vehicle for tracking
by the Velodyne lidar. Since small parking spots where not
an issue in the competition, the two Sick laser scanners were
dismounted in the finals.
F. E-stop system and warning devices
To ensure safe operation in autonomous mode, DARPA
required every team to implement several safety features
such as audible and visible warning signals and emergency
stop devices. Key part of the emergency stop system is
the Omnitech Robotics Darpa Grand Challenge Safety
Radio (DGCSR) [1] which delivers two signals to remotely
control the vehicle. The RUN/PAUSE signal switches
between manual and autonomous operation. When in
PAUSE mode, the vehicle decelerates to a safe stop and
waits for reactivation. When in RUN mode, audible and
visible warning signals are required.
Additionally, the DGCSR provides an ENABLE/DISABLE
signal for emergency stop purposes which can also be
triggered manually by two emergency stop buttons at both
sides of the vehicle. When in DISABLE mode, the vehicle
decelerates to a safe stop and the engine is shut off.
1081
Authorized licensed use limited to: Universitatsbibliothek Karlsruhe. Downloaded on July 2, 2009 at 02:50 from IEEE Xplore. Restrictions apply.

To ensure safe operation even under software system
crash, a hardware-only solution has been implemented.
Our solution makes use of the manufacturer-equipped
immobilizer system, which immediately switches off the
engine when no ignition key is present. Instead of physically
removing the key, a simple relay circuit is used to cut its
power supply.
For emergency braking, another relay triggers the
manufacturer-equipped electronic parking brake, which
has a built-in emergency stop feature. When triggered at
higher speeds, it automatically activates all vehicle brakes
via the antilock brake system until the button is released or
the vehicle has come to a complete stop [8]. As soon as the
vehicle has come to a stop, the parking brake is activated
automatically, safely keeping the vehicle in place even at
slopes.
To keep the brake booster operational during emergency
braking, shutting off the engine is delayed by one second.
Fig. 2 shows the response of our vehicle speed after
triggering the emergency brake system.
Fig. 2. Emergency brake maneuver
G. Power unit
In order to handle the increased power consumption of
the vehicle, a larger alternator (220A) and a power unit
was installed. The latter comprises 2 batteries, DC/AC and
DC/DC converters, a charging device, fuses, and buffer
condensators. With this installation AnnieWAY’s computing
system as well as actuators and sensors are independent of
the car battery, even for hours of testing with a shut down
engine.
III. SYSTEM ARCHITECTURE AND DATA TRANSMISSION
In order to avoid extensive cabling between sensors,
controllers, and actuators, a BUS system can be found in
every modern vehicle. For the same and other reasons a real-
time data base (RTDB) as described in Sec. V, has been
introduced. Fig. 3 gives an overview on the complete system
with emphasis on the inherent data transfer.
The flow of information from the sensors to the actors
for vehicle control is shown. The LIDAR and IMU sensors
are connected to the computing system with a 100 MBit/s
ethernet connection. The raw data is stored into the RTDB
with the help of dedicated I/O modules. All algorithms from
obstacle recognition to decision making [6] are executed
on the computing system. The resulting path along with
velocity information and commands like turning signals
etc. are stored in the RTDB and immediately transmitted
by a UDP bridge to the Autobox via ethernet. In turn, the
Autobox sends vehicle sensor data paired with controller
status information back.
Fig. 3. System architecture and information flow diagram
The controller framework on the Autobox evaluates the
received data, provides it to the respective controllers, and
transfers their output to CAN and TTL signals as described
in Sec. IV. The CAN signal is sent to a gateway, which filters
the messages for safety reasons. The described hardware
components of Sec. II are connected to the gateway CAN
BUS as well as the CANtoLIN adapter handling head lights,
wipers, turning signals, etc. The rest of the components,
such as the beeper, the hazard lights and the DARPA e-stop
system are connected to the distribution box controlled by
the Autobox.
IV. REAL-TIME CONTROLLER FRAMEWORK
Since there is also a scientific focus on dynamic
vehicle control, a universal real-time framework has been
implemented in a MATLAB/SIMULINK environment as
depicted in Fig. 6 which different control algorithms can
be integrated into. The framework is set up in a way
that algorithms implemented in Simulink or C can be
validated online and offline as a matter of a mouse click
without any modifications. For offline simulations the
physical vehicle is automatically substituted by a veDYNA
model [7], a highly accurate simulation of vehicle dynamics.
The framework comprises of
a RTDB-interface,
interfaces to the actuators and vehicle sensors,
cascaded control algorithms,
safety and debugging features.
Through the RTDB-interface information about the
desired vehicle movement as well as LIN commands (e. g.
1082
Authorized licensed use limited to: Universitatsbibliothek Karlsruhe. Downloaded on July 2, 2009 at 02:50 from IEEE Xplore. Restrictions apply.

turning signal) is transferred to the Autobox. In turn, sensor
information from the vehicle’s CAN BUS is provided to the
RTDB.
The cascaded control algorithms for steering, braking,
acceleration and gear shifting (see Figs. 4 and 5) take
control over the hardware communication and enable the
longitudinal and lateral controllers to simply use steering
angle and acceleration as control output.
Fig. 4. Steering control
Fig. 5. Brake control
V. REAL-TIME DATABASE
The real-time database for cognitive automobiles (KogMo-
RTDB)[2] acts as the central communication framework
for high-level decision making on the computing system.
Every process is connected only to the RTDB and to no
other process. For interprocess communication the following
method is applied:
All processes have at least one logical database connec-
tion
Every set of data is packed together into an “object”,
the smallest unit handled by the RTDB
The sending process inserts an object with the relevant
data into the RTDB
The receiving process uses the RTDB-API to find the
object and retrieve its data
Whenever the sender has new data available, it imme-
diately updates the object
The receiver waits for new data and is informed as soon
as it is submitted
The data is automatically buffered within the RTDB for
an adjustable time interval, so it is possible to retrieve
older data, e.g. to combine lidar data points with the
correct GPS-position at the time the measurement has
been performed
Tracked obstacles are inserted as individual objects,
updated with each lidar rotation and removed when they
are lost
Due to the efficient implementation of the real-time
database, it takes only 8.3µs to update an object and 6.4µs
to retrieve it. The full communication from one process to
another takes 29.6µs (see also [2], [3]). Due to the low
overhead, a maximum of computing power is left for the
perception and decision processes (AI modules).
A. Simulation and logging
Using the KogMo-RTDB architecture facilitates the ex-
change of arbitrary software modules. As long as the ex-
changed modules write the same objects into the RTDB, the
other modules will not notice the difference. To test the AI
modules, simulation modules were introduced that compute
the dynamic motion of the own vehicle according to the low-
level lateral and longitudinal control strategy and write the
result into the vehicle status and position objects that would
be written by the Autobox UDP bridge and the I/O processes
from the GPS receiver. With this setup, multiple autonomous
vehicles with multiple decision making processes can be
simulated simultaneously as well as joystick driven cars,
testing the correct interaction.
The centralized data storage offers the opportunity to
record all data together. With the help of the RTDB recorder
all objects can be logged to disk. Whenever a new object
is created, destroyed, or an existing object is changed, the
new state is recorded, including an absolute timestamp with
a nanosecond resolution. Afterwards, the data log can be
replayed in real-time or with a different speed into another
RTDB, giving several options for simulation:
By watching all replayed objects within the database,
performance measurements for the involved modules
can be taken.
Only a selected set of objects can be replayed, so an
algorithm can be tested multiple times under equal
conditions.
The results of a reworked algorithm can be recorded
again together with the original source data.
As raw data is also recorded, parameter modifications
can be tested offline.
1083
Authorized licensed use limited to: Universitatsbibliothek Karlsruhe. Downloaded on July 2, 2009 at 02:50 from IEEE Xplore. Restrictions apply.

Fig. 6. MATLAB/SIMULINK controller framework
The substitution of real-world sensors with the accord-
ing simulation model is possible.
VI. SAFETY CONCEPTS
The most frequently activated safety measure that proved
an important feature for testing has been the seamless
switching between autonomous mode and manual interac-
tion by a safety driver. As soon as either the gas or the
brake pedal is applied, or the deviation between desired
and measured steering angle exceeds a certain threshold, the
system automatically switches to manual mode. To ensure
safe operation when no safety driver is present, such as in the
actual competition, several additional safety measures were
implemented.
A. Manual hardware override
The manufacturer’s emergency system allows a safety
driver to regain control over the vehicle in two different
ways: First, all actuators are designed so that they can always
be overridden by a human operator. In case this is not
sufficient, there are two easily accessible emergency buttons
- one in the center console and another one next the brake
pedal - which completely switch off all actuators and return
control to the driver.
As this system was already integrated by the manufacturer,
it is highly safe and reliable. In manual control, operation
does not differ from a series-production car, so the vehicle
can be used legally on the street.
B. Hardware emergency stop
For operation without a safety driver, a remotely controlled
emergency system based on the DARPA-supplied Omnitech
DGCSR is used. When activated, the vehicle has to come
to a complete stop and, according to DARPA rules, shut off
the engine. Our solution is based on the electronic parking
brake and the electronic immobilizer system. This solution
makes use of vendor-supplied components only, thus it does
not need any additional hardware except for some relays
and a time delay circuit and is therefore highly reliable. As
another advantage, the vehicle can easily be recovered from
DISABLE mode by simply removing the ignition key and
restarting the engine.
C. Software emergency stop
In addition to the hardware emergency stop, the DGCSR
signals is delivered to the Autobox, which itself also triggers
the brakes via the CAN BUS when receiving a PAUSE or
DISABLE signal. Thus even in the unlikely case of an error
in the hardware emergency stop, the Autobox would ensure
that the vehicle comes to a safe stop. Additionally, if no valid
data is received from the main computing system for a certain
amount of time, the Autobox internally switches to PAUSE
state and thus brings the vehicle to a controlled stop. As soon
as the main computer is sending valid data again, the system
switches back to RUN mode and the vehicle continues its
mission.
D. Software monitoring
In case of a detectable software misbehavior, it is safer for
the unmanned vehicle to stop itself automatically rather than
being ultimately e-stopped by the remote control, which
inevitably leads to a disqualification in the competition. So a
software monitoring system was designed to detect failures
and to bring the vehicle to a safe stop. The monitoring
system in Fig. 7 consists of several components:
1) Data watchdog: It indirectly watches the processes by
looking at the data objects they write into the RTDB. For
this analysis the watchdog supervises only one connection
to the RTDB. The monitored processes do not have to fulfill
any prerequisites, like dedicated debugging ports or the like.
By looking at the commit timestamp of every object the
watchdog can decide whether a process is able to meet its
deadlines. If a hardware sensor fails, the I/O process (shown
in Fig. 3) ceases from updating its sensor object, and the
failure is observed by the watchdog. By looking at all
process objects the watchdog can notice dead processes and
restart them. In case of the death of a process, its objects are
preserved for a predefined time (e.g. 5 seconds), so the data
could be used for a possible emergency maneuver along the
1084
Authorized licensed use limited to: Universitatsbibliothek Karlsruhe. Downloaded on July 2, 2009 at 02:50 from IEEE Xplore. Restrictions apply.

Citations
More filters

01 Jan 2010
TL;DR: The safety verification of dynamical systems using reachability analysis, which measures the probability of reaching an unsafe set, and a Markov chain which approximately computes the stochastic reachable set of arbitrary dynamics is generated.
Abstract: This thesis is about the safety verification of dynamical systems using reachability analysis. Novel solutions have been developed for classical reachability analysis, stochastic reachability analysis, and their application to the safety assessment of autonomous cars. Classical reachability analysis computes the set of states that can be reached by a system. If the reachable set does not intersect any set of unsafe states, the safety of the system is guaranteed. Algorithms for this problem have been developed for linear, nonlinear, and hybrid systems. Stochastic reachability analysis measures the probability of reaching an unsafe set. One pursued approach computes over-approximative solutions for linear systems; another one generates a Markov chain which approximately computes the stochastic reachable set of arbitrary dynamics.

220 citations


Cites methods from "A hardware and software framework f..."

  • ...Besides similar sensor technologies, all vehicles share a common computer hardware and software framework [172]....

    [...]


Journal ArticleDOI
TL;DR: Two complementary nonlinear Lyapunov-based tracking-control laws are proposed to solve the problem of stabilization of precalculated state trajectories for speeds between ±6 m/s and they provide a smooth, singularity-free stopping transient.
Abstract: Safe handling of dynamic inner-city scenarios with autonomous road vehicles involves the problem of stabilization of precalculated state trajectories. In order to account for the practical requirements of the holistic autonomous system, we propose two complementary nonlinear Lyapunov-based tracking-control laws to solve the problem for speeds between ±6 m/s. Their designs are based on an extended kinematic one-track model, and they provide a smooth, singularity-free stopping transient. With regard to autonomous test applications, the proposed tracking law without orientation control performs much better with respect to control effort and steering-input saturation than the one with orientation control but needs to be prudently combined with the latter for backward driving. The controller performance is illustrated with a full-size test vehicle.

59 citations


Journal ArticleDOI
TL;DR: Neben der hierfur erforderlichen Umfeldwahrnehmung stellen besonders die Bewegungsplanung und -ausfuhrung zeitkritischer Fahrmanover zur Beherrschung of dynamischen Verkehrsszenarien eine grose Herausforderung dar.
Abstract: Durch den Einsatz autonomer Fahrzeuge kann der Strasenverkehr effizienter, komfortabler und vor allem sicherer gestaltet werden. Neben der hierfur erforderlichen Umfeldwahrnehmung stellen besonders die Bewegungsplanung und -ausfuhrung zeitkritischer Fahrmanover zur Beherrschung von dynamischen Verkehrsszenarien eine grose Herausforderung dar. Herkommliche Verfahren, die trotz trickreicher Modifikationen dieser nicht gewachsen sind, werden konsequent durch trajektorienbasierte Konzepte ersetzt. Umfang: XII, 141 S. Preis: €35.50 | £33.00 | $63.00

44 citations


Additional excerpts

  • ...1), dessen modulares Erprobungsframework [100] sich u....

    [...]


Proceedings ArticleDOI
01 Nov 2016
TL;DR: The requirements for software frameworks for automated driving projects are analyzed and the communication overhead of ROS is analyzed quantitatively in various configurations showing its applicability for systems with a high data load.
Abstract: Automated vehicles are complex systems with a high degree of interdependencies between its components. This complexity sets increasing demands for the underlying software framework. This paper firstly analyzes the requirements for software frameworks. Afterwards an overview on existing software frameworks, that have been used for automated driving projects, is provided with an in-depth introduction into an emerging open-source software framework, the Robot Operating System (ROS). After discussing the main features, advantages and disadvantages of ROS, the communication overhead of ROS is analyzed quantitatively in various configurations showing its applicability for systems with a high data load.

20 citations


Cites methods from "A hardware and software framework f..."

  • ...For the last ten years, the Real-time Database for Cognitive Automobiles (KogMo-RTDB) was used as a data exchange provider within our team’s research vehicles [8]....

    [...]


Proceedings ArticleDOI
20 Mar 2012
TL;DR: Methods for 3D Machine perception based on lidar and video sensors are outlined and a flat input parameterization to plan trajectories that optimize the imposed quality measure is adopted.
Abstract: This presentation focusses on key technologies for automobiles that perceive a priori unknown environment and automatically navigate through everyday traffic. Methods for 3D Machine perception based on lidar and video sensors are outlined. Beyond classical metrology, the recognition and basic understanding of situations must be accomplished for automated trajectory planning in urban traffic. We discuss how to represent and acquire metric, symbolic and conceptual knowledge from video and lidar data of a vehicle. A hardware and software architecture tailored to this knowledge structure for an autonomous vehicle is proposed. Emphasis is laid on methods for situation recognition employing geometrical and topological reasoning and Markov Logic Networks. A quality measure for trajectories is imposed that considers safety, efficiency, and comfort. We adopt a flat input parameterization to plan trajectories that optimize the imposed quality measure. Results from the autonomous vehicle AnnieWAY that recently won the Grand Cooperative Driving Challenge are shown in real world urban and platooning scenarios.

13 citations


Cites methods from "A hardware and software framework f..."

  • ...To assess and validate theoretical findings we have adopted the unified hardware and software framework of the Karlsruhe-Munich collaborate research center ’cognitive automobiles’ [8], [9]....

    [...]


References
More filters

Proceedings ArticleDOI
13 Jun 2007
TL;DR: It is argued that in the long term automated cooperation among traffic participants bears the potential to improve traffic efficiency and safety beyond the level attainable by human drivers.
Abstract: Safety requirements are among the most ambitious challenges for autonomous guidance and control of automobiles. A human-like understanding of the surrounding traffic scene is a key element to fulfill these requirements, but is a still missing capability of today's intelligent vehicles. Few recent proposals for driver assistance systems approach this issue with methods from the AI research to allow for a reasonable situation evaluation and behavior generation. While the methods proposed in this contribution are lend from cognition in order to mimic human capabilities, we argue that in the long term automated cooperation among traffic participants bears the potential to improve traffic efficiency and safety beyond the level attainable by human drivers. Both issues are major objectives of the Transregional Collaborative Research Centre 28 'cognitive automobiles,' TCRC28 that is outlined in the paper. Within this project the partners focus on systematic and interdisciplinary research on machine cognition of mobile systems as the basis for a scientific theory of automated machine behavior.

104 citations


"A hardware and software framework f..." refers methods in this paper

  • ...For the latter, an experimental vehicle based on a VW Passat platform has been equipped with actuators, computers, microcontrollers and sensors (see also [4], [5])....

    [...]


Proceedings ArticleDOI
13 Jun 2007
TL;DR: The architecture presented in this papers offers a method to interchange information with different temporal resolutions liberally among modules with distinct cycle times and realtime demands, allowing effortless buffering of raw data for subsequent data fusion and verification, facilitating innovative processing structures.
Abstract: Cognitive automobiles consist of a set of algorithms that cover a wide range of processing levels: from low-level image acquisition and feature extraction up to situation assessment and decision making. The modules implementing them are naturally characterized by decreasing data rates at higher levels, because raw data is discarded after evaluation, and increasing processing intervals, as knowledge based levels require longer computation times. The architecture presented in this papers offers a method to interchange information with different temporal resolutions liberally among modules with distinct cycle times and realtime demands. It allows effortless buffering of raw data for subsequent data fusion and verification, facilitating innovative processing structures. The paper is completed by measurements demonstrating the achieved real-time capabilities on our selected hardware architecture.

80 citations


01 Jan 2006
TL;DR: How to interface steering, throttle and brake as well as built-in sensors are described, and an inexpensive way to provide a safe research platform for road traffic is shown.
Abstract: Since research in intelligent autonomous road vehicles gets more and more popular, many interested researchers are confronted with the needs to setup a commercially available vehicle with drive-by-wire. Up-to-date road vehicles contain many mechatronical components, sensors and driver assistance systems, which can be interfaced and thus reduce the needs of expensive modifications and additional actors to a minimum. This paper describes how to interface steering, throttle and brake as well as built-in sensors, and shows an inexpensive way to provide a safe research platform for road traffic.

10 citations


"A hardware and software framework f..." refers methods in this paper

  • ...For the latter, an experimental vehicle based on a VW Passat platform has been equipped with actuators, computers, microcontrollers and sensors (see also [4], [5])....

    [...]


Book ChapterDOI
18 Feb 2008
TL;DR: AnnieWAY, an autonomous vehicle that is capable of driving through urban scenarios and that has successfully entered the finals of the DARPA Urban Challenge 2007 competition, is reported on.
Abstract: This paper reports on AnnieWAY, an autonomous vehicle that is capable of driving through urban scenarios and that has successfully entered the finals of the DARPA Urban Challenge 2007 competition. After describing the main challenges imposed and the major hardware components, we outline the underlying software structure and focus on selected algorithms. A recent laser scanner plays the prominent role in the perception of the environment. It measures range and reflectivity for each pixel. While the former is used to provide 3D scene geometry, the latter allows robust lane marker detection. Mission and maneuver selection is conducted via a concurrent hierarchical state machine that specifically ascertains behavior in accordance with California traffic rules. We conclude with a report of the results achieved during the competition.

8 citations


"A hardware and software framework f..." refers methods in this paper

  • ...In the DARPA Urban Challenge 2007 competition, the vehicle was put to a first test by Team AnnieWAY, a spin-off of the Collaborative Research Center, and made it into the finals....

    [...]


Book ChapterDOI
01 Jan 2007
TL;DR: Die hier vorgestellte Architektur bietet Schnittstellen, die sowohl grose Datenmengen effizient transportieren konnen, als auch Methoden zur blockierungsfreien zeitlichen Entkopplung.
Abstract: Kognitive Automobile erfordern unterschiedlichste Algorithmen auf allen Wahrnehmungsebenen. Um diese zu verbinden und deren erfolgreiche Kooperation sicherzustellen werden flexible und leistungsfahige Schnittstellen benotigt. Fur eine sichere Reaktion auf plotzliche Umwelteinflusse muss zudem insbesondere auf den unteren Ebenen eine schritthaltende Verarbeitung gewahrleistet Scin. Die hier vorgestellte Architektur bietet Schnittstellen, die sowohl grose Datenmengen effizient transportieren konnen, als auch Methoden zur blockierungsfreien zeitlichen Entkopplung. Eine besondere Starke ist die nahtlose Integration von realzeit- und nicht-realzeitfahigen Wahrnehmungsprozessen.

7 citations