How Can a Drone Command Be Checked Before Execution?

• Command to validate
• Condition-checking gate
• Allowed sending branch

What you will learn

• Distinguish structural, value-range and semantic checks.
• Trace a proposal through decisions made before execution.
• Explain the separate roles of logs, human oversight and a failsafe.

Before you start

No drone programming experience is needed; the example uses a simulated request with an action, direction and distance.

Why does validation need multiple steps?

A schema can confirm that data has the expected shape, but that does not tell us whether a request is valid now. Think of a request form: first check that its fields are present, then check that values fit the accepted range, and finally ask whether the request fits the current situation.

JSON Schema lets validation keywords apply constraints to a data instance. In the illustrative design, the schema expects an object with action, direction and distance_m; the action and direction must come from options supported by the application, while distance must have a numeric type. These fields and limits are choices for the example, not a standard drone command format. The structural gate rejects free text, a missing required field, a wrong type such as distance represented as a string, or an unexpected field the design does not allow.

A package that passes this gate is only structurally valid. It might still contain a direction the application does not support or a distance outside its configured range. Reporting “schema valid” as if the command were approved confuses formatting with a decision. If the data fails, the validator returns the field and reason; the interface can ask for a corrected proposal without creating a task.

Value ranges and current state answer different questions

A value-range check asks whether each field falls within the application’s accepted set: is the direction a valid option, is the distance a finite number within the configured limit, and is the action supported? These are application rules applied to the data; JSON Schema does not know them from a drone automatically.

A semantic check uses current state to ask whether a well-formed request can be accepted now. In the simulated example, “move forward” has all its fields, but is rejected if position data is stale or another task already owns control. If required state is missing, the system defers or rejects with an “insufficient data” reason rather than silently assuming a value.

This order makes failures easier to understand: check meaning only after the data is parseable; create a task only after both values and state pass. This is an illustrative design, not default PX4 behaviour.

How do people, logs and failsafes fit?

The NIST AI RMF calls for human-oversight processes to be defined, assessed and documented. In this example, an operator sees a preview containing the original utterance, extracted fields, state read and result of each gate. The operator can accept, request clarification or reject. Oversight does not make model output true; it is a decision right specified by the design.

A log could record a request identifier, receipt time, configuration version, normalized fields, input state, stopping gate and reason. Audio need not be retained unless it serves an inspection purpose; personal data should be limited according to the system’s policy. These fields are an architectural proposal, not a NIST-prescribed log format. They let a team identify whether a failure came from type checking, state checking or the operator decision.

The autopilot failsafe has a separate job: respond to configured vehicle fault conditions. PX4 documentation says most failsafes default to Hold before the associated action, giving the user time to notice and override. That does not replace command validation before execution, and it does not mean every rejected proposal will trigger a failsafe. A rejection is an application decision; a failsafe responds to vehicle conditions.

Walkthrough: one request crosses the gates

Hypothetical simulator scenario, not a test result.

A user says, “move forward about three metres.” Speech recognition returns text, then the command-understanding component creates a proposal with action, direction and distance. The first version lacks distance: the structural check stops and records missing_field; no task is sent. After the user clarifies, the range checker verifies the type and application-defined limit. The semantic checker reads the latest simulated state, then the interface shows a preview to the operator.

If state is stale or the operator declines, no task is created. If accepted, the system may pass the proposal to the next coordinator. The log preserves the reason for the branch taken so a developer can reproduce the issue. The example does not claim that a simulator or autopilot supplies these gates automatically; they are application components to design and test separately.

Common misunderstanding

A command that matches a schema suits the situation. A schema checks data; domain rules, state and a responsible person’s decision are still needed.

Frequently asked questions

How is a structural check different from a range check?

Structure checks a package’s shape and types. A range check asks whether the application accepts the values.

When should a semantic check run?

After the package is parseable and its values pass their rules, but before creating a task. It uses current state to catch unsuitable or unsupported requests.

What should a log help explain?

It should show which gate stopped a request, which configuration and state informed the decision, and the reason.

Summary

• Check structure first, value ranges next, and state last.
• Create a task only after acceptance; clarify or reject missing fields and stale state.
• An operator reviews proposals and logs; a failsafe handles configured vehicle faults.