# Prometheus from Amov Lab: an autonomous drone stack on PX4 and ROS

> Amov Lab's Prometheus bundles control, planning and target detection modules for PX4-based drones into one ROS workspace, with a simulator and a commercial hardware line beside it. Here is what the repository actually contains, how to build a module, and where the Apache-2.0 label and the usage restriction disagree.

**amov-lab/Prometheus** — Open source software for autonomous drones.

- Repository: https://github.com/amov-lab/Prometheus
- Website: https://github.com/amov-lab/Prometheus
- Stars: 3,268 · Forks: 465
- Language: C++
- License: Apache-2.0
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/amov-lab-prometheus

## What Amov Lab's Prometheus actually ships

Prometheus is not a flight controller firmware. The README describes it as an onboard-computer software system built on top of PX4 and ROS, aimed at developers who want working examples of autonomous behaviour rather than a blank workspace. The repository is organised around that idea: Modules/ holds the functional code, Simulator/ holds the simulation side, Scripts/ holds helper scripts, and Experiment/ holds experiment material. The README names control, planning and target detection as the integrated research directions and says several functional demos ship with the project.

The intended user is fairly narrow. The quick-start section tells readers they need basic C knowledge, since most programs are C with some C++ and Python in a few modules, and recommends that complete beginners work through the official ROS tutorials first. PX4 source knowledge is explicitly not required, but basic PX4 concepts and operations are. That is a realistic description of the audience: someone who can already build a ROS package and arm a vehicle, and wants the autonomy layer above it.

One thing the README makes plain is that this is a company project, not a hobby repository. Amov Lab sells a Prometheus 450 development platform, a simulation remote controller, airframes, onboard computers, stereo cameras and lidar through its Taobao and JD stores. The open repository and the paid hardware and course business sit next to each other, and the documentation wiki is hosted on the company's domain rather than in the repository.

## How the modules, simulation and build scripts fit together

The architecture visible from the repository root is a set of shell scripts, each compiling part of the workspace: compile_all.sh, compile_communication.sh, compile_control.sh, compile_planning.sh, compile_swarm.sh, compile_ugv_control.sh, plus compile_airsim.sh, compile_matlab.sh, compile_spirecv.sh, compile_fmt.sh and compile_aircraft_sitle.sh. That naming tells you the intended workflow better than any diagram would. You clone the workspace, run the script for the part you care about, and iterate on that module without rebuilding everything.

The split also reveals the dependency structure. Communication is compiled separately from control, and control separately from planning, which matches the README's claim that these are distinct research directions integrated into one platform. Swarm and UGV control get their own scripts, so multi-vehicle and ground-vehicle work are treated as separate targets rather than variations of the aerial stack. The presence of compile_airsim.sh and compile_matlab.sh shows the project has been wired to more than one simulator and to MATLAB, which matters if your lab already has MATLAB tooling.

The topics list on the repository names gazebo, mavros, px4 and slam. MAVROS is the bridge that carries MAVLink between PX4 and ROS, so the data flow is the conventional one for this kind of stack: PX4 handles stabilisation and low-level control, MAVROS exposes topics to ROS, and the Prometheus modules consume and publish on those topics. Gazebo appears as the simulation environment. The README does not document the topic names or message types in the repository itself; that detail lives in the wiki.

## Installing Prometheus and running a first module

The README does not carry installation steps. It sends readers to the Prometheus wiki, hosted at docs.amovlab.com, for installation and use, and states that the wiki is where the instructions live. So the honest answer to "how do I install this" is: follow the wiki page, because the repository root gives you build scripts but not the environment setup that has to precede them.

What the repository does give you is the clone-and-build sequence. The README links both a GitHub and a Gitee mirror, and the .gitmodules file at the root indicates submodules, so a clone needs to pull them in:

```bash
git clone --recurse-submodules https://github.com/amov-lab/Prometheus.git
cd Prometheus
```

After that, choose the module you want. If you are working on control, the root script named for that module is the entry point:

```bash
./compile_control.sh
```

The scripts are named after the modules they build, so compile_planning.sh and compile_swarm.sh follow the same pattern. What you should see is a build of the selected module; the README does not print expected output, and the wiki is the place to check the build against. If you want the whole workspace in one pass, compile_all.sh is the script for that.

Before any of this, the README's prerequisites apply: basic C, ROS tutorial familiarity, and working PX4 concepts. For simulation you also need the simulator side, and the README notes that a remote controller is required for simulation and links to one for purchase. That is not a formality; the simulation workflow as described expects an RC in the loop.

## Where Prometheus is the wrong choice

The licence situation is the first thing to settle, and it is not clean. The repository carries Apache-2.0, and the README's copyright section says the project is protected by Apache License 2.0. The next two lines say the project is for personal use only and must not be used commercially, and that Amov Lab will pursue infringement if the project is used for profit. Apache-2.0 does not contain a field-of-use restriction of that kind, so the README and the licence file appear to say different things. If you are evaluating this for a company, that contradiction is the finding, not a detail to skip past.

