Multi-sensors and Environment Simulator for Collision Avoidance Applications
Samir Bouaziz, Michel Fan, Roger Reynaud, Thierry Maurin
IEF, UniversitC de Paris-Sud
Bstiment 220,91405 Orsay Cedex, FRANCE
samir.bouaziz@ief.u-psud.fr
Abstract
The “PICAR” project is based on “PrometheusProchip ’’
experience and results1. The goal is to design an
embedded multi sensors collision avoidance system for
automotive application[l]. The system includes sensors
like video camera, ultrasonic sensors, a PC hardware
computer, a CAN2 network and a dedicated software for
signal and image processing, data fusion and AI expert
system.
The design of such a system is difJicult under real time
constraints. Therefore, a simulator is a good solution to
test different parts of the system and then to help to
choose the overall architecture. However simulating all
the embedded architecture in real-time becomes a very
complex work
It is necessaiy to have an environment simulator where
sensors can be virtually implemented. The data are then
processed leading to results without hardware costs. The
designed environment software allows the simulation of
physical sensors, and also the emulation of these sensors.
The simulator is interfaced to the physical embedded
hardware by a network bridge. So, we can emulate some
sensors to experiment data processing on the physical
embedded PICAR computer.
This paper presents the physical smart car PICAR and its
embedded system, the virtual world simulator. We explain
how we can mix the virtual world (produced by virtual
sensors) and real world (physical embedded system) to
implement some scenarios (like automatic parking) and
to validate the physical architecture. An alternate goal
can be to design customized sensors.
I This work was supported by the G.I.E. P.S.A.-R.N.U.R. under the
contract no 819040 CNRS/GIE PSA RNUR within the framework of
EUREKA PROMETHEUS PROCHIP research project.
2 http://www.omegas.co.uWCAN/index.html.
127
0-7695-0740-9/00 $10.00 0 2000 IEEE
1. Introduction
First, we give an overview of the PICAR smart car and the
implementation of the simulator.
Our simulator generates virtual data to be processed inner
the simulator or by the PICAR physical hardware system.
Clientkerver mechanism assumes to separate a simulator
kernel (virtual part) and the physical embedded system
(physical part) by using network exchanges. Virtual
Sensors Data are sent to the physical hardware system or
to the client display (2D or 3D).
The physical car PICAR exists also as a model in the
virtual world simulator.
2. The physical plat-form
The PICAR plat-form is an electrical car including some
embedded electronics systems. The goal is to experiment
either customized sensors, computer architectures or data
processing for the following scenarios such as collision
avoidance system [l], automatic parking, or stay on the
lane application.
Figure 1 shows the physical smart car PICAR. The
sensors are of two kinds : internal and external. Internal
sensors give us the proprioceptive information relative to
the smart car, like speed, acceleration, car direction, brake
status.. .etc. Exteroceptive sensors capabilities give
external information around the car. They include
cameras, telemeter, ultrasonic sensors. All external data
are used to detect obstacles. Data fusion processing is
necessary to certify obstacles positions.
CAN network is used to exchange data between sensors
and to centralize them in the embedded computer. CAN is
a serial bus system especially suited for networking
”intelligent” devices as well as sensors and actuators,
within a system or sub-system.
 Clients are of two kinds:
3D/2D display and virtual software data
processing.
physical PICAR embedded system.

Figurel. PICAR smart car

Sensors data are multi-processed by PCs to make data

fusion, to detect obstacles for tracking or avoiding. The
multi-process computer includes RTX Real Time Kernel
assuming software threads management.

3. The simulator Figure 3. Virtual PICAR car in the simulator

The simulator assumes managing the objects position The figure 4 gives the simulator organization. The
(vehicles and other obstacles), generating the sensors data network assumes multi-clients interaction with the
according to the physical models of these sensors. simulator server.

World (road) Simulation server

Sensors
Kernel simulator ,@,
0 Vehicles
Figure2. simulator overview
I
I TCPnP NET
I
I
\

In the figure 2, the world is a virtual description of the

roads, fixed obstacles (trees) and road signs.
The sensors item represents the two kinds of sensors
n
I1 n
I1
models, specified as time flying measurement sensor or client visualization and client visualization and
imaging sensor (1D or 2D). For example, the virtual data processing simulation data processing simulation
telemeter uses a time flying model, CCD camera sensor Figure 4. simulator architecture
uses an imaging 2D model.
The vehicles items are of two kinds: smart cars and others 3.1 Display and virtual data processing
vehicles used as obstacles with predefined trajectories.
3D/2D display is a simple client that simply displays the
The simulator is based on a cliendserver organization. virtual world including roads, and cars and the virtual
The server simulator is dedicated to simulate the sensors smart car. It uses the real time 3D rendering realized by
and the vehicles displacements. All or part of the data are using a direct-3D hardware acceleration (common cards
sent to the clients. on common Intel PC). This client can visualize some
information about the virtual car and results of customized

