Speculation, but I’m still on the search for noise…
The main loop in my code takes on average 6ms or 170 loops per second (Hz), during which the code
- checks the commands for what Phoebe should do
- reads the sensors
- calculates critical angles
- runs the PIDs
- updates the PWMs
and I wonder whether this updating of PWMs at 6ms intervals is causing broad-spectrum noise from the blades depending on what the updates are? Is it this noise forcing me to use the very low (5Hz) DLPF combined with the long complementary filter (0.5s)?
Have a look at the audio spectrum analyser results I got a while back. Although there are clear peaks showing the blade RPM , these all should be filtered out by the DLPF. But there is also a lot of other noise which wasn’t present before the blades started spinning.
If that noise is caused by the constant PWM changes, then I could apply another filter equivalent to the complementary filter, but applied to the change in the PWM signals for each blade, set to average with a tau of say 22ms (45Hz). Certainly ESCs can accept PWM updates at this much lower frequency, and I suspect that although many advertise they can take updates up to 400Hz, perhaps they do filtering on their outputs to limit the noise rapid PWM changes would produce. I can’t see inside an ESC, but it seems plausible.
Backing this up is my belief nothing in a quadcopter’s flight needs to react in 6ms – if nothing else, because the quad has weight and therefore linear and angular momentum, it simply can’t react in line with such rapid and significant changes. Add to that the fact that unless the quad hits something, there’s nothing the quad needs to react to in that time frame, and it starts to sound plausible that actually, I need Phoebe to chill-out a bit by adding that filter.
For the moment, this remains a “Hmm, I wonder”, but if I can get decent behaviour from a DLPF of 5Hz, I may well consider upping the DLPF to 10, 20Hz or more, but soften the output via my own filter; I’d rather be in full-control of what’s going on than leave it to some inpenetrable magic box.
You may wonder “Why bother?”. First, as I said, I’d rather be in control not the DLPF; second, the DLPF is applied to gyro and acclerometer, and causes delay – this is unnecessary and inaccurate for the gyro; and thirdly, if I’m right, use of the DLPF is a sticky plaster to hide a flaw; instead the code should be tailored to fit the quad reactions better.
But first I need to prove that 5Hz DLPF solves the problem.