MPU-9250 vs. Garmin LiDAR Lite

I had hoped yesterday to get going with Sweep integration, with a sanity check flight beforehand just to ensure all is running well – I can’t afford to have crashes with sweep installed.

And sure enough, Hermione crashed.  In the middle of the climbing phase of the flight, she suddenly leapt into the air, and the protection code killed her at the point her height exceeded the flight plan height by 50cm.  At the speed she was climbing, she continued to rise to a couple more meters before crashing down into a shrub bed, luckily minimising damage to components I had spares for.

A second mandatory flight to collect diagnostics (and more crash damage) revealed a conflict over I2C by the IMU and ground facing LiDAR.  The LiDAR won, and the IMU started seeing gravity as just about 0g.  This isn’t the first time this has happened, and I’ve tried various guessed solutions to fix it.

Accelerometer vs. Garmin LiDAR Lite

Accelerometer vs. Garmin LiDAR Lite

The left graph is height: blue is Garmin and is right; orange is the target – what should be happening, and grey is double integrated acceleration which is a very close match to Garmin right  up to the point it  all goes very wrong.  Looking in more detail at the right graph shows the accelerometer results dropped just before 3.5s and about 0.5s before hover would have started.

This ain’t my code; best guess is an interaction over I2C of the LiDAR and IMU, and the IMU loses.  I’ve seen similar IMU damage before, and without more detail, my only option is to add a new one and try again.

Power overload?

I ran several outdoor flights this morning with the LEDDAR enabled, the last of which lost LEDDAR connectivity shortly after takeoff.

That could be due to dodgy wiring, but my first best guess is actually overloading the 5V 1.5A switching regulator I use to power Phoebe’s HoG direct from the LEDDAR.  That’s based on several assumptions:

  • the LEDDAR LEDs self-tune for reflectivity and ambient light levels; outdoor flights on grass would have the LEDs turned up high, soaking up 0.25A
  • the ESCs are not opto-isolated so they too must draw real current.

If the combination of these overloaded the regulator, then that could explain a self-reboot of the LEDDAR, and hence loss of contact with the HoG.

So I put in some protective code to catch the LEDDAR connectivity failure, and switch to only using the integrated accelerometer to complete the flight.

I moved her indoors on the basis that lower light levels and less dispersive, more reflective vinyl floor covering would turn down the LED power.  What I actually got was her rising 8′ 6″ at maximum speed, smashing into the ceiling before I could kill the flight, breaking two props, and gouging out some bits of the ceiling.  I then spent an hour repairing the ceiling damage before the wife and kids came home.  I’ll leave it until tomorrow to test the fix for the bug I introduced to catch the LEDDAR connectivity failure!

A sticky situation

So high is my confidence in Phoebe’s code now that I went looking today for possible hardware problems that could be the cause of her forwards drift.

And I found two!

The first was speculation that Phoebe’s battery bank was only fixed down by rubber bands, and that any jiggling that happened would give asymmetrical acceleration due to spikes when it hit the platform.  A couple of bits of blue-tak fixed that nicely.

And with that, the flight started looking pretty good, to the extent I wanted diagnostics to tune the motion PIDs.  At which point it all went pear-shaped again – this time because the double sided sticky foam attaching Phoebe to her frame didn’t like the cold, damp weather and she broke free!  The resulting crash broke two props, and my stock of spare has depleted severely over the last few days to the extent I’ve had to order replacements for the first time in months!

Live testing will resume tomorrow, but in the meantime, I think I’ll get on with calibrating gravity for Chlöe.

Countdown to CamJam: 7 days to go


  • one bug fix to integrated the gyros rather than just using the last sample
  • one deletion of redundant conversion from horizontal velocity to required angle whose PID is ancient history
  • retune the horizontal PIDs’ gains
  • test flight leading to a number of literally flipping crashes as my guestimate PID gains were way too high
  • fix resultant Phoebe who wouldn’t boot after crashes – SD card socket damaged irreparably – new model A (reserved for the now unnecessary radio control)
  • retune again with much reduced PID gains resulting in…
  • final test flight of the day: she takes off at the angle she was tilted on the ground resulting in rapid backward movements which then slows, stops, and she then returns to the point she took off from.

