I’ve seen a few on-line conversations adamantly stating that quadcopter control needs a real-time OS (RTOS) or microcontroller to ensure accurate timing but with zero solid evidence to back it up. I’ve always been adamant this is just viral hearsay, and I’m being the heretic by coding in Python on Linux.
Of course the PWM signal to the ESCs needs absolute accuracy, but luckily the Raspberry Pi does provide hardware PWM.
Anyway, yesterday, I got to do some testing on the newly restructured code, and the results were underwhelming. Not terrible but not the radical change I was expecting. The only possible cause I could see in the stats was noise swamping accelerometer data.
I’m now not sure how exactly that led to a train of thought about fine-tuning time in my code, but it did.
The net result now is that there is a single time-stamp in the code taken immediately after I read a new batch of sensor data. From that point onwards, time effectively stops for the processing of that data by the rest of the code. All integration, averaging, and PID integration and differential processing uses that single timestamp. That makes for best accuracy in all three(ish) areas. It also has speeded the code up by another 5% (all 7 PIDs had their own time tracking which has now been removed). This means I can also reduce noise by including more sensors samples in the integration and averaging code before feeding it to the PIDs at the same rate as before. So beneficial in lots of ways.
Timing innaccuracy probably wasn’t the cause of the accelerometer noise, but at the same time, improving it has to be “a good thing”TM. My best guess as to the cause of the noise is a dodgy motor which if spun manually, sounds like it has muck in its bearings. Also the new high power props spin slower bringing more prop noise in under the MPU6050 dlpf.
I’m now hoping the timing rework, combined with lower dlpf and a new motor will cut the noise down significantly allowing me to see the results of the code rework.