Click To Fly Mission Replanning (Force Parameter)

Andi Lamprecht ·2026-05-11· 8 min read· Accepted

Title

Context

A “Normal/Abnormal” Click-to-Fly is one, following which, the operator resumes the mission (as opposed to triggering a failsafe and eventually landing the UA).

Following such Click-to-Fly:

• The mission needs to be replanned at least to the next (not completed) objective. This implies updating the flight intent.
• If Click-to-Fly causes sufficient delay that the mission falls out of its flight reservation, the entire mission needs to be replanned.

The main question is: who does the replanning, the onboard software or the Missions Service?

The Missions Service is the only component that can plan missions and it has a replanning API. Notably, the onboard Uncrew can plot paths to a destination, but can’t tell mission items from objectives and it can’t plan deliveries or spin360s (an ersatz of future ISR lawnmower scanning patterns). The replanning API has been introduced when preparing for a demo and as such it may have been hastened. For once, it asks to specify the last completed mission item, while the Missions Service should be well aware of what that is.

The replanning API fits well into the Click-to-Fly scenario:

  sequenceDiagram

    participant Frontend
    participant MissionsService
    participant Avatar
    participant Onboard Uncrew
    participant UTM

    Frontend->>Avatar: Click-to-Fly
    Avatar->>Onboard Uncrew: Click-to-Fly

    activate Frontend
    Frontend->>Frontend: Resume Mission
    activate Frontend
    Frontend->>MissionsService: ReplanMission
    activate MissionsService
    MissionsService->>UTM: Update Flight Intent
    MissionsService->>Avatar: AssignMission
    activate Avatar
    Avatar->>Onboard Uncrew: AssignMission
    deactivate Avatar
    deactivate MissionsService
    Frontend->>MissionsService: StartMission
    activate MissionsService
    MissionsService->>Avatar: StartMission
    activate Avatar
    Avatar->>Onboard Uncrew: StartMission
    deactivate Avatar
    deactivate MissionsService
    deactivate Frontend
    deactivate Frontend

However, the above sequence doesn’t address the autonomous analogue of Click-to-Fly where it’s the UA that evades a crane it sees in its front. Such UA might choose to hold and ask the MissionsService for a new plan, which would be futile because the MissionsService isn’t aware of the crane. The UA could then file for a new plan also submitting the position of the crane it sees or deposit the position of the crane into the Geodata Service beforehand.

We could then adopt the sequence diagram to cover the onboard origin of the ReplanMission request

   sequenceDiagram

    participant MissionsService
    participant Avatar
    participant Onboard Uncrew
    participant UTM

    activate Onboard Uncrew
    Onboard Uncrew->>Avatar: ReplanMission
    activate Avatar
    Avatar->>MissionsService: ReplanMission
    activate MissionsService
    MissionsService->>Avatar: AssignMission
    activate Avatar
    Avatar->>Onboard Uncrew: AssignMission
    activate Onboard Uncrew
    deactivate MissionsService
    deactivate Avatar
    deactivate Avatar
    deactivate Onboard Uncrew
    Onboard Uncrew->>Onboard Uncrew: StartMission
    deactivate Onboard Uncrew

But which MissionsService instance will exactly listen to which Avatar and what happens when one is scaled down?

This implies that the only way the onboard software can urge the MissionsService to replan is to deposit something onto the FlightLog. Every instance of MissionsService listens to the FlightLog-bearing PubSub.

Decision

The UA-initiated detour+replan shall look like so:

