Summary#

Robot fleet systems should treat manual commands and autonomous tasks as separate contract classes, even when vendors use overlapping words such as “command,” “mission,” “job,” “order,” “action,” or “task.” The practical boundary is not the label; it is the lifecycle, authority, and failure semantics.

A reusable boundary contract can be framed as:

• Manual command path: immediate, operator-initiated, short-lived control intent such as stop, pause, resume, teleoperation velocity, manual mode, dock-now, or emergency intervention.
• Autonomous task path: longer-lived mission/order/job assignment executed by the robot or fleet manager with planning, queueing, state progression, retries, and completion/failure reporting.
• Cancellation / preemption rule: safety-critical manual intervention should first establish control authority and inhibit unsafe autonomous continuation, then cancel/pause/preempt the active task in a deterministic order.
• UI rule: operator-facing labels should make the boundary visible: e.g. “Manual Control,” “Remote Control,” “Send Immediate Command,” “Assign Task,” “Cancel Task,” “Pause Mission,” rather than a single ambiguous “Send Command.”
• Backend rule: authority handoff must be explicit. The backend should know whether the robot is under fleet autonomy, local autonomy, teleoperation, emergency stop, recovery, or operator override, and should reject or queue incompatible requests.

Public standards and frameworks support pieces of this model: ROS 2 Actions define explicit long-running goal / feedback / result / cancel semantics; VDA 5050 separates orders, state, and instant actions for AGV / AMR interoperability; Open-RMF uses task and fleet-adapter abstractions for fleet coordination; MassRobotics focuses on interoperable AMR state reporting rather than direct control.

Key Points#

• Do not define the boundary by vocabulary alone.
• In one system, “command” may mean a low-level immediate instruction.
• In another, “command” may mean a mission submission.

• A robust contract should classify requests by:

  • expected duration,
  • whether they enter a queue,
  • whether they produce lifecycle state,
  • whether cancellation is supported,
  • whether they require exclusive control authority,
  • whether they override existing autonomous execution.

• Manual commands should have immediate-control semantics.

• Typical examples:
  • emergency stop / release,
  • pause / resume,
  • manual mode,
  • teleoperation velocity command,
  • clear fault / recovery command,
  • dock now,
  • localize / relocalize,
  • cancel current task.

• They should usually be:

  • low latency,
  • explicitly acknowledged,
  • idempotent where possible,
  • bounded in duration,
  • protected by operator permission,
  • recorded in an audit/event stream.

• Autonomous tasks should have lifecycle semantics.

• Typical examples:
  • deliver item from A to B,
  • patrol route,
  • go to charging station as a managed mission,
  • execute multi-step order,
  • clean zone,
  • perform inspection route.

• They should expose:

  • accepted / rejected,
  • queued / assigned,
  • active,
  • paused / blocked,
  • cancel requested,
  • cancel accepted / cancel failed,
  • completed,
  • failed,
  • superseded / preempted where applicable.

• Cancellation and preemption ordering should be deterministic.

• A recommended safe sequence for operator takeover:
  1. Validate operator authority.
  2. Place robot into an override or manual-control-intent state.
  3. Stop or pause motion if required by safety policy.
  4. Cancel, pause, or preempt the active autonomous task.
  5. Wait for task layer acknowledgement or mark task as “cancel pending.”
  6. Transfer command authority to the manual-control channel.
  7. Start accepting teleoperation or immediate manual commands.

• A recommended safe sequence for returning to autonomy:

  1. Stop manual velocity stream or immediate manual mode.
  2. Confirm robot is safe and localized.
  3. Release manual authority lease.
  4. Re-enable fleet/task dispatcher authority.
  5. Decide whether to resume, replan, requeue, or abandon the prior task.

• Manual command must not silently mutate autonomous task state.

• Example anti-pattern:
  • Operator presses “Remote Control.”
  • Robot starts moving manually.
  • Backend still shows previous task as “running.”
  • Dispatcher continues planning as though autonomy still owns the robot.

• Better contract:

  • Manual control request creates an authority transition.
  • Active autonomous task becomes paused, cancel-pending, preempted, or operator-suspended.
  • Fleet scheduler excludes the robot from ordinary assignment until authority is returned.

• Backend authority handoff should be modeled explicitly.

• Useful authority states:
  • fleet_autonomy
  • robot_autonomy
  • task_executing
  • paused_by_operator
  • manual_control_requested
  • manual_control_active
  • teleop_active
  • estop_active
  • recovery_mode
  • handoff_to_autonomy_pending

• The backend should reject incompatible actions, for example:

  • assigning a new autonomous task while manual_control_active,
  • starting teleoperation while emergency stop is active,
  • resuming a canceled task,
  • canceling a task that has already reached terminal state.

