A drone mission is a program. In most systems today somebody writes it in code, or clicks through a form and hopes.
Blueprints, For Drones
Mission Control is a no-code editor that lets the person who actually understands the mission build its logic themselves, by connecting blocks on a canvas. Take off, fly this perimeter, hold if the battery drops below reserve, come home.
The reference was Unreal Engine’s Blueprint system. If a game designer can build complex behaviour visually without touching C++, an operator should be able to plan a survey flight without touching Python.
Mission Control. A no-code HMI for high-stakes mission orchestration, designed end to end.
The Gap Worth Closing
Drone operations are unforgiving in a specific way. There is a gap between the person who understands the mission and the person who can express it in code, and every handoff across that gap is a chance to lose intent.
These mistakes do not fail politely. A wrong sequence is a lost aircraft, a violated airspace boundary, or worse.
The framing. Code-first tools bury risk in logs, fragmented panels slow down state parsing, and safety ends up reactive rather than built in.
One View, Four Regions
The interface is a single screen on purpose. A block library on the left, the phase canvas in the middle, an inspector on the right, and the generated code with its live errors underneath.
Operators do not get to hunt through tabs while an aircraft is airborne. Everything needed to answer "what will this thing do next" stays in peripheral vision. Tabs are a filing decision, and filing is the wrong thing to be doing under time pressure.
Library, canvas, inspector and faults in one operator view. Nothing about a mission requires leaving this screen.
Colour Carries Risk, and Nothing Else
Cyan is normal. Orange is a warning. Red is critical. Three states, and colour is used for nothing else in the entire interface.
That restraint is the whole trick. The moment colour also means "selected" or "primary action", the operator learns to filter it out, and the day it means "your battery reserve will not get you home" they filter that out too.
Multi-condition gates, battery reserve checks and return-to-base routes all inherit the same three-step scale, so risk reads identically wherever it appears on the canvas.
Safety logic on the canvas. One scale, applied everywhere, so severity never has to be decoded.
Glass Box, Not Black Box
The editor writes real code, and it shows it. The generated source sits under the canvas with errors inline, next to a plain-language mission brief.
Two audiences, one screen. The operator reads the brief in order to fly. The engineer or the auditor reads the code in order to sign it off. A no-code tool that hides its own output cannot be trusted with anything consequential, so this one does not hide it.
The generated code and the mission brief, side by side. Clarity for execution on one side, transparency for audit on the other.
Where It Stands
Mission Control is a design project: an end-to-end HMI concept taken to a high-fidelity prototype, with its own design system, information architecture and interaction model.
It has not flown an aircraft. The safety model here is designed and argued, not certified, and the distance between those two things in aviation is considerable. I would want a real operator to break it before I claimed anything more.