Day 34: Lifecycle nodes, composition, namespaces, launch, and introspection

Managed lifecycle nodes expose defined primary states such as unconfigured, inactive, active, and finalized, plus transitions including configure, activate, deactivate, cleanup, and shutdown. Configuration can allocate resources and validate parameters; activation can begin publishers or task work only after dependencies are ready. A transition can fail and must report why. Not every ordinary ROS node implements the lifecycle interface, so inspect capability rather than assuming a lifecycle command applies.

Composition loads multiple component nodes into one process. It can reduce process and communication overhead and support efficient intra-process transfer, but it also changes failure isolation: a crash or resource problem can affect every component in the container. Separate processes cost more but provide clearer operating-system isolation and independent restart. Choose the boundary from latency, copying, resource use, fault containment, security, and deployment needs; do not compose everything merely because the tool exists.

Namespaces and remapping let reusable node code run more than once without name collisions. A fleet might use /robot_01/telemetry and /robot_02/telemetry, while each node internally publishes relative name telemetry. Avoid hard-coded global names that escape the namespace. Parameters configure a node instance; they need types, units, ranges, defaults, ownership, source, and startup validation. A parameter file plus launch arguments should make the effective configuration inspectable and versioned.

A launch description starts processes or components with explicit names, namespaces, remappings, parameter files, environment, conditions, and shutdown behavior. Launch order alone does not prove readiness: use lifecycle transitions, service/action availability, health state, or explicit events for dependencies. A reproducible bring-up captures the exact command, configuration revision, expected graph, and acceptance checks rather than relying on terminal history.

ROS CLI and rqt tools expose the live system: list and inspect nodes, topics, services, actions, parameters, lifecycle states, components, interfaces, logs, rates, bandwidth, and environment diagnostics. Use them as a structured investigation: identity and namespace, graph endpoints and types, QoS, timestamps/rates, parameters, lifecycle/readiness, logs, and process/network facts. The CLI often uses a discovery cache/daemon, so if evidence conflicts with process reality, verify both and refresh deliberately rather than trusting one stale view.