Is ROS 2 Good for Drones?

ROS 2 is a good choice for a drone's companion computer and a poor choice for its flight controller, which belongs to PX4 or ArduPilot. The flight stack keeps the aircraft in the air on its own hardware, while ROS 2 or a middleware such as HORUS runs the camera, mapping and decision work above it. The verdict flips when everything must run on one small computer. The rest of this post is for someone with a working airframe deciding what to put on the computer riding on top of it.

The quadcopter flies. It holds position in a light wind, it comes home when the link drops, and the autopilot did all of that before you wrote a line of code. What you want now is for the aircraft to do something with its eyes: follow the rows in a field, circle a tower and come back with photographs that line up, land on a platform that is moving.

Every answer online is ROS 2, and every tutorial shows a simulated aircraft taking off inside a simulator on a desktop machine. None of them tell you what happens outdoors, on battery, with the laptop in a car park two fields away. You have also read, in the same afternoon, that ROS 2 is not suitable for anything with a hard deadline and that plenty of flying machines use it, and you cannot make those two statements sit together.

Meanwhile the airframe is real, the payload has a mass budget you have already exceeded once, and every extra board costs flight time. The question you actually have is not whether ROS 2 is good software. It is which part of your aircraft it is allowed to touch.

Should you build a drone on ROS 2?

Yes for the autonomy on top, no for the flying itself, and that division is not a compromise but the standard architecture of every serious autonomous aircraft. The flight controller board runs PX4 or ArduPilot, keeps the aircraft level, follows waypoints, and cuts to a failsafe when something stops answering. It is a small computer doing one job, with firmware written so that job never waits for anything else.

Above it sits a companion computer, which is where cameras, maps, models and decisions live, and where ROS 2 belongs. The two talk over a serial link with a narrow, well-defined vocabulary: go here, hold, take a picture, tell me where you think you are.

That split is what makes the confusing advice make sense. When people say ROS 2 is unsuitable for flight, they mean the stabilisation loop, and they are right. When other people say drones run ROS 2 constantly, they mean the layer above, and they are also right.

The failure mode to avoid is letting the boundary blur. If any part of keeping the aircraft in the air comes to depend on a program on the companion computer, you have built an aircraft that falls out of the sky when a piece of Linux software has a bad afternoon.

What does the software on a drone actually have to do?

Drone software does three jobs on very different timescales, and every architecture question comes down to which layer a piece of code belongs in. The first job is staying in the air: reading the inertial sensors and adjusting motor speeds continuously, forever, without a pause. Miss that job for even a moment and the aircraft tips. It runs on the flight controller and nowhere else.

The second job is going somewhere: following a route, holding a position against wind, returning home, arming and disarming, and refusing commands that would fly the aircraft into the ground. This also lives in the flight stack, and it is the part most people never need to modify, because PX4 and ArduPilot have been doing it for years across an enormous number of airframes.

The third job is understanding: what the camera sees, where the aircraft is when satellite positioning is unreliable, which way to turn to keep a target in frame, whether the landing pad below is actually the landing pad. This job is heavy, needs a real processor, and is where all the interesting work happens.

Middleware, of any kind, is a tool for the third job and occasionally the edge of the second. It has no business inside the first.

What are the real software options for a drone?

There are seven arrangements that people actually fly, and most projects use two or three of them together. PX4 and ArduPilot are the open flight stacks, and choosing between them is its own long argument that has nothing to do with middleware. MAVLink is the protocol they speak, and MAVSDK-style libraries let a single program command a flying aircraft without any framework at all, which is the right answer for one bounded behaviour. ROS 2 on a companion computer is the standard for anything involving perception, and recent PX4 releases can speak to ROS 2 directly, while older arrangements use a translating bridge. HORUS is an open-source real-time robotics middleware for Rust, Python and C++ in which all three languages share the same shared-memory ring buffers, so messages between programs on one onboard computer are not serialised; it is Apache-2.0, it is validated in simulation, and it addresses programs interfering with each other on the companion computer rather than the ecosystem of drone packages that ROS 2 brings.

Below those sit micro-ROS for payload microcontrollers, and above them sit the closed vendor platforms, where the aircraft is bought finished and you write against the manufacturer's SDK inside whatever limits the manufacturer allows.

How do the drone software options compare?

Start with the last column, because a drone project is usually eliminated into its answer rather than argued into it. Weight, battery and airspace rules remove most of the table before any technical preference gets a vote.

What goes wrong when ROS 2 runs the wrong part of a drone?

The classic failure is an aircraft that flies beautifully until the perception program gets busy, and then flies badly in a way nobody can reproduce on the bench. The pattern is always the same: something on the companion computer was quietly load-bearing, the companion computer got busy, and the aircraft noticed.

