# Peng: a minimal quadrotor autonomy pipeline you can read end to end

> Peng is a Rust framework for quadrotor autonomy work: real-time dynamics simulation with IMU and depth sensing, PID control with integral windup prevention, seven trajectory planners including obstacle avoidance and landing, and 3D visualization through rerun. The crate is peng_quad, dual licensed MIT or Apache-2.0, and the roadmap still lists wind, motor dynamics, multiple vehicles and MPC as unfinished.

**makeecat/Peng** — A minimal quadrotor autonomy framework in Rust (Mac, Linux, Windows)

- Repository: https://github.com/makeecat/Peng
- Website: https://deepwiki.com/makeecat/Peng
- Stars: 695 · Forks: 34
- Language: Rust
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/makeecat-peng

## A whole quadrotor pipeline in one readable crate

Peng is described as a minimal quadrotor autonomy framework written in Rust that provides real-time dynamics simulation, trajectory planning and control with modern visualization. The word minimal is doing real work in that sentence, and the crate metadata backs it up. The package is peng_quad, its description names the contents as quadrotor dynamics, IMU simulation, various trajectory planners, a PID controller and depth map rendering, and the repository categories are science::robotics, aerospace::simulation, aerospace::unmanned-aerial-vehicles and algorithms.

So the scope is a research and teaching pipeline rather than flight software. Dynamics, sensing, planning, control and visualization are all present, in a single crate with a src/ directory and a config/ directory, and the dependencies are the ones you would expect: nalgebra for the linear algebra, rand and rand_distr and rand_chacha for noise, serde and serde_yaml for configuration, thiserror for error handling, log and env_logger, rayon for parallel work, osqp for the optimiser, and rerun for the viewer.

The audience follows from that shape. A graduate student learning how a PID controller and a trajectory planner fit together, a robotics developer prototyping a control idea, or anyone who wants a reference implementation in a memory-safe language with no framework in the way. The homepage is a deepwiki entry rather than a marketing site, which fits a project that documents itself through its source.

The crate is published on crates.io as peng_quad, documented on docs.rs, and there is a Discord server linked from the badges.

## Dynamics first, with the integrator as a choice

The simulation layer is where a quadrotor framework usually becomes either a toy or a research tool, and the feature list shows attention on the physics side.

High-fidelity quadrotor dynamics with configurable parameters is the headline. The parameters that matter are exposed through the configuration file, and the README names mass, inertia and control gains as things you configure, which are exactly the values that decide whether a controller tuned in simulation means anything.

There is IMU and depth sensor simulation, so the controller loop is closed over simulated sensor readings rather than perfect state, and optional RK4 integration for accurate dynamics. The optionality is the point. A fixed-step integration is fine for a fast inner loop where you need many steps per second, but the cost of a more accurate integrator is real, and a framework that lets you switch lets you check whether your result depends on the integrator rather than assuming it does not.

The sensor simulation also matters for the control code. An IMU that returns exact values is a different problem from one that returns noisy values, and a controller that behaves well in the first case can behave badly in the second, so having both in the loop is a deliberate design choice for a framework aimed at control experiments.

The project documents this work in a series of blog posts, one of which covers optimization of depth rendering and RK4 based dynamics update, which suggests the performance and accuracy trade-offs are being actively worked on rather than assumed.

## PID control with windup protection, and two control frequencies

The controller is a PID, and the feature list is specific about it: PID control for position and attitude with tunable gains, integral windup prevention, and support for different control frequencies.

Each of those three is a decision. Tunable gains are the obvious requirement, since no two quadrotors have the same mass and inertia. Integral windup prevention is less obvious but more important in practice, because a quadrotor saturates its motors constantly during aggressive manoeuvres, and a saturated actuator with an accumulating integral is the classic way to get a controller that overshoots badly on the first command after a limit is lifted.

Support for different control frequencies is the third. A real quadrotor runs an attitude loop at a high rate and a position loop at a much lower one, and the fact that the framework lets you configure the rate per loop means the code you write here resembles the code you would write on hardware.

The control gains are set in the configuration file rather than in code, which follows the general pattern of the project: the YAML file describes the vehicle, the gains, the planner and the visualisation, and the code stays the same across experiments.

What is absent is worth noticing. The roadmap lists Model Predictive Control as an open item, and the osqp dependency in Cargo.toml points at a convex optimisation solver being present in the dependency tree, presumably for the trajectory planners rather than for a control law, since MPC is not implemented.

## Seven planners, and one YAML file that drives them

The trajectory planning section is the widest part of the feature list, and it is where a framework either gives you options or gives you one algorithm with a parameter.

Peng gives you seven planners. Minimum jerk line trajectory planning. A Lissajous curve planner. A circular trajectory planner. An obstacle avoidance planner. A minimum snap waypoint navigation planner. A quadratic polynomial waypoint navigation planner. And a landing planner.

That list is a good summary of the ways a quadrotor mission is usually specified. A smooth straight line for a simple transfer, a Lissajous for a repeatable pattern in space, a circle for orbiting, waypoint sequences for multi-leg missions, a landing for touchdown, and obstacle avoidance for the case where the straight line is not available.

All of it is selected through configuration. The README says you can configure trajectory planner parameters such as waypoints, obstacles and trajectory type, and that the example lives in config/quad.yaml. The same file also carries the visualisation parameters, including camera intrinsics and depth rendering, so a single document describes the vehicle, the mission and the sensors.

That is a real design decision and it has a limit worth stating plainly. Because the planner is selected by name in configuration rather than composed in code, a task that needs a planner nobody wrote, such as a mission with time-varying constraints across several waypoint legs, is not something you can express by tweaking the YAML. You would write a new planner and add it to the framework.

