3.7.1 Gazebo Simulation (Old)
This package is responsible for the AUV simulation using Gazebo Ignition software. It is divided into:
- assets: contains .sdf and .dae files representing virtual models of the objects used in the competition (e.g., Clarke, tasks' props, pool)
- launch: contains a launch file for each world and one general file (sim.launch) that creates a bridge between Gazebo Ignition and ROS topics
- src: performs data manipulations using topics' data from both sides (Gazebo and ROS), so that the messages are formatted correct.
- worlds: contains the environments (=worlds) for each task. It uses the models from the assets folder and adds physics calculations to the simulation.
This file is responsible for modelling clarke's thrusters, physics properties, and sensors.
It starts by creating a model. The model element defines a complete robot or any other physical object. An SDFormat file can consist of just one model. To understand what each tag does in model, you should check this link.
We use the sensor tag to add a new sensor to a link or joint. Each tag describes one sensor, and you need to import the corresponding plugin (at the end of the file) to use it. A plugin is simply a dynamically loaded chunk of code. So, a plugin for a specific sensor is a chunk of code that collects certain data from the simulation in the same way as the sensor in the real world would.
A joint connects two links with kinematic and dynamic properties. By default, the pose of a joint is expressed in the child link frame. There are multiple types of joints, but we only use revolute joints considering our robot. A revolute joint (or hinge joint) rotates on a single axis with a fixed range of motion.
sim.launch is responsible for launching other packages (controls, propulsion, vision, and state estimation) as well as creating the bridge node between Ignition Gazebo and ROS topics.
The bridges follow the same structure:
<node name="node_name" pkg="ros_ign_bridge" type="parameter_bridge" output="screen"
args="/topic_name@msg_type_in_ROS@msgs_type_in_Ignition">
</node>
Note that the topic name has to be the same in ROS and Gazebo for the bridge to work. If you need to change the name, you can add the remap option:
<remap from="/vision/front_cam/image_rgb" to="/vision/front_cam/color/image_raw"/>
bridge.py is responsible for:
- Taking the thruster message from ROS topic /propulsion/thruster_forces and distributing to each thruster bridge topic.
- Receiving data from the sensors and properly formatting the it based on the ROS messages, such as SbgEkfQuat. It then publishes to the corresponding ROS topics.
- Converting coordinate frames from Gazebo sensors' frames to state estimation frames. Note that this transformation includes sensors' mount offset. The offset is a parameter received from the launch file.
There is one plug-in for the Clarke's hydrodynamic behavior. It requires the user to input a set of parameters based on the model's physics properties. In this section, we will discuss how we calculated those values and what they are for. The calculations can be found in the calculate_fossen.py file. For the description of the parameters, click here.
In the world files, we define the world's physics (common to all objects), such as buoyancy, configurate the GUI, and add (=include) and position the objects.
To include an object, you should use:
<include>
<uri>assets/quali/quali_gate/quali_gate.sdf</uri> <!-- relative path -->
<pose>3 -1 -1 0 0 1.5708</pose>
</include>
To run the sim with a mission, first launch a world in one terminal by roslaunch auv-sim-gazebo <world>.launch. In another tab, do rosrun planner <mmission>.py
- auv_msgs
- controls
- gazebo_ros
- geometry_msgs
- propulsion
- python3-numpy
- ros_ign_bridge
- ros_ign_gazebo
- rospy
- sensor_msgs
- state_estimation
- std_msgs
- tf
- vision