Example of scenario with the RexROV remotely operated underwater vehicle

Example of scenario with the RexROV remotely operated underwater vehicle

In this package, the model of an ROV (remotely operated vehicle) is available in the subpackage uuv_descriptions. For this vehicle, the hydrodynamic parameters used are published in Berg, 2012 and is implemented in this package with a different thruster configuration.

Starting the underwater world

To use this ROV, first it is necessary to load one underwater scenario. There are currently three scenarios available in this package and any of them can be chosen for this example.

The scenario empty_underwater.world contains basically a flat seabed, a texturized sea surface and blue fog. It can be started as follows

roslaunch uuv_descriptions empty_underwater_world.launch

A scenario with animated waves named ocean_waves.world uses OGRE shaders for a more realistic wave rendering and also includes a heightmap as part of the seabed. This scenario does not include blue fog. It can be started as

roslaunch uuv_descriptions ocean_waves.launch

Spawning the vehicle

After one of the scenarios was started, the vehicle can be added to the simulation. In this example, an instance of the RexROV model will be spawned. This is done by running

roslaunch uuv_descriptions upload_rexrov.launch x:=0 y:=0 z:=-20 mode:=default namespace:=rexrov

Notice that the initial position can be provided through the command line in case the vehicle is supposed to be spawned elsewhere in the world. The option mode refers to the vehicle configuration to be used: default starts the RexROV vehicle without any extra manipulator or sensor modules. By using mode:=sonar, for example, the RexROV will be started with a forward looking sonar. The option namespace can be used to give an unique namespace to the vehicle, which is useful in the case multiple instances of this model are created in one simulation. If the namespace option is not explicitly given, the name of the vehicle model is used by default (in this case, rexrov).

Note that the teleoperation node is set up such that the velocity reference is generated only while the deadman button is pressed. In the default configuration for the XBox 360 controller, the deadman button is the LB button.

Starting a velocity PID controller and teleoperation node

Once the vehicle has been spawned, a controller node can be used together with the velocity reference generated by a joystick to start controlling the vehicle.

One single launch file is already available for this:

roslaunch uuv_control_cascaded_pid joy_velocity.launch uuv_name:=rexrov model_name:=rexrov joy_id:=0

This launch file starts three ROS nodes: thruster allocation manager, velocity control and vehicle teleoperation. The thruster allocation manager from the package uuv_thruster_manager is responsible for calculation or for loading a thruster allocation matrix and distributing the control torques between all thrusters. The option model in this case allows the thruster allocation matrix node to look into the config folder in uuv_thruster_manager for stored configuration files and the coefficients of the thruster allocation matrix.

For the teleoperation node to work, the correct joystick index must be given. You can find out which index corresponds to the joystick you are using by installing jstest-gtk. It will provide a list of all devices connected to your computer as /dev/input/js<index>. This teleoperation node is configured for the XBox 360 controller. To check how a new joystick mapping can be given, check the launch file for the teleoperation node.

References

Berg, Viktor. "Development and Commissioning of a DP system for ROV SF 30k." (2012).