kr_autonomous_flight: a GPS-denied quadcopter autonomy stack

A flight stack built for research, not a product

kr_autonomous_flight is the autonomous flight code stack used at KumarRobotics, and the README describes it as providing a complete solution for GPS-denied quadcopter autonomy. It has been tested extensively in challenging urban and rural environments, the rural case being under forest canopy.

The framing matters. This is not a flight controller firmware and it is not a consumer drone stack. It is the autonomy layer of a research programme, published so that other groups can build on the same experiments, with the code, the papers and the videos all pointing at the same body of work.

The constraint the whole stack is built around is GPS denial. Without satellite positioning, a quadrotor cannot use a global frame for its state estimate, and the navigation problem becomes local perception plus a map, which is why the stack carries its own estimation, mapping and planning components rather than assuming a pose estimate exists.

The licensing is the Penn Software Licence, with the details in the license file at the root of the repository. That is not one of the licences most engineers can evaluate from memory, so it is worth reading before you build a commercial project on top of it.

Components, containers and the repository layout

The badges at the top of the README are the quickest map of the system, because there is one per component and they name the split.

There is a build for the base image, one for the client, one for control, one for estimation, one for the map and plan component, one for the state machine, and one for the simulation. So the autonomy stack is decomposed into a client, a controller, an estimator, a mapping and planning unit, and a state machine that sequences them, each with its own container image.

The repository layout mirrors that decomposition.

The repository carries an autonomy core directory, an autonomy real directory and an autonomy sim directory at the top level.

The core directory holds the parts that are the same whether the vehicle is real or simulated, the real directory holds the hardware-facing code, and the simulation directory holds the simulated counterpart. That separation is the standard approach for robotics research, and it is what lets the simulation and the real vehicle share a controller and an estimator rather than maintaining two of each.

The external dependencies are not vendored in the repository. They are declared in manifest files at the root, one of them for all of them, and separate ones for a coverage planner configuration and for the real robot configuration. So a given deployment is described by choosing a manifest and the set of external repositories it pulls in, rather than by a single build.

The pipeline and the external dependency manifests

The README shows the high level code structure as a diagram, and describes the system as a pipeline rather than as a set of services. In a stack like this the interesting question is what consumes what, and the diagram is the answer to that.

The external manifests are the part that matters in practice. Each of the yaml files at the root of the repository describes a set of external repositories to pull in, with the file names indicating the configuration: everything, the coverage planner variant, and the real robot variant.

Those manifests are where the real dependency surface of this project lives. The ROS2 branch documentation names them, listing external dependencies such as the trackers manager, the MAV control package, a lidar inertial odometry package and a quadrotor simulator package, and notes that they are pulled in through files with an external prefix.

That is worth understanding before you try to build the stack, because the difference between a project that builds from a clone and one that does not is usually in the external repositories rather than in the code in front of you. If one of those repositories moves or changes its own interface, your build breaks in a way that is not obvious from the error message.

The other configuration files are ordinary quality tooling: a clang format configuration, a cmake format configuration and a pylint configuration wired to a review dog style reporter, which is the mechanism that posts lint findings onto a pull request.

The experimental ROS2 branch

There is a ROS2 port, and the README is unusually careful about its status.

The port lives on the ros2_dev branch and targets ROS2 Jazzy Jalisco on Ubuntu 24.04. It is built on top of another branch, the one that integrates a lidar 3D planner by default, which adds two capabilities beyond master.

The first is a 3D optimisation based planner, with a gcopter family trajectory optimisation integrated into the action planner. The second is support for both lidar with visual inertial odometry and lidar-only autonomous flight, so the stack can fly without a visual inertial frontend when lighting or texture conditions make that frontend unreliable.

That second capability is the interesting one for the research question the stack addresses. A visual inertial frontend is the usual companion to lidar in a GPS-denied system, and it fails in exactly the conditions that forest canopy and night flight produce. Being able to drop it changes what the platform can attempt, not just how it performs.

Every package, launch file, Docker image and CI workflow on the branch has been adapted for ROS2 Jazzy. The README is explicit that this port has not been extensively tested or experimented with, and that it is not the version used to produce any of the results shown in the papers or videos. It is offered as a starting point for developers who want to use the stack under ROS2.

And it is incomplete in a specific way. Several external dependencies pulled in through the external manifests are still ROS1 only and have to be ported themselves before a full end to end build succeeds. The repository holds a migration report with a per package breakdown and the list of known follow-ups, which is the document to read before estimating the work.

The papers behind the code

The README asks you to cite three papers if you use the code or the models, and reading them tells you what the stack was actually for.

The first is the journal of field robotics paper on fast autonomous flight in GPS-denied and cluttered environments, by Mohta and a long list of co-authors including Vijay Kumar, published in 2018 with the volume and page numbers given. The second is the ICRA 2018 paper on experiments in fast autonomous GPS-denied quadrotor flight.

The third is the 2022 paper in robotics and automation letters on large-scale autonomous flight with real-time semantic SLAM under dense forest canopy, by Liu and colleagues.

Together they trace the arc of the programme, from a fast flight result in cluttered environments to real time semantic mapping under a forest canopy. The videos in the README follow the same order, with real world experiments in large scale autonomous flight with real time semantic SLAM in forests, real world experiments in fast autonomous GPS-denied quadcopter flight, and simulation experiments in fast autonomous flight in urban and rural environments.

The acknowledgement section says this is a multi-year project and credits contributions from current members and lab alumni, with the contributors listed in the papers, and it also names two further contributors and thanks the funding agencies.

For a practical adopter, that list is also a map of the people who understand each part of the stack, which is useful information when something in the estimator or the planner does not behave as the papers suggest.

Contributing, and what to check before you build

The contribution process is minimal, which is consistent with a research code base. Report issues on GitHub, and merge code changes through a pull request on GitHub. There is no separate contribution guide in the README and no mention of a development guide beyond the wiki.

The wiki is where the operational instructions live. The README points at it for detailed instructions about how to use the code, which tells you that the repository itself is not the place to learn the workflow. That is a reasonable split for a stack with this many components, and it is also a warning that you will be reading documentation in a wiki rather than in versioned files.

Four checks before you invest time in this stack.

Which branch you need. The master branch is the version the papers and videos were produced with, the feature branch adds the 3D planner and lidar-only flight, and the ROS2 branch is the experimental port with dependencies that still need porting.

Whether the external repositories your configuration pulls in are still reachable and still build. The manifest files are the place to check, and the ROS1 only dependencies named in the branch documentation are the ones most likely to fail.

What the licence permits. The Penn Software Licence is not MIT and not Apache, and the README points to the license file for details. Whether it suits a commercial deployment is a question for your legal review.

And whether you need the whole stack. The components are separate containers, so a project that only wants the estimator or the planner may not need to build the rest of the pipeline, and the fact that each component has its own image suggests that is a supported way to work.

Editorial conclusion

kr_autonomous_flight suits a research group working on GPS-denied quadrotor flight that wants the autonomy stack behind published forest and urban experiments rather than building one, since the components are separated, the containers are published per component and the external dependencies are declared in manifests you can inspect. It is the wrong choice if you need a supported product, since it is a research code base with no releases and a permissive but non standard licence, and the wrong choice if you are on ROS2 Jazzy expecting a working port, because the README says that port has not been extensively tested and that several dependencies are still ROS1 only. Verify first which branch matches the environment you run, whether the external repositories your configuration pulls in are still reachable, and that your licence choice, the Penn Software Licence, fits your organisation.

Frequently asked questions

Official sources

1. Issues
2. KumarRobotics/kr_autonomous_flight on GitHub
3. README