JIT Jamboree Jubilation

Zoe at 1kHz sampling, 8s flight from Andy Baker on Vimeo.

If you are interested in what triggered the transformation, have a look at these comments.

The net results are I’m getting perfect data reads at 1kHz sampling and alpf set to 2.  And that’s as good as the sensor can possibly provide.

So Zoe is good enough for the Cotswold Jam on Saturday (sold out, sorry), and my employer’s Engineering Conference the following week, and hopefully the Raspberry Pi Birthday Party in early March.

There’s probably some PID tuning to be done that might stop the low-frequency wobbles due to the gyro PID I gain being a bit too enthusiastic.  That would then curtail the drift too.

I’ll post more videos if that turns out to be true.

4 thoughts on “JIT Jamboree Jubilation

  1. That is weird, it never happened to me. Are you still reading 12 bytes at time? I did get some errors when reading the whole buffer (i2c miss), but didn’t go much further to investigate why.
    Maybe using SIG_COND_RESET = 1 can fix your problem? (I didn’t try it)

    Good luck at the Cotswold Jam 😀

    • I’m still reading 12 bytes at a time, and for just that one run they were consistently shifted by 4 bytes (bytes 1 & 2 were accelerometer Z axis)! Sync’ing the code after reset with the FIFO was easy enough as protective code. It’s only happened once so far with lots of flights, so I might be completely wrong. I’ll look at SIG_COND_RESET, thanks.

      The sync problem is possibly a timing issue with running at 1kHz sampling with python code perhaps? Dunno – hopefully the protective code will work and I can forget about it.

    • I don’t see the 0xFFFF (-1) readings any more, but I do still see some small 0gs mostly when I run with the 0 accelerometer low pass filter; I think these are real, and happen when the flight plan switch to hover after ascent and from hover to descent. Both are hard deceleration switches so short bursts of ~0g might be possible.

      I have found a new problem: according to the spec, resetting the FIFO is asynchronous. What I’ve seen once after a reset was the data in the FIFO was offset: it was az, gx, gy, gz, ax, ay but the code expects ax, ay, az, gx, gy, gz. I think it’s most likely at the 1kHz sampling rate, but is always possible. When it happened yesterday with gravity pulling on the X axis, the quad flipped immediately!

      I’ve just added some code to check the samples after FIFO reset and only leave the reset when az is where it should be. I now need to test lots today to make sure it’s safe for the CotswoldJam demo tomorrow.

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.