```mermaid

   sequenceDiagram

    participant Frontend
    participant MissionsService
    participant FlightLog
    participant Avatar
    participant Onboard Uncrew
    participant UTM

    activate Onboard Uncrew
    Onboard Uncrew->>Avatar: ReplanMission
    activate Avatar
    Avatar-->>FlightLog: MissionReplanNeeded
    FlightLog-->>MissionsService: MissionReplanNeeded
    deactivate Avatar
    deactivate Onboard Uncrew
    activate MissionsService
    MissionsService->>MissionsService: ReplanMission
    activate MissionsService
    MissionsService->>Avatar: AssignMission
    activate Avatar
    Avatar->>Onboard Uncrew: AssignMission
    activate Onboard Uncrew
    deactivate Onboard Uncrew
    Avatar->>UTM: Update Flight Intent
    activate UTM
    deactivate UTM
    deactivate MissionsService
    deactivate MissionsService
    deactivate Avatar
``

The operator-initiated detour+replan could look like so:

```mermaid

   sequenceDiagram

    participant Frontend
    participant MissionsService
    participant FlightLog
    participant Avatar
    participant Onboard Uncrew
    participant UTM

    activate Frontend
    Frontend->>Avatar: Click-to-Fly
    activate Avatar
    Avatar->>Onboard Uncrew: Click-to-Fly
    activate Onboard Uncrew
    deactivate Onboard Uncrew
    deactivate Avatar
    deactivate Frontend
    Note over Frontend: Pilot awaits for UA to reach the Click to Fly destination
    activate Frontend
    Frontend->>Frontend: Resume Mission
    activate Frontend
    Frontend->>MissionsService: StartMission
    activate MissionsService
    MissionsService->>Avatar: StartMission
    activate Avatar
    Avatar->>Onboard Uncrew: StartMission
    activate Onboard Uncrew
    Onboard Uncrew-->>Avatar: error: replan needed
    Avatar->>MissionsService: error: replan needed
    deactivate Avatar
    deactivate Onboard Uncrew
    MissionsService->>MissionsService: ReplanMission
    activate MissionsService
    MissionsService-->>Frontend: ReplanningMission
    MissionsService->>Avatar: AssignMission
    activate Avatar
    Avatar->>Onboard Uncrew: AssignMission
    Avatar->>UTM: Update Flight Intent
    MissionsService-->>Frontend: MissionReplanned
    deactivate MissionsService
    deactivate Avatar
    MissionsService->>Avatar: StartMission
    deactivate MissionsService
    deactivate Frontend
    deactivate Frontend

But that introduces a potentially long delay in responding to pilot’s ResumeMission and brings up the question: should the pilot be allowed to approve the replanned mission? Instead the system can try replanning the mission speculatively, already when commencing the Click-to-Fly detour:

```mermaid

   sequenceDiagram

    participant Frontend
    participant MissionsService
    participant FlightLog
    participant Avatar
    participant Onboard Uncrew
    participant UTM

    activate Frontend
    Frontend->>Avatar: Click-to-Fly
    activate Avatar
    Avatar->>Onboard Uncrew: Click-to-Fly
    activate Onboard Uncrew
    activate Onboard Uncrew
    Onboard Uncrew ->> Onboard Uncrew: Start Flying
    deactivate Onboard Uncrew
    Note over Onboard Uncrew: Speculatively asks for MissionReplan from the Click-to-Fly destination
    Onboard Uncrew->>Avatar: ReplanMission
    activate Avatar
    Avatar-->>FlightLog: MissionReplanNeeded
    FlightLog-->>MissionsService: MissionReplanNeeded
    deactivate Avatar
    deactivate Avatar
    deactivate Onboard Uncrew
    activate MissionsService
    MissionsService->>MissionsService: ReplanMission
    MissionsService-->>Frontend: ReplanningMission
    activate MissionsService
    MissionsService->>Avatar: AssignMission
    activate Avatar
    Avatar->>Onboard Uncrew: AssignMission
    Avatar->>UTM: Update Flight Intent
    deactivate MissionsService
    MissionsService-->>Frontend: MissionReplanned
    deactivate MissionsService

    deactivate Avatar
    deactivate Frontend

    Note over Frontend: Pilot can only resume mission after replanning
    activate Frontend
    Frontend->>Frontend: Resume Mission
    activate Frontend
    Frontend->>MissionsService: StartMission
    activate MissionsService
    MissionsService->>Avatar: StartMission
    activate Avatar
    Avatar->>Onboard Uncrew: StartMission
    activate Onboard Uncrew
    MissionsService->>Avatar: StartMission
    deactivate Frontend
    deactivate Frontend

If the pilot chooses to issue another Click-to-Fly, then the replan effort is wasted and the mission a throw-away, but we accelerate the readiness of the UA to resume the mission and offer the Frontend a good trigger to disable/enable the Resume Mission button (disable when replanning).

Let’s note that the interaction between Uncrew and UTM moves to Avatar as per [ADR-0112]

Onboard Uncrew doesn’t have the ability to plan missions (maybe one day it will), but it can execute smart RTL or consult the Pathfinder when working out which way to fly to the Click-to-Fly destination. In both cases it has to tell the backend what it’s up to. This is what [ADR-0112] posits, but it has to change ([ADR-0112] is hereby superseded) because it overlooks the question on when should Avatar send MissionPlanUpdate to the MissionsService (only when the plan comes from the Onboard system and not.. from the MissionsService).

```mermaid

   sequenceDiagram

    participant Frontend
    participant MissionsService
    participant FlightLog
    participant Avatar
    participant Onboard Uncrew
    participant UTM

    activate Onboard Uncrew
    Onboard Uncrew->>Avatar: MissionPlanUpdate
    activate Avatar
    Avatar->>UTM: Update Flight Intent
    activate UTM
    deactivate UTM
    Avatar-->>FlightLog: MissionPlanUpdate
    FlightLog-->>MissionsService: MissionPlanUpdate    
    activate MissionsService
    deactivate MissionsService
    deactivate Avatar
    deactivate Onboard Uncrew