Net: probably the best motion tracking flight yet, but the day would have been much more satisfying had I not had been forced to rebuild her mid-way through.  Still on track for CamJam in 1 week.

No more flippin’ flipping

[With thanks to Dave for getting me rethinking an area I thought I’d already solved.]

I’d had problems in the past when the velocity PID target is changed (e.g. Hover @ 0.0ms-1 to Ascent @ 0.3ms-1) – I was trying to reduce noise at the time, and I speculated that one cause could be that the target changed immediately and the fix was to change the target incrementally over a short period of time.  Normally this “soft” transition between targets for the outer velocity PIDs would be provided by the human being operating their sticks, but Phoebe has to do this herself because she doesn’t have the human feedback.

Revisiting that yesterday, I recognised that for significant transitions, there would be a significant power surge, and this could be what’s causing Phoebe’s flipping.  The transition from hover to ascending could require such a current surge that the voltage of the LiPo drop to under 10v temporarily, causing the Raspberry Pi to reboot – 10v is the lower limit of the DC-DC converter I use to get the 5v to power the Raspberry Pi.

So I changed the transition time from the fixed 0.5s I was using to a dynamic period depending on how large the change in vertical velocity PID target was.  Horizontal velocity target changes don’t need the power sapping current surges (their PID gains are a factor of 600 smaller as they don’t have gravity to fight), so they stay at the default 0.5s transition time.

A quick test flight just now shows it’s working – no more flipping – so I can go back to the equally frustrating drift control again.

3 days, 3 flights, 3 broken props!

I’m glad I ordered so many spares now!

I think I now know the problem; my super-strong, super-light, super-balanced props aren’t so strong when they hit the ground vertically.  Fly Phoebe into the shrubbery and she makes a great hedge trimmer.  Crash her in a way that the prop hits something head on (rather than side-on), and it imperceptibly weakens the blade.

Next flight on take-off, the weakened blade can’t produce lift. so Phoebe flips over it.  It breaks, and its diagonally opposite partner gets weakened in the process, but slightly less.

Next flight on takeoff, Phoebe actually makes it into the air, but that stresses out the weakened prop so she flips again, and both the weakened blade and its diagonally opposite partner get broken.

£38 worth of props bite the dust, metaphorically and literally.

And my motivation for further flights today is significantly deflated.

Taking a break, literally.

Sometimes, Phoebe’s rear left motors doesn’t spin up.  Repeat immediately, and it spins up just fine.  Sadly, when it fails to spin (undetectable by Phoebe), the result is a flip over that back-left corner, and smashing upside down into the ground.

That’s just happened, breaking another 10 x 3.3 prop.  I’m out of spares, and nobody in the UK appears to have stock.  I think I’m stuck for a while.  Still the drift control was improving with each run, prior to this.  It was becoming increasing effective throughout the whole flight – take-off, hover and landing after a minor bug fix I made yesterday.  Oh well, gotta look on the bright side.

P.S. I now have a race on between Spain, Greece and the US to deliver me replacement / spare props.  Given they are rare as hens’ teeth here in the UK, I’m sure I can ebay the excess at the going rate.

Race update: Greece is in the lead, with Spain close behind.  Greece is using TNT, while Spain is using the national equivalent of 1st class international postal service with tracking.  More news as it breaks.

Race update: Oh no, Greece’s entry has been sabotaged by TNT using the wrong post code – it’s only a mile wrong but will the driver have the nouse to work this out?  Only time will tell.

Race update: US has also now joined the running, using a priority international carrier to catch back up with Spain and Greece – it’s impossible to say at the moment what the end results could be!

Race update: Greece are the winners, delivering the props in under 24 hours – thank you!

Race update: Spain comes in a respectable second, delivering in a week  – thank you!

Race update: USA comes in an embarrassing 3rd though not their fault: 7 days to reach uk customs, and 10 days for them to get of their lazy bums to get it to me.  Thanks Go Nitro Hobbies for trying your best, sorry the UK postal service let you down.

