Zequent Client SDK (Python) — Mission Autonomy

client.mission_autonomy creates and manages missions, waypoint tasks, and schedulers, and is the only interface that can start, stop, pause, or resume a task. Unlike the Java SDK, client.connector has no Mission/Task methods at all here — there's no "which one should I call" question in Python.

Full method-by-method reference: Mission Autonomy API Reference.

For Java, see CONNECTOR.md / the Mission Autonomy reference.

Beta preview — 2.0.x, not yet released. Every method below raises LegacyOperationRemovedError on an unmerged branch that replaces this whole page's model. See the 2.0.x migration guide for what replaces it.

Creating a mission

from client_sdk.models import MissionDTO, MissionType

mission = MissionDTO(name="North Perimeter Patrol", type=MissionType.PERIMETER_PATROL)

response = await client.mission_autonomy.create_mission(mission)
if not response.success:
    print(f"Create mission failed: {response.error.error_message}")
else:
    print(f"Mission created: {response.mission_id}")

create_mission/update_mission are route-optimized — confirmed against the backend MissionAutonomyGrpcService: the mission is run through missionRouteOptimizer.optimize(...) before being written. create_task/update_task get the equivalent no-fly-zone-aware expansion for a waypoint task with a mission_id. get_*/delete_* are plain passthroughs — no optimization applies to reads or deletes.

Creating a waypoint task

from client_sdk.models import TaskDTO, TaskType

task = TaskDTO(mission_id=mission_id, task_type=TaskType.WAYPOINT, name="Loop A")

response = await client.mission_autonomy.create_task(task)

Task execution lifecycle

await client.mission_autonomy.start_task(task_id)
await client.mission_autonomy.pause_task(task_id)
await client.mission_autonomy.resume_task(task_id)
await client.mission_autonomy.stop_task(task_id)

These forward a bare task ID to the adapter — works only where the adapter implements the task lifecycle. See Waypoint Missions for the full per-adapter picture, including the command-based alternative (MAVLink, the simulator) that doesn't use this lifecycle at all.

Schedulers

from client_sdk.models import SchedulerDTO

scheduler = SchedulerDTO(name="Nightly patrol", cron_expression="0 22 * * *", mission_id=mission_id)
response = await client.mission_autonomy.create_scheduler(scheduler)

all_for_task = await client.mission_autonomy.list_schedulers(task_id)
everything = await client.mission_autonomy.list_schedulers()  # task_id omitted -- unfiltered

Identical scheduler methods also exist on client.connector — same wire messages, no optimization difference (scheduler operations aren't route-related), so it makes no functional difference which one you call.

Error handling

Every method here returns a response object (MissionResponse/TaskResponse/SchedulerResponse) with success: bool and error: ErrorInfo | None — none of them raise for a business-level error, unlike client.connector's asset/payload/organization/policy methods (which raise ConnectorError; see Connector — Error handling). Only a transport failure raises, as grpc.aio.AioRpcError:

import grpc

try:
    response = await client.mission_autonomy.create_mission(mission)
except grpc.aio.AioRpcError as e:
    # Transport failure -- couldn't reach the platform at all.
    raise
else:
    if not response.success:
        # Platform-side rejection, e.g. validation failure.
        print(response.error.error_message)

See Functional Responses for what success actually confirms.