Incy wincy spider…

Legs

Legs

I’m putting these modified DJI F450 Flamewheel legs (leftovers from Phoebe) to the test. On Phoebe, they were the cause of a lot of damage because they were attached to the underside of her ‘body’; she often tripped over her own legs on landing, and smashed her props into the ground.  So I replaced the legs with the gold foam dome and the legs got shelved.

But in their reincarnated version, they are mounted out on the arms, primarily to protect the ‘wrists’ of the arms from bending if they hit the ground. These arms are lovely bits of machined aluminium, but there is a weak-spot at the wrist where the arm’s cross-section like this Π changes to this .  I’ve got a stack of arms with bent wrists due to landing on them.

If today’s weather clears enough for a quick test flight, I’ll try them out to see if they can sustain landings from the much heavier HoG, and if so, they’ll become a permanent installation.

You put your right prop on..

your right prop off.
on, off, on, off
and smash into a wall.
You do the hokey cokey and you turn around.
That’s what it’s all about!

Why do all my crashes break a right hand, ACW / CCW rotating prop?  I have so many spare lefts it’s getting embarrassing!

Though it wouldn’t help that sometime (I think yesterday) I fitted 10″ instead of my normal 11″ props to Phoebe’s left hand side.  Oopsy – it least that explains the increasing negative (ACW) rotation, eventually leading to the left wall collision.

On the plus side, with the correct props fitted on the left hand side, I got stability matching the take-off angle with the attitude only PIDs (i.e. completely as expected), and zero-drift once the motion PIDs were included too (again, completely as expected).  In other words, absolutely perfect…

…except for the fact she kept climbing; nevertheless still worth videoing.  Two reasons why I didn’t video the flights – they’re called Jacob and Milly; I’m the parent in charge until mid-afternoon so my time for test flights today is very limited!

So back to the Z-axis velocity PIDs, it seems.  I wonder whether the dlpf of 3 (44Hz, 4.9ms lag) could be the cause – either too high or too low – I can speculate on the cause of either way, so I’ll try both dlpf 4 (20Hz, 8.3ms lag) and dlpf 2 (90Hz and 3.0ms lag).

Laters…

Another one bites the dust:

another flaw fixed. After some more PhD / Masters paper reading yesterday, I realized the angles being calculated should not all be in comparison to the the initial inertial reference frame; instead as the rotation matrix is applied, each angle is calculated against the reference frame the previous rotation had achieved.

So my pitch angles were wrong, which lead to bad gravity calculation prior to take-off and that’s never going to be a good thing!  With the code change, the values read of the sloping takeoff platform are as follows where qfrgv_* are gravity read in the quad reference frame, and efrgv* are those reorientated back to the earth frame.  The X and Y values are perfect, but Z is out – that doesn’t surprise me as the Z-axis accelerometer is twice as inaccurate as the X and Y.  Never the less, the ‘drift’ it shows is 7cms-2 which isn’t bad, though it is making it hard for phoebe getting as far off the ground as far as she should be.

pitch 8.722535, roll -0.448118
qfrgv_x: 0.152762 qfrgv_y: -0.007787 qfrgv_z: = 0.995656
efrgv_x: 0.000000 efrgv: 0.000000 efrgv_z: = 1.007337

There’s still something wrong though as this plot of the flight shows:

Mucky lawn flight path

Mucky lawn flight path

She thinks she’s moving backwards according to the sensors and her compensation for that actually has her moving forwards in the real world.

The accurate measure of gravity values suggests that calibration isn’t the problem.  My next suspicion is the way the earth frame velocity PID targets are converted to quad frame.  Fingers crossed.

Supercalifragilisticexpialidocious

I’ve just posted the latest code to GitHub, and I think it’s nigh on perfect (IMHO) – there’s now nothing on my mental ‘niggle’ list that could make it better.

However (and it’s a very big however), it requires nigh on perfect accelerometer calibration.  To give you an idea, if the accelerometer reads gravity as 1.001g rather 1.0g (0.1% accuracy), then you’ve get drift at roughly 1cm/s2 and that builds up to significant drift beyond a few seconds of flight.  Yet the sensors alone are only rated at ±2% accuracy, or 20cm/s2. The 0.1% accuracy error I mention represents a twenty fold improvement over the base 2% level of calibration and is my current best effort but it still limits the flights to tens of seconds rather than minutes in length.

So here in detail is what I do:

  • find two locations with a broad and stable temperature differential – in my case a beer fridge, and the warmest room in the house – in my case, my home office as it has way too many computers in it!
  • Separate the Raspberry Pi from the quad frame and stick it to the inside of a 5 sided perspex cube aligned closely with one edge of the cube.
  • Within both environments, ensure the platform for the cube is flat and horizontal – I have a 10mm thick perspex square with wing-nut bolts at each core and a 0.5° accuracy spirit level to get the best horizontal possible: I sit the beer fridge on this, or just the cube on this depending on the required temperature environment.
  • Within each of the two temperature environments, I then rotate the cube on each of the six sides, reading sensors (sudo python ./qc.py -c) each time until I have a sample for each that is within half of a degree (celsius / centigrade)  of each other according to the sensor output – that’s about as good as I’ve achieved so far because the sensor warms up the more samples you take!
  • From the sensor readings of 1g over the six sides of the cube at a given temperature, you can calculate the offset and gains of those axes such that each reads ±1g at that temperature.
  • With those offsets and gains at two diverse temperature points, you can then calculate a linear mapping between and beyond those temperature points to allow calculation of offsets and gains at any operating temperature.  The sensor output is reportedly linear across temperature at ±2% also and that should be good enough – 2% error in gain / offset at a given temperature is much better than 2% error in absolute readings.

