# YOPO, a learned quadrotor planner that backpropagates through the trajectory cost > YOPO is a learning-based planner for quadrotor navigation in obstacle-dense environments, published at ICRA 2024, which replaces the usual search-then-optimise pipeline with a single network that scores motion primitives and predicts their offsets. The training strategy is the unusual part, since gradients of the trajectory cost are backpropagated directly into the network weights. **TJU-Aerial-Robotics/YOPO** — You Only Plan Once: A Learning Based Quadrotor Planner - Repository: https://github.com/TJU-Aerial-Robotics/YOPO - Stars: 1,245 · Forks: 148 - Language: C++ - License: NOASSERTION - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/tju-aerial-robotics-yopo ## One stage instead of search then optimise YOPO is a learning-based planner for autonomous navigation in obstacle-dense environments, and the abstract states its structure plainly. It integrates three things into a single network: perception and mapping, front-end path searching, and back-end optimization of classical methods. That last combination is the contribution. The classical pipeline for quadrotor planning is a two-stage affair. A front end searches the map for a path, and a back end optimises a trajectory for smoothness and obstacle clearance. The front end is where the local minima live, because a search that starts from a bad initial value in a cluttered map can get stuck, and the classical fix is to seed the search with many initial values. YOPO's answer to that is anchors. The approach adopts a set of motion primitives as anchors to cover the searching space, and predicts the offsets and scores of primitives for further improvement, and the README makes the analogy explicit: it works like the one-stage object detector YOLO. A set of anchor points, and a network that scores them and refines them, instead of a proposal step followed by a refinement step. The training strategy is the second half of the idea, and it is the more unusual claim. Compared to giving expert demonstrations as labels in imitation learning, or exploring by trial and error in reinforcement learning, the method directly back-propagates the gradients of trajectory costs, for example from an ESDF, into the weights of the network. The README describes this as simple, straightforward, accurate, and sequence-independent, and the sequence-independence is the important qualifier, since it means the training needs no online simulator interaction and no rendering. That last point explains why the training data collection is so cheap, and it is the reason the project could afford to train on a Jetson. The paper is You Only Plan Once: A Learning-Based One-Stage Planner With Guidance Learning, published at ICRA 2024, and there is a follow-up, YOPOv2-Tracker, described as an end-to-end agile tracking and navigation framework from perception to action, with a video of the paper and a set of real world experiment videos on YouTube and bilibili. ## The repository is three systems and a SolidWorks file The top level of the repository has four directories and they correspond to the four things you need to run the thing: Controller/, Simulator/, YOPO/ and hardware/, plus a docs/ directory. The Controller is the controller and dynamics simulator, and the Simulator is the environment and sensors simulator. Both are ROS packages built with catkin_make, and the README explains the split: you source devel/setup.bash in each and launch them separately, the controller with roslaunch so3_quadrotor_simulator simulator_attitude_control.launch and the sensor simulator with rosrun sensor_simulator sensor_simulator_cuda. The CUDA in the name is the point, since the environment generation and the sensor rendering are on the GPU. The YOPO directory holds the planner itself, with a config/traj_opt.yaml for the flight speed and the saved weights at YOPO/saved/YOPO_1/epoch50.pth. The hardware directory is unusual for a research repository. The drone was designed by a separate contributor, the components are listed in hardware_list.pdf, and the SolidWorks file of the carbon fiber frame is in the hardware directory, with the complete assembly files included in the hardware release on the releases page. So the physical platform is open as well as the software, which is what makes the real world experiment videos meaningful rather than a simulation demo. The visualiser is RViz with a saved config, rviz -d yopo.rviz, and the map is infinite, so you click a 2D Nav Goal in RViz to set the destination and watch the planner fly there. The README includes a side by side of two environment types, a random forest at maze_type=5 and a 3D Perlin at maze_type=1, and the configuration file for the simulator is where you change the sensor parameters such as camera and LiDAR settings, the scenario type and the obstacle density. The licence is the one GitHub cannot classify, the default branch is YOPO-Simple, and the last push was on 2026-09-09. ## Two branches that answer different questions The Updates section is the part to read before anything else, because the repository has changed shape and the two branches answer different questions. The first update, dated 2025-06-17, says the code is greatly simplified and refactored in Python and PyTorch, and that the simulator was replaced with a CUDA-accelerated randomized environment, which is faster, lightweight and boundless. For the stable version consistent with the paper, the README directs you to the main branch. So the default branch is the rewritten system, and the branch matching the published results is a separate one. The second update, dated 2026-08-14, says the project adopts MINCO as its trajectory representation, along with several other improvements, with a YOPO-MINCO branch and a comparison image. MINCO comes from the GCOPTER repository at ZJU-FAST-Lab, and it is a polynomial-based trajectory representation, so swapping it in changes both the parameterisation of the trajectory and the optimisation problem, not just the output format. The combination of those two facts sets the expectation for anyone picking this up. There is a C++ system that matches the paper, there is a Python and PyTorch system with a rewritten simulator, and there is a branch using a different trajectory representation. The repository is a research programme with several generations in it, not a single codebase. The releases reflect that too. The tags are hardware, described as SolidWorks Models of Hardware Design, and v1.0, described as Pretrained Weight of 15m/s Flight, and the README separately notes that the given weights are pretrained at 6 m/s and perform smoothly at speeds between 0 and 6 m/s, with more pretrained models available on the releases page. So the released weights are labelled for 15 m/s while the default configuration in the repository is described as pretrained at 6 m/s, and the difference is a configuration detail in traj_opt.yaml rather than a different model. The practical advice is to pick the branch that matches your question, read the update notes for that branch, and not to assume the files in the default branch correspond to the published results. ## Getting it running, and what the training loop looks like The installation assumes you already have the heavy dependencies, and it is worth reading that sentence carefully. The project was tested with Ubuntu 20.04 and Jetson Orin or Xavier NX, and the README assumes you have already installed the necessary dependencies such as CUDA, ROS and Conda. The clone is a shallow one, which for a repository with several branches matters because the branch you want is not the default: ```bash git clone --depth 1 git@github.com:TJU-Aerial-Robotics/YOPO.git ``` The environment is a conda environment on Python 3.8, with the versions pinned deliberately: ```bash conda create --name yopo python=3.8 conda activate yopo cd YOPO pip install -r requirements.txt ``` The README explains why the versions are pinned, and it is a good reason: they are the versions the author used, specified to avoid future changes, and you can remove them if you want to take the risk. Then the two simulator builds, and the deactivate and activate dance between them is not a typo, because the controller and the simulator are built outside the conda environment: ```bash conda deactivate cd Controller catkin_make conda deactivate cd Simulator catkin_make ``` Testing the policy means starting both simulators, then running the planner: ```bash cd YOPO conda activate yopo python test_yopo_ros.py --trial=1 --epoch=50 ``` And the visualisation is one command, rviz -d yopo.rviz from the YOPO directory. The training loop is where the efficiency claim shows up. For efficiency, the project proactively collects a dataset of images, states and map by randomly resetting the drone's states, positions and orientations. It only takes one to two minutes to collect 100,000 samples, and you only need to collect once. The generator is rosrun sensor_simulator dataset_generator, and the data lands in a dataset directory alongside the three code directories. That one to two minutes for a hundred thousand samples is the practical payoff of the sequence-independent training claim. A hundred thousand samples of images, states and map, collected in a couple of minutes on the target hardware, is what makes it feasible to iterate on the planner at all, and it is also why the method can be described as free of online simulator interaction during training. ## Conclusion YOPO suits a robotics group that wants a one-stage planner for fast flight in cluttered environments and is willing to work inside a ROS and CUDA toolchain, since the repository ships the controller, the simulator, the planner and the hardware design. It is the wrong choice if you want to run it on a workstation with a consumer GPU, because the tested setup is Ubuntu 20.04 on Jetson Orin or Xavier NX. Before building, read the updates section carefully, because the default branch has been refactored into Python and PyTorch with a different simulator while the paper-consistent version lives on main, and note that the pretrained weights are given for 6 m/s and behave smoothly between 0 and 6 m/s. ## FAQ ### What is YOPO and what problem does it solve? A learning-based planner for autonomous quadrotor navigation in obstacle-dense environments that integrates perception and mapping, front-end path searching, and back-end optimization of classical methods into a single network, published as You Only Plan Once: A Learning-Based One-Stage Planner With Guidance Learning. ### How is YOPO trained? By directly back-propagating the gradients of trajectory costs, for example from an ESDF, into the weights of the network, rather than by imitation learning from expert demonstrations or reinforcement learning with trial and error. The README describes this as sequence-independent, free of online simulator interaction or rendering. ### Which branch should I use? The main branch is the stable version consistent with the paper. The default branch was greatly simplified and refactored in Python and PyTorch with a new CUDA-accelerated randomized environment, and a separate YOPO-MINCO branch adopts MINCO as the trajectory representation. ### What hardware and software does YOPO need? It was tested with Ubuntu 20.04 and Jetson Orin or Xavier NX, and assumes CUDA, ROS and Conda are already installed. The environment is a conda environment on Python 3.8, and the Controller and Simulator are ROS packages built with catkin_make. ### How much training data does YOPO need? The dataset of images, states and map is collected by randomly resetting the drone's states, and it only takes one to two minutes to collect 100,000 samples, which only needs to be done once. The generator is run with rosrun sensor_simulator dataset_generator. ## Sources - [Issues](https://github.com/TJU-Aerial-Robotics/YOPO/issues) - [README](https://github.com/TJU-Aerial-Robotics/YOPO/blob/YOPO-Simple/README.md) - [Releases](https://github.com/TJU-Aerial-Robotics/YOPO/releases) - [TJU-Aerial-Robotics/YOPO on GitHub](https://github.com/TJU-Aerial-Robotics/YOPO) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tju-aerial-robotics-yopo