Defining the hardware interface between a mobile manipulator and a laboratory scheduler

We connect the mobile base, arm, gripper and platform devices behind one agreed hardware interface. Your scheduler requests supported functions and receives their state and result. Before either team starts integration, we agree what each command means, when it is allowed and who handles a fault.

Agree commands, states and recovery responsibilities

In an OEM laboratory robotics project, “API integration” is often treated too narrowly. A REST endpoint, ROS 2 topic or fieldbus connection can move data, but it does not by itself define what a command means, when it is allowed, how progress is reported, what constitutes completion, how faults are classified, or which side owns recovery.

The real interface is a behavioral contract between two systems:

• The hardware platform owns the mobile base, arm, gripper, sensors, interlocks and device-level execution.
• The scheduler / orchestration layer owns workflow sequencing, instrument coordination, task priorities and application-level decisions.

If that boundary is vague, the project can appear to work during a demo but become difficult to maintain, validate and support.

1. Define capabilities before defining endpoints

The first step is to describe what the scheduler is allowed to ask the hardware platform to do. These are capabilities, not low-level actuator commands.

We start by listing the required functions. The command names below illustrate the function types; the released interface document specifies the actual names, parameters and supported commands:

• navigate_to_station(station_id)
• dock(station_id)
• pick(source, labware_id)
• place(destination, labware_id)
• move_to_recovery_pose() or another explicitly defined recovery motion
• scan_barcode()
• charge()
• acknowledge_fault(fault_id) or a more specific recovery command only where the recovery behavior is defined and safe for that fault class

Whether those functions are exposed through REST, gRPC, ROS 2 actions, OPC UA, MQTT or another protocol is a secondary decision. The behavioral meaning should be agreed first.

This principle is consistent with modern automation architectures: asynchronous action models such as ROS 2 Actions separate goal, feedback and result; laboratory standards such as SiLA 2 also emphasize defined features, commands and device semantics rather than raw transport alone.

2. Separate command, state, status and event

These four concepts are often mixed together, but they serve different purposes.

A scheduler should not have to infer completion from a changing coordinate or guess a fault from the absence of motion. The platform should report explicit state transitions and task results.

3. Use separate state models instead of one overloaded list

A single flat state machine easily mixes platform availability, task progress, mobility phase and safety status. That creates ambiguous combinations such as “FAULT versus RECOVERY_REQUIRED” or treats a safety condition as if it were merely another workflow state. A cleaner interface separates at least three concerns:

• Platform operational state: for example READY, BUSY, FAULTED, MAINTENANCE or OFFLINE.
• Task lifecycle: for example ACCEPTED, EXECUTING, SUCCEEDED, FAILED / ABORTED or CANCELED. ROS 2 Actions uses a closely related goal lifecycle and separates goal acceptance, feedback and final result.
• Safety / motion-permission status: exposed separately from the ordinary workflow state. The exact names and semantics must reflect the real safety architecture; a scheduler should observe this status but must not be able to bypass a safety-rated stop or permissive.

Mobility and manipulation phases such as NAVIGATING, DOCKING, DOCKED or MANIPULATING can then be represented as task sub-states or progress feedback rather than expanding the top-level platform state machine indefinitely.

For each model, define which commands are accepted or rejected, which transitions are automatic, what condition ends a task, what survives a reconnect, and which transitions require operator or scheduler action. This separation should be reviewed before coding because it exposes hidden ownership questions without conflating application control with safety behavior.

4. Every command needs an acceptance model

Consider pick(). “Command received” is not the same as “pick succeeded.” A robust interface usually distinguishes at least:

1. Accepted — command is syntactically valid and allowed in the current state.
2. Started — execution has begun.
3. In progress — optional progress or sub-state feedback.
4. Succeeded — task completed according to the agreed success condition.
5. Failed — execution stopped and produced a fault or result code.
6. Cancelled — command was intentionally cancelled, if supported.

This pattern matters because laboratory orchestration is inherently asynchronous. Navigation may take tens of seconds; an instrument may need time to open a drawer; the arm may wait for a station-ready signal. Blocking everything behind a single synchronous response creates brittle integrations.

5. Faults should be actionable, not just numbered

A useful fault model should help the scheduler decide what to do next. Instead of only returning Error 1057, group faults by behavior.

