Robot deployment fixes: the bag recorder never launched, and identity resolution failed silently

[JohnYanxinLiu]

What features did you add and/or bugs did you address?

• Which GitHub issue does this address?

None — both bugs were found while porting fixes back from a real mocap-room Jetson
deployment. Independent of the OptiTrack stack (#374/#375/#376); can merge in either order.

• Additional description if not fully described in the GitHub issue

1. RECORD_BAGS=true never brought the bag recorder up on a robot.
robot-base-docker-compose.yaml has forwarded the variable since #318, but
logging_bringup/launch/logging.launch.xml hardcoded record_bag=false and
onboard_autonomy_all.launch.xml includes it with no arguments, so nothing ever overrode
the default. Only gcs.launch.xml read the variable — which is why the flag looks
functional if you only check the GCS.

The consequence is worse than "no bags": with no bag_record node running, the GCS
control panel's start/stop toggle had no subscriber. rqt_airstack_control_panel
publishes set_recording_status, and both onboard_all/config/domain_bridge.yaml and
dds_router.yaml deliberately bridge that topic across domains — all of it pointing at a
node that never existed.

2. Falling back to unknown_robot / domain 0 was silent.
On the hostname-sourced profiles (l4t, voxl) the OS hostname is the robot's
identity. A device whose name doesn't match default_robot_name_map.yaml's
.*robot-.*(\d+) rule hits the .* catch-all and boots cleanly as unknown_robot on
domain 0, with no error. The symptoms — nothing under /robot_<n>, per-robot config
lookups keyed on ROBOT_NAME finding no profile, zed-l4t (hardcoded
ROS_DOMAIN_ID=1) no longer seeing the stack — surface much later and far from the cause.

• Please add videos and images to demonstrate the feature.

N/A — both changes are console-observable. The new warning prints at container startup:

WARNING: could not resolve a robot identity from 'airlab-desktop' using default_robot_name_map.yaml.
         ROBOT_NAME='unknown_robot' ROS_DOMAIN_ID='0'
         Topics will not be namespaced under /robot_<n>, so nothing will reach
         the rest of the stack. Fix by either:
           - on the HOST (not in this container): hostnamectl set-hostname robot-1,
             which the default map resolves to robot_<n> on domain <n>; or
           - adding a mapping YAML under robot/docker/robot_name_map/ that
             matches your hostnames and pointing ROBOT_NAME_MAP_CONFIG_FILE at it.
         If ROBOT_NAME is empty rather than unknown_robot, check stderr above
         for a resolve_robot_name.py error (missing or malformed map file).

How did you implement it?

Bag recording — logging.launch.xml now reads $(env RECORD_BAGS false) instead of a
hardcoded false, with an explicit default so it stays launchable when the variable is
unset. Added LOG_CONFIG (default log.yaml) to select which topic set in
logging_bringup/config to record, forwarded in robot-base-docker-compose.yaml.

Deliberately not changed: recording still starts and stops via the GCS
set_recording_status toggle. An earlier draft added an auto_start parameter to
bag_record_node; that was dropped because the toggle is the intended control path and is
already bridged across domains on purpose. bag_record_pid is untouched by this PR.

Identity warning — the unknown_robot fallback itself is unchanged. It is a sentinel,
not a guess: it keeps an unidentified robot out of every real robot's namespace so it
can't fight one for a command topic. Changing it to default to robot_1/domain 1 was
considered and rejected — a device that failed to identify itself would take a real
identity, and two aircraft publishing /robot_1/interface/cmd_pose on one domain is a
worse failure than an inert one.

The check tests the resolved identity rather than the sentinel value, because only one
of several failure paths yields unknown_robot:

Failure	Result
Catch-all rule matched	unknown_robot / 0
No rule matched (map without a catch-all)	ROBOT_NAME empty
Map file missing / unparseable / no mappings key	empty
container_name source, Docker-DNS lookup fails	name_to_map empty, mapping block skipped

resolve_robot_name.py reports the middle three on stderr and prints nothing to
stdout, so eval assigns nothing and ROBOT_NAME is left empty — which is worse than
unknown_robot, since push_ros_namespace then gets an empty namespace and topics land
at the root. The check also sits outside the if [ -n "$name_to_map" ] block so it
still fires in the fourth case, where that block is skipped entirely.

Removed dead config — overrides/l4t-px4-realrobot.env set ROBOT_NAME="robot_1" /
ROS_DOMAIN_ID="1". No compose service declares either variable, and Compose only injects
what a service names in its environment: block, so an env file could never set them.
Verified with grep -rn '${ROBOT_NAME\|${ROS_DOMAIN_ID' --include=*.yaml . — only
ROBOT_NAME_MAP_CONFIG_FILE is interpolated anywhere. Those lines have been inert since
#371. docs/robot/docker/robot_identity.md and the configure-multi-robot skill both
prescribed that route and now point at the hostname or a map file instead.

How do you run and use it?

Bag recording — negative control first. This is what demonstrates the fix, since the
old failure was an absent node, not a broken one:

airstack up robot-desktop     # .env ships RECORD_BAGS="false"
docker exec -e ROS_DOMAIN_ID=1 airstack-robot-desktop-1 bash -lc \
  'source /root/AirStack/robot/ros_ws/install/setup.bash && ros2 node list | grep bag_record'
# expect: no output

Then with the flag on:

airstack down
RECORD_BAGS=true airstack up robot-desktop

docker exec -e ROS_DOMAIN_ID=1 airstack-robot-desktop-1 bash -lc \
  'source /root/AirStack/robot/ros_ws/install/setup.bash && ros2 node list | grep bag_record'
# expect: /robot_1/bag_record        <-- absent before this PR

docker exec -e ROS_DOMAIN_ID=1 airstack-robot-desktop-1 bash -lc \
  'source /root/AirStack/robot/ros_ws/install/setup.bash && \
   ros2 topic echo --once /robot_1/bag_record/bag_recording_status'
# expect: data: false               <-- up, and correctly idle

Exercise the GCS toggle — the path that was unreachable:

docker exec -e ROS_DOMAIN_ID=1 airstack-robot-desktop-1 bash -lc \
  'source /root/AirStack/robot/ros_ws/install/setup.bash && ros2 topic pub --once \
   /robot_1/bag_record/set_recording_status std_msgs/msg/Bool "{data: true}"'

ls robot/bags/     # expect airstack_<timestamp>/ and zed_<timestamp>/

docker exec -e ROS_DOMAIN_ID=1 airstack-robot-desktop-1 bash -lc \
  'source /root/AirStack/robot/ros_ws/install/setup.bash && ros2 topic pub --once \
   /robot_1/bag_record/set_recording_status std_msgs/msg/Bool "{data: false}"'
# status returns to false; the mcap finalizes

Confirm LOG_CONFIG is actually read:

docker exec -e ROS_DOMAIN_ID=1 airstack-robot-desktop-1 bash -lc \
  'source /root/AirStack/robot/ros_ws/install/setup.bash && \
   ros2 param get /robot_1/bag_record cfg_path'
# expect: .../logging_bringup/config/log.yaml
# then re-run the stack with LOG_CONFIG=bogus.yaml and confirm the node fails with that path

Identity warning — two one-liners cover both branches without editing any files:

docker exec -e ROBOT_NAME_SOURCE=bogus              -it airstack-robot-desktop-1 bash  # unknown_robot branch
docker exec -e ROBOT_NAME_MAP_CONFIG_FILE=nope.yaml -it airstack-robot-desktop-1 bash  # empty-ROBOT_NAME branch

Both print the warning at shell start.

Note: robot/bags/ is not gitignored upstream, so test bags appear as untracked
files — rm -rf robot/bags/* afterwards. Also, log.yaml is currently the only file in
logging_bringup/config/, so LOG_CONFIG has exactly one valid value today; the knob is
forward-looking. Its zed section lists topics that don't exist in a bare desktop sim,
so zed_<ts>/ will be near-empty — pre-existing, not changed here.

Testing with PyTest

• What pytests did you add?

None. Both changes are container bring-up wiring, which the existing tiers don't cover
cheaply: the unit tier collects colcon package tests (this touches a launch file and a
shell script, neither of which is a testable package), and integration/system both
require a running stack.

What I did instead: exercised all five identity-resolution outcomes against the real
resolve_robot_name.py and the real map files with a harness that sources the actual
.bashrc block, confirming the warning fires in exactly the four failure cases and stays
quiet on success. Compose resolution was verified with docker compose config --format json across the desktop and l4t profiles.

• Exact command

N/A. Existing suites should be unaffected — airstack test -m unit for a regression check.

• Expected results / what to look at

A maintainer should run the bring-up commands in the section above. The single most
telling check is the negative control: ros2 node list | grep bag_record returns nothing
on develop with RECORD_BAGS=true, and returns /robot_1/bag_record with this branch.

Possible follow-up: a system-tier test asserting bag_record appears under
RECORD_BAGS=true and reaches bag_recording_status: true after a toggle would cover the
bag half properly. Happy to add it here if reviewers would rather it not land untested.

Documentation

• Was mkdocs.yml updated? (y/n)

n — docs/robot/docker/robot_identity.md is already in the nav (mkdocs.yml:106); this
edits that existing page rather than adding one.

• Sufficient scope?

Yes. robot_identity.md gains: a correction (an unmatched hostname does not make
resolve_robot_name.py exit with ROBOT_NAME unset — the stock map's .* catch-all
always matches, so it boots silently as unknown_robot), a note that on hostname
profiles the device name is how a robot gets named at all rather than only how robots are
told apart, and a danger box explaining that setting ROBOT_NAME in an env file does
nothing. The configure-multi-robot skill gets the same corrections plus a reordered fix
list that leads with the two routes that work.

• Sufficient visual media?

The warning text above is the user-facing surface; there is no GUI component.

Versioning

• Version bumped?

Yes — 0.19.0-alpha.8 -> 0.19.0-alpha.12, in its own commit (fd4b1319) per the
convention used by the OptiTrack stack. alpha.9/.10/.11 are claimed by #374/#375/#376,
hence the jump to .12; if this merges before that stack, those will need renumbering.

---

Behavior change to flag for reviewers

Anyone currently running RECORD_BAGS=true for GCS bags will now also get a bag_record
node on every robot. It comes up idle and records nothing until the GCS toggle says so,
but it is not a no-op. RECORD_BAGS=false opts out.

🤖 Generated with Claude Code