White off

OK, I’ll stop on the “white” blogs after this one.

I’ve just done some more 0g calibration as per yesterday, but in the early-morning cooler temperatures outside.

Outdoor 0g offsets

Outdoor 0g offsets

Compared to yesterday’s indoor X, Y accelerometer offsets of (40, 200), this mornings results are roughly (3.5, 157.5) so there is a temperature drift, although the overall shape is similar.

I then flew Zoe outdoors on yesterday’s indoor offsets, and still got reasonable 10s flights with about 1m drift.  Later today, I’ll take her out in the warmth and fly with the offsets from yesterday, and try to video the results for you to see.

White out

I’ve been unable to get Zoe working in WAP mode with the mid-March release of Jessie.  Sometimes the hostapd starts fine, sometimes it doesn’t, and there’s some conflict between configuring the static IP address in the DHCP client config (dhcpcd.conf) and the booting of the DHCP server (udhcpd) – it starts OK according to the boot logs, but by the time I’ve logged in, it’s stopped.

So for now, I’ve dropped back to the end-January image that works, and I’ve stored off a copy of the working pre-WAP mid-March image so I can pick it up another time.

Then I did some tinkering with 0g offsets, measuring them 5 times, then twisting Zoe 90° and measuring again until I had 20 readings.  Here’s what it looks like suggesting an X offset of about 40 and a Y offset of about 200 is about right.

20 0g offsets

20 0g offsets

So I then took her out to fly several 10s flight including 6s of hover.  Some were immaculate, others less so, and the main factors (guess work) are the slope of the ground, and the weight balance, particularly if it shifts in flight because (for example) I’d not got one of the batteries tied down as tightly as possible!  Even for the imperfect flights, it was possible to see her successfully stopping the drift, and then the drift started up again, to be stopped again.  I think some PID tuning is required here as this suggests the correction is using the P part of the PID and it needs some I.

Progress report

Although the blog’s been quiet, I am still tinkering with both Zoe and Phoebe.

Zoe’s drift is better with 3 changes:

  • I’ve changed my 0g offset calibration so that it’s now done standing on her feet, and an average of 4 readings are taken with her rotated 90° each time and an average used
  • I’ve changed the double sided foam sticking her HoG to the frame – it’s all a bit of a balancing act between having her held down firmly, and yet also providing buffering against vertical prop vibrations
  • I’ve change the code which controls how many samples are per motion processing – there was a minor bug in the timing I knew of, but until now had not thought it worth the effort fixing it.

Here’s the result.

I don’t think it’s going to be possible to get things much better – my guess is the 0g offsets are the dominant contributor to the reduced drift, and they vary. Here’s the output from three runs – the first with her resting on her props, and the other two on her feet; the entries with the Z axis set to 0 are the averages of the preceding 4 calibration test entries. 8000 is roughly 1g to give you an idea of the size of these offsets.

0g calibration results

0g calibration results

The progress with Phoebe is less positive; with the SRF02 rangefinder installed, the code blocks during initializion; i2cdetect can see the sensor so I presume it’s because the sensor is only rated to 100kbps I2C baudrate.  There is a similar URF from a different manufacturer which does support 400kbps, but only if the I2C master (the Raspberry Pi) supports clock stretching; sadly the RPi I2C driver does not, although that may be fixed soon apparently.  However, until that happens, height control using the URF is blocked.

Without the sensor, she’s flying, but occasionally seems to decide to drift; it’s not a steady drift, it suddenly kicks in as though she gets a dodgy reading from the sensors.  I then have to kill the flight before she gains too much height.  It’s not clear to me yet what, if anything I can do about this.

Soul destroying

Yet another slow period here on the blog, sorry.

Stuff is rattling around my head:

  1. should I buy the latest Dyson d8 handheld vacuum cleaner or stick with my current eol DC44 that’s slowly dying on me?
  2. should I buy an Apple iPhone SE or stick with my 4s that’s also slowly dying on me?
  3. should I sell my soul to pay for one or both of the above?
  4. should I give up on Phoebe and Zoe or keep banging my head against a brick wall with them and their consistent horizontal drift?

I’m guessing you’re probably only interested in the 4th item in the list above?  I’m working on the laser dot tracker to get height information and to take Phoebe for a walk on her laser leash.  Trouble is that because of the horizontal drift, there isn’t much time for the camera to latch onto the two fixed dots which track height, and (more importantly in this context) the third from the leash, especially as indoors, I’m only getting a camera shot or two per second.  Effectively the laser solution won’t work without a reducing the horizontal drift further without further sensors.

