BRbrumby
simulated runs

Schedule Sim Run

post/api/v1/sim-runs

Request

  • Base URL
    https://api.brumby.com (the document declares no server; this is the origin it was published from)
  • URL
    https://api.brumby.com/api/v1/sim-runs
  • Auth
    HTTP bearer

Request body

farm_idstring required
device_idstring required
paddockstring nullable
mode'survey' | 'muster' | 'flight_plan' nullable
destinationstring nullable
flight_planobject nullable
dispatch'launch' | 'headless'

How a simulated run reaches an aircraft, and therefore who authorises it.

LAUNCH is the ordinary path and the only one that flies anything: the run schedules a mission request exactly as the customer app does, a pilot signs the JSA and presses LAUNCH, and the dock delivers. FleetOps adds nothing to that sequence and skips nothing in it.

HEADLESS never asks a dock for anything. The bench composes the same mission config from the same farm and runs it against a stub dock, so there is no clearance to grant, no aircraft to arm and nothing to authorise -- which is why there is no JSA on it. A sweep of two hundred seeds is this one; a run you want a flight record for is the other.

autonomy_host'bench' | 'jetson'
mission_idstring nullable
mission_plan_idstring uuid nullable
mission_plan_revisioninteger nullable

Response

Successful Response

run_idstring uuid required
batch_idstring uuid nullable required
ordinalinteger required
farm_idstring required
device_idstring required
world_slugstring required
paddockstring nullable required
autonomy_host'bench' | 'jetson'
simulator_hoststring nullable
runner_launch_mode'worker' | 'command'
weatherobject
mission_configobject nullable
mission_plan_idstring uuid nullable
mission_plan_revisioninteger nullable
claim_tokenstring uuid nullable
lease_expires_atstring date-time nullable
cancel_requestedboolean
herdobject required
dispatch'launch' | 'headless' required

How a simulated run reaches an aircraft, and therefore who authorises it.

LAUNCH is the ordinary path and the only one that flies anything: the run schedules a mission request exactly as the customer app does, a pilot signs the JSA and presses LAUNCH, and the dock delivers. FleetOps adds nothing to that sequence and skips nothing in it.

HEADLESS never asks a dock for anything. The bench composes the same mission config from the same farm and runs it against a stub dock, so there is no clearance to grant, no aircraft to arm and nothing to authorise -- which is why there is no JSA on it. A sweep of two hundred seeds is this one; a run you want a flight record for is the other.

state'pending' | 'requested' | 'claimed' | 'running' | 'succeeded' | 'failed' | 'cancelled' required

Where one cell of a sweep has got to.

PENDING through FINISHED is the bench's own progress. REQUESTED is where a LAUNCH run waits: its mission request exists and the pilot's queue owns it from there, so FleetOps deliberately stops describing it -- the request's own state is the answer, and a copy here would be a second one.

mission_request_idstring uuid nullable required
simulation_run_idstring uuid nullable required
claimed_bystring nullable required
claimed_atstring date-time nullable required
started_atstring date-time nullable required
finished_atstring date-time nullable required
outcomeobject nullable required
failurestring nullable required
created_bystring required
created_atstring date-time required

Changes

No recorded changes to this operation across all 1 revision of this API.