local_costmap does not respect the use_sim_time parameter

[david-wb]

Bug report

The /local_costmap/local_costmap node does not respect the use_sim_time parameter.

Required Info:

• Operating System: Ubuntu 22.04
• ROS2 Version: Humble
• Version or commit hash: ros-humble-navigation2 1.1.14-1jammy.20240407.041637
• DDS implementation: Cyclone

Steps to reproduce issue

1. In the nav2_params.yaml file, set use_sim_time: True for local_costmap

   local_costmap:
   local_costmap:
     ros__parameters:
       use_sim_time: True

2. Launch the simulation
3. Run

   $ ros2 param dump /local_costmap/local_costmap
   /local_costmap/local_costmap:
   ros__parameters:
   /bond_disable_heartbeat_timeout: true
   always_send_full_costmap: true
   clearable_layers:
   - obstacle_layer
   - voxel_layer
   - range_layer
   filters: []
   footprint: '[]'
   footprint_padding: 0.1
   global_frame: odom
   height: 8
   inflation_layer:
     cost_scaling_factor: 3.0
     enabled: true
     inflate_around_unknown: false
     inflate_unknown: false
     inflation_radius: 0.6
     plugin: nav2_costmap_2d::InflationLayer
   lethal_cost_threshold: 100
   map_topic: /map
   observation_sources: ''
   obstacle_layer:
     combination_method: 1
     enabled: true
     footprint_clearing_enabled: true
     max_obstacle_height: 2.0
     min_obstacle_height: 0.0
     observation_sources: scan
     plugin: nav2_costmap_2d::ObstacleLayer
     scan:
       clearing: true
       data_type: LaserScan
       expected_update_rate: 0.0
       inf_is_valid: false
       marking: true
       max_obstacle_height: 2.0
       min_obstacle_height: 0.0
       observation_persistence: 0.0
       obstacle_max_range: 2.5
       obstacle_min_range: 0.0
       raytrace_max_range: 3.0
       raytrace_min_range: 0.0
       sensor_frame: ''
       topic: /scan
   origin_x: 0.0
   origin_y: 0.0
   plugins:
   - obstacle_layer
   - inflation_layer
   publish_frequency: 10.0
   resolution: 0.05
   robot_base_frame: base_link
   robot_radius: 0.6
   rolling_window: true
   track_unknown_space: false
   transform_tolerance: 0.3
   trinary_costmap: true
   unknown_cost_value: 255
   update_frequency: 10.0
   use_maximum: false
   use_sim_time: false
   width: 8

Expected behavior

The ros2 param dump should show use_sim_time: true and the local costmap should update in rviz as the robot moves.

Actual behavior

The ros2 param dump shows use_sim_time: false, and the local costmap fails to update in rviz as the robot moves.

[padhupradheep]

Hey, it could probably that, in the launch file, the use_sim_time param might be set to false. Could you please check that?

[david-wb]

@padhupradheep No, there is not a single instance where use_sim_time is false in my repo.

[tonynajjar]

Can you report the value of use_sim_time for the global_costmap, controller_server and planner_server? The costmaps inherit this parameter from the controller and the planner nodes. See here

[david-wb]

They all show use_sim_time: false. But I set use_sim_time: True for every config in the nav2_params.yaml.

[tonynajjar]

Weird, the next step would be to try to reproduce on our side.

Launch the simulation

Can you send the exact command you ran? (along with any other setup-specific stuff we should know about)

[david-wb]

If I pass use_sim_time = true to the nav2 bringup, finally everything uses sim time. It seems this global parameter always overrides the params file, even when unset.

    bringup = IncludeLaunchDescription(
        PythonLaunchDescriptionSource(bringup_share + "/launch/bringup_launch.py"),
        launch_arguments={
            "params_file": os.path.join(pkg_share, "config/nav2_params.yaml"),
            "map": os.path.join(pkg_share, "config/map.yaml"),
            "use_sim_time": "True",
        }.items(),
    )

[SteveMacenski]

@david-wb can you reproduce using the nav2_bringup as the example, not your custom files? That helps us isolate potential problems to bugs in the stack vs bugs potentially present in your custom use. For example, when you launch with use sim time as true/false, do you still see that issue with our default bringup? https://github.com/ros-navigation/navigation2/blob/main/nav2_bringup/launch/tb3_simulation_launch.py

[david-wb]

Sure, here is the simplest way I can reproduce the issue.

Run

ros2 launch nav2_bringup bringup_launch.py map:=/opt/ros/humble/share/nav2_bringup/maps/turtlebot3_world.yaml

This will use the default nav2 params which have use_sim_time set to True for the /amcl node.

But the actual value is False:

$ ros2 param get /amcl use_sim_time
Boolean value is: False

It seems the use_sim_time param of bringup_launch.py overwrites whatever is present in the params file, even when it is unset. Maybe this is by design, but it means the values of use_sim_time in the params file are always ignored, which is a bit confusing.

[SteveMacenski]

I just tested

ros2 launch nav2_bringup tb3_simulation_launch.py

steve@reese:~/Documents/navigation2_ws$ ros2 param get /amcl use_sim_time
Boolean value is: True

and

ros2 launch nav2_bringup tb3_simulation_launch.py use_sim_time:=False

steve@reese:~/Documents/navigation2_ws$ ros2 param get /amcl use_sim_time
Boolean value is: False

So this appears to be working in main. Humble's branch is a little different in the use sim time handling, so make sure to use the files from humble to base your launch and nav2 yaml configuration files based off of. If you mix and match you will run into issues since the use sim time handling between the main branch and humble was fundamentally refactored. From experience, I know some users have had issues mixing and matching branch config/launch/nodes so just want to point that out and ask that you test that.

[david-wb]

The problem is that the launch file will always override whatever is in the params file for the use_sim_time param. It is not an issue for me now that I am aware of it.

[SteveMacenski]

Yes, this is the case. use_sim_time has always been a "special" parameter that has unique considerations. You can however remove the setting of use_sim_time from your launch files so that it only uses what's in the param files, which should be straight forward.

Does that answer you question?

[david-wb]

Yup, all good thanks.