Between a rock and a hard place, again!

There’s been no progress on GPS routing in the last few days.

For RPi B3 performance reasons, I’m limited to down-facing video resolution of 320 x 320 pixels @ 10fps.  That rules out flying on the back lawn; only the gravel drive in sunshine* will do.  On the plus side, there’s a lot less clutter and more space on the drive once my wife’s gone to work in the morning.  On the downside, any negative flight result results in broken props.



I’ve only recently swapped from the T-motor CF to T-Motors white beechwood props, based on price, looks and sturdiness.  And this week, I’ve found out that the lovely white beechwoods are out of production.  It turns out I’d bought the UK’s stock last month, and, as a result, I’ve bought Germany’s (perhaps the EU’s) leftover stock this week.  As a result, these white props are in safe storage for show-and-tell at the Cotswold Raspberry Jam only; for testing, I’ve found these XOAR 12×4 beechwood props that are nearly identical, except they come in beechwood brown unsurprisingly.

These new props, combined with improved code changes have been tested, and as a result, GitHub has been updated.

Time now to finally get on with GPS routing, weather permitting – the forecast says rain for a week 🙁

*I am strongly considering adding down-facing bright LED lighting to Hermione so that flying conditions are not so significantly limited by weather conditions.

Beauty is in the eye of the beholder,

so behold her(mione):



Here’s a quick test flight just to check I’ve not broken anything; more details on Vimeo.

It all started with the props: I’d broken 6 of the CF ones in the last week or two (costing £110 to replace) and on hunting for cheaper alternatives*, I found the white beechwood T-motor props.  They are half the price, stronger, and less likely to split on impact – the CF ones are actually a sandwich with a middle layer of what looks like wood fibre and any lateral contact with the ground and the sandwich splits in three.

The new props’ span is an inch shorter but with slightly higher pitch; after an initial test flight, it was clear they were more powerful as a result. They also look nicer, and that’s what triggered the rest of the makeover.

I’ve been looking for a chapeau to cover her beret PCB for ages (the PCB doesn’t conform to the standard HAT definition, hence beret), and over time I’ve built up a collection of yellow and orange plastic salad bowls as a result, but none quite fitted right.  But with the new white colour scheme, I found one that fitted nigh on perfectly, just a little dremel trimming required.

Finally, the feet: these are rubber lacrosse balls.  They are heavier and stronger than the previous yellow dodgeball foam feet that Hermione forever punched holes through on landing.  The increased prop power more than copes with the extra foot weight.

I think the new look added nearly a kilo in total, and measuring her on the scales, she now weighs 4.6kg, so it’s amazing she takes off at all!

*The problem with most more-affordable props is they don’t fit upside-down on the ground facing motors in Hermione’s X8 format frame.

Hermione’s and Zoe’s powerware

All of Hermione and Zoes’ powerware – battery, ESCs, motors and props come from a single supplier: Paul Maddock who runs based in Chester, UK where I used to live until 2010.  Over the years, he’s provided a great service, including a couple of specials for me, and so is definitely worth a mention.

Here’s the list of Hermione’s parts I have from him:

This is probably the best set of powerware possible, to match Hermione’s best frame possible.

I also got Zoe’s powerware and frame from there too, though annoyingly, her motors are no longer available:

Once more, THBAPSA.

Compare and contrast!

Spot the difference! from Andy Baker on Vimeo.

There are two difference between the above (shot earlier) and the below (shot a week ago): the props and the amount of drift. I wonder why?

A different point of view from Andy Baker on Vimeo.

P.S. I only swapped the props this morning and flew the white props prior to swapping; the white props drifted about 4 or 5 times the distance in the same flight time; I had to start the white prop flights near the left hand side sofa, and kill the flight before it hits the right hand side wooden chest.

“In the deep mid-winter…

calmly flew my drone;
carbon props were spinning
with very little roam.”

In the deep mid-winter from Andy Baker on Vimeo.

I’ll get my coat.

I’ve finally found some carbon props that work for Zoe; sadly they’re not the cute looking tri-blades I’d been hunting for – they only seem to be available for tiny quads.  My new ones are 8″ tip to tip, compared to the 6.5″ of the floppy props.  They provide a lot more lift at lower rotation rate which is good as far as capturing all available data is concerned below the 460Hz low pass filter.  Critically, and the main reason for wanting CF props, they are very strong, and don’t bend permanently with gentle contact with the ground unlike the floppies.

Finally cracked the current batch of problems.

The are two classes of problems: never getting off the ground, or alternatively, leaping off the ground.

The inability to get off the ground regardless of prop type was due to my code disbelieving that near zero G readings were invalid; discarding the zero G readings meant the velocity integrated higher during warm-up phase, meaning the motion processing code thought it was rising faster than it actually was.  Once the zero G readings were included, then the floppy props worked, but for some reason the carbon ones still struggled to get off the ground.

The reason for this CF prop problem turned out to be the jitters during the prolonged spin up of the props.  The code tries to keep Zoe on the ground while the code winds the props up to hover speed.  At a micro level, this means the feet would lift off, the code would slow down the props, and the feet would hit the hard take-off surface;  this hard micro-collision causes a low reading which integrates to a falling velocity event though the quad was sat on the floor.  When the flight-plan finally flips to ascent, it has to overcome the integrated negative velocity, and so leaps into the air.  The fix is three-fold:

  1. don’t take off from hard surfaces
  2. get the quads off the ground ASAP – don’t wait around for the props to spin up
  3. add physical buffering so the 0g impacts don’t make it to the sensors – for example sitting the HoG on a soft foam pad, and adding soft balls to the feet.

