That’s all, folks…*

Featured

I think I’ve done all that can be done with my Raspberry Pi, Python piDrones.  Code is updated on GitHub as a result.  Here’s the vimeo links to the proof-of-the-pudding as it were:

The hardest by far though was the simplest in concept: a stable autonomous hover beyond a few seconds; each of the cool functions listed above probably took a few weeks on average; in contrast, the one-minute-plus hover took years.

There’s lots more videos on Vimeo linked to the blog via pidrone.io/video.

I’ve achieved my personal target and then some: taking a Raspberry Pi and Python to create a piDrone, starting from absolutely ignorance, and doing it my way without using other’s code, ideas or suggestions.

What else could be done?  My only idea is long distance / time flights requiring:

  1. GPS fused with existing distances sensors
  2. Compass fused with existing orientation sensors
  3. Long range wireless connectivity
  4. Nuclear-fusion batteries.

Lack of #4 renders 1-3 pointless.

Also pointless sadly is Penelope; Hermione, my big 3B, is the queen of autonomous control and Zoe, my Pi0W, the queen of human control.  Two’s company, three’s a crowd. The only thing unique I can do with ‘P’ is to get her RPi 3B+ and Stretch O/S completed, and my motivation is lacking; that makes Penelope the queen of spare parts 😥

Time for me to find another hobby to hold back my terminal-boredom-syndrome.  On my bike, me thinks.

So long, and thanks for all the fish!


* …nearly.  I’m doing some refinement for Zoe, primarily so I can take new to the Cotswold Raspberry Jams and anything new and exciting the RPi releases next.

Passion Flower

Zoë’s always my simplest and the best looking.

While Hermione and Penelope both have lids (custom cropped 50mm dome and cropped salad bowl respectively), Zoë and her predecessors never have.  This has now been fixed.  And finally, this is more DIY.  Starting with clear acrylic (perspex) domes and tubes (10cm in diameter and lengths), these are stuck together (fused effectively), sawed in half, filed and painted.  I made a prototype and final version that I prefer to prototype due to the unexpected slope of the frame.

At the same time, I’ve been enhancing her O/S to Stretch, and adding the Garmin LiDAR-Lite v3HP – a requirement to use Stretch I2C implementation – but also thinner so a little more protected on landing.

I’ve been refining the hardware, both with the PCB to accommodate the GLLv3HP effectively and an updated 2A voltage regulator, combined with ESC wiring shortened so they fit snugly inside the frame, both for safety and prettiness value.

Finally, I’ve been refining the code at the I2C level to make it as efficient as possible; Zoë is running on the brink of working due to the single CPU Pi0W.

Here’s the result:

She looks unstable.  She’s top heavy and hence very sensitive to the slightest breezes.  I may put more effort into tuning, but since her priority is for indoors, I’ll test that first.

Why six years?

It probably took a years at the beginning to get the system working at a basic level, and a couple of years at the end adding cool features like GPS location tracking, object-avoidance, human remote-control, custom cool lids etc.  So what happened in the intermediate three years?

The biggest timer-killer was drift in a hover: the accelerometer measures gravity and real acceleration along three perpendicular axes.  At the start of a flight, it reads a value for gravity before takeoff; during the flight, integration of new readings against the initial gravity reading provides velocity.  In a calm summer’s day, all worked well, but in other conditions, there were often collisions with brick-walls etc.  Essentially, the sensors say they weren’t moving whereas reality said it was.  It took years to recognise the correlation between winds, weather and crashes: lots of iterative speculation spanning the seasons were required to recognise the link to temperature variations*.

There are two factors: first, the IMU has been optimised to operate above 20°C – below that and small temperature changes lead to significant drift in values; secondly, once in flight, weather- and prop-breeze cools the sensor compared to the ground measurement of gravity.  I tried lots of ways to handle the temperature changes; at one point, I even bought a beer-fridge for mapping accelerometer gravity values against temperature!  It’s back to its intentional purpose now.

Digging back, it’s clear how others have coped:

  • DIY RC drones used synchronising the IMU and RC each flight along with sheltering the IMU from the wind.  The pilot wasn’t interested in static hover and is part of the feedback loop for where it to go.
  • at the bleeding edge, the DJI Mavic has a dynamic cooling system embedded in the depths of the frame keeping the IMU at a fixed temperature, along with two ground-facing cameras and GPS to long-term fine tuning.
  • All videos I saw were from the California coastline!!!

But I did it my way, the DIY experimentation way resulting ultimately with passive temperature stability by wrapping the IMU in a case to suppress wind cooling, combined with a Butterworth low-pass filter to extract gravity long-term, and the LiDAR / RPi camera to track the middle ground.  I perfected reinvention of the wheel!

Hindsight is wonderful, isn’t it!


*My apologies for the complexity of this sentence, it represents the frustration and complexity I encountered working this out over years!

Penelope

She exists for two purposes only:

  • produce a system overcoming the I²C and network changes in Jessie / Stretch after March 2017
  • use up the reams of the new spare parts acquired over the years of drone development.

It’s been more expensive in time and money than I’d hoped, primarily because of the cost and delayed shipping of the Garmin LiDAR-Lite v3HP.

I’m only showing a stable hover as that is infinitely harder than anything else:  accelerometer noise and drift over temperature and time, integrated for velocity and again for distance means that after a few seconds, errors in the integrated velocity and distance are very wrong and increasing rapidly, and only the extra sensors of ground-facing LiDAR and video constrain this increasing drift errors.

She weighs 4.1kg which is more than I’d like due to battery usage, but the only over-heavy bits are the black Lacrosse-ball feet at 0.6kg for the four – this makes her only a few grams lighter than Hermione.

All she’s missing compared to Hermione is the obstacle-avoidance due to the fact the KickStarter Scanse Sweep team have shut down.  Given the obstacle-avoidance concept has been proven, I’m not out to find an equivalent.

Barring an Archimedes “Eureka!” bath moment, this is genuinely the end-of-the-line for my RPi piDrones.

The code has been updated on GitHub as a result.

Garmin LiDAR-Lite v3HP working…

but at a price.  Here’s the python classes:

v3

####################################################################################################
#
#  Garmin LiDAR-Lite v3 range finder
#
####################################################################################################
class GLLv3:
    i2c = None

    __GLL_ACQ_COMMAND       = 0x00
    __GLL_STATUS            = 0x01
    __GLL_SIG_COUNT_VAL     = 0x02
    __GLL_ACQ_CONFIG_REG    = 0x04
    __GLL_VELOCITY          = 0x09
    __GLL_PEAK_CORR         = 0x0C
    __GLL_NOISE_PEAK        = 0x0D
    __GLL_SIGNAL_STRENGTH   = 0x0E
    __GLL_FULL_DELAY_HIGH   = 0x0F
    __GLL_FULL_DELAY_LOW    = 0x10
    __GLL_OUTER_LOOP_COUNT  = 0x11
    __GLL_REF_COUNT_VAL     = 0x12
    __GLL_LAST_DELAY_HIGH   = 0x14
    __GLL_LAST_DELAY_LOW    = 0x15
    __GLL_UNIT_ID_HIGH      = 0x16
    __GLL_UNIT_ID_LOW       = 0x17
    __GLL_I2C_ID_HIGHT      = 0x18
    __GLL_I2C_ID_LOW        = 0x19
    __GLL_I2C_SEC_ADDR      = 0x1A
    __GLL_THRESHOLD_BYPASS  = 0x1C
    __GLL_I2C_CONFIG        = 0x1E
    __GLL_COMMAND           = 0x40
    __GLL_MEASURE_DELAY     = 0x45
    __GLL_PEAK_BCK          = 0x4C
    __GLL_CORR_DATA         = 0x52
    __GLL_CORR_DATA_SIGN    = 0x53
    __GLL_ACQ_SETTINGS      = 0x5D
    __GLL_POWER_CONTROL     = 0x65

    def __init__(self, address=0x62, rate=10):
        self.i2c = I2C(address)
        self.rate = rate

        #-------------------------------------------------------------------------------------------
        # Set to continuous sampling after initial read.
        #-------------------------------------------------------------------------------------------
        self.i2c.write8(self.__GLL_OUTER_LOOP_COUNT, 0xFF)

        #-------------------------------------------------------------------------------------------
        # Set the sampling frequency as 2000 / Hz:
        # 10Hz = 0xc8
        # 20Hz = 0x64
        # 100Hz = 0x14
        #-------------------------------------------------------------------------------------------
        self.i2c.write8(self.__GLL_MEASURE_DELAY, int(2000 / rate))

        #-------------------------------------------------------------------------------------------
        # Include receiver bias correction 0x04
        #AB! 0x04 | 0x01 should cause (falling edge?) GPIO_GLL_DR_INTERRUPT.  Can GPIO handle this?
        #-------------------------------------------------------------------------------------------
        self.i2c.write8(self.__GLL_ACQ_COMMAND, 0x04 | 0x01)

        #-------------------------------------------------------------------------------------------
        # Acquisition config register:
        # 0x01 Data ready interrupt
        # 0x20 Take sampling rate from MEASURE_DELAY
        #-------------------------------------------------------------------------------------------
        self.i2c.write8(self.__GLL_ACQ_CONFIG_REG, 0x21)


    def read(self):
        #-------------------------------------------------------------------------------------------
        # Distance is in cm hence the 100s to convert to meters.
        # Velocity is in cm between consecutive reads; sampling rate converts these to a velocity.
        # Reading the list from 0x8F seems to get the previous reading, probably cached for the sake
        # of calculating the velocity next time round.
        #-------------------------------------------------------------------------------------------
        dist1 = self.i2c.readU8(self.__GLL_FULL_DELAY_HIGH)
        dist2 = self.i2c.readU8(self.__GLL_FULL_DELAY_LOW)
        distance = (dist1 << 8) + dist2

        if distance == 1:
            raise ValueError("GLL out of range")

        return distance / 100

v3HP

####################################################################################################
#
#  Garmin LiDAR-Lite v3HP range finder
#
####################################################################################################
class GLLv3HP:
    i2c = None

    __GLL_ACQ_COMMAND       = 0x00
    __GLL_STATUS            = 0x01
    __GLL_SIG_COUNT_VAL     = 0x02
    __GLL_ACQ_CONFIG_REG    = 0x04
    __GLL_LEGACY_RESET_EN   = 0x06
    __GLL_SIGNAL_STRENGTH   = 0x0E
    __GLL_FULL_DELAY_HIGH   = 0x0F
    __GLL_FULL_DELAY_LOW    = 0x10
    __GLL_REF_COUNT_VAL     = 0x12
    __GLL_UNIT_ID_HIGH      = 0x16
    __GLL_UNIT_ID_LOW       = 0x17
    __GLL_I2C_ID_HIGHT      = 0x18
    __GLL_I2C_ID_LOW        = 0x19
    __GLL_I2C_SEC_ADDR      = 0x1A
    __GLL_THRESHOLD_BYPASS  = 0x1C
    __GLL_I2C_CONFIG        = 0x1E
    __GLL_PEAK_STACK_HIGH   = 0x26
    __GLL_PEAK_STACK_LOW    = 0x27
    __GLL_COMMAND           = 0x40
    __GLL_HEALTHY_STATUS    = 0x48
    __GLL_CORR_DATA         = 0x52
    __GLL_CORR_DATA_SIGN    = 0x53
    __GLL_POWER_CONTROL     = 0x65

    def __init__(self, address=0x62):
        self.i2c = I2C(address)

        self.i2c.write8(self.__GLL_SIG_COUNT_VAL, 0x80)
        self.i2c.write8(self.__GLL_ACQ_CONFIG_REG, 0x08)
        self.i2c.write8(self.__GLL_REF_COUNT_VAL, 0x05)
        self.i2c.write8(self.__GLL_THRESHOLD_BYPASS, 0x00)

    def read(self):
        acquired = False

        # Trigger acquisition
        self.i2c.write8(self.__GLL_ACQ_COMMAND, 0x01)

        # Poll acquired?
        while not acquired:
            acquired = not (self.i2c.readU8(self.__GLL_STATUS) & 0x01)
        else:    
            dist1 = self.i2c.readU8(self.__GLL_FULL_DELAY_HIGH)
            dist2 = self.i2c.readU8(self.__GLL_FULL_DELAY_LOW)
            distance = (dist1 << 8) + dist2

        return distance / 100

The need for the v3HP is that its I2C conforms to an I2C  deviant added to the Raspberry Pi in March 2017.  It is also smaller and theoretically higher precision.

Trouble is, it comes with several problems:

  • $10 more than the v3
  • radically modified I2C registers missing several beneficial options in the v3 resulting in potentially less efficiency.
  • poor documentation meaning I was pointed at the GitHub sample to work out how to use it.

On the plus side, Penelope has now had a successful first live flight as a result but at a price.  I’m in two minds now whether to get one for Zoe when the only benefit for her is physical size.

Garmin LiDAR-Lite v3 vs. v3HP

Here’s Hermione, photographed with the Pi NoIR camera, showing the Garmin LiDAR-Lite v3 IR laser beam on the ground:

H's LiDAR beam

H’s LiDAR beam

Here’s Penelope’s equivalent:

Penelope's lack of laser

Penelope’s lack of laser

They are running identical code but Hermione gets data back over I2C for the distance whereas Penelope gets ‘1’ meaning no laser signal received, either for out-of-range, bad reflection direction, or in this case, the IR laser is not running.  There is no way to manager the laser in soft- or hardware.

Not a great start for the LiDAR-Lite v3HP 🙁


P.S. I’ve found and updated the different between the I2C registers between the GLL v3 and v3HP. However none of these mention control of the laser, and with the GLL v3HP using the new I2C registers code, the laser is still not showing.   😥


P.P.S. It seems the new v3HP I2C registers don’t support a couple of functions I was relying on:

  1. set sampling rate to 10Hz so I could always read the latest height from the ground when the lateral pixel distance was know.
  2.  always able to read the latest values automatically – this seems now to require a WRITE then a READ whereas previous, only a READ was required for the latest setting.

On the plus side it’s more accurate (apparent) though without an operating laser, that a moot point!

Refining Zoe, Reinstating Penelope, Retiring Hermione

The Garmin LiDAR Lite v3HP has arrived from RobotShop.

Garmin LiDAR-Lite v3HP

Garmin LiDAR-Lite v3HP

Strictly speaking, I don’t need it for Zoe nor Hermione, the previous version works well, but there are some benefits of the latest version:

  • it’s smaller, so sits under Zoe without the LiDAR virtually touching the ground
  • its data ready interrupt now works with Rapsberry Pi GPIO
  • it’s compatible with the Linux Stretch variant of the I²C protocol.

The latter means I can finally finish Penelope; I’ll be blogging on it as it progresses.

For Zoe, I’m doing various refinement, including a PCB to incorporate the new LiDAR.  I’ve also made a custom case foam for her; my plan here is I can show her off at events like the Cotswold Raspberry Jam.

Zoe's custom case

Zoe’s custom case

Hermione on the other hand has now become an art-statue only; the only physical difference between her and Penelope is the Scanse Sweep whose creators have just shut down hence no link to their site! I don’t want to further develop object avoidance to the extent of maze tracking when there are no spares available to allow for the inevitable crashes!  She is a very pretty statue though, isn’t she!

Hermione statue

Hermione statue

Human. I am human.

From the Mavic:

From my iPhone:

The only mysterious behaviour was the unexpected drift after the end of deliberate yaw; it’s not the RC nor me; best guess, the sensors are seeing the yaw as lateral drift somehow.


P.S Zoe is now retired as she’s done all she can within the constraint of her CPU speed.  She’ll be back if and when a faster Pi0W is announced.

P.P.S. Penelope is boxed up also, partly because there’s nothing she can do that Hermione hasn’t done already, and partly because Garmin are still faffing around launching their new LiDAR.  If that appears, there is some value in bringing her back to life, both because she’s a (faster) B3+ and she’s running Stretch – up to now, everyone is stuck on Jessie from February 2017  – the last point I2C worked with the Garmin.

P.P.P.S. The title is from the film “Arrival” which is very good if that’s the sort of film you like!