Helper scripts in several demos print null, fail on a fresh start or watch the wrong entity

[bburda]

Description

I ran every demo from a fresh build (--no-cache --pull, current main of this repo and of ros2_medkit). All CI smoke tests pass. The helper scripts that a user runs by hand have six problems that CI does not see:

1. Explorer scripts print null. sensor_diagnostics/check-demo.sh, moveit_pick_place/check-entities.sh, turtlebot3_integration/check-entities.sh and turtlebot3_integration/check-faults.sh read fields the API does not return:
   • data IDs imu, fix, scan map to topics /imu, /fix, /scan with no publisher; the sensors publish on /sensors/imu, /sensors/fix, /sensors/scan
   • message fields are read from the top level; the message is under .data
   • list items only carry id, name, type, description, href, x-medkit, so area, category, is_located_on and hosted_by are always null
   • /configurations list items have no value
   • fault items carry fault_code, reporting_sources, description, last_occurred; the scripts read code, reporter_id, message, timestamp
   • with active faults, check-demo.sh prints "Faults exist but none provide both 'entity_id' and 'code'" and skips the snapshot and bulk-data sections
2. multi_ecu_aggregation: the first script on a fresh ECU fails with Node not found. The container scripts call ros2 param set. The first call in a container where the ros2 daemon is not running yet does not see the nodes. On a cold actuation_ecu, three calls in a row returned 1, 0, 0. After a fresh run-demo.sh, the first inject-* or restore-normal.sh fails, and restore-normal.sh stops before it resets the actuation ECU.
3. moveit_pick_place/move-arm.sh does not reach the container when ROS 2 is sourced on the host. It decides "I am inside the container" when ros2 node list exits 0, and that command exits 0 on an empty graph too. With /opt/ros/jazzy on PATH, ./move-arm.sh ready fails with The passed action type is invalid.
4. moveit_pick_place/move-arm.sh prints "Done" for goals that were aborted. pick_place_loop sends goals to the same controller all the time, so manual goals are often preempted (Current goal preempted by new incoming action, status ABORTED). The script prints ✅ Done and exits 0 anyway.
5. turtlebot3_integration/setup-triggers.sh watches the wrong entity. It creates the trigger on apps/diagnostic-bridge, but the fault from the suggested ./inject-nav-failure.sh (NAVIGATION_GOAL_ABORTED) is on apps/anomaly-detector. The watcher gets no events.
6. ota_nav2_sensor_fix/run-demo.sh talks about TurtleBot3. The header comment and the Foxglove hint say TurtleBot3; the image builds the Robotnik RB-Theron.

Steps to Reproduce

1. cd demos/sensor_diagnostics && ./run-demo.sh, then ./inject-noise.sh, then ./check-demo.sh: sections 5-8 print null and the snapshot sections are skipped.
2. cd demos/multi_ecu_aggregation && ./run-demo.sh, wait for the gateway, then ./inject-sensor-failure.sh && ./restore-normal.sh: one of them fails with Node not found.
3. source /opt/ros/jazzy/setup.bash, start the moveit demo, run ./move-arm.sh ready.
4. Run ./move-arm.sh demo a few times while the demo runs and compare the printed goal status with the ✅ Done lines.
5. cd demos/turtlebot3_integration && ./run-demo.sh, then ./setup-triggers.sh, ./watch-triggers.sh <id>, ./inject-nav-failure.sh and ./send-nav-goal.sh: no event arrives.

Expected vs Actual Behavior

Expected: the explorer scripts show real values, every script works on the first run after start, move-arm.sh drives the container arm and reports the real goal result, the trigger fires for the suggested fault, and the text names the right robot.

Actual: as listed above.

Environment

• OS: Ubuntu 24.04 (WSL2), Docker 28.4
• ROS 2 Distro: Jazzy (inside the demo images)