Tackling the challenge of testing an immense set of driving states
One of the main challenges in progressing the development of Automated Vehicles (AV) is in assuring that they are safe. CavPoint's initial focus is to develop new ways to automatically find problematic driving scenarios for the AV control software. Because our search methods automatically generate new scenarios within a simulated environment, we require simulation tools.
Connecting simulation software to AV control software
The AV control software is our system-under-test. In order to test this software within a simulation software package, we need to connect them together using Bridge software. The role of the Bridge is to send vehicle sensor data (LIDAR, cameras, inertial data, GPS, ...) from the simulator to the AV control software and to send AV vehicle commands (accelerator, brake, steering, etc.) back to the simulator. This testing technique is called Software-in-the-Loop.
CarMaker is typically used by major car manufacturers. You will find a more detailed description of CarMaker on our previous blog post.
Apollo is an AV control software. In technical terms they are aiming at an SAE level 4 geofenced application. It is actively under development and is backed by Baidu, one of the largest Chinese technology companies.
Implementing the Bridge between the AV software and the Simulator
Carmaker provides a comprehensive C code interface that can be used to access vehicle states (position, orientation, speed, ...) as well as control signals (throttle, brake, steering, ...) and sensor data (GPS, LIDAR, ..). Our Bridge directly used the CarMaker C code interface to access the ego vehicle data.
Apollo’s architecture leverages Docker to organise its main components into containers (Perception module, Routing module, Control module, ...). At its interface, Apollo only handles data specified in Google protobuf definition files. Protobuf is a way to transfer (or even store) data in an efficient manner. Protobuf definition files describe and list signals forming a protobuf message. Apollo messages are composed of different individual signals distributed across 10 protobuf definition files. These individual signals include timestamps, vehicle state, sensor and control data.
Data Format Conversion
The data exchanged through the bridge is not represented in the same way in Apollo and CarMaker. For example, Apollo requires some vehicle spatial orientation information for computing its position in space and uses a quaternion format. However, CarMaker does not represent the vehicle orientation using the quaternion format, so we used a combination of data provided by Carmaker to reconstruct it.
We have implemented required conversions so that the data communicated have equivalent meaning in Apollo and CarMaker.
From an early prototype to a higher performance implementation
In a prototype exercise, we proved that we could run a communication Bridge using Python. The prototype in Python was only implementing a small part of the Bridge and was only communicating a small number of messages. Then, once the prototype showed that the concept was viable, we subsequently re-implemented it in C++ for performance reasons.
Our implementation of a Bridge between the CarMaker simulation environment and the Apollo AV control software provided us with in-depth understanding of their interface and their timing requirements.
Creating a bridge is a task that most OEMs and startups in the Automated Driving space would have to carry out to connect their AV control software to a simulator. A bridge is an essential piece of software that enables testing AV control software in a safe environment (because it is done in simulation). In addition, it prevents the risk of damaging expensive hardware prototypes in the testing process. This task of setting up a co-simulation environment is an absolute prerequisite for the testing of any AV control software.
We would like to thank IPG Automotive for providing support for this work.