As a Father’s Day present from me to me, I’ve just bought a PX4FLOW from ebay.  Reik Hua’s quad can hover until bored or battery discharge with one of these.  Mine’s on a slow-boat from China so could take up to a month to arrive.

When it does, the LEDDAR will go into safe-keeping – not retired, just pending the arrival of its sibling LiDAR Scance Sweep.

Beyond saving me from terminal boredom syndrome (TBS), the PX4FLOW will give me stuff to do over the summer and motivation.  Primarily it gives me  high precision Z axis height and X and Y axis velocities.

So the list of stuff to do for the summer includes

  • Fuse X,Y velocoties with integrated acceleometer velocities from long term low drift hover
  • add distance / direction PIDs with integrated PX4FLOW velocities for X and Y, and it’s build in sonar height for Z axis – this should stop the lurge.
  • get the compass working just for additional yaw stability to start with, though this can obviously be extended to provide orientation.
  • Play with fixed height, horizontal movement flight plans
  • Have a go at flying in circles – requires angle PID to provide a constant port/starboard angle combined with a fore/aft constant velocity


  • get DHCP / udhcp working on latest Jessie Zoe WAP
  • get Wiimote working for crawler robot – this will probably be my test platform for the Scan Sweep

Complementary sensors

LEDDAR One provides long-term distance and, by differentiation, long term Z-axis velocity vectors in the quad-frame

Scanse Sweep provides primarily 360° range finding; with lots of complex mapping between boundary frames – a frame comes from a join the dot plot of the flight zone – it should be possible to get quad-frame distance / direction / velocity movement vectors too.  However…

PX4FLOW provides horizontal velocities and height over I2C meaning easy software integration and fusing with the current inputs for the velocity PIDs; although this is contrary to my DIY desire, it will fill the gap between now and the arrival of Scance Sweep.

There is a balancing act however:

  • Both LEDDAR and Scanse Sweep have longer ranges.
  • Scanse Sweep is the only sensor providing object detection and avoidance – and hence the possibility of fulfilling one of my dreams for my drone to wander through a maze.
  • PX4FLOW is open hardware / source – a chinese equivalent is what Reik Hua uses as a result.  Using PX4FLOW would make LEDDAR redundant temporarily, but once I have Scance Sweep, PX4FLOWs open-source software may well provide guidance on how to convert Scance Sweep boundary distances into velocities, thus making PX4FLOW redundant, and swapping back to LEDDAR.  The fact Scance Sweep is tracking an outline of the flight area rather that sequential photographs like PX4FLOW may mean I can do the processing in python which again would keep the processing within my DIY desire.
  • PX4FLOW will work outside in an open area as it’s using a down-facing Z-axis camera to work out X- and Y axis velocities, whereas Scanse Sweep needs an area with boundaries – this makes outdoor testing of PX4FLOW possible which is always a necessity for initial testing of new sensors.

A fusion of all three would make a quad capable of flying anywhere at a couple of meters height.  That would be quite an achievement!

So I think I’ll be getting a PX4FLOW.  Annoyingly, PX4FLOW has gone out of stock just after I started blogging about it.  Is that evidence that people actually do read this blog?

Σ some sensors

So far, I’ve been looking at LiDAR sensors

  • the LEDDAR One gives me quadframe z-axis height and with differentiation, velocity
  • the Scanse sweep gives a 360° quadframe x- and y-axis plot of the borders of the flight area; to turn that into something useful is going to require more processing; something along the lines of using the known pitch, roll and yaw gyros to rotate the previous scan into the current scan frame, and then compare the misalignment between the two to guesstimate movement direction and speed.  It’s not clear yet how much of this will be provided by the Scance processing and how much I’ll have to do, but a 360° scan feels like a lot of data to process.

My friend in China is using the equivalent of a PX4FLOW optical flow sensor: a downward facing low resolution camera with gyro and URF.  Like I described above, with the height and the incremental angles from the gyro, they process picture frame changes to come up with horizontal velocities – critically, the PX4FLOW is doing this, and spitting out velocities over I2C.  Follow the link and page down to the “Accuracy” section to see how well the tracking works for a manually controlled flight; the integrated-velocities distance / direction plot of the flight path overlayed on the satellite image is a very convincing match.

A long time ago, in a galaxy far far away, I’d seen the PX4FLOW, seen its price and moved on.  But now, I’m starting to wonder whether I should think again.

Having said that, perhaps with scanse, I could do the same, but much simplified by only matching the outline of the flight space rather 2 photos of the same space.  And perhaps I can break this down into small enough pieces that a whole outline can be processed in pieces during 100 motion periods (i.e. 1s).  This is starting to feel viable and is a lot more aligned with my DIY desire rather than buying a PX4FLOW that does it all for me.


One dream sleep later…

…and I have a speculative cause for Chloe’s LEDDAR loss of modbus communication.  Spoiler: there’s a video at the end.