That was just embarrassing

The test flight from the other day with zero drift working well on hover does appear to have been a one off.  Today, there was drift, and there was to some extent corrective action in place too, but it was too small and too late – I suspect PID tuning as the ‘too late’ action suggest the horizontal velocity PID I-gain is dominant.  I think for the moment, I’ll stick with D-gain disabled as the results were still better than previously.

So today I moved on to trying my larger, more powerful blades (11 x 3.7 rather than 10 x 3.3).  This should reduce the spin rate for a given power or put it another way, more oomph available for corrective action.  What a mistake that was; 2 flights, 2 blades (£25) smashed to pieces, and a significant reduction in the (already limited) drift control.

The only plus side is that it did suggest a cause and fix:  with the bigger blades, spin rate was much reduced, perhaps allowing more noise past the DLPF and in to swamp the genuine sensor readings; so on Wednesday (next good forecasted weather), I’ll head down to the park (no walls, no iron railings for dismantling props) with Phoebe reloaded with her 10 x 3.3 props, and a lower (10Hz) DLPF to see the net result.

I simply can’t risk another crash – the 10 x 3.3 blades are rare as hen’s teeth compared to the 11 x 3.7 – perhaps that’s why?

Attempted Murder Suicide

It’s been a bit quiet here for the past few days as I’ve been testing drift control and until yesterday, there wasn’t a lot to report, so I didn’t bother.

Yesterday’s testing seemed to show progress in the right direction – Phoebe sort of held her own against a 20mph tail wind, before tilting into the wind at an increasing angle towards me.  So I called it a day, knowing the problem was with the ‘matrix’ I was using, and set out to find the problem.

So I went out to the park earlier today with a revised version of the matrix to try.  And that’s when it happened – despite the similar 20mph tail wind, she shot up off the ground, and headed straight for me, directly into the wind.  I had to dive off the stool I was on (she just slashed open the sleeve of my down jacket) and having missed me, she smashed herself into the ground, destroying one propeller and having a really good go at chopping several cables, which luckily they were out of reach.

I have no idea what the lesson is from the software / sensors point of view yet, but I have definitely learned Phoebe is a long way from being trustworthy!

P.S. And do you know what’s worse, Phoebe managed to unplug her power supply, meaning no stats were written (they’re stored in shared memory and dumped to file at the end of each run), meaning I’ve got to do the same thing again tomorrow!


I’ve broken Phoebe’s wrist twice in the last few days.  I had spares from when I swapped her default red arms for black, but still…

I was baffled why; her code intends for a 1.5m take-off over 3s, hover for 3s, and land over 5s (to guarantee touchdown), and she’d been doing that beautifully.  And then suddenly she wasn’t – she was rising to 3 or 4 meters, and continuing to rise when she’s supposed to be hovering.  That’s when I hit the kill switch she broke her wrist falling from 4m onto the kids play slide / swings – twice.

Finally thank heavens, it dawned on me.  As part of rebuilding her legs, I took them off completely, which allowed me to swap the breadboard with the smaller one with neoprene rubber padding for noise suppression – and critically a new (identical) MPU6050 breakout.  Except it wasn’t identical, and it needed gravity to be recalibrated as the stored values related to the old sensor.  Because I hadn’t, even when she was flat on the ground, she was read -1.1g instead of -1.0g on the vertical axis – that meant that throughout the run there was an additional 0.1g vertical power being applied to meet the +1g target.  0.1g might not sound much, but that means 0.1 * 9.81m/s/s, meaning actually she climbed faster in takeoff and continued climbing but slower in hover.  I suspect had I not hit the kill switch, she’d not have started descending in landing mode, but hovered at best or continued to climb gently at worst leading to an even more damaging landing.  So anyway, lesson learnt – recalibrate gravity if you swap identical brand sensors over.

Tomorrow’s weather is looking better so I hope to get some safe flights done and see the effect on my noise filtering, and hopefully from there, get back to drift management / non-horizontal ground take-offs.

Wish me luck!