Page 115 - The ROV Manual - A User Guide for Remotely Operated Vehicles 2nd edition

subsea environment. Most systems support multiple camera outputs and split screen to simulate multiple camera views that may simultaneously be available on the ROV system.
Dynamics module
A DM is dedicated to computing the motion of the ROV and other scenario objects. The vehi- cle’s reaction to various programmed parameters will simulate motion according to operator- commanded thruster forces along with collisions with obstacles and environmental forces acting upon the vehicle and components (e.g., body, manipulators, umbilical cable, and other appendages). It broadcasts object positions and orientations to the display modules along with forces to integrated engineering applications. These outputs are recorded for use in the pilot performance evaluation. All objects are provided with a dynamics configuration file that contains all of the relevant physical parameters having impact upon the movement of (and interaction between) scenario objects.
The lack of visual cues in the camera displays due to dirt kick-up (as the result of (or punish- ment for) hitting the seafloor) or engaging thrusters while too close to the bottom can result in sloppy piloting. How well a simulator performs as a generic or mission-specific training (and par- ticularly as an engineering support) tool is predominantly dependent in its dynamics engine—the heart of any simulator system. Off the shelf hardware (particularly video cards) can enable any sys- tem to provide good effects with a high refresh rate for a large number of polygons (which are the building blocks that 3D models are made of).
It is the DM that processes and translates operator control commands into forces in the context of the objects and environment around the ROV system. It is the complexity of the models (as well as the speed/accuracy with which the module processes this) that determines the realism of the sim- ulation. Thus, the effectiveness with which the module is able to provide positive training and reli- able verification of operator performance may be measured for employee evaluation and mission achievability. The DM performs its task behind a cloak of secrecy masked by the video (and sonar) displays. The next section provides a look behind the curtain at this most critical of elements.
4.2.2 Physics simulation
A core requirement of an ROV simulation provides that after every step of the simulation, all of the components of that simulation (i.e., the objects being simulated) are in plausible locations and orientations. To maximize the possible range of scenarios developed (thus reducing developer workload), a stand-alone physics package is often utilized for handling position and orientation updates. These scenarios are then compounded into a single world transform (Figure 4.7). This package, commonly referred to as a “physics engine,” is software that provides an approximate simulation of certain physical systems such as rigid body dynamics (including collision detection), soft body dynamics, and fluid dynamics. These are extensively used in the fields of computer gra- phics, video gaming, cinema special effects, and high-performance scientific simulation. While their main uses have been in the gaming industry (typically as middleware), they have come to be increasingly relied upon by various engineering disciplines. For example, the European Space Agency uses the PhysX library for verification of the Mars sample rover for the ExoMars Program tentatively slated to investigate the Martian environment.
From a programmer’s point of view, the physics engine handles all calculations required to update every object’s transform after each simulation step (Figure 4.8). This includes integrating
4.2 Simulation 103