The Avatar gains

service UAVRequestToMissionService {
    rpc ReplanMission(ReplanMissionRequest) returns(ReplanMissionResponse);
}

Dealing with Errors and Emergencies

UERQ-SYS-231 (“Emergency over Deconfliction”) asks

“For emergency operations, click-to-fly commands should not be denied due to airspace conflicts.“

WaypointUAVCommand is essentially a goto or Click-to-Fly. It asks the UA to detour and fly to the given destination.

The force parameter proposed for WaypointUAVCommand may seem cryptic and deserves clarification. The Click-to-Fly procedure can encounter an error because UTM is temporarily unavailable (Avatar responds with error that isn’t a rejection nor acceptance, just a failure to communicate with the UTM when updating the flight intent). Uncrew can (especially in emergencies) chose to surface this failure to the pilot and ask them if they still want to Click-to-Fly. This is where the pilot can say WaypointUAVCommand(force=1)where they instruct the Onboard system to ignore errors. Likewise Click-to-Fly can encounter a conflict (rejection from UTM), which it also may choose to surface to the pilot so the pilot can confirm WaypointUAVCommand(force=2) that, on their responsibility, they want to ignore not just errors, but also positively identified conflicts. This implements UERQ-SYS-231.

The force argument can’t enforce this 2-way handshake from the Frontend as the Frontend can be configured to issue WaypointUAVCommand(force=2)on the first attempt. This gives Uncrew the flexibility to implement different flows, but it may be seen as a security loophole. Uncrew can have the Frontend implement the 2-way handshake, but the pilot can chose to circumvent and issue the command directly w/o the Frontend. We conclude this is not an attack vector, as even if we did enforce the 2-way handshake, the JWT-holding attacker could simply play ball achieving the same result.

The support for the force parameter should be configurable initially at install-time and later, when we have dynamic setting management in place, at runtime.

Overall, the force parameter will be utilized according the the following matrix:

UA Disconnected

The Operator and MissionsService always need to know the current mission plan, even in cases when UA establishes a connection after a connection loss and flight plan change. To support this, the UAV should enclose the current mission plan each time it connects to Avatar with  SubscribeUAVCommands.

Consequences

• We unify the flow of control for regular planning and user- vs UA- initiated replanning and establish, what we hope, is the correct separation of concern.

• We choose to use PubSub for notifying MissionsService that a new plan is needed while PubSub’s SLA have been seen, very infrequently, to cause a long delay. We consider this risk mitigable in two ways:

  • Have frontend alert the operator that its vehicle is seemingly idle awaiting something;
  • This aspect of PubSub SLA is hurting us elsewhere (timely delivery of telemetry to UTM and DSS) so the correct solution might be to replace PubSub.

Alternatives Considered

Onboard Mission Replanning

Moving the mission planning function onboard is an option, but there is no problem it solves at this stage.

The “what if the UA is disconnected” argument is immaterial, as then we’re entering emergency scenarios and will be aborting the mission.

UAVRequestToMissionService

ReplanMission should be mentioned in the FlightLog, so we could add it into the existing telemetry rpc Avatar exposes to UA.

Other than: ReplanMission is clearly a request, not telemetry, we don’t have strong arguments either way.

Formal Impact

List any systems or services that are impacted by this architectural decision.