We build on PX4 and ArduPilot. When neither fits, we build the stack.
Open flight firmware is the right starting point for almost every program. Knowing when it isn't — and being able to do something about it — is the difference.
PX4
The stack we reach for on programs that need a clean module architecture, uORB messaging, ROS 2 via uXRCE-DDS, and a strong multicopter / VTOL controller lineage. Best fit for research-grade autonomy and companion-heavy designs.
PX4 services →ArduPilot
The stack we reach for when vehicle breadth matters: ArduCopter, ArduPlane, TradHeli for traditional helicopters, Rover and Sub. Mature failsafe handling, Lua scripting, and a deep parameter surface. Note the GPL obligations — we'll walk you through them.
ArduPilot services →Custom flight stack
We don't ship a proprietary firmware today, and we won't pretend to. But when a program's licensing, certification path or control architecture rules out PX4 and ArduPilot, we are prepared to write the stack — and we'd rather say so plainly than sell you a fork.
Custom firmware →PX4 vs ArduPilot vs custom — how we decide
| Consideration | PX4 | ArduPilot | Custom |
|---|---|---|---|
| License | BSD-3, permissive | GPL-3, copyleft | Yours |
| ROS 2 / companion integration | Native (uXRCE-DDS) | Via MAVLink / DDS bridge | Designed in |
| Traditional helicopter support | Limited | Strong (TradHeli) | Designed in |
| Scripting without rebuild | Limited | Lua scripting | As required |
| Certification / DO-178C path | Difficult | Difficult | Possible, expensive |
| Time to first flight | Weeks | Weeks | Months to years |
The honest default is: use PX4 or ArduPilot. We propose a custom stack only when we can write down the specific requirement the open stacks can't meet, and we put that reasoning in the architecture document so you can argue with it.
Firmware services
- Board bring-up for new flight controller hardware and custom carrier boards
- Sensor and peripheral drivers (IMU, barometer, rangefinder, airspeed, ESC telemetry, CAN / DroneCAN)
- Custom flight modes and mode-transition logic
- Mixer and actuator allocation for non-standard airframes (coaxial, tilt-rotor, hybrid VTOL, heli)
- Control-loop tuning with logged flight data, not guesswork
- Failsafe, geofence and flight-termination behavior
- Upstream-tracking forks with a documented rebase strategy, so your customizations don't rot
Tell us the airframe and the flight controller.
We'll tell you which stack we'd start from, and why.
Start a project