Master and workers
TOPOLOGY
A star around the master
One node is always the master. In the cluster design, compute-node workers register with it and offer their accelerators and idle worker slots, and the master schedules jobs onto them.
JOB OFFLOAD
One contract for heavy work
Reconstruction and perception are too heavy for a small companion computer. The job API lets a drone or the operator push that work to the compute node and read the result back.
The job interface
A job moves from queued to running, then completed, failed or cancelled. A worker runs the backend without holding the job-store lock, so a reconstruction that takes minutes never blocks the API, and a cancel that lands mid-run wins.
POST api/compute/jobs GET api/compute/jobs/:id POST api/compute/jobs/:id/cancel GET api/compute/status
Submit
A drone holding a credential this node issued, or the operator through the agent, submits a job. The node records it and places it on the queue.
Attach
A keyframe dataset is uploaded to the node's work directory, so the job carries everything it needs to run.
Read
The submitter polls job status and fetches the outputs when they are ready. Job records also sync to the operator's cloud account.
SCHEDULING
How the master places work
Each worker advertises its accelerators, idle worker slots and queue depth to the master, and the status reports the total idle slots across the cluster.
- Master
- Always exactly one
- Workers
- Register and offer accelerators and idle slots
- Job kinds
- Reconstruct, perception offload, SLAM offload
- Callers
- Drones with a node credential, the operator
- Single-node mode
- One node acting as master with its own worker slots
- Multi-node scope
- Distributed scheduling and failover when the master is lost are in development
EXPLORE
Related
One console, many GPUs
The cluster is designed to let one master borrow the compute of every machine on the bench. Read about the worker profile.
See compute nodes