Precise, concise installation instructions

I ended up doing a complete reinstall from scratch to upgrade Zoe to my new Pi-Zero-W, so here’s my latest set of installation instructions.  I recommend printing these off so you can refer to them easily as you do the installation.

These work for any version of Raspberry Pi running the latest Raspian Jessie Lite.

I can confirm that the Pi-Zero-W inbuilt WiFi does support WAP / soft-AP.

Annoyingly, I messed up soldering the GPIO connection onto the Pi-Zero-W, so I have another one on the way.

Crash back down to earth.

Normality has returned.  I took Hermione out to test what video resolution she could process.  It turns out 640 x 640 pixels (40 x 40 macro-blocks) was yesterday’s video frame size.  800 x 800 pixels (50 x 50 macro-blocks) this morning was a lot less stable, and I think the 960 x 960 pixels (60 x 60 macro-blocks) explains why.

At 960 x 960, Hermione leapt up into the sky; the height breach protection killed the props at 1.5m but by then she was accelerating so hard she probably climbed to 3m before dropping back down like a brick onto the hard stone drive upside-down.  Luckily only 2 props got trashed as that’s an exact match for the spares I had left.

Rocketing into the sky appears to be Hermione’s symptom of a IMU FIFO overflow.  For some reason, Hermione doesn’t catch the FIFO overflow interrupt so she just carries on, but now with gravity reading much less than zero because the FIFO has shifted so in fact she’s reading gyro readings, and so had to accelerate hard to compromise.  The shift happens because the FIFO is 512 bytes and I’m filling it with 12 byte batches; 512 % 12 != 0.

How does this explain the 800 x 800 wobbles?  My best guess is that these 2500 macro-blocks (800² / 16²) are processed just fast enough to avoid the FIFO overflow shown by 900², but does have a big impact on the scheduling such than instead of the desired 100Hz updates to the motors, it’s a lot nearer the limit of 23Hz imposed by the code.  That means less frequent, larger changes.

So that mean I need to find the balance between video frame size and IMU sampling rate filling the FIFO to get the best of both.  Luckily with indestructible Zoe imminently back in the running, I can test with her instead.

Zoe resurrected

I’ve only just boxed up Zoe having reached her limit, but now the Raspberry Pi Zero W has been released with WiFi and Bluetooth built in, freeing up her one micro-USB socket and thus opening up the possibility of adding GPS tracking to her too.  I’ve just ordered one from The PiHut to try it out.

This isn’t going to affect her maximum camera video size of 480 x 480 pixels, so she’s never going to work as well on gravel like Hermione, but it’s a useful upgrade nonetheless.


I haven’t smiled this much since my kids were born.  I’m still beaming now with the occasional burst of delighted laughter too; my jaws are even starting to ache.  It’s just over 4 years since the project was born, and finally it’s shown that a Raspberry Pi running standard Raspian Linux and programmed in Python is more that capable of running a fully autonomous quadcopter (though strictly speaking, Hermione is an X8 drone). 🙂 😛 😀 😎

P.S. This isn’t the end but the opening up of the next phase:

  • Test higher resolution for the ground facing RaspiCam video, ideally to the maximum of 1076 x 1076 pixels and see whether that’s good enough for lateral flights on the gravel drive.  This is relatively simple and could well happen in the next few days.
  • Add GPS both for setting multi-step targets, and, combined with compass, tracking the flight location / orientation between these targets.  There’s several phases to keep me busy here.
  • Add the imminently arriving Scanse Sweep for object avoidance
  • Set her loose in a maze!

But for the moment, I just need to wait for my rabid grin to ease!

P.P.S. Code’s updated on GitHub

P.P.P.S. I’ve stashed the video on the front page so I can carry on blogging.

Air punch!

just like Andy Murray winning at tennis, I was shouting “Yes!” while beaming, and punching the air!  I don’t think any flight has ever given me this big a sense of joy and success.

Not only had the pre-warmed LiPos combined with the new PCB resolved the I²C problem, Hermione was flying in a breeze and when it gusted, she returned back to where she took of from suggesting her camera motion tracking is working well over the gravel.

So once more, I’m back on a roll.  I’ll make up a better winter coat for the LiPos, and then see if I can crank up Hermione’s video pixels.  I will upgrade to the new PCB next week, and they include the LED and button switch I’ll need for setting up GPS preset flight steps.

And I’ll get a video done to show it all working again once the wind eases up enough.

Hermione in wonderland.