Second, the documentation language and location. The primary README is Chinese, with an English README linked separately. Installation, topic names and troubleshooting live on the company wiki rather than in the repository, and the community channels named in the README are a Chinese forum, a WeChat contact, and a Bilibili account. A team without Chinese reading ability can use the code, but will be working from a thinner slice of the documentation than the project actually has.

Third, hardware coupling. The README's hardware section is not incidental: the 450 platform, the RC, the onboard computer, the stereo camera and the lidar are all sold by the same company. The software is open, but the path of least resistance runs through that hardware. If you fly a different airframe, expect to spend time on configuration that the wiki does not cover for your setup.

Finally, scope. This is an onboard autonomy stack, not a ground station, not a telemetry backend, and not a replacement for PX4. If your problem is flight stability, Prometheus is not the layer you want.

## Prometheus against a plain PX4 and MAVROS setup

The obvious alternative is not another autonomy framework but the raw combination the README itself builds on: PX4 plus ROS plus MAVROS, assembled by you. The difference in approach is one of defaults. A hand-rolled PX4 and MAVROS workspace gives you the bridge and nothing else. You write the offboard control loop, you pick the planner, you wire the detector into the control path, and you decide the message types. Prometheus arrives with those decisions already made and packaged as modules with demos, which is why the README frames it as a full solution rather than a library.

That trade is real in both directions. You get working examples for control, planning and detection on day one, and a build script per research direction so you can work on one without the others. You inherit the project's structure, its assumptions about how a vehicle is configured, and its documentation language. A lab that already has a working MAVROS stack and its own planner will find Prometheus mostly redundant. A lab starting from zero on a PX4 vehicle will find the pre-built modules save the weeks that the bridge and the first offboard loop usually cost.

The swarm and UGV compile scripts point at a third option: if your interest is multi-vehicle or ground vehicles rather than a single aerial platform, Prometheus has targets for those, which a bare PX4 and MAVROS setup does not address at all.

## Maintenance, releases and what an upgrade costs

The release history is short and old. The repository lists v1.0 as the stable release, dated 2021-02-01, preceded by v1.0-rc1 in December 2020 and v1.0-rc in November 2020. No later tagged release appears in the list. The last push to the repository was on 2026-04-03, so work has continued on the main branch after the v1.0 tag, but whatever has changed since 2021 has not been cut into a numbered release.

That has a practical consequence for upgrades. If you track main, you are tracking unreleased code, and the CHANGELOG.md at the repository root is the only change record the repository itself provides. There is no documented migration path between versions, and the README does not discuss rollback or version pinning. For a lab, pinning to a known commit and reading the changelog before pulling is the only defensible routine the documentation supports.

The bus factor is another cost. The project is maintained by a company, with support routed through a forum, a WeChat group and periodic live streams on Bilibili. That is a real support channel, but it is not an issue tracker in the repository, and questions asked there are not searchable the way repository issues are. Budget for that if you plan to depend on it.

Licence implications beyond the personal-use sentence are outside what this article can settle. The Apache-2.0 file and the README's commercial restriction need a lawyer's reading, not an engineer's.

## Conclusion

Adopt Prometheus if you already fly PX4 and want a ROS-side starting point for control, planning or detection work, and if you are willing to read the Chinese wiki because the README points there for installation rather than carrying steps itself. Do not adopt it if you need a permissively licensed stack for a commercial product: the README states the project is for personal use and forbids commercial use, which sits awkwardly beside the Apache-2.0 file, and only a lawyer can tell you how that resolves. Before committing, verify three things: that the wiki's installation page still matches the compile_*.sh scripts at the repository root, that your distribution and ROS release appear in that page, and that the target hardware you intend to fly is listed among the supported airframes.

## FAQ

### What is Prometheus from Amov Lab?

It is an open source onboard software system for autonomous drones, built on PX4 and ROS, that integrates control, planning and target detection modules with several functional demos.

### How do I install Prometheus?

Installation instructions are not in the README; it points to the Prometheus wiki at docs.amovlab.com for installation and use. The repository provides the build scripts, such as compile_all.sh and compile_control.sh, that run after the environment is set up.

### What do I need to know before using Prometheus?

The README asks for basic C knowledge, since most programs are C with some C++ and Python in a few modules, and recommends the official ROS tutorials for complete beginners. PX4 source knowledge is not required, but basic PX4 concepts and operations are.

### Can Prometheus be used commercially?

The repository carries Apache-2.0, and the README says the project is protected by that licence. The same section also states the project is for personal use only and must not be used for commercial purposes, and that Amov Lab will pursue infringement for profit-making use.

### Does Prometheus work with simulators?

Yes. The repository lists gazebo among its topics and includes compile_airsim.sh alongside the simulation directory, and the README notes that a remote controller is required for simulation work.

## Sources

- [amov-lab/Prometheus on GitHub](https://github.com/amov-lab/Prometheus)
- [License: Apache-2.0](https://github.com/amov-lab/Prometheus/blob/main/LICENSE)
- [Project website](https://github.com/amov-lab/Prometheus)
- [README](https://github.com/amov-lab/Prometheus/blob/main/README.md)
- [Releases](https://github.com/amov-lab/Prometheus/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/amov-lab-prometheus