Real-robot deployment fixes: make RECORD_BAGS and ROBOT_NAME overrides take effect

[JohnYanxinLiu]

Two deployment knobs that look wired up but are inert. Both are forwarded into the robot container and then read by nobody, and neither failure is visible until you go looking for output that never appeared. Found while porting fixes back from a real mocap-room drone deployment.

Independent of the OptiTrack PR stack (#374/#375/#376) — nothing here depends on it, and it can merge in either order.

RECORD_BAGS never enabled bag recording on a robot

robot-base-docker-compose.yaml has forwarded the variable since #318, but:

• logging_bringup/launch/logging.launch.xml hardcoded <arg name="record_bag" default="false" />
• onboard_autonomy_all.launch.xml:56 includes that file with no arguments

so nothing ever overrode the default. Only gcs.launch.xml reads $(env RECORD_BAGS) — which is why the flag appears to work if you only check the GCS.

Fixing the gate alone wasn't enough: bag_record_node comes up with self.active = False and the only path to run() is the set_recording_status subscription, so you'd get a running recorder that records nothing on an unattended robot. Added an auto_start parameter (declared False, so existing toggle-driven behavior is unchanged) which the launch file sets from BAG_AUTO_START, default true — RECORD_BAGS already gates whether the node runs at all.

Also added LOG_CONFIG to select which topic set in logging_bringup/config to record, defaulting to the current log.yaml.

ROBOT_NAME / ROS_DOMAIN_ID couldn't be overridden

#370 made .bashrc keep a pre-set ROBOT_NAME instead of always overwriting it from the container/hostname map — but no compose service declares the variable, and compose only injects what a service names in environment:. So setting it in an override .env did nothing. This is the missing half.

It matters on hosts whose hostname misses the .*robot-.*(\d+) rule in default_robot_name_map.yaml: a Jetson named airlab-desktop falls through to the catch-all, comes up as unknown_robot on domain 0, and is silently invisible to the rest of the stack.

Safe when unset. Compose passes an empty string; .bashrc's [ -z "${ROBOT_NAME:-}" ] and [ -z "$existing_robot_domain_id" ] guards treat that as absent, so the existing mapping path is untouched. robot-offboard's explicit ROS_DOMAIN_ID=0 also still wins, since a service's own environment: overrides what it extends.

Single-robot only, documented inline: replica deployments (deploy.replicas / NUM_ROBOTS>1) share one env, so setting these would collapse every replica onto the same name and domain. Leave them unset there.

Behavior change to be aware of

Anyone currently running RECORD_BAGS=true for GCS bags will now also get a recorder on every robot, actively recording. That's the intended semantics, but it isn't a no-op for existing users — RECORD_BAGS=false or BAG_AUTO_START=false opts out.

Testing

• logging.launch.xml parses; robot-base-docker-compose.yaml parses; bag_record_node.py parses.
• Not yet exercised on hardware — the ROBOT_NAME half is what the real Jetson deployment ran with.

🤖 Generated with Claude Code