The 0g offsets of the X and Y accelerometers when horizontal seem to be the best contender so I’ve been putting a little more effort in that area.  A typical set of offsets from Zoe might read:

-138.571429 98.380962, -8313.238095

There are raw averaged accelerometer readings in the X, Y and Z directions.  In ms-2, they read

-0.166 0.118, -9.955

So Zoe when stationary and upside down thinks she’ll drift ≅ 3m backwards, 2.125m to the left over her standard 6s flight.  Which means in a real flight, she should be compensating for this by drifting 3m forwards and 2.125m to the right; yet from every recent flight shown in videos, she consistently and only drifts left by a meter or two.  So I’ve got something very wrong about 0g offsets or some area of horizontal flight control I can’t guess.

And this is frustrating enough that selling my soul to Apple or Dyson might actually be more satisfying!

 

Travel sickness

I took Phoebe to Cheltenham on Wednesday to check out the new location for the Cotswold Raspberry Jam (tickets still available but going fast).

Yesterday (Thursday), I took her out for a few more ‘confidence building’ test flights, and she was a changed quad – she climbed too fast and continued to climb during hover and she drifted significantly.  Oh sh1t – we have the perfect location to show her off, but somehow she was no longer fit to be shown.

Today (Friday), she’s back to behaving normally again so I’m concerned her accelerometer had drifted in transit to Cheltenham – while carrying the case, her Y axis was pointing down, sensing gravity and her Z axis was not unlike normal – that matches the drift I was seeing.  I hope that’s not the problem as that would ruin the chance of an indoor flight at the Jam – hopefully the weather will be good on the day, so at least an outdoor flight should still be possible.

Anyway, while trying to work out what was going wrong, I reviewed a couple of things I’d not done for a while.

The first is prop balancing – using my Dremel to lightly strim the underside of the props so that they have a matt surface, and they balance well on one of the maglev prop balancers.  The matt surface allows the air to flow over the props smoother which leads to better more efficient air-flow, and reduced turbulence resulting is greater lift.  For that reason, I used P1000 wet and dry sandpaper to matt and smooth both top and underside of the props.

Balanced blade

Balanced blade

The other is (controversially) to re-add 0g calibration but only on the X and Y axis – the primary directions of drift – in such a way it can be done indoors from a relatively flat surface prior to demo flights, but also can be disabled easily without the risk of coding errors with a destructive resultant flight.  Calibration takes half a second, and results are stored to file, and reloaded each flight; if the calibration is not possible, then the calibration file settings can be set to 0 to disable it, thus dropping back to Phoebe’s performance from the last few days.

I don’t think either of these were related to her travel sickness, though now done, there’s no point in undoing them again!

I couldn’t let it lie!

I still feel there must be a way to get a fixed 0g offset algorithm, based on the fact off-the-shelf quads won’t have to undergo this level of faff by the user; there must be a simple setup for the manufacturer.

Here’s what I got in my latest attempt:

XY 0g offsets vs. temp change

XY 0g offsets vs. temp change

Look’s good, doesn’t it?  Nice trend lines which the samples offsets are really tightly aligned with.

The graph X-axis shows the change in temperature since the IMU started.  The 333.87 is about 1ºC, so this is what the test plots offset changes as the chip temperature increases away from the boot temperature.

The graph Y-axis shows the 0g offsets: the accelerometers scale is configured as ±4g so the vetical axis covering -1000 ⇒ +800 is the equivalent of -0.12g ⇒ +0.10g.

The lines show the 0g offsets as the difference in temperature increases from the initial boot termperature: the green ones are the accelerometer X-axis offsets; the blue ones are the accelerometer Y-axis offsets; the paler -464 lines come from a garage estimated +10ºC test environment; the darker +1600 lines come from an indoor estimated +20ºC.

OK, with that explained, down to so positive interesting bits:

  • the 0g offsets are all very close to 0 when the test starts i.e. when the temperature difference from ambient is near to 0.
  • all of the samples fit a linear trend line beautifully.
  • the 2 y-axis trends are very similar despite the tests being booted at very different temperatures

But there are very odd bits too:

  • in contrast to the y-axis trends, the x-axes trends are virtually the opposite of each over when booted at the very different temperatures
  • all of the offets are hugely different from the ones I’ve measured by the same method previously, perhaps by a factor of 10!

Net: I critically need to try to understand these oddities if I stand any chance of using these offsets in a meaningful way.  If I can, then this gives me the best possible / nigh on perfect way to allow for offsets shifting as the difference from ambient changes.

More zero-gravity temperature trend graphs

OFFS

OFFS

So these batches of zero-g offsets were gathered with care. Each cluster is about 20 samples.  They look good, don’t they, but I’m struggling to trust them.