128
data processing. Therefore, we can test in a virtual reality
some sensors data processing without physical embedded
architecture constraints.
Figure 5 shows different windows, 3D rendering and
iinformation resulting of the data sensors Drocessing..
Figure 5. Example 3D Real-time rendering
The blue smart car is changing lane. This is due to the
result of sensors data processing that warns about the
yellow car (obstacle). The sensors data processing is
using this display client as the virtual smart car embedded
computer.
Only the blue car is smart car. All other cars are
considered as static cars. It means that they execute
predefined trajectories.
l All or part of the simulated data are seen as coming from
Figure 6.2D display and results superposition
129
Another visualization is a 2D graphics. Figure 6 shows an
example of 2D visualization. There is two kinds of
rectangles: simulated cars positions and calculated objects
that are the result of the processing. This 2D visualization
is very interesting because it assume to validate a global
processing performance.
3.2 The physical system client
This client is the physical embedded system of the PICAR
car. It is used to implement data processing and to control
the car.
This system is connected to the simulator network and is
included like a client of the simulator. This is done by
using the network formatter bridge. The simulator
generates virtual sensors data and transmits them to the
physical client by using the bridge.
The figure 7 shows the physical client interaction with the
simulator environment.
sensors and actuators
uhvsical client
Embedded
I E i t t e r bridge computer I
@,
Simulation server data processing
and
simulation
Figure 7. Physical client and the simulator
the local physical CAN network of PICAR. The
embedded programs will execute data processing and will
make feedback to actuators to control the smart car. This
feedback is captured by the formatter bridge and will be
sent to the virtual smart car (of the simulator).
During this step, it is necessary to disconnect the physical
sensors and actuators physically connected to the CAN
embedded network.
3.3 Simulator implementation level data generated by the simulator to the physical
electronic part of the sensor in order to be processed by
The simulator kernel is event driven. Events are generated the physical dedicated sensor electronics.
by all sensors and actuators. A real-time clock is
considered as an event actuator for the simulator. This will
assume to generate or to send sensors data by respecting
the real-time world.

During the simulation, we can compare the sensors events

to the static musical notes included in partition of the
music. Some extended events (from physical client) are
considered as dynamic events. So, we have to define a
textual language to describe scenarios execution of the
simulation. There are three kinds of definitions : static
objects (like roads, trees.. .), predefined vehicles and their
displacements, and finally sensors descriptions.

Here is example of sensor description :

CAMERA <name>.STANDARD(...,nb4,nb5);

Parameters indicates relative position of camera, it also

indicates if the camera is fixed or embedded, and if this
camera generates sensor data or high level objects
positions (in order to use these positions for the 3D/2D
visualization clients). This high level kind of sensors is
named Visualization sensors and generates less data
because the 3D/2D display is assumed by the display
client.
Each virtual sensor model is described in C/C++ language
module. Some predefined low level primitives can be used
to describe interaction between the virtual world and the
virtual sensor.
The figure 8 gives an overview of the software simulator
organization.
4. Conclusion
This paper deals with a virtual environment simulator to
simulate and to model sensors. The second objective is to
use virtual sensors data to evaluate a physical embedded
architectures and data processing programs.
We want to include the electronic part of the sensors in
the environment simulation. The simulator will send low
Figure 8. simulator Server Software organization
5. References
[l] R. REYNAUD, T. MAURIN
O n board data fusion and decision system used for obstacle
detection : 2D vision versus 1D sensor fusion IEEElIES ‘94
[2] A. CHEBIRA, R. REYNAUD, T. MAURIN
Reconstruction of 2D parameters using infrared sensors
SPIES 93, International Symposium on Optics Imaging and
Instrumentation,San Diego, USA, July 1993
[3] Y. Guinand, N. Valayden, F. Bizoueme, S.Bouaziz,...
Low cost sensors for collision avoidance applications
IEEE Int Symposium on Intelligent Vehicles ‘95, Detroit 25-
26 sept 95.
[4] R. Sukthankar, D. Pomerleau, C. Thorpe << SHIVA :
Simulated Highways for intelligent Vehicle
Algorithms B, IEEE intelligent vehicles symposium,
p332-337, September 1995.
[ 5 ] D. Estbve, A. Coustre, M. Garajedagui, (< L’inttgration
des systbmes Clectroniques dans I’automobile du
XXIeme sikcle >,,Ctpadubs Editions book, 1995.

130