turtlebot3: run the simulator, the map and the pose in the same place

[bburda]

Description

Three settings had drifted apart in the headless turtlebot3 profile, and together they stopped the
demo from navigating at all. Each one hid the next, so they had to be found in order.

The simulator was never given the world. gz_args was passed as separate tokens, and launch
joins those with no separator, so gz started with one glued argument:

gz sim -r-s-v2/opt/ros/jazzy/share/turtlebot3_gazebo/worlds/turtlebot3_world.world

No sensor data reached ROS, so AMCL never published the map to odom transform, the global costmap
could not activate, planner_server sat in Activating for 68 seconds and the lifecycle manager
gave up on the whole stack:

[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 bring up all requested nodes. Aborting bringup.

The map was in the wrong place. turtlebot3_world.yaml carried origin: [-1.76, -2.42] while
the map.pgm it points at ships in turtlebot3_navigation2 with origin: [-10.0, -10.0]. The map
landed about eight metres from the robot, so the spawn point at (-2.0, -0.5) sat outside the map
rectangle. This one only bites once the pose below is right: Nav2 plans from the estimated pose, and
the old configuration estimated (0, 0), which was still inside the old bounds. With the pose
corrected and the origin still wrong, every plan is refused before it starts:

[planner_server]: GridBased plugin failed to plan from (-2.00, -0.50) to (-1.00, -0.50):
  "Start Coordinates of(-2.000000, -0.500000) was outside bounds"

AMCL started somewhere the robot is not. It was configured at (0, 0) while the robot spawns
at (-2.0, -0.5). Headless has no RViz to set the pose by hand, so the covariance stayed high and
the robot could not follow a path.

Related Issue

closes #75

Testing

New tests/smoke_test_navigation.sh runs in the existing turtlebot job, on the stack that job
already starts, so it costs no extra build. Measured against a running demo, 10 passed and 0 failed:

bt-navigator, planner-server, controller-server, amcl   all reach active
lifecycle manager                                        brings up every node
anomaly detector                                         registered, so an empty fault list means something
robot                                                    inside the global costmap
sensor origin                                            inside the map
two goals, the second back to the spawn point            accepted, then completed
localization                                             not wrong at error severity

Each fix was then reverted on its own, to check the test fails when the bug comes back:

gz_args back to separate tokens   5 FAIL  lifecycle x2, bringup, goal rejected, goal not completed
map origin back to -1.76,-2.42    3 FAIL  robot outside costmap, sensor outside map, goal failed
initial_pose back to 0,0          2 FAIL  both goals stop completing

The localization check is a guard against AMCL losing the robot altogether, not the check that pins
the initial pose: under that last mutation the goals fail while it still passes. It keys on error
severity on purpose, because a healthy drive touches a covariance of 0.307 against the detector's
warn threshold of 0.300, and failing on that would turn the demo doing its job into a red build.

The second goal is there because the goal checker's xy_goal_tolerance is 0.25 m: with one goal the
robot ends up standing on it, and a second run against the same container reported success without
moving.

The existing tests/smoke_test_turtlebot3.sh still passes 49 of 49 on the same stack, including
after the shared smoke library gained request timeouts.

One thing outside this branch: the spawn point stays configurable through x_pose and y_pose
while the AMCL pose is a fixed value in the parameter file, so overriding the spawn recreates the
mismatch. That coupling predates this change and is not addressed here.

Benchmark baselines for this demo are no longer comparable with older runs, because the simulator
and the navigation stack now actually run.

With all three in place the demo raises its navigation faults for real for the first time: a goal
sent while the stack was misconfigured produced NAVIGATION_GOAL_ABORTED from
/bridge/anomaly_detector/goal_status through the detector itself, not through injection.

Checklist

• Tested locally
• README updated (if needed)

[mfaferek93]

smoke_lib.sh:8 has set -euo pipefail and this assignment has no || true, so one curl timeout or connection reset ends the whole script (reproduced with an unreachable port: rc 7, "exited abnormally") instead of the goal being recorded as failed. lifecycle_state at 78-81 already captures the body first with || true; same pattern here.