CopterExpress/clover: a ROS framework and Raspberry Pi image for PX4 drones

What Clover actually solves for a PX4 drone

PX4 handles stabilisation and flight modes. It does not give you a convenient way to say "fly to this coordinate" from a Python script running on a companion computer. Clover fills that gap. It is a ROS-based framework, distributed as a ROS package, that exposes autonomous drone control through ROS topics, and it is shipped mainly as a preconfigured Raspberry Pi image so the companion computer arrives with the software already in place. The README describes the intended workflow plainly: install the Raspberry Pi on the drone, flash the image to a microSD card, and "taking the drone up in the air is a matter of minutes".

The audience is educational. The README lists Copter Hack, the WorldSkills Drone Operation competition, the Autonomous Vehicles Track of the NTI Olympics 2016 to 2020, Quadro Hack 2019 and the Russian Robot Olympiad as events where the drone has been used. That tells you more about the design centre than any feature list: the priorities are a short path from unboxing to a first autonomous flight, and an API simple enough for students to read. The kit itself is sold unassembled, with a Pixracer-compatible autopilot running PX4, a Raspberry Pi 4 companion computer, a camera and additional sensors, batteries included. If you already own a PX4 quadcopter and a Pi, the software is the part you are here for.

How the pieces fit: ROS, mavros, aruco_pose and the clover package

The architecture is a stack of ROS packages on the companion computer, talking to the flight controller over a serial link. The image ships ROS Noetic on Raspbian Buster, with mavros bridging between ROS and the PX4 autopilot, OpenCV for vision, ROS periphery drivers for GPIO and the LED strip, an aruco_pose package for marker-assisted navigation, and the clover package itself for autonomous drone control.

Data flows in two directions. Commands from your node go through the clover package and then mavros to the autopilot. Position estimates come back the other way: mavros relays the autopilot's state, and aruco_pose can contribute a position derived from camera observations of ArUco markers. That second path is the interesting design choice. Marker-assisted navigation means the drone's localisation can be anchored to printed markers in the room rather than to GPS, which is why the kit works indoors and why the topic list includes optical flow. The trade-off is that the flight area has to be prepared with markers, and the quality of the estimate depends on the camera seeing them. The repository also contains clover_blocks, clover_description, clover_simulation and apps, so there is a simulation path and a description package for the airframe alongside the flight code. The README does not describe how closely the simulation matches the image, and that is worth checking yourself before you rely on it for grading.

Installing Clover and running a first autonomous flight

The README points at the Releases section for the preconfigured Raspberry Pi image and states that the image has the software installed and configured. That is the supported path: flash the image to the microSD card, boot the Pi, and the ROS workspace is already there. The README does not give a command-line flashing procedure, so use whatever imaging tool you normally use for a Raspberry Pi and take the image from the releases page.

For manual package installation and running, the README defers to the clover package documentation in clover/README.md. The repository layout confirms the package directory exists at clover/, so that file is the place to look for the build steps rather than the top-level README. The README does not reproduce them here, so do not assume a particular catkin invocation.

After the package is in place, the API description for autonomous flights is the page the README links to on GitBook, at clovercoex.tech/en/simple_offboard.html. That is where the topic names and message types for offboard control are documented, and it is the file to read before writing any flight code. The README does not reproduce the API inline, so treat the GitBook page as the reference rather than guessing topic names.

One practical note on the image: it is built on Raspbian Buster with ROS Noetic. Noetic is the last ROS 1 distribution, and Buster is old enough that third-party Python packages you pip install may need attention. If your course depends on a modern Python library, verify it installs on the image before the term starts.

Where Clover is the wrong tool

Clover is not a general flight stack. It assumes PX4 firmware on the autopilot and a Raspberry Pi as the companion computer, and the shipped image is built for that combination. If you fly ArduPilot, or your companion computer is a Jetson, you are outside the supported configuration and will be assembling the pieces yourself.

The image is also a fixed target. Raspbian Buster and ROS Noetic are both end-of-line in the ROS 1 line, and the repository's newest stable release is v0.25 from 2024-08-08, with v0.26 available only as an alpha from 2024-09-19. The last push to the repository was on 2026-04-14, so work continues, but the release cadence is slow enough that you should not expect the image to track upstream ROS or Debian changes quickly. If your requirement is a current, long-term-supported operating system on the companion computer, this is a mismatch you will feel at every upgrade.

There is also a documentation boundary worth naming. The README states that the source code is MIT but that the documentation under docs/ is licensed under Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International. If you plan to build commercial training material from that documentation, the licence is not the same as the code licence, and that distinction is easy to miss.

Clover compared with building directly on MAVROS

The obvious alternative is to skip Clover and use mavros directly. Mavros is already in the image and is the standard ROS bridge to MAVLink autopilots; it is maintained as part of the wider ROS ecosystem and works with PX4 and ArduPilot alike. Building on mavros gives you a much wider support surface and no dependency on a single vendor's release schedule.

The difference in approach is where the convenience lives. Mavros exposes the autopilot's services and topics fairly directly, which means you handle arming, mode switching, setpoint streaming and the offboard heartbeat yourself. Clover wraps that into a simpler API aimed at autonomous flights, and adds the aruco_pose package so marker-based localisation is available without you writing the vision pipeline. For a student writing their first offboard script, that is a real reduction in the amount of MAVLink plumbing they need to understand. For an engineer integrating a custom sensor suite, the wrapper is one more layer between you and the autopilot, and you may prefer the direct route.

A second alternative is the simulation route: the repository includes clover_simulation, which lets you exercise the same API without flying. The README does not document how faithful that simulation is to the image, so it is a development aid rather than a substitute for a bench test.

Maintenance, upgrades and the licence split

The repository is not archived, and the last push was on 2026-04-14. Releases are infrequent: v0.25 landed on 2024-08-08, v0.24 on 2023-10-11, and v0.26 exists only as v0.26-alpha.1 from 2024-09-19. Plan for a stable image that changes slowly and an alpha track that may change under you.

Upgrade cost is dominated by the base system, not by Clover itself. Because the image pins Raspbian Buster and ROS Noetic, moving to a newer base means rebuilding the image, and the repository includes a builder/ directory and a build-image GitHub workflow, so that path exists. The README does not document a rollback procedure for the image, and it does not describe an in-place upgrade from one Clover release to the next. Flashing a new microSD card and keeping the old one is the practical approach, and it is the one the release-based distribution implies.

On licensing, the split is explicit in the README: the platform source code is MIT, while the documentation under docs/ is Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International. The practical consequence is that reusing the documentation in a paid course or a commercial manual is governed by a different licence than reusing the code. That is a question for your own legal review, not something the repository answers.

Editorial conclusion

Adopt Clover if you are running a course, a club or a competition team that already has PX4 hardware and a Raspberry Pi 4 companion computer, and you want offboard control through ROS topics rather than writing MAVLink by hand. Do not adopt it if you need a general-purpose flight stack for arbitrary airframes, or if you expect the source tree alone to be enough: the quickest path is the released Raspberry Pi image, not a manual build. Before you commit, read the simple offboard API page at clovercoex.tech and check that the topics it documents match the release you plan to flash, since the newest release listed in the repository is v0.25 from 2024-08-08 and v0.26 is still marked alpha.

Frequently asked questions

Official sources

1. CopterExpress/clover on GitHub
2. License: MIT
3. Project website
4. README
5. Releases