Open-RMF Fleet Adapters: Verify Command Progress and State Freshness
Published 2026-11-02 21:12:34 -05:00 (America/New_York). Sources checked 2 November 2026.
The adapter is an integration boundary
The Open-RMF Jazzy fleet-adapter README describes adapter nodes communicating with proprietary fleet drivers and managers through ROS 2 messages. This boundary connects systems with different responsibilities. A successful message exchange does not prove that the connected robot has begun, continued or completed the physical work represented by a higher-level assignment.
Ask the integrator to identify the precise control capability exposed by the deployed adapter and the fleet manager that retains authority over the robot. Record both software versions and the interface contract. Do not assume that every fleet integration permits identical operations simply because each is described as an Open-RMF connection.
Map commands to observable progress
For one representative assignment, document the request identifier, the adapter’s translation, the fleet manager’s response and the evidence of actual progress. Define when the adapter may declare completion. A vendor API returning accepted should remain distinct from a completed physical task. Keep identifiers stable enough to investigate an incident across both systems.
Define status freshness and the meaning of unavailable information. A retained last-known position can help diagnosis, but must not appear as a current observation indefinitely. The application needs an agreed response when updates stop and a reconciliation procedure when communication returns. Set those requirements from the site’s workflow rather than borrowing an unexplained timeout from another project.
Test the boundary under interruption
Begin with a supplier-approved simulated fleet or isolated integration test. Submit an assignment, interrupt a test status source and observe the adapter and operator interface. Restore the source and check how task identity and state are reconciled. Retain the command and status timeline from both sides so the result does not depend on one system’s interpretation alone.
Exercise a request rejected by the fleet manager and an assignment that remains pending. Confirm that neither becomes successful merely because the adapter process stays alive. Do not test communication failure by disabling protective equipment or forcing live traffic conflicts. Physical fleet trials need qualified supervision and the site’s approved operating controls.
Accept a clear responsibility boundary
The handover should identify which supplier diagnoses adapter translation, vendor-fleet state and physical task execution. Include an annotated normal transaction and an interrupted transaction. Operators should be able to identify an unresolved task and the authorised next action without comparing incompatible technical logs on several computers.
Acceptance should reconcile every submitted assignment with an observed result or an explicitly retained uncertain state. Keep the tested capability level and version pair with the report. This establishes evidence for one integration boundary; it does not certify traffic safety, guarantee collision avoidance or establish that every robot brand exposes the same functions. Adding another fleet therefore requires its own capability and state-contract review rather than reusing the connection label as proof.
Record the source clock and observation time for status updates. Freshly received information can still describe an old robot state if it was buffered elsewhere in the integration.
Source: Open-RMF fleet-adapter package README (Open-RMF rmf_ros2 Jazzy branch, checked 2026-11-02). The acceptance proposals above are editorial guidance, not reported project results. Compare robot models and manufacturer profiles, or discuss the integration requirements.