A UAV flying under the MIGHTY planner reached 6.7 meters per second in real-robot tests while avoiding every obstacle that appeared in its path. The system, built by researchers at MIT and the University of Pennsylvania, handles UAV trajectory planning by reacting to obstacles in milliseconds while keeping the flight path smooth and the travel time short.
MIGHTY runs on the robot's onboard computer and sensors. It is open source and does not depend on proprietary software packages that can cost hundreds of thousands of dollars. The work appears in IEEE Robotics and Automation Letters.
The lead author is Kota Kondo, a graduate student in aeronautics and astronautics at MIT. He is joined by Yuwei Wu, a graduate student at the University of Pennsylvania, and Vijay Kumar, a professor at Penn. The senior author is Jonathan P. How, a Ford professor of aeronautics and astronautics at MIT and a principal investigator in the Laboratory for Information and Decision Systems and the Aerospace Controls Laboratory.
The problem with a fixed travel time
A trajectory planner is the software that decides the path a robot follows to get from one point to another. For a UAV entering a collapsed building after an earthquake, the planner must adjust quickly to sudden obstacles and still stay on course toward its goal.
Existing tools force a trade-off. Some commercial systems generate smooth trajectories quickly but cost hundreds of thousands of dollars. Open-source alternatives often underperform those commercial solvers or are hard to use.
Many open-source planners begin by estimating how long the trip will take. They then find the best path within that fixed time. This makes trajectories fast to compute, but it has a cost. If the UAV has to go far out of its way around an obstacle, it may need to speed up to stay within the time budget. Higher speed makes it harder to avoid sudden hazards.
How MIGHTY plans a path
MIGHTY uses a mathematical technique called a Hermite spline. It optimizes the flight path and the travel time together in a single step. The result is a smooth trajectory that can be controlled precisely.
Solving space and time together creates a much larger optimization problem. Kondo said the larger problem is harder to solve in a feasible amount of time. To reduce that overhead, MIGHTY does not build each trajectory from scratch. It makes an initial guess at the trajectory and then refines it through iterative optimization, using a map of the scene built from the UAV's lidar sensors.
"We can make a decent guess of what the trajectory should be, which is a lot faster than generating the entire thing from nothing," Kondo said.
Kondo also said the planner is self-contained. "With MIGHTY, everything is integrated in one piece. It doesn't need to talk to any other piece of software to get a solution. This helps us be even faster than some of the commercial solvers," he said.
What the tests showed
In simulated experiments, MIGHTY needed about 90 percent of the computation time of state-of-the-art methods. It reached its destination safely about 15 percent faster than those approaches. In tests on real robots, it reached 6.7 meters per second and avoided every obstacle that appeared.
The researchers list several uses beyond search and rescue. These include last-mile delivery in cities, where UAVs must avoid buildings, wires, and people, and industrial inspection of complex structures such as wind turbines.
Next, the team wants MIGHTY to control multiple robots at once and to run more flight experiments in challenging environments. They plan to keep improving the open-source system based on user feedback. The research was funded in part by the United States Army Research Laboratory and the Defense Science and Technology Agency in Singapore.
Davide Scaramuzza, a professor and director of the Robotics and Perception Group at the University of Zurich, was not involved in the work. He said MIGHTY revisits the trajectory representation itself. He noted that Hermite splines have already been used in visual simultaneous localization and mapping, and that joint optimization of path geometry, timing, velocity, and acceleration while keeping local control gives robots more freedom to compute fast, dynamically feasible motions in cluttered spaces.
Analysis: what this changes and what is unproven
The most useful part of this result is the combination of properties, not any single number. Fast computation, smooth paths, and onboard execution have each been achieved before. The reported advance is getting them together without a commercial solver. Because that dependency carries a price tag in the hundreds of thousands of dollars, removing it changes who can reproduce and extend the work. Universities and small companies that could not afford the solvers can now test against a competitive baseline.
The design choice also fits the problem. A fixed travel time forces a UAV to speed up after a detour, which is exactly when a sudden obstacle is hardest to avoid. Optimizing time and path jointly addresses that coupling directly. The initial-guess-and-refine step explains how the planner keeps the larger problem tractable. The reasoning holds together, and it matches the reported simulation results.
Several points remain unproven. The simulation gains are modest: about 90 percent of the computation time, and about 15 percent faster arrival. These are improvements over the state of the art, not step changes. The reported figures do not name which methods were compared, so a reader cannot tell how MIGHTY ranks against any specific commercial solver. The claim that it is faster than some commercial solvers comes from the lead author, and the supporting comparison is not detailed.
The real-robot result, 6.7 meters per second with every obstacle avoided, is encouraging. The number of flights, the obstacle types, and the environments are not stated. It also is not clear how the planner behaves in the dense, cluttered, GPS-denied settings that the earthquake scenario implies. The researchers themselves list more flight experiments in challenging environments as future work, which suggests that testing is still limited.
Multi-robot control is also still ahead. Search-and-rescue deployments would likely involve more than one UAV, and MIGHTY has not yet been shown to coordinate them. Open-source adoption will depend on whether outside users can match the reported performance on their own hardware, and the team has said it will rely on user feedback to improve the system. That outside testing will say more about MIGHTY's value than the first paper can.