Concretely, it looks like a drone that holds position perfectly in an empty room and drifts once the mapping program starts. It looks like a landing that goes fine on a cool morning and wanders in the afternoon when the little computer heats up and slows itself down to survive. It looks like a link between aircraft and ground where messages arrive in bursts, so the aircraft alternates between confident and lost.

The second classic failure is discovery on a wireless link. ROS 2 assumes a friendly local network by default and behaves accordingly, which is fine in a lab and unpleasant across a field, and the symptoms are strange enough that people blame the aircraft. If your ground link is the suspect, why ROS 2 struggles on ordinary wireless networks explains that specific failure better than any drone-shaped answer.

The cure for both is the same rule: nothing the aircraft needs in order to stay safe may live off the flight controller.

Are you flying a hobby quad, a research platform, or a product?

A hobby quad rarely needs any middleware, a research platform almost always wants ROS 2, and a product usually ends up with a narrow custom layer plus a flight stack. For a hobbyist adding one behaviour, a single program talking MAVLink to the autopilot is complete, and it will fly this weekend instead of next month.

Research is where ROS 2 wins outright, and not narrowly. Mapping, visual positioning, object detection, multi-aircraft coordination and simulation all exist as packages somebody else has debugged, papers are published with code that assumes them, and a student joining in October can be productive by November. Choosing anything else in a lab means rebuilding tools instead of doing the work you are funded for.

Products face a different pressure, which is that everything onboard must be justified to somebody eventually: an auditor, an insurer, a regulator, or a customer whose site you are flying over. That pressure pushes teams toward a small, well-understood set of software on the aircraft, and often toward keeping the interesting work on the ground or in review afterwards.

What computer is riding on the drone?

The board bolted to the airframe decides more than any preference does, because on an aircraft every choice is paid for in flight time. A small single-board computer can run ROS 2 and a camera pipeline together, and it will get warm, draw current and cost you minutes in the air. That is a real trade and not a footnote: a shorter flight can mean a mission that needs two batteries instead of one.

If the payload computer is a capable module with a graphics processor, you have room to be relaxed about architecture, and most of this article's warnings soften. If it is the smallest board you could fit, the calculus changes: every process is competing for a modest amount of computing power, and processes competing is exactly when programs start missing the moments they were supposed to act on.

If there is no companion computer at all, only the flight controller, then ROS 2 is not part of the conversation and micro-ROS is the only version of that world that fits. Some of the best small drones are built this way, with the autopilot doing everything and a microcontroller handling one clever payload.

How soon does the drone have to fly a real mission?

If the first real flight is weeks away, use the flight stack and a single script; if it is quarters away, build the layer properly. The reason is that drone projects lose their time in places software people do not expect: airspace permissions, weather windows, a propeller that arrives late, the day spent discovering that the camera mount vibrates at exactly the wrong frequency.

Setting up a full framework on a companion computer is not the hard part of a drone project, but it is a part that competes directly with flying days, and flying days are the ones that teach you what the aircraft actually does. A team that spends its good-weather week on software integration usually pays for it in the autumn.

The reasonable compromise, and the one most experienced teams reach, is to fly early with the simplest thing that commands the aircraft, and to introduce the heavier layer only once the mission is understood and the behaviour is stable. That order also means the framework arrives when you can describe what you need from it, rather than when you are guessing.

What does your team already know how to do?

The skills already on the team matter more on a drone than on a ground robot, because an aircraft punishes learning-on-the-job in a way a rolling machine does not. A team that has flown things before knows to test failsafes deliberately, to bench the payload before flying it, and to treat every new process on the companion computer as a potential source of trouble. A team that has only written software tends to discover those habits by losing an airframe.

If your engineers know ROS 2 from ground robots, that knowledge carries over cleanly to the companion computer, and the drone-specific part is the flight stack's vocabulary rather than the middleware. If your engineers are embedded people who have lived inside autopilot firmware, they will be more comfortable extending the flight stack and treating the companion computer as a subordinate accessory, which is also a legitimate architecture.

The mixed-language question is worth naming too. Vision work tends to arrive in Python, and the control-adjacent parts tend to be written in C++ or Rust, and the boundary between those is where drone software gets untidy.

What do you give up by putting ROS 2 on a drone?

You give up mass, power and simplicity, and on an aircraft those are the three things you never have spare. A companion computer needs mounting, cooling, a power supply that survives motor noise, and a share of the battery that would otherwise be flight time. Every one of those is a mechanical problem before it is a software problem.

You give up a certain kind of confidence. A flight stack alone is a known quantity with years of incident reports behind it. Add a Linux computer running a stack of processes and you have added a component whose failure modes are less predictable and less well documented in the aviation sense, which matters as soon as anyone official asks what happens when it stops.

