Drone and UAV programming

What drone programming includes

We write the logic of autonomous UAV missions and set up the flight controller on the client's hardware: the drone stays theirs, and we prepare the firmware, the routes and the in-flight behavior. The work includes planning aerial-survey and object-orbit routes, setting points of interest for inspection, calibrating the sensors, the failure modes and the geofences. We configure the PX4 or ArduPilot stack for the specific frame, gimbal and payload, and link the telemetry over MAVLink to the ground station. Separately we set up the return-to-home scenarios and the behavior on loss of communication and loss of satellites, so the craft doesn't go into uncontrolled flight. Drone programming at this level isn't assembling hardware but configuring the autopilot and writing the missions that this autopilot executes.

How an autonomous mission is set up

At the core lies a flight controller with an autopilot that reads the GPS, the inertial sensors, the barometer and the compass, and keeps the craft on the set trajectory. A mission is described as a sequence of waypoints with altitude, speed and actions at each point: take a shot, hover, turn the gimbal, change altitude. The ground station and the autopilot exchange commands and telemetry over the MAVLink protocol, so the operator sees the position, charge and status in real time. The stabilization and navigation algorithms recompute the control signals to the motors dozens of times per second, holding the course against wind and drift. Our part is to assemble this scenario, write the parameters and trigger thresholds so the client's craft executes the route predictably.

Where drone autopilots grew from

Modern open autopilots grew out of two projects of the late 2000s. The DIY Drones community appeared in May 2007, and Jordi Munoz, as early as late 2007, wrote a stabilization program for Arduino, out of which ArduPilot grew — he released version 1.0 together with Chris Anderson in 2009, and that same year his craft won the first Sparkfun AVC competition. In parallel, in Switzerland, Lorenz Meier launched the Pixhawk research project at ETH Zurich: work began around 2008, and in 2009 the first open developments on control and computer vision came out. By 2011 Meier's team had completely rewritten the stack from scratch — and so PX4 appeared in the form that underlies the current platform. These two lines, ArduPilot and PX4, are what define the practice of drone programming today.

Why software and precision decide it

Aerial survey and inspection give a usable result only with precise geo-referencing: a positioning error of a few meters shifts the orthophoto map and derails the building of a 3D model. The mission's precision is set by the autopilot setup — sensor calibration, the navigation filter parameters, the correct route geometry with frame overlap. No less important is legality: correctly set geofences, altitude limits and behavior on loss of communication keep the craft in the permitted zone and reduce the risk of a violation and a crash. The drone physically flies and shoots on its own, but the quality of the data and the safety of the flight are determined by the program and its setup, not just the characteristics of the frame and camera. That's why an error in a single fail-safe parameter costs more than the choice of the hardware itself.

Stack: PX4, ArduPilot, MAVLink

The working stack is built around two autopilots and one transport protocol. PX4 is a modular architecture on top of real time, convenient for integrating one's own modules and computer vision; ArduPilot is a mature stack with broad support for craft types and developed mission and failure logic. MAVLink links the autopilot with the ground station and external modules: compact binary messages carry telemetry, commands and mission parameters over the radio channel. On top of this we work with ground stations like QGroundControl and Mission Planner, and for programmatic control we connect to the autopilot via MAVLink commands. The specific choice between PX4 and ArduPilot is dictated by the client's task and their controller, not by habit — for both platforms we write missions and edit parameters on their hardware.

When the key tools appeared

The MAVLink protocol was developed by Lorenz Meier at ETH Zurich and released under the LGPL license in 2009 as part of the Pixhawk project. ArduPilot got MAVLink support in early beta versions in 2011, and PX4 included it at its launch around March 2012; by the same time MAVLink was picked up by the QGroundControl ground station. In 2017 MAVLink 2.0 came out — it added message signing to protect against command spoofing and extended packets up to 280 bytes. PX4 itself as a standalone platform took shape after the complete rewrite of the Pixhawk stack in 2011, and at the same time the NuttX RTOS was taken as the basis. These dates matter in practice: they set which firmware and message versions to consider the baseline when setting up the client's autopilot.

Why the task can be trusted to us

The combined experience of our development team in IT exceeds 45 years, and for us an autopilot is first and foremost software and its configuration, not the magic of hardware. We approach a mission as an engineering task: we fix the parameters, keep firmware versions and verify the craft's behavior in simulation and on the ground before the production flight. The failure scenarios, geofences and return-to-home are tested in advance so that the first real flight isn't a test of hypotheses. We don't manufacture drones and don't pass someone else's hardware off as our own — we program and set up the client's equipment, relying on PX4, ArduPilot and MAVLink. As a result the customer gets not a promise but a reproducible setup that can be verified by the logs and repeated on the next craft.