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.

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.

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!

Hmm, needs more work…

This isn’t as bad as it looks!  The take-off is automatic to a safe altitude which unfortunately took Zoe out of frame; once the auto takeoff completed, I rc’d her back into frame, and then did what I described in the video.

Causes of the problems?

  • primarily, the nut-behind-the-wheel – I need a lot more person-practise!
  • secondly, Zoe is at her performance limit hence her instability.
  • third and finally, once she left the high-colour-contrast mat, she didn’t stand a chance!

What this does show is the code is good, and I next plan to do the same outdoors with Hermione once the wind drops and the temperature rises.

Neither Zoe nor furniture were damage in this video!

What Zoe saw.

I’ve finally found and almost resolved the instability problem with Zoe.  Zoe is a Pi0W compared to Hermione’s B3.  As a result, she’s a single CPU at lower frequency and she’s struggling to keep up.  In particular the LiDAR / Video distance increasing lag behind the IMU:

Distance

Distance

As a result, once fused, Zoe is reacting to historic movements and so drifting.  The IMU data processing takes priority and by slowing it down to 333Hz (from 500), that allows enough space to process the LiDAR / Video distance to stay in sync with the IMU.  Here’s the result for a simple 10 second hover.

There is still lagging drift but much less than seen previously; this drift is still cumulative; hence my next step is to reduce the video frame size a little more.

While this might not be the reason behind the RC drift, it cannot have been helping.


By the way, the fact the incrementally lagging drift is consistently left / right suggests strongly that I need to reduce the port / starboard PID due to the weight balance, primarily the LiPo battery aligned fore / aft in the frame.  On the plus side, without this flaw, I’d never have been able to diagnose the drift problem so clearly and quickly!

The nut behind the wheel…

and a flat battery, but the concept was proven:

Once the stable hover at one meter has attained, the RC takes over: look for the yaw, the forward lateral movement, the height gain, and the awfully unstable landing due to the battery running too low.

As a first live trial it’s brilliant; next step: charge the batteries, and get the human trained to use the RC better!

Obstruction avoidance test 2 – PASSED!!!!!

After a minor tweak to the handling resolution of the Scanse Sweep data, all works brilliantly.

This is a five metre forwards flight, with the flight paused and later resumed once the obstacle has been avoided.  Note that ‘H’ tracks the obstruction at about one meter away.  Hence she flies a quarter circle around the circular cardboard tube, before continuing the forward flight when the obstruction is behind her.

The code is updated on GitHub as a result.

Obstruction Avoidance Overview

Here’s what ‘H’ does detecting an obstacles within one meter:

Now it’s time to get her to move around the obstacle and continue to her destination.  All sensors are installed and working; this is pure code in the autopilot process*.

Here’s the general idea for how the code should work for full maze exploration:

  • Takeoff, then…
    • hover
    • record current GPS location in map dictionary, including previous location (i.e index “here I am” : content “here I came from” in units of meters held in a python dictionary
    • do Sweep 360° scan for obstacles
    • find next direction based on the current map contents either…
      • unexplored unobstructed direction (beyond 2m) biased towards the target GPS point (e.g. the centre of the maze)
      • previously visited location marking the current location in the map dictionary as blocked to avoid further return visits
    • head off on the new direction until
      • obstacle found in the new direction
      • unexplored direction (i.e not in the map so far) found
    • repeat

And in fact, this same set of rules are required for just avoiding obstacles, which is good, as I doubt I’ll ever be able to find / build a suitably sized maze, and if I did, the LiPo will run out long before the centre of the maze is reached.


* The fact it’s pure code means it’s going to be quiet on the blogging front apart from GPS tracking videos when the weather warms up.  I’m also considering building a new version of Hermione from the spares I have in stock, provisionally called “Penelope”.  She’s there for shows only; I can then use Hermione purely for testing new features without worrying about breaking her prior to an event.