MAVPlanner and Why It Still Matters After All These Years
I've been working with UAV flight planning tools since the early PX4 days, and MAVPlanner (sometimes called MavPlanner or MAVPlanner) has been a consistent part of my toolkit. The short version: it's a standalone 3D path planning application that generates smooth, kinematically feasible trajectories for fixed-wing, multirotor, and VTOL aircraft, then exports them in formats your autopilot actually understands. The core workflow looks like this. You load a terrain mesh or define waypoints in a 3D space. The software runs an algorithm—usually RRT* or a variant of A*—and grows a tree through free space while respecting your vehicle's minimum turn radius, climb rate, and other constraints. When it finds a valid path, it smooths it into a continuous trajectory with velocity and acceleration profiles baked in. You export the result as a MAVLink trajectory message sequence, a PLANNED_POSITION_TARGET_LOCAL_NED stream, or a simple CSV/text file depending on your setup. From there you fly it in Gazebo, PX4 SITL, or straight to hardware via an onboard companion computer.
What It Actually Solves
Most beginner workflows stop at waypoint lists sent through QGroundControl or Mission Planner. Those work fine until your vehicle has real kinematic constraints, or until you need terrain-following flight, or until you're working with a fixed-wing that can't just hover and reverse. MAVPlanner sits in the gap between "point A to point B" and "here's a physically flyable path that respects the airframe." The smoothing step alone is where the value shows up. Raw waypoint-to-waypoint paths produce jerky control commands. The planner applies bezier or polynomial interpolation so the autopilot receives gradually changing setpoints. Your motors don't hunt. The battery lasts longer. The footage doesn't look like an earthquake.
Installing and Running It
The source lives on GitHub under the MAVProxy organization. Clone it, check the dependencies, and build. Typical requirements you'll need:
Get the Full Details
- Python 3 (2.7 still works on old releases but don't)
- numpy, scipy, matplotlib for the math and visualization
- PCL or a compatible library if you're doing point-cloud-based terrain parsing
- Optional: Gazebo + PX4 SITL for end-to-end validation
The build process is mostly standard CMake. If you hit dependency errors on Ubuntu 20.04 or later, you'll likely need to install libpcl-dev and qtbase5-dev manually. The project README covers this, but it was last updated a while ago and some package names shifted. Once compiled, you launch the GUI from the terminal. It opens a window with a 3D viewport on one side and a parameter panel on the other. Load your terrain file, drop in initial waypoints, set your vehicle model from the presets or define your own, and run the planner.
Export and Integration
This is where things get practical. The trajectory comes out as a time-parameterized sequence of positions, velocities, and orientations. You feed it into your autopilot in one of several ways: MAVLink trajectory messages work well if your companion computer runs MAVProxy or a Python MAVSDK script. You iterate through the trajectory points and publish them at the desired rate. Most people use a loop that sends the next point every 100–200 milliseconds depending on how smooth they want the input. For PX4, you can also map the output to the PLANNED_POSITION_TARGET_LOCAL_NED message type or convert it to a custom mission item list. ArduPilot users typically go the waypoints route but with interpolated intermediate points to avoid the sharp corners.
One Specific Problem I Hit (and How I Fixed It)
Last year I was running a fixed-wing mission over a mountainous area imported from a DEM (digital elevation model). The planner generated a perfectly valid path on paper. The simulation looked great. Then I loaded it onto the actual hardware and the drone tried to dig into a ridge at waypoint four. The issue was a coordinate frame mismatch. The DEM was in WGS84 geographic coordinates with elevation above sea level. The planner was interpreting the terrain data as local NED (North-East-Down) meters without the proper geodetic transform. So what looked like 200 meters of clearance above terrain in the viewport was actually ground impact when the coordinate origin was applied incorrectly during export. The fix was straightforward once I spotted it. I re-exported the terrain with an explicit geodetic reference point and used the planner's built-in altitude mode set to "above mean sea level" rather than "above ground level." Then I added a 50-meter buffer on the minimum altitude parameter as a safety margin. After that, the same mission flew clean on hardware. I wish the GUI made this clearer. It doesn't.
Counter-Intuitive Things Beginners Miss
Here's the first one: higher resolution terrain isn't always better. MAVPlanner's search speed depends heavily on how finely your obstacle space is discretized. A 1-meter DEM might look precise but it forces the planner to explore a vastly larger state space, which can make convergence take ten times longer or fail entirely on complex missions. A 5–10 meter DEM often produces a path that's good enough and finds it in minutes instead of hours. You can always smooth the trajectory afterward. The second one: the default RRT* settings are conservative to the point of being unusable for most real-world drones. The collision checking radius, the expansion step size, and the rewiring threshold all need tuning. If you're seeing paths that hug obstacles uncomfortably close or loops that take absurd detours, adjust these three parameters before you assume the planner is broken. It's not. It's just operating with defaults meant for a generic demonstration, not your airframe.
The Honest Downsides
MAVPlanner is not a real-time replanning tool. It's an offline planner. If your drone encounters a new obstacle mid-flight, this software won't help you. You need something like a local planner with DWA or TEB for that. The distinction matters because people buy into it thinking it solves the full autonomy stack. It solves one layer. The documentation is sparse. The code is readable but not beginner-friendly. There's no built-in tutorial for connecting it to ROS2, which is where most new projects live now. You'll be reading source code and writing glue scripts yourself. It hasn't seen major updates recently. The core functionality works fine, but the ecosystem has moved toward tools that integrate more tightly with ROS and modern autopilots. If you're starting a brand-new project from scratch today, you might also evaluate tools like QGC's advanced waypoint modes, ROS-based planners like move_base or Nav2 with UAV plugins, or the newer PX4 Trajectory Generation modules that handle similar problems inside the autopilot itself.
When It's Still the Right Call
If you need a standalone tool that produces clean kinematic trajectories without building an entire ROS pipeline, if you're working with custom airframes that don't fit neatly into existing mission planners, or if you want full visibility into the path planning process because you're debugging why a flight failed, MAVPlanner does the job. It's not pretty. It's not modern. But it's transparent, it's free, and it doesn't hide the math from you. That last point is worth repeating. Most commercial tools wrap their planners in a black box. You enter waypoints and hope. With MAVPlanner you can watch the tree grow in real time, see exactly which configuration space cells were explored, and understand why it chose path A over path B. That visibility pays off when things go wrong at 200 meters altitude over terrain you can't see clearly. If you want to try it, the repository is public. Clone it, build it, load a sample terrain, and run a simple mission in Gazebo before touching real hardware. Your first few trials will teach you more about trajectory planning than any tutorial can.
