CONTEXT – Autonomous vehicle industry has become increasingly important over the last few years. Automotive companies determined to develop their own self-driving car must guarantee safety for their customers. Therefore, it implies many testing procedures with prototypes which can be very expensive. In this context, simulation appears as an affordable way to make tests earlier in the development process, that also leaves more room for mistakes. The in-the-loop approach enables companies to be as close as possible to reality, by testing the behaviour of a simulated vehicle with a dedicated software such as SCANeR studio. To go even further, SCANeR can be combined with a flexible framework called ROS, Robotic Operating System. It is a middleware used in robotics to interface different entities that could help us gather information from SCANeR studio’s simulator, process them to regulate the vehicle’s behaviour and send data back to the simulator in order to observe the efficiency of our regulation.
CHALLENGE
As SCANeR runs on Windows and ROS on Linux, the feasibility of our regulation strongly depends on a reliable bidirectional communication between them. We also need to set up a regulation program on ROS that is able to integrate with the bridge in order to control a simulated vehicle on SCANeR.
SOLUTION
Develop a functional bridge between SCANeR’s simulator and ROS’s programs so that they could exchange data and process in a synchronous way. A regulation program is set up in ROS in order to control the vehicle behaviour.
NEXT STEPS
Now, we can go even further with such a system, by including a real environment in our testing loop. We will try to upload this code on a single board microcontroller such as a Raspberry PI, that could pilot a miniature model of a self-driving car, available in our university. A first achievement could be driving in a straight line down the corridor, without hitting walls.
BENEFITS
SCANeR studio, provided by AVSimulation, is a powerful software dedicated to autonomous vehicle simulation in realistic traffic situations. The user can act on the car settings and create a scenario that suits best for their tests. The final purpose of our project consisted of a speed regulation and thanks to SCANeR, we are able to track the speed of a vehicle moving forward on a road, and extract data needed to compute our PID controller on ROS.
A partnership with Renault Software Labs led us to this innovative project that was part of one of our training units called “Projet
Initiation de Recherche (P.I.R.)” at our engineering school “INSA Toulouse”. Our main goal was to communicate between two different
softwares that run on two different operating systems : SCANeR studio 1.8 and ROS run respectively on Windows 10 and Ubuntu 16.04.
The first step of our researches was to understand how SCANeR studio 1.8 worked and how to make it interact with an external environment. So we followed a training initiation supervised by two engineers from Renault Software Labs. Thanks to their expertise, we learned the main features offered by this simulator that provide an easy way to implement external processes, running on different programming languages. Regarding our project, we had SCANeR running on a Windows PC and ROS running on a Linux core virtual machine. Then, we created a configuration in order to interface SCANeR and ROS’s nodes which were implemented in C++. We also had to install SCANeR requirements on our Ubuntu machine (such as SCANeR Studio daemon for Linux and different packages). Thanks to a shared folder, we were able to communicate between SCANeR, on Windows, and ROS’s processes on Ubuntu.
Before being able to write functional code to extract data from SCANeR, we had to understand the SCANeR’s API. That is why we had to analyse carefully the documentation given in “Network.html”.We particularly studied the IVehicle and ISensor Interfaces in order to have better understand the functions and data we wanted to manipulate. Moreover, we had a sample from an existing bridge, capable of transmitting the speed of a car controlled by SCANeR modelhandler toward ROS. So in the first place, we successfully obtained the speed on ROS, showing that the bridge was working from SCANeR to ROS. Then we used a ROS visualisation tool called RVIZ in order to display a marker moving as the speed changed in SCANeR.
The next step in our project was to send information back to SCANeR to control the vehicle speed from ROS. As we analysed the SCANeR API to see how the receive and transmit data functions worked, we learnt how to set vehicle parameters such as speed.
This implies another change to SCANeR’s configuration, which was initially unable to regulate the speed of the vehicle. Our external
ROS program acts as an external input for the simulator that allows us to control the vehicle’s speed.
Finally, the last step was to combine the reception and the emission threads : we wanted to change the vehicle’s behaviour according to the environment and data from simulated sensors. Our control module on ROS consists of three different parts. A first program which receives data from the vehicle’s sensors on SCANeR and transmits them to a calculator. The second one is a calculator, which handles received data and computes orders to obtain the desired behaviour. This regulation was implemented with a PID controller. The last program sends data from the calculator back to SCANeR to finally regulate the vehicle. For example, with this system, we could see a vehicle running on SCANeR that adapts its speed depending on the perceived distance with the preceding vehicle.
Thus, this project gave us the opportunity to use SCANeR studio 1.8, an effective simulator aimed at professional use, in order to create a test-bed integrated with ROS, that is able to include various programs such as a speed regulator. We experienced some of the challenges that industrials often face regarding simulations and we understand now how important this stage is in the development process.