Here’s why, moving from left to right for the clusters of samples:

  • the leftmost clusters were taken in the garage (ambient 10ºC)
  • for the next pair of clusters, HoG was powered up in the beer fridge stuffed with ice blocks (ambient << 5°), readings taken, then moved out of the fridge (ambient ≈ 20°C) and more readings taken
  • finally the last pair of readings were taken with HoG booting in the office (ambient ≈ 20ºC), and then moved back inside the fridge (ambient << 5ºC).

Or to put it another way, following any set of data left to right, the estimated ambient temperature was 10, 5, 5, 20, 20, yet the corresponding temperature read from the chip is more like 19, 21, 29, 31, 32.  The biggest discrepancy is between the two 5’s in ambient and the 21,29 pair as reported by the sensor.  The next is the fact the garage reading of temperature is lower than the beer fridge packed with ice!

But I don’t have any choice but to use this data for best estimating zero-g offsets against temperature.

Why do I care so much about getting this accurate?  Because the difference between the minimum and maximum varies between 0.03 and 0.1 ms-2 – and that the difference between a stable hover and accelerating in any direction.

Or to make it more explicit, in my back garden, the longest flight I could hope for is 7s before HoG smashes into a brick wall, or flies up over the roof top unless I get this tuning absolutely accurate.

Annoyingly, there are gale force winds for the next to days, so I won’t be able to test the results of this latest calibrating for a while.

Zero-G, ambient and calibration

OK, so I think I’ve got my head around this.  These are the readings taken from the beer fridge packed with ice blocks.

'ice cold' beer fridge

‘ice cold’ beer fridge

Clearly the absolute temperature readings are rubbish, but also clearly, the temperature range of the test is only about 1.5°C.  If you look at yesterday’s graph, these numbers above are the tight little clusters of samples around the 25 – 26°C.  The fact they are tight clusters is because the ice-laden beer fridge was able to hold the chip temperature stable while the testing went on.

Outside of such a temperature controlled environment, the chip temperature changes and so you get the spread of offsets shown in the graph.

So what does this mean?

  • first, for every flight, read the garbage “ambient” value as soon as the chip is powered up – ideally this means boot in the same environment the flight is going to happen
  • throughout the flight, track the changes in temperature – i.e. (raw temperature – “ambient) and use this value to work out the change in the offsets due to temperature drift.

The next step is calibrating offsets against the difference from ambient.  It’s going to take something like booting HoG and reading ambient, and then have her hard loop reading gravity in that environment whilst periodically logging the change in (temperature – ambient) versus offset.

I’ll report when I’ve got some data.

 

Finally…

with the offset / gain in place, and a tweak of the horizontal velocity PIDs, I finally can see drift control working.  It’s still there, but so much better than ever before.

It also confirmed I need to do some temperature trend-lining for accelerometer offsets and gains – I did the offset / gains indoors at about 20°C.  Outside it’s only 10°C and that definitely had a significant effect on vertical velocity, and to a lesser extent horizontal too.

I almost daren’t say it, but it really does now feel I’m on the downhill run and the finish line is finally in sight – still in the distance – but visible at last.  Phew!

Gravity calibration, past and present…

Here’s what I’ve tried for gravity calibration so far:

Sit Phoebe on the flattest platform you can find.  Sensors should read (0, 0, 1)g.  Save the actual values to file and use each flight.  Take-off OK, but drift terrible suggesting angle errors – suggesting not just sensor offsets but gain errors too (hindsight applied liberally). This ‘solution’ was the default for many months until I really started trying to actively attack drift.

Next try the same, but with temperature compensation – convert multiple readings of “(0, 0, 1)” like above against temperature, and use excel to produce a trend-line linear equation for any temperature.  Good, but still no effect on drift, because I was ignoring the possibility of gain as well as offset.

Then the mathematical approach, but still ignoring gain: if the accelerometer was perfect, and not accelerating, then the combination of all 3 dimension sensors must read 1g regardless of surface tilt.

√(ax2 + ay2 + az2) = 1

where sensor values = real values + offset.  Trouble here is too few equations with too many variables to find (or perhaps not, read on…)

So I went back to the experimental side, and ran 4 tests, with Phoebe tilted towards each leg in turn, trying to guess the equation that might find a fixed offset for each dimension. No luck, but again hindsight reveals I was tilting in 3 axes not two so all my guessed equations could not be right.  But I hadn’t spotted that.

I had considered all this in the past, buying a perspex cube inside which I could strap the unchristened Phoebe, measure g in 6 directions, and work out both offset and gain.  Sadly even duct tape isn’t strong enough to strap her down well enough, and I had much bigger problems back then