Took her outside this morning, and the safety test without LiPo consistently threw I²C errors as yesterday.  I brought her straight indoors, still powered up, both her and my piPad and ran the same test; she worked perfectly. Curiouser and curiouser.

P.S. Shortly after writing the above, I had a eureka moment in the shower: I remembered reading LiPos don’t work well in the cold, and even the Mavic instructions suggest letting it run for a while before take off to let the battery chemistry warm out.  Next test then is to wrap both LiPos (batter bank and the main power) in bubble wrap, boot her up indoors, and then take her outside to fly.  I’ll report back here anon.

P.P.S. It worked!!!!! I wrapped both LiPos in some neoprene foam (normally used for scuba suits), set everything up and running the code and therefore the GLL and PWM to keep the LiPos warm indoors. After a couple of minutes, I lugged everything outside, and she did two flights without a glitch. Roll on spring / summer!

Boding not well enough…


With the new PCB, she works perfectly with no I²C errors.  So I took her outside, and she hit I²C errors immediately and consistently.  Back indoors immediately, and once more, no I²C errors.  There are only two differences:

  • 20°C indoors compared to 5°C outdoors
  • LiPo not plugged in indoors, but was outdoors.

I’m assuming the latter is the problem, probably caused by ESC drawing too much power.  If so, my even newer PCB layout should resolve this.  I’d better get on and order it pronto.


Bodes well!

The new PCB arrived, and I’ve done a few indoor tests, and I’ve only seen one I²C error over a total of 60s testing.  Previously, the I²C problem would occur in a fraction of a second.  So my power spike / noise speculation was probably right but needs refining.  Next step is to take Hermione out to build up confidence and to check what video frame resolution she can handle – currently it’s 640 x 640 pixels.  Annoyingly there are gales blowing and forecast to stay for the next few days.

I’ve already been designing the layout for the next PCB revision before this one arrived.  The main change is that the PCB is fed 5V independently from the Raspberry Pi.  Obviously their grounds are connected.  The power comes from a dual port (2.5A each) LiPo Battery Bank – one of these already powers my piPad B3 and RPi touch screen independently and beautifully.

In addition, but unrelated to the PCB power solution, the new PCB design includes a button and LED.  These are for use in the next phase: setting up a series of points in the flight plan based upon GPS targets.

Essentially, prior to a flight, Hermione is set down in several places, and the button pressed; the LED flashes while a sufficient number of GPS satellites have been acquired, at which point the LED goes on for 1 second, the GPS position is saved to file and the LED goes off.  This can be repeated several times to construct a list of GPS positions saved to file as the flight plan.

At the start of a flight, the LED flash / on / off sequence is repeated to acquires enough satellites and record the take-off GPS position; Hermione then climbs to 1m height, and hovers there for a second, yawing to face the first GPS target point saved previously in the flight plan file.  Then she heads there at 1m/s.  Once at the first GPS point, she hovers again, yawing to point towards the second GPS target, and off she goes again, with the sequence repeated for all of the prerecorded GPS targets.  On reaching the final pre-recorded GPS point, once more she hovers for a second while she yaws to face the takeoff GPS point taken at the start of the flight, and back home she goes.  Simples!

Doesn’t bode well

I’ve been tinkering with the existing PCB layout (shown below) to see if power supply changes fix the Garmin LiDAR Lite (GLL) I²C interference.

Hermione's closeup

Hermione’s closeup

I’ve basically removed the black cuboid 1.5A 5V switching power regulator using the space instead to add a 680uF electrolytic capacitor between 5V and ground near the GLL as specified in the docs.  I then powered her up directly via the PCB, rather than indirectly via the RPi micro USB 5V output GPIO pin.  I used a lab power supply which can handle up to 5A.

Hermione showed identical I²C errors with the GLL plugged in, even if not used.  The PSU showed only 0.45mA at boot, 0.5mA with Hermione’s code running passively, and about 0.6A while she was ‘flying’.  This strongly suggests the new PCB won’t solve the problem either.  I am running out of fingers to cross 🙁

The option of using the GLL PWM output is still open, but I’m not keen to swap over to using the pigpio library this requires as it uses a daemon process in the background, unlike RPi.GPIO and RPIO which both directly access the /dev/gpio devices.  I wonder how hard it would be to write my own PWM C library with python wrapper to epoll the GLL PWM pin?  It would require a new PCB revision as would pigpio so there’s a PITA there too.  For some reason, probably because this all just works on Zoe, I still want to keep banging my head to solve the I²C problems.