# MRS UAV system: a research stack for multirotor experiments

> The MRS UAV system is the ROS 2 Jazzy platform from the Multi-robot Systems Group at the Czech Technical University in Prague, covering control, state estimation, mapping and planning for underactuated multirotor helicopters, with a Gazebo simulation and a one-command install through the group's apt PPA. The trade is speed of research against documentation, which the group says plainly it does not maintain.

**ctu-mrs/mrs_uav_system** — The entry point to the MRS UAV system.

- Repository: https://github.com/ctu-mrs/mrs_uav_system
- Website: https://ctu-mrs.github.io/
- Stars: 645 · Forks: 108
- Language: Shell
- License: BSD-3-Clause
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/ctu-mrs-mrs-uav-system

## A research platform, not a flight stack for a product

The MRS UAV system comes from the Multi-robot Systems Group, a robotics lab at the Czech Technical University in Prague that specialises in multi-rotor helicopters. The README states the reasoning behind the platform directly: real-world and replicable experiments should support excellent research and science in robotics, so the platform is built to allow safe real-world experimental validation of approaches in planning, control, estimation, computer vision and tracking.

The system properties are listed in four bullets. It is built on the Robot Operating System Jazzy, it is meant to be executed entirely onboard on a companion computer, it can control underactuated multirotor helicopters, and it contains control, state estimation, mapping and planning pipelines. Two of those deserve emphasis. Onboard execution means the system is not a ground station with a radio link to the analysis code, which is a deliberate constraint on how experiments are run, and underactuated multirotor control is a research problem rather than a solved consumer feature, which tells you what kind of aircraft and what kind of questions the platform is built for.

The laboratory framing matters for expectations. The system is described as research-oriented and evolving rapidly, and the group says most of its users are researchers who already know the platform or first-year students who might not know ROS at all. That is a candid statement of who the code is written for, and it sets the bar for what you should expect to get from the documentation.

The control and estimation architecture is published as a peer reviewed article, The MRS UAV System, in the Journal of Intelligent and Robotic Systems, volume 102, article 26, from 2021, with a DOI of 10.1007/s10846-021-01383-5. That paper is the design document, and it predates the ROS 2 port by several years, so it describes the control and estimation approach rather than the current package layout.

## The metapackage table tells you which modules exist and which do not

The README's system components section is the most useful map of the project, and it is split into two tables. The first lists the main metapackages. The MRS UAV System metapackage carries the UAV core and UAV modules, and the MRS UAV System - Full metapackage carries all of the below, both from this repository and both on the ros2 branch, with the packages named ros-jazzy-mrs-uav-system and ros-jazzy-mrs-uav-system-full.

The second table lists optional modules and metapackages, and here the structure of the project shows itself. Each module lives in its own repository with its own ros2 branch and its own Debian package: mrs_uav_core, mrs_uav_modules, mrs_octomap_mapping_planning, mrs_open_vins_core and mrs_point_lio_core. Octomap handles mapping and planning, OpenVINS and PointLIO are the state estimation cores, and the whole set is pulled into one install through the full metapackage.

Then the table stops being a list and becomes a to-do list. Precise Landing is marked TODO, ALOAM Core is marked TODO with a question mark and probably not, LIO-SAM Core is marked TODO with a question mark and probably not, and Hector Core is cut off mid-entry. The authors left these questions in a public table, which is unusual and useful, and it means the optional module set is genuinely in flux. A reader planning a system with precise landing or lidar-inertial odometry should not assume the package is available, because according to this table it is not.

The decomposition into many repositories with matching ros2 branches is the architectural decision to understand. It lets the group evolve the estimation core independently of the vehicle and simulation layers, and it means an install pulls code from several places, each with its own version of the same migration work.

## Installing through the CTU apt PPA

The native installation is four steps, all of them apt commands. The first adds the ROS 2 packages for Ubuntu and installs the desktop and development tools:

```bash
curl https://ctu-mrs.github.io/ppa2-stable/add_ros_ppa.sh | bash
sudo apt install ros-jazzy-desktop-full ros-dev-tools
```

The second step is configuring the ROS environment, and the README points at the official Jazzy Ubuntu installation documentation for the setup environment section rather than restating it. The third step adds the group's own stable PPA:

```bash
curl https://ctu-mrs.github.io/ppa2-stable/add_ppa.sh | bash
```

The fourth step is the system itself:

```bash
sudo apt install ros-jazzy-mrs-uav-system-full
```

Two observations about the design. The packages are delivered as ordinary Debian packages from a PPA, so a machine that already has ROS 2 Jazzy on it can add the group as one more apt source and install the stack with a single command, and updates come through the normal apt upgrade path. That is a deliberate choice to make a research stack installable without a colcon workspace, and it is what makes the system usable on a companion computer rather than only on a development machine.

The cost of that choice is that the PPA is a single point of failure for the whole stack. If the PPA is unreachable, or a package is broken in it, the documented install path stops. The README also warns that if you use the shell additions that make common ROS 2 commands usable, you should not manually source ROS or your workspaces, which is a hint that the environment setup has more moving parts than the four commands suggest.

## Starting the one-drone simulation

The first thing to run after installation is the example simulation session. The README takes you into the tmux setup shipped with the multirotor simulator and starts it:

```bash
cd /opt/ros/jazzy/share/mrs_multirotor_simulator/tmux/mrs_one_drone
./start.sh
```

The path tells you how the project is packaged. There is no source checkout here, because the system was installed as Debian packages into /opt/ros/jazzy, and the simulator ships its own tmux configuration, which suggests the session splits the system across multiple terminal panes so that you can watch the individual nodes while the vehicle flies.

