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

If your scheduler sends a plate-transfer command and the connection drops, can it find out whether the plate moved? That is one of the questions we need to settle before connecting the software. At LabCarry, we agree the supported platform commands, their completion conditions and fault responses with your team. You retain control of the laboratory workflow.

Agree commands, states and recovery responsibilities

Start with the response to a command. Does it mean the request arrived, the platform accepted it, or the physical task finished? A REST endpoint, ROS 2 topic or fieldbus connection can carry all three messages. The interface document needs to distinguish them so your scheduler knows when it can proceed.

The interface document assigns responsibilities to both sides:

• 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.

For a failed pickup, for example, the platform needs to report what it detected. Your scheduler then needs enough information to decide whether the workflow should wait, request a permitted recovery or stop for operator attention.

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

Use these terms consistently in the command document, status messages and test results. A software engineer should be able to read a message without guessing which kind of information it carries.

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: ACCEPTED, EXECUTING, SUCCEEDED or ABORTED, with CANCELING and CANCELED for supported cancellation. These are the lifecycle names used in this article; the released interface must define its own exact mapping. ROS 2 Actions 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

For pick(), the scheduler needs separate evidence that the platform accepted the request and that it completed the pickup. Use the lifecycle names from the diagram, and keep progress feedback separate from the final result:

1. ACCEPTED — the request is valid and allowed in the current state.
2. EXECUTING — the platform has started the task.
3. Progress feedback — optional information about the current phase; this is not a separate terminal state.
4. SUCCEEDED — the agreed completion conditions have been met.
5. ABORTED — execution ended without meeting the completion conditions; return the defined result or fault information.
6. CANCELING / CANCELED — a permitted cancellation is being processed or has reached its defined outcome. The response does not by itself prove that physical motion has stopped.

Navigation, drawer opening and station permission do not finish at the same time. The scheduler needs to follow the task while other equipment is working, then act on the final result. A single reply saying “OK” leaves that decision unclear.

Use a completion evidence record before advancing the workflow

A terminal result is useful only when the receiving software knows what that result proves. For each command, agree a compact evidence record that connects the request, the platform outcome and any condition owned by the instrument or scheduler team.

If the project has no direct observation for an external physical condition, record that limitation instead of making the platform result stand in for missing evidence. The completion evidence worksheet provides a focused review table for this handoff.

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

For example, three hardware attempts per command and three scheduler submissions can produce nine physical attempts for one workflow step. These are illustrative counts, not recommended retry limits.

Assign the retry at the level that has the information and authority to make it:

• 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.

Hardware-level recovery can include a bounded barcode reread or local alignment correction where the fault-specific procedure permits it. Any recovery motion needs a known starting condition, an agreed path and the required motion permissions. Choosing another instrument remains a customer workflow decision.

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. Bind each command ID to an immutable canonical request payload and command type. A duplicate ID with the same payload returns the current or retained result without starting another physical action. The same ID with a different payload is rejected as an ID conflict. Define the retention window, persistence across restart and status-query behavior before integration. Where events can be replayed or arrive out of order, also define a platform boot or session ID, monotonic sequence number and timestamp source. 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

Within an agreed work package, we implement and verify the 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 confirms a connection. Your software team also needs to see how the platform responds in the situations below. Select applicable scenarios in the FAT plan and agree the permitted simulation or controlled test method before execution:

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-rated stop or emergency-stop function preventing motion.
11. Ordinary application permissive or process interlock preventing the requested action.

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

Review the platform hardware scope alongside the command definitions. Physical readiness at the instrument also depends on the handoff positioning conditions. Include the agreed command, interruption and recovery cases in the hardware FAT plan.

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