It always happened after a step change in the flight plan, either to-takeoff or hover; are these causing power spike(s) which cause a LEDDAR reboot?  So I looked at the stats.  Acceleration was very spiky throughout, looking like the 13″ wide, 5.5 pitch (1355 or 13/5.5) props were actually over-compensating, over-and under-shooting for each motion processing – see graph, and count the peaks and troughs – about 100 per second as expected; pretty good confirmation of the speculation.

Overpowered props

Overpowered props

Clearly PID tuning was needed, unless…perhaps Chloe was still tuned for the expensive T-motor 12/4.0 props.  A quick swap and flight later, and the noise was down in the stats, and more importantly, the LEDDAR communications wasn’t lost.

And the consistent drift to the left?  I woke up wondering what the flight plan said, and sure enough, she was supposed to drift left.  Oops, pilot error!

Chloe + LEDDAR from Andy Baker on Vimeo.

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!

‘Scoping the Modbus

Using the LEDDAR One on Phoebe, I had to drop her sampling rate to 500Hz to prevent FIFO overflow.  This isn’t bad, but I decided to investigate why adding LEDDAR into the mix has slowed the processing down significantly.  Out with my OSCIUM iMSO-104 iPad scope.

The following allows a crude estimate of the the baud rate to be at least 50kbps:



This shows the time the LEDDAR One takes for a request / response processing – about 3ms

Request / Response timing

Request / Response timing

This shows the reaction time to the rising edge data ready interrupt (DRI); since the Quadcopter and the test code only poll the interrupt every 10ms, this is fine too.

Interrupt response

Interrupt response

What’s also visible is the cost of doing 3 individual reads of the registers (about 20ms) compared to reading 5 registers in a single shot which drops it down to about 5ms as shown below:

One-shot registers read

One-shot registers read

I’ve swapped Phoebe to use the one-shot read as above, and as a result, she’s running the IMU at 1kHz again while running the LEDDAR.

Fusion flaw

I collected some diagnostics to start investigating the wobbles shown in the previous post’s video:

Fused velocities

Fused velocities

It’s fairly clear the fusion bias is still strongly towards the accelerometer.  In a way I’m glad as it makes my next steps very clear.

LEDDAR first flights

Clearly, there’s work to do, but at least she took off, and didn’t soar into the stratosphere!

Initial tests with LEDDAR vertical velocity fusion from Andy Baker on Vimeo.

A couple of post-post comments:

  1. This does confirm that LEDDAR works well in sunlight with a very speckled (grass) surface to bounce its IR LED light off.
  2. It turns out the LiPo needed charging – I’ve previously found low-charge LiPos do result in more wobbly flights with these high pitch CF props
  3. Forgotten this final point but I’ll update the post when I remember! Ah, that’s it – the code is still driven by velocities, not distances, so the LEDDAR usage is not guaranteeing height of the ground, but it’s providing vertical velocity stability (differentiated from the distance / timestamp changes) for the integrated (and therefore drifting) vertical velocity from the accelerometer.

Bah- or Mint-Humbug?

It’s been a bit of a “Bah Humbug” few days.

RPIO.PWM needs upgrading to use mailboxes to find the memory mapping from the video cortext to the RPi for Zoe.  I needed to merge the ServoBlaster code into RPIO.PWM which although not hard, was going to need care and time;  the latter of which is hard to find in my house.

The LEDDAR integration worked well, but for some completely unrelated reason, the asynchronous code I use for catching hardware interrupts stopped working – it was only catching the first.  That meant there was no protection mid-flight for a FIFO overflow and the commensurate dodgy data and resultant crash.

And then in the last two hours, today turned into a “Mint Humbug” day.  Mint Humbugs are my favourites sweets; I have two bags of them in the office right now.  What was the source of the turnaround, you may ask?

I realised while cycling back home after buying some beers that I didn’t need the asynchronous callbacks any more; they date from the pre-FIFO era when I needed to know a batch of data was ready. Simply polling the interrupt pins was a better solution.  That’s now implemented and tested passively in my ‘lab’; live testing starts tomorrow.

And while I was finishing this up, I got an email from a friend in China who started building his quad based loosely on my code a few months ago; he got in touch regularly asking advice and I happily gave it.  But a while back the tables turned; today he sent me his latest flight video of 35s of stable hover.  The flights are in an underground concrete car-park, and he’s using LiDAR technology for obstacle avoidance and position stability, and it works beautifully.  Sadly, I don’t think I can share his video due to the Chinese Wall between us.

Shortly after his first e-mail arrived, a second e-mail from him arrived in my inbox containing his mailbox version of the RPIO.PWM code which he uses on his RPi 2 & 3.  I couldn’t believe my luck.  Thank you so much Reik Hua!

And to finish the day off, I’ve subscribed to another 6 months of the MagPi magazine, which means I have another free Pi Zero plus camera cable on the way.

Now, where is that bag of mint humbugs – it’s time to celebrate!