The repository carries a directory of animated demonstrations that show the simulator running, including a Gazebo sequence of the aircraft flying a circle, and the repository topics list includes gazebo alongside control, estimation, tracking, drone and ros. So the simulation is a first-class part of the platform rather than a stub, which is what makes the reproducible research claim in the paper title achievable: a flight you develop against in simulation has a counterpart in the real system.

The one-drone session is the example. The package names and the metapackage table show that the simulator is one component among many, and the diagram files and the transition diagram in the repository indicate a larger set of prepared scenarios. What the README documents for a first run is this single script, and it is the piece to expect to work out of the box.

## The unstable PPA, the zenoh middleware and the ROS 2 transition

Two pieces of maintainer-facing guidance sit behind a details block in the installation section, and both matter if you are a developer rather than a user. There is an unstable PPA, ctu-mrs/ppa2-unstable, whose packages are built immediately after being pushed to the ros2 branch, and if both PPAs are present the unstable one takes priority. The README warns in strong terms that the unstable PPA might be internally inconsistent, buggy and dangerous, and it is intended for the group developers, not for users.

The second point is the middleware. The README says you should normally use zenoh as the RMW implementation, which is a departure from the default DDS stack, and that the shell aliases make common ROS 2 commands usable, with the warning not to manually source ROS or your workspaces if you use them. Choosing a non-default RMW is a strong signal about the direction of the platform, and it is also a dependency you inherit when you adopt the stack.

The ROS 2 migration is tracked openly. The README links a diagram hosted on the group's Obsidian knowledge base showing the state of the transition to ROS 2 in real time, and the repository layout reinforces that the work is spread across many repositories, each with its own ros2 branch. For an adopter this means the transition is incomplete in places and will keep moving under you, which is the same trade the group describes when it says the system evolves rapidly.

## Documentation is a side effect, and the packages are the manual

The group is unusually direct about the state of its documentation. The website scratches the surface of what it should contain, as the README puts it, and the system is research-oriented and evolves rapidly. Most users are researchers who already know the platform or students who might not know ROS, and keeping up to date documentation for that audience is hard work since the group mostly develops the system while using it for research.

So the stated strategy is to educate users to look around the packages, since each contains its own README, to explore the launch files, and to be able to read the code, which the group strives to keep readable. That is a defensible position for a lab whose artefacts are the research output, but it transfers work to the adopter. A new user is expected to read code and launch files, not follow a tutorial.

The alternative to adopting the whole stack is to take the pieces individually. The optional modules table shows the boundary of what the group maintains, with OpenVINS, PointLIO and Octomap in their own repositories under the group's own package names, so you can take the estimation core without the vehicle and simulation layers and assemble your own stack. The difference in approach is that the MRS metapackage pins a tested combination of versions and provides a matching simulation for each component, whereas assembling the pieces yourself means resolving version compatibility and building a simulator that matches your vehicle, which is the work the group already did for its own platform.

The repository layout supports that picture. The top level holds .ci for the continuous integration setup, .fig for figures used in the documentation, a docker directory for container based setups, and ros_packages for the package sources that get built into the Debian packages, with a LICENSE file for the BSD-3-Clause terms. The project publishes no GitHub releases, so the apt PPA and the ros2 branch are the two channels to watch, and the last push was on 2026-08-14.

## Conclusion

MRS UAV system suits a robotics lab or a graduate student who wants a complete multirotor stack with a simulator and matching simulation-to-real pipeline rather than assembling one from parts, and it suits a commercial product team poorly, because the platform evolves fast and the documentation stays thin by design. Before committing, read the README in each package and the launch files as the group asks, check that your hardware and companion computer fit the onboard execution model, and remember that several advertised modules, including precise landing, ALOAM, LIO-SAM and Hector, are still marked TODO in the project's own table. The last push was on 2026-08-14 and the project publishes no GitHub releases, so track the ros2 branch rather than a version tag.

## FAQ

### How do I install the MRS UAV system?

Add the ROS 2 PPA and the group's stable PPA with the two curl scripts, install ros-jazzy-desktop-full and ros-dev-tools, configure the ROS environment, then install the stack with sudo apt install ros-jazzy-mrs-uav-system-full.

### How do I run the MRS UAV simulation?

The README starts the example session by running cd /opt/ros/jazzy/share/mrs_multirotor_simulator/tmux/mrs_one_drone and then ./start.sh, which uses the tmux setup shipped with the multirotor simulator.

### Which optional MRS UAV modules are available?

The README lists UAV Core, UAV Modules, Octomap Mapping and Planning, OpenVINS Core and PointLIO Core as optional modules in their own repositories. Precise Landing, ALOAM Core, LIO-SAM Core and Hector Core are still marked TODO in that table.

### Does the MRS UAV system need a companion computer on the drone?

Yes. The README lists the system as meant to be executed entirely onboard on a companion computer, and it can control underactuated multirotor helicopters with control, state estimation, mapping and planning pipelines.

### What licence does the MRS UAV system use?

BSD-3-Clause, with the licence stored in the LICENSE file at the root of the repository. The packages are distributed as Debian packages from the group's apt PPA.

## Sources

- [ctu-mrs/mrs_uav_system on GitHub](https://github.com/ctu-mrs/mrs_uav_system)
- [Issues](https://github.com/ctu-mrs/mrs_uav_system/issues)
- [License: BSD-3-Clause](https://github.com/ctu-mrs/mrs_uav_system/blob/ros2/LICENSE)
- [Project website](https://ctu-mrs.github.io/)
- [README](https://github.com/ctu-mrs/mrs_uav_system/blob/ros2/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ctu-mrs-mrs-uav-system