ROS 2 Bundle Loading Decision

Review date: 2026-04-08.

Decision

For the first ROS 2 beta node, load the ONNX bundle from startup ROS parameters. Do not add a bundle-load or bundle-reload service to the initial strict_inference_node. Changing bundles should happen by relaunching the node with a different bundle_dir parameter value or parameter file.

Why Params First

  • The published M2 checkpoint is still one Python node, one launch file, one rosbag test, documented. Startup parameters keep that scope narrow and fit the normal ROS 2 launch/YAML deployment path.
  • load_onnx_runtime_bundle(...) already validates bundle metadata and opens the ONNX Runtime session eagerly. Doing that once at startup gives a clear fail-fast path before the node begins subscribing and publishing.
  • Hot-swapping a validated bundle is not just "load a new path": it also means replacing the ONNX Runtime session, updating diagnostics state, and deciding how in-flight requests are drained or rejected.
  • A reload service would likely want lifecycle semantics, explicit quiescing, and a dedicated service contract. That is too much machinery for the first beta node.

Expected Startup Contract

  • bundle_dir should be a required node parameter for the first node.
  • ONNX Runtime provider/session tuning can also be modeled as startup parameters so launch files remain the single source of deployment config.
  • Runtime parameter changes should not trigger a live reload in the first beta; operators should restart or relaunch the node when changing bundles.

Deferred Service Path

Revisit a bundle reload service only if the ROS 2 integration grows a managed or lifecycle-node path where in-place swaps materially reduce downtime or orchestration complexity. That managed path now exists as the optional lifecycle_strict_inference_node variant for deployments that need on_configure / on_activate orchestration, but it still loads exactly one bundle per configure cycle and does not add a live reload service. If that service is added later, it should be additive over the startup parameter path rather than replacing it.