The Sandbox: the AVSandbox knowledge hub

One of the largest challenges facing software developers today is how to exhaustively test rapidly changing software to a deadline. Software built to run inside vehicles face hardware limitations with strict speed and architecture requirements. But while these requirements are necessary for deployment, development cycles can benefit greatly from the speed increases of simulation and test automation using intuitive software languages. Reducing setup time between tests in this manner allows more use cases to be tested and real time debugging, crucial to visualise bugs over time, to diagnose root causes efficiently.

So simulation can be useful, but where do we begin with supporting vehicle automation? Well a simulation, as Google will tell you, is an imitation of a situation or process. It is an imitation because calculating how objects move through the world takes time. Every simulation must adhere to a base simulation time step, a value configured by the system under test. For example, an engine that rotates thousands of times a minute requires a much smaller time step than an air conditioning unit to achieve comparable accuracy. But there are significant differences in the methods used for implementation as I will now explore.

Simulation Modes
In each step, the simulation calculates new states for all actors in the scene. The amount of time this takes depends on the solver type and the number and complexity of physics interactions and can be categorised as follows: The simulation is fixed step if it waits for the next time step before starting the new step and as soon as possible (ASAP) if the next step starts immediately.

Figure 1: Fixed Step vs ASAP Simulation

While ASAP simulation is usually quicker than fixed step for a given model, the synchronisation required to achieve this can be quite complex and may not work at all if interfacing with software or hardware that requires strict real-time behaviour. Fixed step synchronisation can be simpler, however the danger here is that a very computationally demanding step may take more than its allocated time and overrun, as occurs in the example above. This issue can be addressed by either taking some of the following time steps to solve the calculation or increasing the fixed step time at the cost of simulation speed. If the time step is much smaller than the time required to calculate the step, the step may be missed entirely. Real time applications especially then, should be designed with the most time-consuming scenarios in mind to avoid overruns.

So the simulation can run at different time steps, but its constituent parts, the physics and graphics updates, can also run at different time steps either synchronously or asynchronously. Asynchronous mode allows each part of the simulation to run at its own speed, useful for running real time hardware, driver, or vehicle in the loop testing. Synchronous mode waits for all elements of the simulation to be ready before beginning the new step. One of the main features of the latest release of rFprois a mode called Synchro-Step which allows users to do just this to give fully deterministic simulation. Synchronising the simulation in this manner allows the simulation to run faster than real time, perfect for large scale testing on powerful computers, or slower than real time to test high definition models. Changing the number of simulation instances and the number of computers they run on, gives complete control to optimise performance.

The Vehicle Control Cycle
The Vehicle Control Cycle shown below, defines the flow of information between the vehicle and environment. The Vehicle Control is represented by two processes, the Object Detection and Decision Making blocks. These interface with the Environment using the Sensor Suite and Vehicle Actuation and transfer data as annotated by the arrows.

The Environment
The Environment is a physics engine in which scenarios are rendered and conducted. Each scenario contains a world or location which includes all the scenery and lighting and may be populated by actors including vehicles, pedestrians and other dynamic objects. The scenery includes the road network and road infrastructure such as traffic lights. Actors may have paths to follow over the duration of the simulation, which is often defined in a scenario description language such as OpenScenario.

Each sensor has a type, position, direction and field of view in the environment and outputs data that can be read by the vehicle controller. Commonly the vehicle actuation commands are steering, throttle and brake with controls such as the indicator, gear selection and the ignition key optional.

Vehicle Control
The Object Detection and Decision Making process all the data from the environment through the Sensor Suite. The object list output format from the object detection consists of all actors and road network information with influence over the Decision Making.

A base time step of 1ms is common for vehicle simulation, but individual models are often allocated longer, such as updating the vehicle position which may be calculated 100 times a second. By simply multiplying by the velocity, say 40m/s, we can find the expected distance travelled in this time to be 0.4m. Whether this gives sufficient detail is dependent on the task, and the time step can be modified accordingly.

Written by Rob Smith – Project Engineer

Please get in touch if you have any questions or have got a topic in mind that you would like us to write about. You can submit your questions / topics via: Tech Blog Questions / Topic Suggestion