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 electricwingman.com 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.

Buffering

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.

Stall

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.

The benefits of floppy props

The standard T-motor Air Gear 200 props are plastic and very flexible.  During takeoff they bend upwards as they spin up until the bend is strong enough to ‘lift’ the quad off the ground – this makes the lift very gentle.

In contrast, the CF props have no flex, any lift is directly and immediately applied to the frame, and therefore to the sensors.  The sensors feel everything; there’s no smoothing or caressing; sharp spikes in motor speed make it to the sensors, to the extent that acceleration may exceed the range of the sensors; I believe this is the cause of my negative G problem.

With the IMU configured to suppport a range of ±2g (the highest resolution), then an additional 1g spike a take-off will overflow.  With the hard light higher pitch CF props, it seems entirely possible this could happen.

There are several ways to fix this each with various pros and cons.  I could

  • increase the low pass filter, but this does still allow the overshoot but then filters it out, along with other valid data – this works though it’s a hack / workaround / sticky plaster, not a fix.
  • extend the range of the sensor to ±4g but there’s a corresponding reduction in sensor resolution which means larger undetectable drift
  • add physical buffering like the props do – I did this previously with the HoG floating on 8 very solt silicone gromits.  I don’t want to use this again (expensive and breakable) but something similar with thicker, softer foam tape sticking HoG to the frame could work
  • soften the flight plan transition in software.

What I’d going to do it a combination of safety precautions and diagnostics

  • I’ll add diagnostics to flag these 0g events, and to skip any data including such an event for safety reasons.
  • I’ll up the range of the sensors to ±4g, and add further diagnotics to flag overshoots over ±2g just to make sure I’m right!

I’ll decide the final solution based on what I find out.

 

Redecorating the lounge ceiling

I don’t like the props Zoe uses that come with the T-motor Air Gear 200 kit; they’re flimsy plastic, they bend and the stay bent.

A quick ebay browse over the weekend turned up some 3 blade carbon props, with the required 5mm bore hole, and 6″ span compared to the plastics’ 6.5″.  Perfect.  They arrived in the post this morning.

So I gave them a quick try prior to packing up Zoe for the work engineering conference tomorrow; the result?  I’m redecorating the lounge ceiling.

Swapping back to the flippy floppy props and normal service was resumed. Phew!

I’d seen this in the past with Phoebe and that triggered the new custom PCB for her, after which she no longer had the I2C errors, and I was able to swap her to the 1kHz sampling FIFO code.  Yet while testing this outdoors yesterday, she still lept into the air until I turned the alpf filter down from 0 (460Hz) down to at least 2 (96Hz).

The fact Zoe now does this too with the CF props is scary and fascinating.  Once I get back from the conference, I’ll be switching her over to the CF props and flying her outside with diagnostics enable to try to track down why such a simple swap of props yields such radically different behavior!

But for now, I need to get back to repainting the lounge ceiling before the wife and kids get home and spot the distruction!