Mission planning and validation for transmedium unmanned vehicles, translating natural-language operator briefs into checked flight-controller parameters with safety interlocks.
A mission-programming adapter receives an operator mission brief expressed in natural language and compiles it into a validated set of mission parameters for a transmedium drone flight controller. A parser maps the brief to candidate parameters such as waypoints, depths, payload actions, and transition points. A validator checks the candidate parameters against vehicle limits, geofences, depth and altitude envelopes, and a rules base, and inserts or verifies medium-transition safety interlocks for each air-to-water and water-to-air transition. The adapter rejects or flags parameters that violate limits and requires explicit human authority for sensitive actions, providing a human-authority hand-off rather than autonomous decision-making for those actions. The adapter compiles and validates missions; it does not autonomously decide to interfere with crewed vessels, and any such action is gated to a human authority. The result is faster, less error-prone mission setup for a vehicle that crosses the air-water interface, with safety and authority constraints enforced at compile time and carried into the executable parameter set.
Programming a transmedium mission by hand is slow and error prone. An operator must specify waypoints, dive depths, payload actions, and the points at which the vehicle transitions between air and water, while respecting vehicle limits, geofences, and legal constraints. Mistakes at a medium transition are especially dangerous. Natural-language and block-based programming front ends for drones exist, and ground control stations validate some parameters, but known systems do not specifically compile a natural-language brief into a transmedium parameter set in which medium-transition safety interlocks are inserted and verified for each air-water crossing, nor do they bind sensitive actions to an explicit human-authority hand-off at compile time. There is also a risk that a natural-language interface is over-trusted and allowed to authorise sensitive or unlawful actions. There remains a need for an adapter that translates an operator brief into validated, limit-checked transmedium mission parameters, that enforces medium-transition interlocks, and that explicitly requires human authority for sensitive actions rather than letting the language model or planner decide autonomously, so that the convenience of natural-language tasking does not weaken safety or lawful control.
The invention provides a mission-programming adapter and method. A parser converts a natural-language operator brief into candidate transmedium mission parameters including waypoints, depths, payload actions, and medium-transition points. A validator checks the candidates against vehicle limits, geofences, depth and altitude envelopes, and a rules base, and for each air-to-water or water-to-air transition inserts or verifies a safety interlock, for example confirming a permitted entry attitude, a ballast precondition, or a rotor-inhibit. Parameters that fail validation are rejected or flagged for correction. Sensitive actions are tagged as requiring an explicit human-authority hand-off and cannot be armed by the adapter alone. The validated parameter set, with interlocks and authority gates embedded, is emitted to the flight controller in an executable form. The adapter compiles and validates missions and does not autonomously decide to interfere with crewed vessels; such actions are gated to a human authority. The result is faster, safer, and auditable transmedium mission setup.
FIG. 1 is a block diagram of the mission-programming adapter showing a natural-language input (80), a parser (82), a validator (84), a rules base (86), an interlock inserter (88), and an output to a flight controller (90). FIG. 2 is a flowchart of the compile and validate method. FIG. 3 is a schematic of a transmedium mission with waypoints, a dive segment, a transit depth, and air-to-water and water-to-air transition points. FIG. 4 is a detail of a medium-transition interlock record. FIG. 5 is a flowchart of the human-authority hand-off for a sensitive action. FIG. 6 is an example of a validation report returned to the operator. Referring to FIG. 1 and FIG. 2, the parser (82) receives the natural-language brief (80) and produces candidate mission parameters: a sequence of waypoints, commanded depths, payload actions, and the points at which the vehicle transitions between air and water. The validator (84) checks each candidate against vehicle limits, geofences, and the depth and altitude envelopes, and against the rules base (86), which encodes safety and legal constraints. Candidates that violate a limit are rejected or flagged with an explanation in the validation report (FIG. 6) so the operator can correct the brief. Referring to FIG. 3 and FIG. 4, for each air-to-water and water-to-air transition the interlock inserter (88) inserts or verifies a medium-transition safety interlock, for example a precondition on ballast state, entry attitude, depth confirmation, or rotor-inhibit, so the executable mission cannot cross the interface without the interlock being satisfied. Referring to FIG. 5, actions tagged as sensitive, including any action affecting other vessels, are bound to a human-authority hand-off: the adapter marks the action as requiring explicit human authorisation and does not arm it autonomously. The validated parameter set, carrying its interlocks and authority gates, is emitted to the flight controller (90) in an executable form, and a record of the compilation, including which rules were applied and which actions require hand-off, is retained for audit. In an embodiment the parser is a language model whose output is constrained to the validator schema, so the language model proposes but the validator and rules base dispose.
| Patentability | 62.0% |
| Prior-art position | 52.0% |
| Technical merit | 64.0% |
| Commercial | 60.0% |
| Composite genius score | 59.9/100 (Marginal) |