The drone topped out at 0.5 m/s. None of it was the EKF's fault.

In 2018 I was building drone autonomy for unstructured outdoor environments — places where GPS is patchy, the map doesn't exist, and obstacles are not where any plan says they should be. The platform was an Intel T265 for visual-inertial odometry, a D435 for depth, an NVIDIA Jetson Nano running ROS, and a PX4 flight controller. State estimation fused T265 VIO with GPS through an EKF.

Everything worked. The drone could localize, see obstacles, plan a path, fly it. And it topped out at around 0.5 m/s safe forward velocity — slower than a person walking.

The thing nobody tells you: it wasn't any one component's fault.

What gets blamed first

The EKF gets blamed first. Always. Someone looks at a fused estimate that wobbles and assumes the filter is wrong — re-tunes Q, re-tunes R, swaps process models, switches to UKF. We did all of that. None of it bought us 1 m/s.

What was actually happening

Three subsystems, each fine in isolation:

• T265 VIO drifted, but only at rates GPS could correct.
• GPS updated at 5 Hz — slow, but adequate for the time scales we were operating at.
• Jetson Nano ran depth perception, occupancy mapping, planning, and the control loop. Each pipeline by itself fit in the GPU budget.

Run them together and the math changed. Perception, planning, and control share a clock. When obstacle avoidance has to recompute a trajectory because the EKF revised localization between GPS fixes, every stage downstream pays. Each individual stage stayed under budget. The composition didn't.

The maximum safe velocity is the speed at which the slowest end-to-end perception-to-action loop can still produce a plan that hasn't been invalidated by where the drone has actually moved. Push past that, and you're flying open-loop into geometry you haven't seen.

You can't tune your way out of a hardware ceiling.

The systems lesson

The fix wasn't a better filter. It wasn't a better depth model. It wasn't a smarter planner. It was a Xavier — and at 2018 prices, on the weight and power envelope we had, the Xavier was a different drone.

Hardware-first design choices set ceilings you cannot optimize through. If you want to fly faster, the answer is almost never a better algorithm. It's a better compute platform — or a slower drone.

We learned this the long way.