Issues with Automatic Model Insertion and Movement in Gazebo with ROS2

Question

I'm facing a peculiar issue with Gazebo and ROS2 integration, where a truck model does not move as expected when inserted into the environment automatically via a launch file, contrary to its behavior when inserted manually.

Environment

• ROS2 Iron
• Gazebo 11.10.2
• Ubuntu 22.04

Problem Description:

I have a custom world in Gazebo, which includes the Sonoma Raceway model. I also have a truck model (SDF format) that I need to insert into this world. When I manually insert the Sonoma Raceway model followed by the truck model into an empty Gazebo world, the truck can move without issues.

However, when I try to automate this process using a ROS2 launch file, where the world (with the raceway and truck models included) is loaded at the start, the truck does not move.

Attempts:

• Custom Ground Plane: I tried adding a custom ground plane with specific friction properties to the world file, but it did not resolve the issue.
• Delaying Truck Insertion: I experimented with delaying the truck model's insertion to simulate manual insertion (using time.sleep() in Python), but it was not effective.
• Adjusting Friction Properties: I modified the SDF files of both the raceway and the truck model to adjust friction properties, with no success.
• Launch File Modifications: I made several changes to the launch file to try different approaches for spawning the truck model, including using spawn_entity.py from gazebo_ros.

Code Samples:

World File: https://pastebin.com/w18v0ccm

Launch File: https://pastebin.com/ceqREdAs

Observations:

1. The truck moves as expected when inserted manually.
2. No error messages in the console that point to the cause.
3. The issue seems related to how the models are loaded into Gazebo via the launch file.

Request for Help:

I'm looking for insights into what might be causing this behavior and how to resolve it. Any suggestions on how to ensure the truck moves as expected when the environment is set up automatically would be greatly appreciated.

Additional Materials:

The video link below is showing the manual insertion and movement process and the automated setup (truck does not move issue) for better clarity.

Troubleshooting Movement Issues in Gazebo: Manual vs. Automated Model Insertion"

Thank you in advance for your time and assistance!

Answer 1

After extensive troubleshooting and fine-tuning of the ODE physics parameters within my Gazebo and ROS2 integrated simulation environment, I've identified a set of parameters that enabled movement for the truck model, albeit at a slower pace than expected. This configuration represents the best balance achieved between enabling movement and managing the simulation's responsiveness and realism within a complex terrain, specifically the Sonoma Raceway model integrated with a custom truck model.

Effective ODE Parameters Configuration:

<physics type="ode">
  <real_time_update_rate>1000.0</real_time_update_rate>
  <max_step_size>0.013</max_step_size> <!-- Smaller for more accuracy -->
  <real_time_factor>1</real_time_factor>
  <ode>
    <solver>
      <type>quick</type>
      <iters>100</iters> <!-- Reduced from 150 to potentially soften the simulation, lower to reduce computational load -->
      <precon_iters>0</precon_iters>
      <sor>1.4</sor> <!-- Lower to potentially reduce rigidity -->
      <use_dynamic_moi_rescaling>1</use_dynamic_moi_rescaling>
    </solver>
    <constraints>
      <cfm>0.001</cfm> <!-- Lower for a tighter simulation, reducing "sponginess" -->
      <erp>0.15</erp> <!-- Increase to ensure error correction is more effective -->
      <contact_max_correcting_vel>500.000000</contact_max_correcting_vel> <!-- Lower to reduce the aggressiveness of contact corrections -->
      <contact_surface_layer>0.01</contact_surface_layer> <!-- Lower to minimize penetration without increasing rigidity -->
    </constraints>
  </ode>
</physics>

These parameters facilitated the truck's movement using cmd_vel commands, although the motion was slower compared to simulations using less complex terrains (just default gazebo ground). It's important to note that when employing a trajectory planner to control the truck's movement, initial movement was observed but sustained motion was not maintained. This behavior suggests that the combination of complex terrain simulation and the computational demands of the path planner may lead to CPU overload (my 8 cores reached each one 98% of consumption within this terrain and 70% without it), affecting the truck's continuous movement.

Below is a video of this behavior:

Using Cmd_vel pub to move truck, 10 - 20 m/s

Trajectory Planner - Truck remains stuck

I am open to getting more optimum solutions!