Fleet
Fleet missions
Plan and operate robot work from /app/fleet/missions: create or schedule a mission, assign a suitable robot, follow execution, and record a clear terminal result.
On this page
Start here
Missions give operators one lifecycle for scheduled or immediate robot work. Use the console to define the task and waypoints, choose or automatically select a robot, and move the mission through explicit states while keeping the robot's real availability in view.
Before you begin
- Workspace operator access to /app/fleet/missions
- An eligible robot plus validated waypoints, capabilities, priority, and schedule
Put it into practice
-
Create and review the mission
Enter the work, priority, waypoints, and optional scheduled_at. Keep it pending until the payload and timing are ready for assignment.
-
Assign with awareness
Use auto-assign when an online robot with required capabilities should be selected, or assign explicitly only after checking that the chosen unit is operational.
-
Operate to a terminal state
Start queues an execute command, then wait for robot acceptance before considering work in progress. Pause, resume, and cancel request typed controls bound to that execute attempt; the actual status changes only on robot success ACK. Complete/fail are reasoned manual overrides, not device confirmations.
The mission is attached to the intended robot, its state reflects the real work, and it ends as completed, failed, or cancelled rather than remaining indefinitely in progress.
01 Console
details/app/fleet/missions
Review the mission list, create immediate or scheduled work, auto-assign one pending mission or all eligible pending missions, and open a mission for detail. Priorities are low, normal, high, and critical.
/app/fleet/missions/:id
Review command correlation, execution/control results and trace. Start and request pause/resume/cancel as device commands; use the reason-required Manual override form only when an operator must close without device confirmation.
02 Status and scheduling
detailsStatuses
Mission status is pending, assigned, in_progress, paused, completed, failed, or cancelled. Execution status distinguishes queued, running, interrupted (outcome unknown), device-terminal results, and overridden. A queued execute is assigned until ACK; only delivery_state known_unsent permits local cancellation. A control request leaves actual mission status unchanged until robot success ACK. Unknown/possibly delivered queued work receives a pending device cancel and cannot be blindly redelivered.
Auto-assign
Automatic assignment selects fresh online, linked robots and respects payload.required_capabilities. Explicit assignment has the same liveness and identity gates. Busy robots are refused with a 422 validation error on robot_id. POST /api/v1/operator/missions/auto-assign-all handles up to 500 pending missions per call and returns one result per mission.
Waypoints
Stored as {"waypoints": [...]}; an empty object is allowed. Each waypoint is an object with numeric lat (-90 to 90) and lng (-180 to 180), an optional string action, and an optional params object. Anything else is a 422 validation error on waypoints, for example "must be a list of waypoints", "waypoint 2 needs a numeric lat (-90 to 90) and lng (-180 to 180)", "waypoint 2 action must be a string", or "waypoint 2 params must be an object". The same rules apply on create, on PUT /api/v1/operator/missions/:id, and on PUT /api/v1/operator/missions/:id/waypoints.
03 Create then observe a mission
example// Run only from an authorized, same-origin operator browser session.
const csrf = document.querySelector('meta[name="csrf-token"]').content;
const created = await fetch('/api/v1/operator/missions', {
method: 'POST', credentials: 'same-origin',
headers: {'content-type': 'application/json', 'x-csrf-token': csrf},
body: JSON.stringify({mission: {name: 'Dock inspection', priority: 'normal',
waypoints: {waypoints: [{lat: 41.715, lng: 44.827, action: 'inspect'}]}}})
});
const mission = await created.json();
// Assign an eligible robot, then POST /missions/:id/start.
// A start response can still be assigned/queued: read detail until a robot ACK.
Troubleshooting
- Auto-assign finds no robot
- Check online state and payload.required_capabilities. Automatic selection only considers online candidates that satisfy the requirement.
- An explicit assignment targets a retired unit
- Explicit assignment verifies workspace ownership, a linked active service identity, a fresh online heartbeat, and no active mission. An offline, stale, retired, or unlinked robot is ineligible.
- A scheduled mission did not start
- Confirm scheduled_at has arrived, the workspace is active, the robot is eligible and not busy, and the mission is pending or assigned. Dispatch may remain queued until reconnect. Accepted work is not automatically re-executed after transport loss; interrupted means outcome unknown, not failure.
- Cancel reports control_pending
- An earlier pause/resume/cancel control may have reached the robot. The platform preserves its command link instead of replacing it or claiming a physical stop. An accepted control that loses transport is interrupted (outcome unknown), not failed or automatically retried. Wait for that exact robot and command's ACK, then retry cancellation if still needed. A queued execute is cancelled locally only when delivery_state is known_unsent; legacy unknown or possibly_delivered delivery requests a device cancel and fences execute redelivery even across a control timeout, while still accepting a late bound ACK.