Designing FlightLang: Exploring a Domain-Specific Language for UAV Missions

Unmanned aerial vehicles are often discussed in terms of hardware. Airframes, batteries, sensors, and flight controllers dominate most conversations about drones. Yet the real complexity of autonomous systems rarely lies in the hardware alone. It lies in the logic that determines how the system behaves.

A drone that surveys a location, follows a route, or reacts to obstacles is not simply executing commands. It is following a structured sequence of decisions, constraints, and transitions that determine what happens next.

In practice, this logic is often expressed through a mix of configuration files, mission planners, scripts, and embedded code. Each tool solves a specific problem. None of them necessarily provide a single, coherent way to express mission intent.

The result is that mission behavior can become difficult to read, difficult to validate, and difficult to simulate in a structured way.

FlightLang began as a small exploration of whether that mission logic could be expressed differently.

The Case for a Domain-Specific Language

Domain-specific languages appear in many areas of computing. SQL expresses queries against data. CSS expresses layout and presentation rules. Infrastructure tools often use declarative languages to describe systems rather than implement them procedurally.

The common idea behind these languages is that certain problems benefit from being described in the vocabulary of the domain itself.

UAV missions are a strong candidate for this type of approach.

Most missions follow a predictable conceptual structure. A vehicle begins in a defined state, transitions between states based on events or conditions, and performs actions during those states. Timing constraints, sensor requirements, and safety conditions influence these transitions.

Despite this structured nature, the logic is often scattered across multiple tools and layers of code.

A domain-specific language for flight missions offers an alternative perspective. Instead of writing procedural instructions, the developer describes the mission in terms of states, events, and transitions.

This approach does not replace existing flight control systems. Rather, it explores whether mission logic can be represented in a form that is easier to reason about, analyze, and simulate.

FlightLang is a proof of concept built around this idea.

Designing the Language Around States

The core structure of FlightLang revolves around missions and states.

A mission represents the overall task the vehicle is attempting to complete. Within that mission, individual states define distinct phases of behavior. Transitions between states occur when events happen or conditions are met.

This structure mirrors how many real-world mission systems already behave internally, but makes that structure explicit in the language itself.

A simplified example might look like this:

mission Survey

state Takeoff
  on reached_altitude -> Transit

state Transit
  on reached_waypoint -> SurveyArea

state SurveyArea
  deadline 30 s
  on timeout -> ReturnHome

state ReturnHome

Even in this minimal form, the mission reads more like a description of behavior than a set of instructions. The structure highlights the flow of the mission rather than the mechanics of implementing it.

The goal of this approach is clarity. When the mission logic is expressed directly, it becomes easier to understand how the system is expected to behave.

Units as Part of the Language

Another design consideration in FlightLang is the treatment of units.

Flight systems operate within physical constraints. Distances, velocities, altitudes, and timing values all play an important role in determining safe and predictable behavior. In many programming environments these values are represented as raw numbers, leaving it up to developers to remember the intended unit.

This can lead to subtle errors, particularly when multiple systems interact.

FlightLang experiments with making units explicit within the language itself. Values such as meters, seconds, or milliseconds can appear directly in mission definitions.

For example:

deadline 50 ms
sidestep(5 m)

The idea is that the language can eventually reason about these units and validate whether they are being used correctly. The current proof of concept only explores this capability in a limited form, but the design direction is clear. Unit awareness has the potential to make mission definitions safer and easier to verify.

Simulation as a First-Class Idea

Mission logic is often tested only after it is connected to a real system or a complex simulation environment. That workflow can make experimentation slow and increases the cost of mistakes.

FlightLang approaches the problem differently by treating simulation as part of the language pipeline from the beginning.

The current proof of concept includes a simple runtime that interprets mission definitions and simulates their state transitions. The simulator is intentionally minimal. It is not designed to model flight physics or environmental conditions.

Its purpose is more basic. It allows the mission logic itself to be executed and observed.

This separation between mission logic and the underlying flight system creates an interesting possibility. Missions could eventually be validated, analyzed, or simulated independently of the hardware that will execute them.

Even in an early prototype, this idea suggests a useful direction for experimentation.

What the Proof of Concept Demonstrates

The first FlightLang proof of concept focuses on the structure of the language rather than the completeness of its implementation.

The prototype currently includes a simple toolchain composed of several stages.

A lexer and parser transform FlightLang files into an internal representation of the mission structure. A lightweight type checking phase performs limited validation, particularly around units. A code generation stage prepares the mission for execution. Finally, a small runtime simulator executes the mission and traces its state transitions.

A command line interface ties these components together, allowing example mission files to be parsed and executed.

This implementation is intentionally modest. The goal is not to create a production-ready system but to explore whether the language design itself makes sense.

Limitations of the Current Prototype

Because FlightLang is a proof of concept, many aspects of the language remain incomplete.

The expression system is minimal and supports only a subset of potential operators. The unit type system is exploratory rather than comprehensive. The simulator models only state transitions rather than real-world dynamics.

These limitations are expected at this stage. The purpose of the project is to test whether the design direction is promising before investing in deeper implementation.

Language design is often iterative. Early prototypes help reveal whether the underlying structure is intuitive and whether the ideas hold up when expressed in real examples.

FlightLang is currently at that exploratory stage.

Looking Ahead

Several areas of the language could evolve as the project develops.

The expression system could expand to support richer conditions and validation rules. The type system could incorporate stronger unit checking and safety constraints. Static analysis could detect unreachable states, unsafe transitions, or conflicting timing requirements.

Integration with existing flight ecosystems is another possible direction. Mission definitions could eventually generate configuration or code for systems that already control UAV hardware.

Equally interesting is the potential for deeper simulation and analysis tools built around the language itself.

All of these possibilities remain open questions.

Why Explore This Idea

FlightLang is not an attempt to replace existing flight control systems or mission planning tools. Those systems are the result of many years of engineering and operational experience.

Instead, the project explores a narrower question:

What would mission logic look like if it were treated as a language in its own right?

By experimenting with that idea, even in a small proof of concept, it becomes easier to understand how mission behavior might be expressed more clearly, validated more reliably, and simulated more easily.

Whether FlightLang itself evolves further is less important than the insights gained through the process of designing it.

Sometimes the most valuable outcome of a proof of concept is not the software it produces, but the questions it raises about how systems can be described, reasoned about, and improved.