How software-only simulation can make testing of AGV control software more cost-effective and efficient
Automating complex tasks with software is not easy in the industrial world – mistakes can lead to accidents that endanger valuable property or even the safety of people. Therefore, rigorous testing is required to avoid failures in the system. When testing software that controls expensive machinery, availability of physical equipment can become a bottleneck. What kind of solutions could software-only simulations enable?
In the field of industry, AGV (Automated Guided Vehicle) software testing can be difficult, as it is often dependent on expensive hardware, which is not always readily available. A reliable way of testing in a software-only environment saves both time and money, as there is no need to involve the heavy machinery for smoothing out the rough edges in the software.
In my master’s thesis, I examined the implementation of a lightweight simulation environment for the evaluation of software used to control automated guided straddle carriers. The simulator is based on Gazebo, an open-source robotics simulation software with support for multiple physics engines, which allows for advanced and flexible physics simulation.
Software-only simulation
Software-only simulation is an environment that utilizes the actual onboard navigation and control system, and implements a virtual device layer that communicates with the machine control system – just like real-world devices would.
For the software-only testing, all the existing onboard software and end-user interfaces can be used with the simulator without further modification. Test cases used for real-world machine testing can also be used for its virtual counterpart.
Gazebo as a tool
Gazebo is an open-source robotics simulator that supports many different physics engines and has a wide variety of different expandable sensor and controller implementations. Gazebo is able to react to the commands given by the machine control system and produce credible data.
If, for example, the control system issues the straddle carrier to drive forward and turn right, the command is propagated to Gazebo through the virtual device layer, which is used as a mediator between the two systems. Following this, the simulated machine does the work according to the instructions and at the same time continuously returns data from the simulated sensors. The data tells what is happening to the machine at that moment – for example, tire angle, velocity and so on.
Such data can be imported from Gazebo in a format that is understandable to humans, but not to the machine control system. For this reason, the obtained data is sent back to the virtual device layer, which converts the data into a format identical to what would be obtained from a real-life sensor.
Since the machine controller software is dependent on many hardware devices and actuators found in the physical vehicle, a requirement for a functional software-only environment was to implement a virtual device layer that imitates the functionality and communication interface of each device.
In practice, this means understanding the structure of the incoming and outgoing data for each connected device, and how it is expected to be handled in a way that the machine control system will believe it is communicating with real hardware.
