Time is of the essence.

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.

2 thoughts on “Time is of the essence.

  1. Not sure what accurate timing is being talked about exactly here. OK, you have to make sure the PWM signals are good, which as you say is handled by the hardware. Other then that, it surely depends on exactly what flight characteristics you are going for.
    Example: You limit the vehicle’s roll rate to a maximum of 5 degrees per second, and also want to limit the vehicles attitude to be within +/-10 degrees of level. From level flight, it takes 2 seconds before the vehicle has rolled 10 degrees. (Of course, if there is a continuous external force being applied which causes a roll of greater then 5 degrees per second and the vehicle is trying to compensate for that then it will fail to completely compensate, but I’m just thinking about simplest cases for the moment, pun not intended). Now, for a Raspberry Pi, 2 seconds is a lot of time to check the attitude and take appropriate action, even using Python. Roll rate is determined by the difference in thrust between rotors, in the simplest case the left and right pair.
    Example 2: Roll rate is permitted to be 360 degrees per second. From level, the vehicle has a maximum of 1/36 seconds to take action before the 10 degree roll limit is reached. A bit more challenging to say the least.
    In the first example a relatively leisurely approach to updating the rotor speeds will easily keep the vehicle within the +/-10 degree roll limit.
    Now consider applying an external force, which the vehicle will try to oppose in an attempt to maintain level flight. If the external force is constant then the control system will go through the loop of comparing the vehicle’s attitude with level and adjusting the thrust of the left and right rotors to roll the vehicle until it is back to level. The more quickly the loop runs, the more smoothly the vehicle will roll back to the level position.
    My conclusion: The speed of looping through the control steps does not necessarily require a RTOS, just sufficient speed for the requirements.

    • There just seems to be a belief that an RTOS (rather than Linux) is needed for the timings to drive a quad. The specific “timings” are never stated. Other than the PWM, I reckin that’s rubbish (utter b0ll0x actually!)

      The RPi can supply hardware PWM with 1 – 2ms pulses at 1us resolution with a 300Hz carrier – more than enough to keep the ESCs happy.

      The rest just needs just a little care in the code. My timer tuning as all about getting as many loops through the control code – trying to keep it over 200Hz. The PWM output only needs say 30Hz updates, meaning I can average out more noise from the sensors the faster the outer sensor reading / averaging code runs.

      I do also have the some tweaks in the code to stop it being paged out to ‘disk’ from ‘ram’ to ensure that nothing outside can cause it to jitter or block, but that’s more a safety precaution than a necessity

      Prior to the last few days’ changes, the code loop had dropped down to about 185Hz, but is now up to about 215Hz. Now I’m back from Legoland(!) I hope I’ll get a proper chance to test the code ‘rewrite’ properly against the noise produced by the more powerful and hence slower spinning props!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.