turtlebot3 headless: no simulation data reaches ROS, Nav2 bringup aborts

[bburda]

Description

In the headless profile the turtlebot3 demo never gets simulation data into ROS, so Nav2 never
finishes its bringup and the robot cannot navigate at all.

The gateway shows empty topic lists for both ros_gz_bridge and turtlebot3-node, even though
Gazebo reports the robot was spawned and the bridge announces its topics at startup:

[create-2] [INFO] [ros_gz_sim]: Entity creation successful.
[parameter_bridge-3] [INFO] [ros_gz_bridge]: Creating GZ->ROS Bridge: [scan (gz.msgs.LaserScan) -> scan (sensor_msgs/msg/LaserScan)] (Lazy 0)
[parameter_bridge-3] [INFO] [ros_gz_bridge]: Creating GZ->ROS Bridge: [odom (gz.msgs.Odometry) -> odom (nav_msgs/msg/Odometry)] (Lazy 0)

Without /scan, AMCL never publishes the map to odom transform. It does load the map and set
its initial pose, so the problem is upstream of AMCL:

[amcl]: Received a 384 X 384 map @ 0.050 m/pix
[amcl]: initialPoseReceived
[amcl]: Setting pose (0.000000): 0.000 0.000 0.000

From there the failure cascades:

[global_costmap.global_costmap]: Timed out waiting for transform from base_link to map to become available,
  tf error: Invalid frame ID "map" passed to canTransform argument target_frame - frame does not exist
[global_costmap.global_costmap]: Failed to activate global_costmap because transform from base_link to map
  did not become available before timeout
[lifecycle_manager_navigation]: Failed to change state for node: planner_server
[lifecycle_manager_navigation]: Failed to bring up all requested nodes. Aborting bringup.

planner_server sits in Activating for 68 seconds before the manager gives up. Because the
manager aborts the whole bringup, planner_server and bt_navigator stay inactive, and any
navigation goal is refused with "Goal rejected by action server".

Two likely causes are already ruled out:

• Gazebo is not paused. The launch file passes -r in gz_args.
• AMCL has an initial pose. nav2_params.yaml sets set_initial_pose: true.

That leaves the gz to ROS topic mapping in the bridge as the place to look.

This also means the demo never produces the navigation faults it is built to show
(NAVIGATION_GOAL_ABORTED, NAVIGATION_GOAL_CANCELED, NAVIGATION_NO_PROGRESS). CI does not
catch it because tests/smoke_test_turtlebot3.sh deliberately does not navigate.

Steps to Reproduce

1. cd demos/turtlebot3_integration
2. docker compose --profile ci up -d --build turtlebot3-demo-ci
3. Wait about 60 seconds, then read the lifecycle state of the Nav2 nodes:
   curl -s -X POST http://localhost:8080/api/v1/apps/bt-navigator/operations/get_state/executions -H 'Content-Type: application/json' -d '{"parameters":{}}'
4. docker compose --profile ci logs turtlebot3-demo-ci | grep -i "Aborting bringup"

Expected vs Actual Behavior

Expected: all Nav2 lifecycle nodes reach active and a navigation goal is accepted, so the demo
can produce its navigation faults.

Actual: bt_navigator and planner_server stay inactive, the lifecycle manager logs
"Failed to bring up all requested nodes. Aborting bringup.", and goals are rejected.

Environment

• OS: Ubuntu 24.04 (container)
• ROS 2 Distro: Jazzy

Reproduced twice on an otherwise idle machine, using the CI image and the CI launch command, so it
is not resource starvation.