More aerial autonomy stacks?

Hi all!

As mentioned in the WG proposal, we wanted to start getting an overview of all things Aerial Robotics. So here I’m already making a heads start before next week’s meeting :slight_smile:

Here is a list of aerial robotics autonomy stacks that support ROS that I’ve found so far:

Anybody that knows of any other (ROS) autonomy stacks for aerial vehicles that we can add to this list?

Mind that I don’t mean autopilot firmware/software (like Ardupilot) or communication bridges (like MAVROS), but stacks that contain multiple solutions for autonomy, vision, positioning and communication as a bundle, which is usually run offboard or on a companion computer.


Hi, I’m Juanma from Spain! It’s great to see that the ROS aerial robotics community is starting to be active and coordinated :grin:

I know this one from the MRS group mrs_uav_system


Ah yes that is a good one @jmmp18, thanks!

Come to think of it, should sim-only be included here too? Then hector_quadrotor and RotorS or such should be included, although the latter doesn’t have any autonomy integrated so not sure if it counts.

1 Like

If there’s interest - the Nav2 framework is generally open-ended w.r.t. its application using the BT as the key reasoning block. Its something I’ve thought deeply about to have add-on repositories nav2_aerial & nav2_height (or similar) to have the the appropriate sets of Planner / Controller server implementations with more semantically meaningful APIs for those applications - alongside any plugins of interest. Likely a key change is the environmental model used.

Then, its trivial to use the rest of the Nav2 tooling and use the rich library of BT plugins we have available to build your autonomy behavior.

Food for thought! If you were looking to greenfield make something on general requirements, I’d be happy to chat about this in more detail and come up with a game plan!


Hello!, @KimMcG in our preprint ([2303.18237] Aerostack2: A Software Framework for Developing Multi-robot Aerial Systems) of Aerostack2 we have a comparison with other frameworks and other options like CrazyChoir or XTDrone appear too. Maybe you can have a look to see if you want to consider these frameworks or not.


Hi @KimMcG, we used ROS 2 with our 250-vehicle swarm for DARPA OFFSET.

Our system, RISE, has been operated with 174+ physical vehicles simultaneously (100+ of which were aerial vehicles), and with more than 250 vehicles in simulation.

You can read more in our recently published paper, here:


Hey @KimMcG, thanks for kicking this off, it’s a great effort to help raise awareness of all the great tools in the community and their many benefits.

Question for the whole community: How do we define Autonomy Stack?


You make a very good point! Absolutely, we should not try to reinvent the wheel here. There is a possibility that any of these stacks are already using BT or some elements of the NAV2 framework. I would like to see if overlap is possible between different platforms, and not just NAV2_aerial, but also NAV2_nautical :wink:

With starting the community WG, our current goal is to gather more information about projects that are out there and create an overview, perhaps indicating parts that aerial robotics people missed in the current offering of the ROS packages. Once we have that nice landscape, it would be a great ground for discussion in the near future. I am looking forward to that already!

(I don’t know if you saw my talk at ROScon '22, but I did try to connect a minidrone (crazyflie) to the NAV2 package. I did put myself in a difficult position by using a 4-point lidar, but I definitely got some ideas for possible improvements!)

1 Like

@smac thanks for the guidance! This sth using much less effort to implement considering the fact that we assume autonomy as autonomous navigation!

But I also agree with @mrpollo to define something more accurate for the word “Autonomy” as there are already available flight stacks to take care of navigation. But if we mean navigation and autonomy fully by ROS that has a lot to be discussed in my opinion.


Yeah there is a lot of gray area there… I would say perhaps, let’s not try to limit ourselves too much and see this as a brainstorm session :smile:

Anything related to aerial autonomy, just throw it in here!

1 Like

I second that question. I’ve seen very different things presented: onboard, remote control, swarm management, etc. Perhaps categories should be formally defined.

1 Like

I think at least the definition I have in mind of an aerial autonomy stack is a combination of packages that contain multiple parts in navigation and/or perception and/or simulation etc. At least sufficient for an Aerial vehicle to perform it’s task or application (partly) by itself.

It’s also perhaps a matter of divergence of subjects. If we can gather as much as possible, we can cluster them in the right categories later. But at least we have a bit of a start!

I’ll fine tune the agenda for tomorrows meeting a bit, as it might be good to discuss together on what an aerial autonomy stack is based on the input of this thread, so I’ll add a specific item. Thanks all for your comments so far!


During the meeting we had a couple of suggested definitions, which I collected and put into chatgpt with the prompt to make something out of it and this is the result:

An aerial autonomy robotics stack is a collection of building blocks that enable the development of autonomous aerial vehicles, by providing a modular and scalable architecture for sensing, perception, planning, and control tasks. It allows unmanned aerial vehicles to perform complex missions without human intervention, while accommodating different hardware configurations and simulation environments.

What do you think? I think that we can add details but just as a starting definition to define the whole idea of an aerial autonomy stack.


It’s a great starting point. I think that covers all the main fields that an autonomy stack should provide :slight_smile:

1 Like

Cool! I’ve started the landscape repo by the way, and I’ve added the autonomy stack page on it too: