I’m in the process of migrating the sample code for using the LiDAR-Lite to the format I normally use. It’s not been as simple as I thought. I’ve narrowed the problem down to this. Look for the SPOT THE DIFFERENCE comments.

I’ve just tested this sample I pulled from GitHub; it works. This isn’t a good thing. This success sucks! The only difference between what it’s doing and what I am is all the 20ms sleeps between all reads and writes. Together that means each read of velocity or distance takes > 60ms – hence the lack of need for sleep in the while loop at the bottom.

But at least I can use it to work out either whether it’s possible to integrate the 20ms into my quadcopter code while I read the IMU in the meantime, or better, get rid of the 20ms breaks altogether.

However, I don’t have a good feeling about achieving either of the above based on what I’ve seen so far. Only time will tell.

First, ViDAR: I’ve got fed up of calling it video macro-block something or the other, so now it’s Video Detection and Ranging. I think it’s now working as well as it can without a height detector; it’s a long way from perfect, but until I can rely on stable height, I can’t identify further bugs. I’m almost certainly going to wait for the Garmin LiDAR-Lite (GLL) to provide the height information.

There’s one bug I’ve fixed which explains why the PX4FLOW only uses a gyro – the angles involved are increments not absolutes. The picture below tries to show that it’s not the absolute tilt of the quadcopter that needs to be accounted for, but the increment:

ViDAR angles

I’ve also got the compass working – I’ve just pulled out the critical bits. Most of the samples I found use the MPU9250 master I2C to attach to the compass; compass data is then picked from MPU9250 registers. But I found this version which exposed the compass registers for direct access which is much cleaner and clearer.

Here’s what I get plotting a walk around the garden carrying her – it’s not a great match.

Garden track

0.0m is my office window. Everything beyond is -10m, -20m is the garden; the walk in the garden was

15m SSW

9m ESE

18m N

That’s an approximate right angle triangle, but the scan doesn’t show that without a lot of imagination. The scaling is right, but the direction is very noisy. I’m not sure whether this is a code bug or just pushing the limits of GPS accuracy. I’ll have a few more goes to see if I can get any better. GPS samples are at roughly 1Hz.

Code update plans for Chloe

ultimately, that output file with be a FIFO read by Chloe’s code. She’ll use select.select() to monitor the file contents, and sleep, whereas now she just sleeps.

I’ll add command line parameters –indoors or –outdoors to select the range of sensors to be used – primarily GPS; PX4FLOW / Scanse Sweep and LEDDAR will work in both environments.

If using the GPS, add startup code to ensure at least 4 satellites are feeding the GPS for accurate triangulation – during the walk, I had 4 indoors and 6 outdoors; obviously the more satellites, the greater the accuracy.

Reik Hua sent me his copy of the mailbox code just as I’d started looking into using the mailbox for RPIO.PWM, thus saving me loads of time and brain-ache! He uses it for his quadcopter with B2 and B3 Raspberry Pis, and I’ve just tested it on Zoe, the Pi Zero and it worked there perfectly too. Reik Hua has kindly agreed to me passing this on to Chris Hager who owns the RPIO code on GitHub, thus making it generally available to all and allowing me to discard another personal hack from my repository.

What’s the fuss about? With the new kernel version in May, the RPIO code stopped working as it was assuming a fixed memory address for the DMA. The mailbox provides the actual address which had changed with the new kernels. So not only does the RPIO now work with 0’s, 2’s and 3’s – it’s also now future proofed. And that’s why I could show Zoe back in the air yesterday!

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.

I’ve tried various ways to acclimatise Zoe’s sensors prior to flight. The best so far is to set the props spinning at minimum speed, and after 5 seconds, grab a FIFO full of data (42 batches of samples in the 512 byte FIFO and 12 byte batch size), and use these to calculated start-of-flight gravity. The props then continue to run at this base speed up to the point the flight kicks off.

The net result is a stable flight with no vertical drift during hover, but with horizontal drift of about a meter. Without this code, horizontal drift is half this but she continues to climb during hover.

I’m not sure how I can improve this, so I’ll leave it alone for now and instead have a look at making a DIY cardboard box to keep Zoe out of the wind.

In passing, I did a quick analysis of the code size: 1021 lines of python code, 756 lines of comments and 301 blank lines giving a total of 2078 lines in Quadcopter.py. Here’s the script I knocked together quickly FYI:

I’ve put Zoe’s code up on GitHub as the best yet, although the either / or of vertical / horizontal drift is seriously starting to pᴉss me off.

Note that since I’ve moved the IMU FIFO into the Quadcopter.py code, QCIMUFIFO.py is not longer on GitHub; Quadcopter.py is the latest best working version and QCDRI.py is the best version that uses the data ready interrupt in case you are seeing the I2C errors like I used to.