Here’s the data I’ve obtained and sorted.  The leftmost column is raw temperature readings.  The rightmost 4 columns are gravity measured over 3 axes, in both directions at two temperature ranges.  Column 2 is temperature in celsius / centrigrade – I don’t use this in the calibration, but it makes it easier to spot a small range of temperature values.  The accelerometer scale is set to ±2g so the values of ±16384 are whats expected, and are the targets of the calibration calculation.

-3393, 26.550588, 16537.84, -294.84, -842.44
-3383, 26.58, -16404.88, -14.1, -1062.72
-3390, 26.559412, 179.44, 16369.72, -953.2
-3391, 26.556471, -59.44, -16662.18, -974.54
-3383, 26.58, 45.62, -176.4, 15436.18
-3386, 26.571176, 75.52, -94.92, -17342.8
-6517, 17.362353, 16505.3, -275.08, -531.38
-6543, 17.285882, -16426.64, 1.22, -846.94
-6484, 17.459412, 185.44, 16368.36, -695.24
-6462, 17.524118, -55.6, -16649.48, -707.32
-6552, 17.259412, -38.96, -177.82, 15697
-6552, 17.259412, 96.96, -75.92, -17063.76

 

Slip sliding away

Went out testing yesterday morning aiming to tune the drift code, but it was a complete mess.  I can’t fully explain why, but certainly one factor was the battery and raspberry pi were slipping around in flight, despite being firmly attached with velcro and either none slip padding (for the battery) or non-slip feet (for the Raspberry Pi).  The problem was the moisture still in the air after the morning mist cleared.

So I’ve improved the velcro, made better fitting non-slip padding for the battery, and added double sided sticky tape to hold the Raspberry Pi down, and I’ll try again later today.

It’s hardly worth blogging about this, other than to point out how well attached to the quad frame all the loose pieces must be if you stand any chance of consistent test flights.

 

Making a list, checking it twice

because Phoebe is back and I’m treating her nice!

Her battery is now much more firmly attached than before, so hopefully no further slippage there.

New micro-SD card arrived yesterday, Phoebe’s backup image applied, apt-get update, upgrade, dist-upgrade, and she’s fitter than ever.  Thursday is good weather for testing, so I’m currently upgrading the diagnostics (making them easier to interpret), guesstimating / double checking PID gains, and also planning tests.

I realized that take-off from uneven ground does not need the horizontal speed PID, just the absolute angle PID.  This means I can test the latter without the results of the former confusing things – I’ll just set the gains to 0.  She may inherit some horizontal momentum during takeoff until the complementary filter angle starts to be dominated by the accelerometer Euler angles (rather than the integrated gyros which can’t sense the tilted ground), but then she should drift at a (slow?) fixed speed horizontally.

Then if that works, the horizontal speed PID gains can then be used to stop the drift.

Only Thursday will tell.

I started singing…

Fly, Fly, little Raspberry Pi
Reading sensors, driving motors
Spinning propellers thereby…
Lifting you up, soaring into the sky
While the camera really proves you can fly,
The camera really proves you can fly!

First untethered, successful, safe take-off, hover and landing from Andy Baker on Vimeo.

With my sincere apologies to Don McLean for corrupting his original far superior lyrics

If you ignore the yaw, this represents a successful take-off, hover and land.  It’s programmed to be a 9s flight, 3s takeoff, 3s hover, and 3s land.  The drift is just due to the trampoline not being completely horizontal, and I’m not at all worried about the bouncing as that’s what trampolines do when something lands on them.

The yaw was unsurprising as I’d turned off it PID for this testing. And now I have a safe secure test platform, and code to get the drone in a good position for yaw testing (i.e. off the ground!), I’m now relishing the chance to tune the yaw PID.

Finally I also have some cracking stats to look at too to allow the drone to this autonomously – in this test, the spin speeds for take-off, hover, and landing were all hard coded during the testing so I could get an idea of acceleration produced by them.

And no crashes 🙂

The only way is up, baby, for you and me now…

only trouble is, the lovely English summer has definitely gone now, and the renowned drizzly English Autumn has taken hold.

I still need to sort out fast safe, autonomous take-off by the drone, and there seems to be little advice out there since everyone has an RC which they hold up to full power, and then release to hover once it’s in the right place.  I could do that in the code, but it feels a bit clunky; I’d rather use the vertical acceleration / speed PIDs, and that’s what I’ve been tinkering with in the padded cell test environment, but the results of the limited testing showed either very slow takeoff resulting in yaw, or pogo-stick / trampoline takeoff which made me giggle but were also unacceptable in reality.  The net result of both was a crash due to the drone reaching the end of its tether.

So it’s outside I must go for untethered take-off landing testing.  Hence there may be some delay in any exciting updates as once more the weather has final say.

On the plus side, all this rain is softening up the concrete like soil in the garden, meaning it’s much better for the drone’s inevitable violent crashes!