The interface should expose both a stable machine-readable code and human-readable diagnostic context. Fault codes must remain stable across software revisions or be versioned explicitly.

6. Decide where retry logic lives

Retry logic is a frequent source of duplication. If the hardware controller retries a failed pick three times while the scheduler also retries the command three times, one workflow step can unexpectedly execute nine physical attempts.

A clean rule is:

• Device-level recovery stays in the hardware platform when it is local, bounded and does not change workflow intent.
• Workflow-level retry or rerouting stays in the scheduler when it changes task priority, selects another station, requests human intervention or affects sample disposition.

Examples of hardware-level recovery might include re-reading a barcode once, re-running a local docking correction, or returning the arm to a safe pose after a non-safety motion error. Choosing a different instrument because the first one is unavailable is scheduler logic.

7. Design duplicate handling for physical commands

Network interruption creates an important question: if the scheduler sends place() and loses the connection before receiving the result, what happens if it sends the same request again?

A physical pick or place is not inherently idempotent: repeating the same logical command can cause a second physical action. The interface should therefore use a unique task ID / command ID and define an execution policy such as at-most-once behavior or explicit de-duplication. The platform can then distinguish:

• a new command,
• a duplicate of a command already accepted or in progress,
• a duplicate of a completed command whose previous result can be returned,
• an invalid command conflicting with the current platform or task state.

This prevents a reconnect or retry from silently creating duplicate physical handling. The platform should retain enough command/result history, for a defined time or count window, to answer the scheduler consistently according to the agreed recovery policy.

8. Status data should be useful but not excessive

A scheduler usually needs operational status, not every internal motor variable. A practical status model can include:

• platform state and active task ID,
• current station / target station,
• navigation / docking result,
• arm availability and current high-level pose state,
• gripper open/closed/object-present status,
• barcode result and identified labware/sample ID where applicable,
• battery and charging state,
• interlock / E-stop summary,
• active fault codes,
• software / firmware / configuration version.

Detailed diagnostics can be available through a service interface, log file or engineering endpoint without making the scheduler depend on them.

9. Version the interface and configuration

The scheduler should know which interface contract it is talking to. At minimum, expose:

• interface version,
• platform configuration ID,
• relevant firmware/software versions,
• enabled capability set.

This becomes important in OEM repeat production. A field replacement of an AMR controller or arm firmware update can change behavior even if the physical machine looks identical. Configuration traceability should therefore be part of the delivered hardware record.

10. Define the ownership boundary explicitly

Our hardware and your scheduling software connect at this boundary:

Customer Scheduler → LabCarry Platform Interface → Mobile Base + Arm + Gripper + Sensors + Interlocks

We implement and verify the agreed platform functions below that boundary. Your team owns the laboratory workflow logic above it.

The platform reports device outcomes such as:

• “Docking failed: station alignment outside permitted window.”
• “Pick failed: object presence not confirmed.”
• “Barcode read: ID = ABC123.”

Your scheduler decides:

• whether to retry the entire workflow step,
• whether to send the sample to another instrument,
• whether a mismatched sample should be quarantined,
• whether the process may continue after an application-level exception.

11. Interface validation should test behavior, not just connectivity

A successful ping or API call proves very little. FAT should include interface scenarios such as:

1. Valid command in valid state.
2. Valid command in invalid state.
3. Duplicate command ID.
4. Scheduler disconnect during navigation.
5. Scheduler reconnect while task is still running.
6. Platform restart with an incomplete previous task.
7. Docking fault followed by defined recovery.
8. Barcode mismatch.
9. Gripper / object detection failure.
10. Safety interlock preventing motion.

For each case, both sides should know the expected state, response code and ownership of the next decision.

What should be agreed before the build?

• The capability list exposed to the scheduler.
• Command parameters and success conditions.
• State model and allowed transitions.
• Status fields and update behavior.
• Fault taxonomy and stable fault codes.
• Retry ownership and automatic recovery limits.
• Command IDs, duplicate handling and reconnect behavior.
• Interface transport/protocol and security requirements.
• Versioning and configuration traceability.
• FAT scenarios for normal, fault and reconnect behavior.

Technical references

• ROS 2 Actions — goal lifecycle, feedback, result and cancellation model
• SiLA 2 — feature- and command-based laboratory device communication