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.
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.
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:
- GPS fused with existing distances sensors
- Compass fused with existing orientation sensors
- Long range wireless connectivity
- 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.
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!
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!
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:
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!
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!
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.
Close, but no cigar; the avoidance direction got ‘H’ too close to the obstacle, triggering the critical landing, but a good first test nonetheless.
…celebrating the Raspberry Pi 6th Birthday. I’m now packing her away into safe keeping until the day.
P.S. Her instability was purely down to her batteries being too darn cold