Low WAMV Speed/RTF

[merebloss]

Describe the bug
While running our team's algorithm for one of the 2023 tasks, it was noted that despite no change in the specified minimum and maximum speed from last year, the WAMV does not move as quickly as in the prior version of Gazebo/ROS.

This reduced speed persists even when the VRX simulation is run headless and when the boat is controlled by publishing a thrust value of 1 to both the right and left thrusters (in the default configuration) to rule out the possibility that our solution is slowing it down.

Expected behavior
The expected result of publishing a thrust value of 1.0 to both thrusters would be the WAMV traveling at max speed and thus reducing the distance between the goal position and the starting position quickly. However, the change in pose error (as a stand-in for speed) reduces very slowly (~0.005 at each time step when run without the GUI) as compared to doing a similar test in the 2022 environment.

There is a very low (25%) real-time factor when running Gazebo with the GUI enabled, but I expected this to have less of an impact when running the simulation without the GUI. I am not sure if this issue is related to the low RTF mentioned in another issue earlier.

To Reproduce
List the steps to reproduce the problem:

1. Launch VRX environment (e.g. ros2 launch vrx_gz competition.launch.py world:=stationkeeping_task)
2. In the simplest test case, ros2 topic pub --once '/wamv/thrusters/right/thrust' std_msgs/msg/Float64 "data: 1.0" and ros2 topic pub --once '/wamv/thrusters/left/thrust' std_msgs/msg/Float64 "data: 1.0" (both thrusters actuate, as confirmed via the GUI, and the WAMV drives approximately toward the goal waypoint)

System Configuration:

• OS: Ubuntu 22.4 (on a laptop)
• ROS Version: ROS 2, Humble
• Gazebo Version: Gazebo Sim 7.0.0
• Graphics Card: UHD Graphics 620
• Are you using VRX or VRX Classic? VRX

[merebloss]

The maximum thrust value is no longer 1. Adding a scaling factor resolved this issue.