## rerun for visualization, and the version pairing to watch

Visualization runs through rerun.io, and the framework uses it for real-time 3D visualization, depth map rendering, state telemetry logging and configurable logging frequencies. Multi-threaded depth rendering is listed under performance, and rayon is in the dependency list, which is how the depth pipeline gets its parallelism.

The rerun integration comes with a troubleshooting section in the README, and the first step is a version check. If you encounter any issue with rerun, the README tells you to verify that the rerun-cli version matches the rerun version in Cargo.toml, and the command for that is:

```bash
rerun --version
```

The pinned version in the current Cargo.toml is rerun = 0.33, and the demo link in the README points at a rerun viewer of version 0.22.0, so the viewer you open in the browser and the client you build can differ in version, and that mismatch is the first thing to check.

For Linux and WSL2 users, the README redirects to the rerun troubleshooting documentation, which is a hint that the visualization path has more platform specific behaviour than the rest of the framework.

The logging side is the quieter feature. Configurable logging frequencies let you record state at a lower rate than the control loop runs, which is what makes a long run inspectable rather than merely fast, and the state telemetry is what the rerun recording actually contains when you replay it.

## Three commands to a running simulation

The installation paths are short, and the prerequisites are Rust and rerun-cli.

From crates.io, the README gives three commands:

```bash
cargo install rerun-cli
cargo install peng_quad
peng_quad config/quad.yaml
```

The third command is the interesting one, because it shows the shape of the tool. The binary takes a configuration file, and config/quad.yaml is the example that ships with the project. There is no separate command to start a viewer, no scene to author, and no step-by-step script: the configuration selects the vehicle, the gains, the planner and the visualisation, and the binary runs the whole loop.

Building from source is the same idea with the source tree:

```bash
cargo install rerun-cli
git clone https://github.com/makeecat/Peng.git
cd Peng
cargo run --release config/quad.yaml
```

The release profile is worth a glance in Cargo.toml, since it is tuned for a simulation loop. The dev profile enables a small amount of optimization with opt-level 1 for the crate itself and opt-level 3 for dependencies, which keeps the inner loop fast without the wait of a full release build. The release profile sets codegen-units to 1 and uses thin lto, so the whole crate is compiled as one unit with a second optimization pass over dependencies.

The package version in the manifest is 0.5.6, the edition is 2021, and the minimum supported Rust version is 1.88.

## The roadmap is a list of what is still missing

The roadmap section is more useful than a feature list, because it tells you where the framework stops.

Four items are unchecked. Wind field and environmental effects. Motor dynamics simulation. Multi-quadrotor simulation. And Model Predictive Control.

Each of those is a boundary. Without wind and environmental effects, the simulation does not tell you how the vehicle behaves outdoors, which is the situation that matters for most flight work. Without motor dynamics, the actuator model is idealized, so a controller that is stable in simulation may not be stable on hardware where motor response lags. Without multi-vehicle support, the framework is strictly single vehicle. And without MPC, the control law is the PID described earlier.

So the honest summary is that Peng is a single-vehicle simulation and control framework with a good visualization, not a full autonomy stack.

Around the code, the repository carries the usual project files: CONTRIBUTING.md, CODE_OF_CONDUCT.md, SECURITY.md, the two licence files, a config/ directory, an assets/ directory, and a CI workflow. The licence is dual, MIT or Apache-2.0 at your option, as the README puts it, with the exception that files not otherwise noted carry the dual licence.

The release history is worth reading against the roadmap. v0.5.4 is dated 2025-02-15, v0.5.5 on 2025-05-07, and v0.5.6 on 2026-02-11, and the last push to the repository was on 2026-09-21. Patch releases on a 0.x version, with a long gap before the most recent one, is a project moving in small deliberate steps.

## Conclusion

Peng suits students, researchers and developers who want to understand or prototype quadrotor autonomy without inheriting a large robotics stack, since the whole pipeline fits in one crate with a YAML configuration file and a rerun viewer. It does not suit anyone who needs flight-ready control software, because the roadmap shows wind effects, motor dynamics, multi-vehicle simulation and MPC as work still to be done, and it does not suit a team that needs a maintained release cadence, since the gap between v0.5.5 in May 2025 and v0.5.6 in February 2026 is long. Check three things before you build on it: that the rerun-cli version you install matches the rerun version pinned in Cargo.toml, that your Rust toolchain is at least 1.88, and that the planner you need exists today rather than on the roadmap. The last push to the repository was on 2026-09-21.

## FAQ

### How do I install and run Peng?

Install the viewer and the crate with cargo install rerun-cli and cargo install peng_quad, then run peng_quad config/quad.yaml. From source, clone the repository and run cargo run --release config/quad.yaml. The Rust toolchain must be at least 1.88.

### Which trajectory planners does Peng include?

Seven, according to the feature list: minimum jerk line, Lissajous curve, circular, obstacle avoidance, minimum snap waypoint navigation, quadratic polynomial waypoint navigation, and a landing planner. The planner and its parameters are chosen in the configuration file, with an example in config/quad.yaml.

### What does the Peng roadmap still list as unfinished?

Wind field and environmental effects, motor dynamics simulation, multi-quadrotor simulation, and Model Predictive Control, all of them unchecked in the README.

### How do I troubleshoot a rerun problem in Peng?

The README's first step is to verify that the rerun-cli version matches the rerun version in Cargo.toml, which is currently 0.33, using rerun --version. Linux and WSL2 users are pointed to the rerun troubleshooting documentation.

### What licence is Peng released under?

It is dual licensed, MIT or Apache-2.0 at your option, with the MIT and Apache licence files at the repository root and the same wording in the Cargo.toml manifest. The README notes an exception for files that are noted otherwise.

## Sources

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

---

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