“One of the ironies is that the bigger and more expensive a vehicle is, the cheaper and slower a CPU you can get away with. If you've got a one-ton vehicle, there's no real point in running the control at multi-kilohertz. You're just wasting cycles.”
Software Engineering Radio - the podcast for professional software developers · Hands-On Engineering Podcasts · November 2026
Context
Asked what loop rates and latencies are needed to keep a drone stable, Tridgell says small quadcopters benefit from very fast control loops, while large heavy aircraft respond slowly enough that low-end processors do the job.
Transcript
…and the thrust, the change in the thrust angle impacts the barometer and actually changes the pressure. So you get sort of feedback systems where sensors are altered by the way you're trying to fly. So all sorts of little bits and things to keep us entertained in trying to make it fly correctly.
And what are the typical rates or latency requirements to keep something in the air and keep it stabilized? What sort of
rates are you talking about? I've been looking at that actually, sort of there's control bandwidths and rates. There's a lot of people who try to push rates up really, really high. So, and there can be some benefit for that. But the default, you know, copter, multi-copter setup for ArgyPilot is the main loop. So the PIDs run at 400 Hz. Whereas if you look at something like Beta Flight, they default to multiple kilohertz. But we do a lot more per loop than they do, right? On the same class of CPUs or microcontrollers. But the rates that you send signals out, so if we're a classic quadcopter with PWM output might be running, telling the commanding the ESCs at 400 Hz. A default fixed wing, a simple little foamy fixed wing, defaults to 50 hertz, which is really quite low. As far as the sort of the control bandwidth, I've been doing a bunch of measurements lately with chirp signals going through real motors and ESCs and propellers to look at how much actual control bandwidth. And the 3DB roll-off is typically, even for little five…
Yeah, that's definitely counterintuitive. So this sounds like a lot of complexity. Broadly speaking, how is ArgyPilot's codebase structured to manage that? Is it a single monolithic thing? Is it modularized in some way?
It's all Git, of course, up on GitHub with lots of submodules. How many submodules we've got now, but lots of different submodules for different communication protocols and things like MavLink and DroneCan and various compilers and things. We have DroneCan compilers, MavLink compilers, those types…
I see. So I imagine that rebuilding the firmware, uploading it to a flight controller and taking an aircraft out into the field every time you want to test a change to this software would be time consuming, expensive, and potentially even dangerous. So how do you approach testing within RGPilot?…
More from Software Engineering Radio - the podcast for professional software developers