But today is a new day and after a good night’s sleep with my thinking cap on, with it comes a new plan to allow for gain as well as offset.  Start with a test platform tilted at an angle.  Sit Phoebe on that platform, both nose down and nose up, and read those values.

Accelerometer calibration test rig

Accelerometer calibration test rig

Then

a = g * (s + o)

where a is expected value for gravity, g is the gain, s is the sensor reading and o is the offset.

Nose down ‘a’ and nose up ‘a’ should be the same value with opposite signs leading to

g * (s + o) = - g * (s' + o)
g * (s + s') = g * 2 * o

So

o = (s + s') / 2

Then knowing the angle of tilt from my spirit level combined with the fact that the perfect sensor reading for the angle would be sin θ (with units of g) leads to

a = sin θ
g * (s + o) = sin θ
g = sin θ / (s + o)

I suspect that just an approximate value for θ will suffice, as the equation right at the top could be used to fine tune all the gains equally to ensure 1g at any angle of tilt.

Time to stop talking and get on with it. Here’s the raw data I got:

 Raw     Temp      X accel   Y accel   Z accel    X gyro    Y gyro     Z gyro

FD
-4011, 24.732941, -0.142926, 0.012745, 1.050931, -0.053121, 0.025203, -0.000613
-4003, 24.756471, -0.142944, 0.012847, 1.050797, -0.053175, 0.025116, -0.000586
-4007, 24.744706, -0.143027, 0.012854, 1.050942, -0.053439, 0.025573, -0.000224
AD
-4269, 23.974118, 0.158685, 0.007537, 1.050188, -0.051737, 0.025540, -0.000832
-4280, 23.941765, 0.158802, 0.007494, 1.050043, -0.051684, 0.025404, -0.000848
-4269, 23.974118, 0.158779, 0.007461, 1.050281, -0.052030, 0.025653, -0.000663
LD
-4119, 24.415294, 0.005269, -0.140297, 1.050463, -0.052647, 0.025136, -0.000694
-4105, 24.456471, 0.005559, -0.139865, 1.050735, -0.052635, 0.025112, -0.000635
-4117, 24.421176, 0.005273, -0.140439, 1.050992, -0.052608, 0.025244, -0.000740
RD
-4057, 24.597647, 0.010099, 0.160093, 1.050826, -0.052801, 0.025332, -0.000706
-4046, 24.630000, 0.009812, 0.160029, 1.050554, -0.053320, 0.025580, -0.000406
-4055, 24.603529, 0.009934, 0.160293, 1.051040, -0.053330, 0.025560, -0.000511

where FD = fore down, AD = aft down, LD = left down and RD = right down by 10°.

That results in the following

x_offset = 0.007894833
x_gain = 1.28560825
y_offset = 0.009969
y_gain = 1.333382476

Same thing can be done with the z axis using the same data slightly differently:

oz = (sz - s'z) / 2
az = cos θ
gz * (sz + oz) = cos θ
gz = cos θ / (sz + oz)

Resulting in the following – you get two sets of possible sets of offsets / gains depending on whether the tilt is fore / aft or port / starboard.

zfa_offset = 0.000359667
zfa_gain = 0.936797208
zps_offset = 0.0000383333
zps_gain = 0.937294721

Although the offsets are quite different between both samples, they are an order of magnitude smaller than the X and Y axis offsets so I’m not bothered – the gains match nicely which is reassuring. Because I didn’t turn Phoebe on her head, it’s not possible to find the offsets, so essentially, the offsets are 0, and the gain is covering the discrepancy.

And finally, some sanity checking (not with the wife this time) that everything I’ve done here matches the equation I showed at the start based upon the 12 samples I took.

√(ax2 + ay2 + az2) = 1

There’s actually 24 sanity checks as the z axis gain and offsets could be calculated from both the fore / aft (pitch) tilt values or the left / right (roll) values:

1.006204657	1.007968538
1.005967585	1.007731109
1.006276408	1.008040318
1.004816622	1.006578528
1.004608175	1.006369695
1.005035531	1.006797684
1.007888677	1.009651313
1.008157198	1.009920557
1.008939806	1.010703849
1.008478641	1.010242242
1.007941093	1.009703971
1.008978921	1.010743092

And actually, I’m really pleased with that – errors are primarily going to be due to the rather course measurement of 10° of tilt.  Next steps:

  • test the values above to see what happens live
  • refine the test rig for accurate angles
  • re-run the test at multiple temperatures and throw the gains / offsets into excel for adding temperature related trend lines.

On a roll again!