Crash back down to earth.

Normality has returned.  I took Hermione out to test what video resolution she could process.  It turns out 640 x 640 pixels (40 x 40 macro-blocks) was yesterday’s video frame size.  800 x 800 pixels (50 x 50 macro-blocks) this morning was a lot less stable, and I think the 960 x 960 pixels (60 x 60 macro-blocks) explains why.

At 960 x 960, Hermione leapt up into the sky; the height breach protection killed the props at 1.5m but by then she was accelerating so hard she probably climbed to 3m before dropping back down like a brick onto the hard stone drive upside-down.  Luckily only 2 props got trashed as that’s an exact match for the spares I had left.

Rocketing into the sky appears to be Hermione’s symptom of a IMU FIFO overflow.  For some reason, Hermione doesn’t catch the FIFO overflow interrupt so she just carries on, but now with gravity reading much less than zero because the FIFO has shifted so in fact she’s reading gyro readings, and so had to accelerate hard to compromise.  The shift happens because the FIFO is 512 bytes and I’m filling it with 12 byte batches; 512 % 12 != 0.

How does this explain the 800 x 800 wobbles?  My best guess is that these 2500 macro-blocks (800² / 16²) are processed just fast enough to avoid the FIFO overflow shown by 900², but does have a big impact on the scheduling such than instead of the desired 100Hz updates to the motors, it’s a lot nearer the limit of 23Hz imposed by the code.  That means less frequent, larger changes.

So that mean I need to find the balance between video frame size and IMU sampling rate filling the FIFO to get the best of both.  Luckily with indestructible Zoe imminently back in the running, I can test with her instead.

7 thoughts on “Crash back down to earth.

  1. Hi,

    I’m reading about your problems with both I2C and computational performance, and I have to ask: have you considered “hybrid” approach with dedicated circuit (like STM32) to handle low level functions (like motor updates, gyro processing, inner PID loop) and RPi to handle high level functions like positioning?
    While RPis are excellent small computers, they are not realtime systems and not best suited for those kinds of usages

    • The whole point of this project has been to see whether a Raspberry Pi running standard Raspian Linux running Python could fly an autonomous drone, and so far I’ve not found any reason saying it can’t. There are three critical factors I’ve found that might suggest a RTOS is mandatory, but isn’t:

      1. Capture every IMU sample – using the IMU FIFO makes this easy and makes ‘space’ to do other things – the IMU sampling is set to 500Hz and the motors’ PWM still gets updates at about 100Hz – the difference helps average out noise from the IMU accelerometer.
      2. Accurate clocking – I use the IMU clock i.e. the number of samples on the FIFO to do this – this is critical for the various bits of integration over time in the code e.g. acceleration -> velocity -> distance for example
      3. High speed and accuracy PWM – the RPIO (not RPi.GPIO) python library exposes RPi hardware PWM channels to the GPIO pins with a resolution of 1us.

      The problem I’m hitting here is processing the video motion tracking macro-blocks fast enough before the IMU FIFO overflows – that’s the cause of this crash – moving this lot out to ‘C’ code would solve this if really necessary, but so far, keeping the video resolution down to 640 x 640 pixels works fine. The video frame rate also gives me another external clock which I use for converting video motion to velocity.

      So as yet, I’ve got no need for an RTOS or Arduino etc. All that’s left is GPS tracking, and this is such a slow input with simple processing that I’m pretty confident this can be done exactly as I set out: just Rasperry Pi + Raspian Linux + Python.

      This is very much a research project to prove the point; that’s why I bought the DJI Mavic Pro when I simply want to have some fun 🙂

      • I love research project and like to reinvent the wheel from time time by myself, so I have great admiration for the work and effort you put into this project. I, for example participate in INAV flight controller project. For research and fun.

        But, while reading your reply, something has hit me: “the difference helps average out noise from the IMU accelerometer” . Does it mean you use accelerometer for flight stabilization? Not the gyroscope? If so, why? Acc is very noisy and from INAV experience I know that if LPF on it is above 15Hz it gets very very noisy. And 15Hz LPF is just too low for good flight characteristics. So, is it acc or gyro fed into PID loop after all?

        • I do use gyro for flight stabilisation, yes. But because mine are autonomous, I use the accelerometer integrated for velocity and distance (as well as the usual angles). DLPF is set to 0x1 = 184Hz on the accelerometer – the point is getting all the data I can rather than risking throwing away subtle valid data. Vibrations from props etc all averages out ultimately.

          I then use a merge of accelerometer and gyros to give stable, noise free angles that don’t drift over time.

Leave a Reply

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