You also give up some ability to reason about timing. Once several programs share one onboard computer, the question of whether a given piece of information arrived before it was needed becomes an actual engineering question rather than an assumption, which is the same wall ground robots hit and is why projects tend to outgrow the framework they started on.

And you give up some of your evenings to integration, which is a real cost when good flying weather is finite.

When is ROS 2 the better choice?

ROS 2 is the better choice for essentially every drone that has to understand its surroundings, and HORUS is not the answer for a team whose real gap is that nobody has written their mapping or detection code. If the aircraft must build a map, locate itself visually when satellite positioning is poor, recognise what is beneath it, or coordinate with other aircraft, the packages that do those things live in the ROS 2 world and represent years of work you would otherwise repeat.

ROS 2 also wins whenever the work must be shared or published. A university group, a consortium, a supplier delivering a payload to somebody else's airframe: all of them benefit more from a common interface than from any private one, and code that arrives with a paper usually assumes it.

And ROS 2 wins on simulation and recording. Being able to fly a mission in a simulator on a rainy week, and to replay a real flight at a desk afterwards to work out what the aircraft was thinking, changes how fast a drone project moves. That single capability has saved more airframes than any architectural argument.

Is ROS 2 too slow to keep a drone in the air?

No, and here is why: ROS 2 is not being asked to keep the drone in the air, so the question is aimed at the wrong layer. The loop that stops an aircraft tipping over runs on the flight controller, on dedicated hardware, in firmware that does not share its processor with a camera pipeline. Nothing on the companion computer participates in that loop, and no messaging choice makes an aircraft more or less stable.

What is true, and worth taking seriously, is a different statement: on a general-purpose computer running a general-purpose operating system, you cannot promise that a particular message arrives by a particular moment. That is a property of the machine and the operating system underneath, not a flaw in any framework, and what real-time actually means for robot software is the honest treatment of the distinction.

The practical consequence is a design rule rather than a warning. Any behaviour whose lateness would hurt someone belongs on the flight controller, in firmware, where lateness cannot happen. Everything else can tolerate a delay, and should be written to notice when a delay happened rather than to assume it did not.

Will changing middleware fix a drone that lags or drifts?

Partly, but not the way you think: most drone lag comes from the aircraft's own estimate of the world, not from the messages moving between programs. A drifting position hold is usually a sensor problem: vibration reaching the inertial measurement unit, a compass confused by current in a nearby wire, a satellite fix that is worse than the numbers on screen suggest. Changing how programs talk to each other will not repair any of those.

The genuine messaging problem has a distinctive signature. It appears when a second heavy program starts, it gets worse when the payload computer heats up, and it goes away when you stop the vision process. If your aircraft behaves perfectly with one program running and unevenly with three on the same onboard computer, that is a timing problem between processes, and it is the one case where how messages move genuinely changes what the aircraft does.

Tell the two apart before spending a quarter on a rebuild. Fly the same mission with the payload software disabled. If the drift is still there, the fix is mechanical or in the flight stack.

How do you decide what to run on your drone?

Decide by drawing the line between what keeps the aircraft flying and what makes the mission interesting, and refusing to let anything cross it. Write down every behaviour the aircraft needs, and mark each one as flight-critical or not. Everything flight-critical belongs to PX4 or ArduPilot on the flight controller, and that list should be short and unglamorous: stabilise, hold, return, land, cut power. Everything else can live on the companion computer.

Then choose the layer above by what you are missing. If you are missing mapping, detection or simulation, take the ecosystem. If you are missing nothing but the aircraft misbehaves whenever two onboard programs run at once, the gap is in how those programs share one machine.

Here is the decision in five lines.

• If your mission is a flight plan the autopilot can already fly -> PX4 or ArduPilot alone, because adding a computer adds only mass.
• If you need one extra behaviour on a working aircraft -> a MAVLink app, because a single program flies sooner than a framework.
• If the aircraft must map, recognise or navigate visually -> ROS 2, because those packages already exist and already work.
• If your onboard programs interfere with each other -> a shared-memory middleware, because the trouble is between processes on one machine.
• If you must fly commercially next month -> a bought aircraft and its SDK, because building an airframe is a separate project.

The HORUS Fit Framework reduces the choice to five axes you can judge without a benchmark: ecosystem size, setup effort, team size fit, deployment target, and licence. On an aircraft, deployment target usually decides, because mass and battery overrule preference, and licence matters more than people expect once a payload is delivered to a customer.

The day your onboard programs start fighting each other is not the day to begin evaluating middleware. Put HORUS on your shelf before then: star it so it is in your list when you start building.