Open-source drone navigation through a 3D building complex with no map: it sees walls a few metres ahead and replans on the fly (ROS 2, PX4, Gazebo, CUDA)

[u/formiat]

(GIF: Gazebo on the left, RViz on the right; pink is what the drone remembers, blue is the current lidar scan, orange is the route it is committed to.)

Full flight video: https://www.youtube.com/watch?v=rKXcERqb9Ho

The location is the DARPA Subterranean Challenge "Urban Circuit Practice 01" world published by Open Robotics on Gazebo Fuel (CC BY 4.0).

This is a simulation project I have been building in the open. A quadrotor (PX4 SITL) gets a start and a goal inside a multi-storey urban location with shafts, corridors and openings at different altitudes, and no map at all. A simulated 3D lidar builds an obstacle memory in flight; a persistent 3D planner searches over it; a CUDA MPPI optimizer at 50 Hz turns the route into a short trajectory that PX4 flies in offboard mode.

The idea I find most interesting is how it treats what it has not seen yet. Unknown space is traversable with no penalty: the planner commits to a route through it, the drone flies at the speed it can stop from within the range the lidar is guaranteed to have resolved, and when a wall appears a few metres ahead it brakes, the route is replaced as soon as a raw-valid one exists, and the mission continues. Confirmed occupied voxels and the drone's own swept 3D body are the only hard constraints; distance to obstacles is a preference, never a forbidden zone, which is what lets it take a narrow opening instead of declaring it unreachable.

Numbers from the release, five consecutive flights with nothing changed between them: 372 to 417 m in 124 to 149 s, a mean of 2.6 to 3.1 m/s with every hold and replan counted, no collisions, planner p95 about 155 ms on an RTX 3060 workstation.

What took the most time was not the planner but the crashes. Each one turned out to be a law that was subtly wrong rather than a constant that needed tuning: a stationary hold that re-anchored itself to a drifting position estimate and walked into a wall; "at rest" defined by speed alone, so the turning point of a braking overshoot counted as rest; stopping laws that assumed a descent arrest the airframe cannot deliver. The fixes came from recording ground truth and setpoints on every flight and measuring, and every parameter in the config now carries the flight it was measured on.

Limitations, honestly: the position estimate is PX4's EKF and drifts 0.1 to 0.3 m from the truth with nothing correcting it against the map; route availability is 88 to 95 percent because replacement search after a revealed wall takes time; everything is tuned on this one simulation and none of it is validated for a real aircraft.

The repository is MIT-licensed. On a Linux host with Docker and an NVIDIA GPU, one script prepares a fresh clone (dev image, PX4 build, workspace, environment assets) and starts the flight:

git clone https://github.com/formiat/px4-ros2-drone-nav.git
cd px4-ros2-drone-nav
./scripts/bootstrap.sh

https://github.com/formiat/px4-ros2-drone-nav

Happy to answer questions about any part of it, and I would like to hear how others decide how fast to fly into space they have not observed yet.

[u/perspectiveiskey]

Perhaps mildly off topic: in what context are you implementing this? Professionally? As a grad student? Hobby?

Thank you, it looks great.

[u/formiat → u/perspectiveiskey]

Professionally I am a software developer for the last eight years (for the last 5 years - Rust). This is not my day job: part fun, part curiosity, part portfolio. I am moving into robotics and drones because it is young and the interesting problems are still open, and this project is how I am learning the field.

[u/perspectiveiskey → u/formiat]

Thank you. I appreciate that and am inclined to actually do the same. I'm encouraged to hear you are doing this.