A bit more on drift tuning

So I ran a few more tests this morning fiddling with the horizontal speed PIDs to maintain drift tuning.  And actually, I think they worked with just the PID D gain set.  Trouble is, D-gain tends to be spiky normally as it tracks change in error rather than absolute error, so any minor wobbles tend to lead to big changes in output.  Throw into the mix the noise the accelerometer is renowned to produce and you have a recipe for disaster.  And that’s what happened.

On the plus side, she did maintain her overall position around her taking off point; on the minus side, she deviated several meters either side while doing so.

One of those deviations smashed her into the kids’ swings, ripping off her video camera – the cable got cut, but I think the RaspiCam should be OK.  In the same crash the leg / frame were distorted more than ever before – once again, repairable, but I am starting to think I may need to take her to the village park for testing!

Where next?

  • I’m wondering if I can do a running average of the accelerometer output to reduce the noise?
  • There is scope to reduce the DLPF in the MPU6050 from the 20Hz I’m using down to 5Hz – I think that’s my easiest step to try next
  • I do need to consider swapping to a horizontal acceleration rather than speed PID – perhaps now’s the time to do that, as it opens up the use of I gain for smoothing – the down side is that you’d only quickly nudge the joystick to change movement since it’s controlling acceleration rather than speed.
  • Finally, I’ll see if I can do something to add physical filtering to isolate the breadboard from the frame better – I have some silicone foam tape 1cm thick that the breadboard could sit on – this is a bit of a faffy rebuild those, so this is the last step – it turns out fixing Phoebe’s distorted frame meant she was in enough pieces I could add the new padded circuit, so we’ll see what effect that has.

11 thoughts on “A bit more on drift tuning

  1. @alex – it’s all a bit arbitrary – a balance between filtering out noise vs allowing as much real data in as possible. The higher the dlpf frequency, the less lag there is in the data because the filtering takes less time, but at the same time, you’re letting more vibrations in, so need high sampling rate to ensure vibration samples average out and you’re left with just noise-free accelerometer data.

    With my recent sample rate reaching 800Hz, I could go higher with the dlpf – motion processing at 43Hz so roughly 20 samples averaged, so I could open the dlpf up another step to 98Hz with 3.8ms lag – that’ll be next in line on my tinkkering list once I have the PIDs tuned based upon my latest understanding.

    • I suppose “xx” in the
      –dlpf xx
      tag at the end of the run-code command represents
      1, 2, 3, 4, 5, 6
      corresponding to this right?
      # 0x01 = 180Hz
      # 0x02 = 100Hz
      # 0x03 = 45Hz
      # 0x04 = 20Hz
      # 0x05 = 10Hz
      # 0x06 = 5Hz

      is there any way to program different cutoff frequencies? also, how do you quantify lag?

      and just to make sure I get the big picture, the dlpf is ONLY applied to the gyro measurements right or is it also implemented for the accelerometer readings as well? This is executed inside the chip itself since the Invensense provided that capability?

  2. This post is very interesting. I see in git code that MPU6050 bandwidth is now 5Hz, isn’t it too narrow? I’d expext a response time of more than half a second.

    • The 5Hz is the digital low pass filter frequency – the filter used to remove noise from the sensor inputs – it might be a bit low so I do have some testing to do. I’ve tested with 20Hz also. But this doesn’t affect the response time.

      The response time (how often the sensors produce new information) is set to 250Hz, so comfortable faster than the 170Hz the code is currently running at.

      So the quads overall response time currently is about 6ms which is plenty fast enough

        • The picture you show is a high pass filter set to about 2Hz – so any data below 2 Hz is filtered out. My DLPF is a low pass filter, set to 5Hz (though I might try up to 20Hz). This means that movement in the sensors slower than 5 Hz gets through – so for example any linear motion or rotation gets through. What doesn’t get through is the physical noise produced by the rotating motors which can dominate the sensor output, hiding any real movement. This means you get better readings that are accurate – you only get movement of the quad, not vibrations..

        • Sorry, I’ve just changed my mind – the 5Hz DLPF is the best; The signals we are interested in from both the accelerometer and gyro are sort of like DC signals – essentially low frequency (~0Hz) changes in acceleration and angular speed. Any higher frequency sensor readings are all essentially noise – oscillations caused by the motors etc. Certainly for Euler calculation to be accurate, there must be no acceleration; without accleration then we are just using the distribution of gravity across the 3 axes to calculate the angle of pitch, roll and tilt. By using the lowest available DLPF yields the most accurate Euler calculations even if there is acceleration in the system.

        • My apologies Frederico, I now see your point: I’m going to set the MPU6050 DLPF to 42Hz – this should allow all the relevant information through, and the complementary filter will average out the noise from the angles calculation.

          I also use the acceleromter for vertical ascent / descent speed, but as that’s an integral, it too shouldn’t be too badly affected by noise.

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.