The Co3-AUVs simulator is designed with a double objective, first to be used for prototyping and testing our research and developments, second as an appealing 3D graphical animation in order to enlarge the outreach of the results to a non technical audience. Furthermore, the simulator is intended to be fully open source and supported by a reasonable tool chain for environment, object, and robot modeling.
In year 1 of the project, a study was made to assess the different options for the simulator including the usage of already existing simulation packages to start with. Based on this study, the decision was taken to follow the road in between a completely new development and using already established simulators, namely to develop something based on well established software packages for 3D visualization. Concretely, the simulator is implemented using the Bullet Physics Library as the physics engine and the Object-Oriented Graphics Rendering Engine (OGRE) as rendering engine.
A major component of simulation of ranging sensor data is being able to perform ray tracing in the simulated environment. Due to this, the ray tracing capabilities of commonly used simulator and rendering engines were benchmarked. These included USARSim, a robot simulator widely used in the RoboCup Rescue Virtual Competition but also for underwater robotics, Object-Oriented Graphics Rendering Engine(OGRE), a popular open source graphics rendering engine used in commercial titles, and the Bullet Physics Engine, an open source physics engine used in several commercial applications. Empirically, it was found that Bullet outperforms both OGRE and USARSim in number of raytraces clocking 70000 raytraces per second in one thread, compared to 15000 raytraces for OGRE, and 40000 raytraces for USARSim using multiple threads.
Due to its clearly superior ray tracing capabilities, the Co3-AUVs Simulator
uses Bullet as the physics engine, and OGRE as the rendering engine. The
simulator uses a modular design and the different components are decoupled.
Interaction between different components is implemented using the listener
pattern. Listeners are registered to their respective modules at startup.
Whenever changes are made to a component, it propagates them by calling
the appropriate function on all registered listeners. This structure allows
interchangeability in the different modules, and allows for distribution
of the different components across different machines without affecting
the architecture. For example, numerous rendering engines can be implemented
as separate listeners, without