The future’s bright; the future’s orange!

Well, tangerine actually!

With the IMU FIFO code taking the pressure off critical timings for reading the IMU, a huge range of options have opened up for what to do next with the spare time the FIFO has created:

  • A simple keyboard remote control is tempting where the QC code polls stdin periodically during a hover phase and amends the flight plan dynamically; ultimately, I’d like to do this via a touch screen app on my Raspberry Pi providing joystick buttons.  However for this to work well, I really need to add further sensor input providing feedback on longer-term horizontal and vertical motion…
  • A downward facing Ultrasonic Range Finder (URF) would provide the vertical motion tracking when combined with angles from the IMU.  I’d looked at this a long time ago but it stalled as I’d read the sensors could only run at up to 100kbps I2C baudrate which would prevent use of the higher 400kbps required for reading the FIFO.  However a quick test just now shows the URF working perfectly at 400kbps.
  • A downward facing RPi camera when combined with the URF would provide horizontal motion tracking.  Again I’d written this off due to the URF, but now it’s worth progressing with.  This is the Kitty++ code I started looking at during the summer and abandoned almost immediately due both to the lack of spare time in the code, and also the need for extra CPU cores to do the camera motion processing; Chloe with her Raspberry Pi B2 and her tangerine PiBow case more than satisfy that requirement now.
  • The magnetometer / compass on the IMU can provide longer term yaw stability which currently relies on just the integrated Z-axis gyro.

I do also have barometer and GPS sensors ‘in-stock’ but their application is primarily for long distance flights over variable terrain at heights above the range of the URF.  This is well out of scope for my current aims, so for the moment then, I’ll leave the parts shelved.

I have a lot of work to do, so I’d better get on with it.


Hmm, that’s interesting, but…

not in the way I’d expected…

Scrot screen capture

Scrot screen capture

What’s interesting:

  • using the finest level of data error checking, the numbers are huge – 36 errors during warm-up rising to 50 after the flight – some of these may actually not be a problem because Phoebe was stationary throughout; an error is spotted when the sensors partially read as 0xFFFF starting from the Z gyro, but for the Z-gyro, 0xFFFF = -1 = 0.008°/s
  • the yaw angle read prior to takeoff is ridiculous – Phoebe doesn’t move throughout this flight, yet yaw says she span clockwise by 70° during the warm-up period!
  • The IMU core temperature only varied by 0.02°C between boot-up and the end of the flight – this is a good thing and again suggests any temperature drift during a flight is due to breeze

The second is the only real problem as it will skew the initial angle calculations made during warm up; it also add this during flight but there isn’t the corresponding yaw it should introduce. I have to assume the yaw PID is doing its job well?.

Anyway, putting the protecting code back in place lead to this.

Scrot screen capture

Scrot screen capture

All’s looking a lot happier here.

The whole point of this is to try to compensate in software for the temperature drift during warm-up time, and afterwards when the props start spinning and the breeze cools the IMU back down; this was my speculation for why indoor flights don’t drift, but outdoor flights do. I think it worked but it was hard to just: comparing flights with and without boot-up prediction, the predictive code did seem to drift less, but both flights failed to reach their intended altitude, and the flights were both killed after a few seconds to stop Phoebe tripping over her toes. I’ll try later on in the day once the ambient temperature has risen about 10°C.

P.S. I don’t think there is a way to fix the height changes in different ambient temperatures – I think only an altimeter can sort that.

Blind, deaf, disorientated, lost and scared of heights…

and yet, amazing.

So in that last video of a ~10s flight, Phoebe drifted about 1m when she shouldn’t have.  To me, that’s amazing; to you, that may be underwhelming.  So here’s why you should be amazed.  Basic school math(s):

distance = ½ x acceleration x time² ⇒ plugging in the numbers above says she was accelerating at 0.02m/s² (2cm/s²) instead of zero to travel 1 meter in 10 seconds.

Gravity is roughly 10m/s².  The accelerometer is set to read up to ±4g.  So that’s a range of 8g or roughly 80m/s²

So 0.02/80 * 100 = 0.025% error or a ±8 error value in the sensor range of ±32768.

Now the critical part – the sensors are only rated at 2% (±655) accuracy, and yet I’m getting 0.025% or 80 times that degree of accuracy.

And that’s why I don’t think I can get things very much better, whatever I do.

There is a slight chance that when the A2 is released (sounds like that’s shifted to next year now), I may be able to run the sampling rate at 1kHz without missing samples (I’ve had to drop to 500Hz to ensure I don’t miss samples at the moment).

Other than that though, she needs more sensors:

  • camera for motion tracking (!blind)
  • ultrasonic sensors for range finding (!deaf)
  • compass (!disorientated)
  • GPS (!lost)
  • altimeter (!scared of heights).

but they’ll also need an A2 for the extra processing.  So this is most definitely it for now.


Every time I threaten to retire Phoebe, she throws a spanner in the works.

I took her out for some horizontal velocity PID tuning this morning.  It’s below freezing point outside and my expectations weren’t high, but her thermostat code still brought her sensors up to the 40° calibrated temperature.  Probably 5 flights consisting of 3 seconds take-off at 0.5m/s, 5 seconds hover, and 3 seconds descent at 0.5m/s.

Of those 5 flights, one was, well, there’s no other word for it, perfect.  A perfect pass of the Ronseal test.  Don’t get me wrong, the other did well wrt drift management and getting to approximate hover over the take-off point but this particular flight just worked: take-off from a sloping ground stabilized up to 1.5m, completely static hover for 5s, and then an elegant descent back to the original take-off point.

The cause: gravity calibration in the Z axis.  Every flight starts with Phoebe peacefully sitting on the ground, measuring gravity in her X, Y, and Z axis.  That then produces a set of Euler angles used to rotate gravity back to earth axes where gravity should read 0, 0, 1 in the X, Y and Z axes respectively.  X and Y always measure zero to 8 decimal places.  Z seems to have a variability of 0.2% still though despite the thermostat – gravity could read between 0.998 and 1.002g and it seems entirely random.

But this particular flight, the sensors said earth gravity was 0, 0, 1.000009g!  That’s 0.001% error in the Z-axis or 0.1mms-2 acceleration error.  That correspond to a maximum drift velocity over the course of the 11s flight of 0.55mms-1!

That has multiple effects, the key two being angles and velocity calculation: with 0.001% error in the Z axes, then all angles and velocities were essentially right for the duration of the flight, hence the fact she rose to the right height and hovered over her takeoff position.

I’d love to know the cause of the random variance of accelerometer values from the Z axis – is it sensor tolerance, or ground vibrations or something else I’ve missed (the motors aren’t running at this stage of initialized before you ask)?

A barometer / altimeter + magnetometer / compass may fix it entirely:

  •  the barometer / altimeter will provide an alternate measure of vertical velocity @ ±10cm resolution
  • the magnetometer with provide orientation, and critically pitch, roll and yaw compared to the earth magnetic core.

A fusion of these sensor readings with their current accelerometer source could well improve matters – “fusion” just being the merging of the sources through a complementary or Kalman filter.

So why don’t I just get on with it?  Because still I cannot find a sensor that meets critical physical properties – none of them provide a double row of pins with 0.1″ pitch in both directions to allow connection to a breadboard or prototype PCB.

I think I need to put my politest head on and see whether DroTek have fixed their pin pitch spacing for their 10 DOF IMU yet.  Wish me luck!