Simulation and Testing - Challenges of the Driverless Project

In the 2017 season, TU Darmstadt Racing Team decided to participate in the Formula Student Driverless. Since 2017, two Formula Student racing cars have been built each year, one of them driving completely autonomously. From the overall complex of the different challenges in the development and application of the vehicles, the special contents in the area of simulation and testing in the Driverless discipline are presented in the following.

Motivation and Challenge

The "Lambda-D2019", this year's driverless vehicle from TU Darmstadt for the Formula Student, has to compete in the four dynamic disciplines called Acceleration, Skidpad, AutoX, and Trackdrive as part of the competition. The Acceleration trial means a pure acceleration race at 75 m. In the Skidpad classification, the lateral forces of the racing car are tested while driving on a course that is reminiscent of a recumbent "8". The AutoX trial offers a circuit of up to 500 m in length. It is driven exclusively on sight because the vehicle does not know the route, since no previously created route map may be used. Ten laps on the track of the AutoX describe the Trackdrive classification. In this discipline, however, a map created in AutoX may be used, allowing the car to follow an optimized race line.

The entire racing team of the TU Darmstadt consists of 35 people, of which 15 are in the Driverless category. Since the test time with the vehicle is usually very limited, an essential challenge is to work out alternative options that allow testing of individual systems and algorithms beforehand. For pre-tests, there are generally two approaches: Either recorded or simulated sensor data during a trip can be given to the autonomous system as input. In this way, the developers can at any time test and validate the individual components of the system on the computer. To be able to record the most realistic possible data, the team of TU Darmstadt developed a system called RosCar last season, Figure 1. For this, a standard Kettcar was equipped with all sensors and arithmetic units which will later be installed in the racing car. This allowed the recording of data even before the completion of the vehicle. In this way, however, only an open loop can be tested. This means that the actions of the autonomous system do not affect the sensor data. A closed-loop simulation was therefore developed last season.

Figure 1

LambdaD-2018 (left) and rebuilt Kettcar RosCar for data acquisition (right) (© TU Darmstadt Racing Team)

Race Car

The Lambda D2019 is the third driverless vehicle of TU Darmstadt. It is based on the Lambda with electric rear-wheel drive developed in 2016 and has been equipped with a steering and brake actuator as well as sensors and computing units for the Driverless category. Installed are two 360° lidar sensors and a stereo camera with a resolution of 2k for the detection of the pylons and wheel speed sensors, a correlative optical sensor (Correvit sensor) and an Inertial Measurement Unit (IMU) for the state estimation. Through the combination of lidar and camera, the distance and color of the pylons can be very accurately recognized and processed. The system uses Linux 16.04 LTS as an operating system. This is ROS Kinetic, an open-source robot middleware that provides many useful tools and the ability to connect each system component. For the calculation, a standard, self-configured computer (i7 8700k CPU, 32 GB RAM and a GTX 1060 graphics card) is used. The hardware was mounted in the side boxes, Figure 2. The Lambda-D2019 now has a total weight of 233 kg with all components of the autonomous system.

Figure 2

Side box of LambdaD-2019 with built-in computer (© TU Darmstadt Racing Team)

Simulation

The simulation creates a complete environment model in which all sensors are simulated. As a result, sensor data, as generated by the lidar in the real vehicle, is generated. The special feature here is that the complete autonomous system can be tested from the detection of the pylons to state estimation. In ROS, an open-source simulation environment called Gazebo is already well integrated, which greatly simplifies the implementation of the simulation into the autonomous system, Figure 3. Another highlight is that the simulation can run completely on the vehicle and thus uses its infrastructure. This achieves the same latencies between different computing units (excluding sensors) as would occur during real travel.

Figure 3

Gazebo simulation (bottom left) with visualization of the autonomous system (© TU Darmstadt Racing Team)

All this allows completely simulated testing of the autonomous system. In the next season a complete automation of the simulation will be worked on. Overnight different scenarios can be simulated and in the morning there is a report on the result.

Test Cycle

Unfortunately, simulations cannot fully reflect reality. Therefore, the team of TU Darmstadt has introduced the so-called pushing method. In this case, after successful simulation, the vehicle is pushed through the scenarios set up in reality. In addition to the autonomous system, only the built-in steering actuator is active and steers the vehicle independently through the course. The values for the requested acceleration and speed can be viewed and checked in real-time. Through this intermediate step, errors can be detected and corrected so that the vehicle is ready for use on the day of the test. After successful pushing, the car can also be tested on the test bench with an active tractive system. Another advantage is that the race car can be pushed in front of the workshop and no extra locked area for the test operation is necessary. With the help of this method, larger errors can often be detected and rectified at an early stage. After successful pushing test, the system can be investigated under completely real conditions.

Testing

The test phase is one of the most labor-intensive times in Formula Student. It can be divided into the following areas: preparation, testing, and follow-up. The preparation begins on the first day of the season. In the season schedule, the testing must be planned early on, not only to test at the end of the racing car but also to be able to check individual components during the season. Furthermore, the preparation includes the collection and evaluation of test plans. Each member of the team creates test plans, which contain the implementation and necessary structures for testing its assembly. The challenge now is to organize and sort these test plans so that they can be tested as efficiently as possible.

Before the actual test day, there are still more tasks to do. The day before, everything is prepared so that it can start the next day directly with the tests. This means that all necessary items such as pylons, tools and other equipment have to be packed. The evening before, all mechanical components will be checked and software tests will be carried out as far as possible. Once it has been ensured that everything is working properly, the vehicle can also be loaded.

The test day starts early in the morning. As a rule, up to ten people are involved in a test day. At the beginning of the briefing, the tasks are distributed and the goals of the day are recorded. Thereafter, the tests and the telemetry are set up by the respectively assigned persons. Telemetry is a very important part of testing. With it, it can be tracked in real-time what the racing car is currently doing or would like to do. For this purpose, the team of TU Darmstadt developed a telemetry station this season, Figure 4, a portable box with all the important components. This is designed for the Driverless project because on the one hand the autonomous system and on the other hand the vehicle data must be monitored. The telemetry station can also be used in the Electric category of Formula Student. The highlight here is the ease of use. Since everything is integrated into the station, it can be invited directly without forgetting the essential parts. During the entire test day, the telemetry station keeps a protocol. The protocol records all important decisions, parameters and events to evaluate them later.

Figure 4

Telemetry station (seen from the front) (© TU Darmstadt Racing Team)

After a test day, the follow-up begins, which usually takes two to three days to complete. The vehicle is checked and any errors that have occurred are rectified. For the postprocessing software, the log and the recorded data is evaluated. These can then be used to derive the tasks for the next two to three days before another test day is scheduled again.

Outlook

For the season 2019/2020, the members of the Driverless category have already considered new topics. The concept of the RosCar will be further developed. In the 2019/2020 season, a radio-controlled model car in the scale 1:6 is to be used, which has all the sensors and functions of the newly developed race car. This makes it possible to test many components beforehand. This applies to both hardware (for example boards) and software. Furthermore, the automation of the simulation and the automatic evaluation of recording data will be worked on. The latter should output important data directly for an evaluation.