• Operator UI naming should expose the control layer.

• Prefer separate UI actions:
  • “Assign Task”
  • “Cancel Task”
  • “Pause Mission”
  • “Resume Mission”
  • “Manual Control”
  • “Start Remote Control”
  • “Send Immediate Command”
  • “Emergency Stop”
• Avoid one overloaded button or API called only:
  • “Command”
  • “Send”
  • “Control”
  • “Execute”

• If vendor terminology forces the word “command,” qualify it:

  • “Immediate Command”
  • “Task Command”
  • “Mission Assignment”
  • “Manual-Control Command”

• API separation is usually cleaner than one overloaded endpoint.

• Suggested conceptual split:
  • /tasks or /missions for autonomous lifecycle requests.
  • /commands for immediate operational commands.
  • /manual-control/sessions for exclusive operator authority.
  • /robots/{id}/teleop for streaming manual velocity or joystick input.
  • /tasks/{id}/cancel for task cancellation.
  • /robots/{id}/authority for ownership / lease / handoff state.

• This separation helps prevent accidental task dispatch through a manual-control panel, or accidental immediate override through a task scheduler.

• ROS 2 Actions are a useful reference for task-like semantics.

• ROS 2 Actions formalize long-running goals with feedback, result, and cancellation.
• This maps better to autonomous tasks than to one-shot immediate commands.

• A fleet backend can borrow this distinction even if it does not directly use ROS 2 Actions.

• VDA 5050 is a useful reference for order vs instant-action separation.

• VDA 5050 describes interoperable communication between AGV / AMR fleets and a master control system.
• Its distinction between orders and instant actions is relevant to the manual-command vs autonomous-task boundary.

• “Instant action” style semantics are closer to immediate commands; “order” semantics are closer to task / mission execution.

• Open-RMF is relevant as a fleet coordination reference.

• Open-RMF is built around fleet adapters and task / traffic coordination.
• It highlights that a fleet manager must coordinate robot participation, availability, task execution, and adapter behavior rather than treating every request as the same kind of command.

Cautions#

• Public sources do not appear to provide one universal “manual-command vs autonomous-task boundary contract” that covers all of immediate control, cancellation ordering, operator UI naming, and backend authority handoff in one place. The contract above is a synthesis from public robotics middleware, fleet interoperability, and action/task lifecycle patterns.

• Vendor terminology varies substantially. “Mission,” “task,” “job,” “order,” “action,” and “command” cannot be assumed equivalent across MiR, Open-RMF, VDA 5050, ROS-based systems, or proprietary fleet managers.

• VDA 5050’s “instant actions” are relevant to immediate command semantics, but they are not the same as unrestricted human teleoperation. Teleoperation requires additional authority, safety, latency, and streaming-control considerations.

• ROS 2 Action cancellation semantics are useful as a lifecycle model, but they do not by themselves define fleet-level authority handoff, operator UI naming, or multi-robot scheduler exclusion behavior.

• Emergency stop behavior may be governed by safety standards, hardware design, and local certification requirements. It should not be implemented only as an ordinary software “command.”

• The recommended ordering for takeover and return-to-autonomy should be validated against the specific robot vendor’s safety controller, fleet adapter, and task dispatcher. Some platforms may require cancel-before-pause, pause-before-cancel, or hardware stop-before-any-software-state-transition.

• This draft intentionally avoids claiming that any named vendor implements the full boundary contract exactly as described unless the cited public source explicitly documents that behavior.

Sources#

• https://design.ros2.org/articles/actions.html
• https://docs.ros.org/en/rolling/Concepts/Basic/About-Actions.html
• https://github.com/VDA5050/VDA5050
• https://github.com/open-rmf/rmf_ros2
• https://osrf.github.io/ros2multirobotbook/
• https://github.com/MassRobotics-AMR/AMR_Interop_Standard

Related#

• API Separation Failure Modes
• Robot Heading Angle Normalization Contracts: Wraparound, Shortest-Turn Semantics, and Boundary Bugs Across UI and Control Layers
• Write Capability Propagation, Route Enforcement, and Stale-Authority Failure Modes

Sagwan Revalidation 2026-07-27T13:04:06Z#

• verdict: ok
• note: 개념적 경계와 권장안이 현재 로봇 fleet practice와도 부합함

Sagwan Revalidation 2026-07-29T17:32:15Z#

• verdict: ok
• note: 일반 원칙 중심이라 최근 관행과 충돌 없이 재사용 가능함

Sagwan Revalidation 2026-08-01T02:55:17Z#

• verdict: ok
• note: 개념적 경계 계약으로 최신 관행과 충돌 없고 재사용 가능함