This is work in progress.

There’s a third problem though which was troubling me with the CF props even once the previous two had been (partially) fixed – they still struggled getting Zoe off the ground compared to the floppy props despite their profiles being very similar.  I finally spotted the problem when I was swapping prop types.  The floppy props have a deliberately rough surface whereas the CF ones are coated in the gloss varnish, presumably to cover splinters in the CF.  Airflow at the prop surface is better over rough surfaces due to micro-turbulence, and that causes a better airflow and lift at the macro level.  The higher speed CF probs gloss surface was causing the air-flow to break away from the props at lower revs.  This results in a lack of expected lift, so the code spin the props faster making the situation worse.  Some sanding of the CF props to roughen the gloss surface improved matters significantly but again this is still work in progress.

CF props and near zero G

So I’ve finally worked out why Zoe doesn’t work with her carbon props.  2 factors:

  1. I’ve been using a hard take-off surface outdoors rather than the wet, soggy lawn.  This means that while the blades are winding up to hover speed, Zoe’s legs are imperceptibly bouncing up and down on the hard surface.  An upwards force from the blades is smooth, but as a leg hits the hard surface, the hard deceleration is picked up by the accelerometer as near zero or negative G.
  2. I’d still got the near zero G protective code in place, not recognising the near 0 G does happen when impacting with hard surfaces .

Hence the vertical velocity integration was ommitting the low or negative G forces, meaning the vertical velocity was showing much higher rates than expected, so the code wound down the prop speeds to slow down the perceived ascent.  Hence she never got off the ground.

Moving her to the saturated lawn and removing the protective code filtering out near 0G readings meant she finally took off.  She was very unstable but she took off.

So more physical buffering is required – I’ll be attaching sponge balls onto her feet to soften the hard impacts.  At the same time I have some softer (I think) foam pads coming too for attaching Zoe’s HoG to the frame.  Finally, I need to get her off the ground as quickly as possible rather than faffing around bringing her props up to speed in a nice controlled manner.  Oh, and I need to get her off the ground ASAP.


I’ve finally got the FIFO buffer code working with lots of protection against overflow, and also using a guaranteed way to ensure the code and FIFO are always synchronised.  It works perfectly, so I’ve updated the code on GitHub

Then I took Zoe and Phoebe about; with the floppy props Zoe flew OK but not as well as usual and, as usual, neither would fly at all with the CF props.  Some stats revealed unsurprisingly that it’s Z-axis noise from the props;  Zoe’s floppy props aren’t so floppy at freezing temperatures but when I brought her indoors, she was fine again.

The problem is the motors / props can’t react fast enough to sharp spikes in acceleration, so drift ensues – in this case downwards vertical drift keeping them both pinned to the ground when the sensors felt the spikes.  I need to find a way to soften those acceleration spikes such that the net integrated velocity is the same, and the motors can react to it.

There’s a couple of approaches I can take here, and as usual, I’ll be trying both.

The first is to add additional foam buffering between the HoG and the frame to soften the blows just like Zoe’s floppy props do.  The second is to tweak the vertical velocity PID gains to be dominated by the I-gain and reduce the P-gain significantly.


How wings work 101.

I’m pretty confident this explains the radical behavioural difference between Zoe’s plastic and CF props: the higher pitch of the CF props means the airflow over the props would be disrupted at lower rotation rates and the props would stall producing virtually no lift; the code would then increase the props speed as a result, worsening the situation to the extent that Zoe would never get off the ground – which is exactly what is happening.

In particular, at the take-off transition from ground ‘hover’ to ascent, there’s a sharp increase in props rotation driven by the vertical velocity PID P gain as the target changes from 0m/s to 0.3m/s.  This immediate kick could well be hard enough to break the smooth airflow over the props, causing them to stall and thus kill the lift – it then never recovers as the motors spin ever faster to compensate for the insufficient lift.

However if I shift the bias towards the I gain, then the increase in motor speed is smoother, and this would result in the airflow speed increasing in line with the prop rotation, and reduce the risk of the props stalling.

I have a vague memory from somewhere that once a prop (or wing) stalls, it’s very hard to stabilize the airflow again; as an example, if an aeroplane stalled at high altitude, suddenly the only force would be gravity and the plane would drop like a brick; however, if the pilot points the nose of the aircraft down towards the earth, this would streamline airflow over the wings again and the pilot could then pull-up using the reinstated lift from the wings.

Why’s that relevant?  Because it means there’s no point trying to recover from stalled props for a quad; the solution is to stop it happening in the first place.

The interesting bit is whether it will be possible to tune the vertical velocity PIDs such that both types of props run with the same PID settings?

Only indirectly related, I could do with some additional PID to ESC calibration.  The PWM runs from 1ms to 2ms in 1us increments.  At 1ms, the ESCs are synchronised with the PWM and they stop their annoying whining, but it’s only at 1.15ms pulses that the props start spinning.  That shows up in flight as wobbly landings, and there is a risk that the PIDs could actually turn of the motors during flight; I need to update the PWM code so that it knows about the ESC minimum value.  I think this is only a few lines of code.