Whenever a new algorithm is developed or an existing one is modernized, the need arises for its comprehensive testing before using it on a car in real road conditions. If the required software behavior is predetermined, then special software tests can be used for preliminary tests. However, they have several significant drawbacks: firstly, their creation for each algorithm requires significant time costs; secondly, they cannot be used if the behavior of the system is not strictly regulated.
Therefore, for the initial verification of research and testing algorithms, it is generally accepted to use a simulator in which a virtual double of an unmanned car is created and its behavior is simulated in various road scenarios.
In addition, the use of the simulator provides a number of advantages:
- Testing time for developed software is reduced - it is much easier to run a simulator than to recreate a script of interest in the real world;
- it becomes possible to test in the most unlikely and difficult traffic situations without risk to people or infrastructure;
- it becomes possible to repeatedly reproduce the same traffic situation in the same conditions.
It should be understood that the key drawback of the simulator is the impossibility of creating fully realistic virtual worlds. As a result, the use of the simulator does not completely replace the tests on a real car, but only reduces their number.
Over the past few years, there have been many open simulators designed to test unmanned vehicle software: Gazebo , V-Rep , Webots , LGSVL Simulator , MicrosoftAirSim , CARLASimulator , Deepdrive, and many others.
So why, with such a variety of existing simulators, did we choose Gazebo? Everything is explained quite simply: we needed in the shortest possible time a simple simulator that has good integration with ROS and all the necessary tools to create a virtual copy of our car. To solve our problem, it was necessary to simulate the operation of various sensors (lidars, cameras, inertial navigation system, etc.), control and dynamics of a car, traffic lights and pedestrians. All this was present in Gazebo in the form of plugins.
To create a virtual backup for an unmanned vehicle, we took its 3D model and set the basic kinematic and dynamic parameters for it - the mass of the car, the clutch of the wheels, the minimum turning radius, etc. Then we equipped it with virtual copies of all the sensors we use and set parameters identical to the characteristics of their real prototypes.
To create virtual training grounds in Gazebo, we use terrain maps built in the real world - all objects are placed at the same positions as in reality. At the same time, we transfer to the simulation: the road network, traffic signs, railway crossings, traffic lights and the main participants in the traffic - pedestrians and cars.
For example, this is the model of the autopolygon used by us to prepare for the qualification of the technological competition “Winter City” :
During the preparation, the virtual double of an unmanned vehicle repeatedly overcome various routes on a virtual training ground.
If you look at the created polygon, several questions may arise: why is such a low realism? Where are the houses, falling snow, trees, etc.? In this case, such details are redundant and absent, because the simulator should reflect only those aspects of the real world that are most important for the current software system. Adding redundant aspects would require significantly more time than the savings from using the simulator. It is important to remember that the final setup and tests are carried out on a real car.
Using the Gazebo simulator gave us a number of advantages during the development process. Nevertheless, we highlighted a number of shortcomings that are becoming more and more significant in the process of developing the unmanned StarLine car. Significant disadvantages of Gazebo include:
- errors in the operation of the vertical rays of 3D lidars when calculating them on a video card;
- lack of tools for automatic generation of urban infrastructure and road scenarios;
- low realism simulating car dynamics;
- low photorealism;
- lack of simulated weather conditions.
In this regard, we plan to change the simulator used, if by the end of the year Gazebo remains at the same program level.
Also in the future, we plan to create fully automatic and continuous testing of all StarLine smart car software in a simulation deployed on a remote server. This will allow you to accumulate virtual kilometers for each version of the software and be sure that each developed algorithm has been thoroughly tested before being implemented in a real unmanned vehicle.