piDrone + piRC interaction

I was considering adding the remote controller WiFi connection into the autopilot, but now I’m against it, simply because it’s easier to plug it directly into the Motion process.  Ultimately Autopilot  / Sweep will still play a role, protect again “object collision”, but initially at least, they won’t be implemented.

                |  RC |······
                +—————+     ·
+—————+                     ·
|Sweep|———>———+             · 
+—————+       |             ·
        +—————+———+     +———·——+
        +—————+———+     +———+——+
+———+         |             |
|GPS|————>————+             |
+———+                       |
                +—————+     |

The testing code for piDrone ⇔ piRC WiFi interactions is well underway, only hindered by the dither making the decision above, and the ever-slipping release of the Garmin LiDAR-Lite v3HP.  Oh, and my kids are on Easter school holidays and we’re going to my parents, so no updates until Friday at the earlier!

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.

Who broke my WAP?

In the previous post, I’d reported that a single hostpad now worked with both the RealTek and Broadcom drivers.  I’m sure I tested this otherwise I wouldn’t have said it, yet one day later, my WAP stopped working with both WiFi dongles; my iPad can not longer connect to Zoe.  Layer 2 MAC connection are working fine with either WiFi dongle, but Layer 3 IP connections no longer connect.  Until I’ve resolved this, all testing of the camera motion has stalled.

As a result blogging is likely to stall for a while, rather than me blogging frustrated swearing online!

RealTek WiFi dongles now supported with standard hostapd

Someone has quietly enhanced the hostapd support for the Raspberry Pi Jessie distribution so that WAP support via hostapd works for both the Broadcom and RealTek chipsets underlying the WiFi dongles.  Previously, the very common dongles using then RealTek drivers have needed their own version of hostapd for WAP support, built from the source code..

Another annoying non-standard installation step has now vanished – yeah!


Say ‘Hi!’ to Hermione*

Hermione will be the mother of all that’s gone; she’s a bit heartless at the moment – her HoG will be an RPi A3 when it appears on the market.

Hermione flat-out (with banana for scale)

Hermione flat-out (with banana for scale)

Hermione flat-out (with banana for scale)

Hermione tip-toes (with banana for scale)

The main reason behind building yet another quadcopter is the frame:

  • loads more space for extra sensors
  • folding arms so it’s easily transportable
  • beautiful build – lots of CF and CNC machining
  • lots of extension platforms adding lots of options of where to put all the pieces – installed here are a power distribution board (in the plate sandwich), a plate for her HoG, and a GPS plate sticking out to the left.

The one thing that’s missing are legs – I’ve had the ones supplied before, and they crack and break with the down-falls my testing produces.  There are stronger ones I’ll be getting.  I’ve bought from previously for Chloe so I know the high quality of their frames; the previous frame I’d bought was premature, and sadly I ended up selling it.

But this time, I have a purpose for all the extra space: Hermione will be deployed with GPS, LiDAR x 2, PX4FLOW, a RPi Camera and anything else I can get onto her.  Also the frame supports an X8 layout as well as standard quad format; X8 is where each arm has 2 motors and props: the top motor prop is set up as normal; the lower one is upside down, and the prop is installed on the motor upside down.  The topside and underside props spin in opposite directions.  This format provides more power for heavy lifts and protection against motor / prop damage or failure.  Each prop has its own ESC and separate PWM feed.

Doing the above requires the A3 for its extra cores to do a lot more sensor processing and a new PCB to support the new GPIO pin requirements.

GPS, LiDAR and LEDDAR require UART connections; X8 requires another 4 GPIO pins for the 4 ESCs PWM feed.  One of the sensors – probably GPS – can use the USB port, assuming the A3 has built-in WiFi like the B3.  PXFLOW uses I2C.

My thinking is that LEDDAR and PXFLOW provide term fused inputs to the distance PIDs; GPS provides targets for the flight plan; compass is the yaw input with the the flight plan providing direction of travel so that a camera pointing forwards can always track her progress; Scance Sweep provides object detection overriding the GPS flight path short term to avoid objects.

Together, this means I could set a start and end position for a flight using GPS (either just start and finish or with intermediate check points), and then just set her loose autonomously to track against those points, whether this is simply flying from A to B or getting from the entrance to the centre of a maze, logging “where I’ve been” to ensure she always prioritises new paths through the maze.

Here’s the current PCB eagle layout for Phoebe and Chloe:



  • the right hand side 3 vertical PCB tracks are for the LiPo to 5V regulator – I’m planning on Hermione having a BEC on her PDB (power distribution board), so that opens up space for the rear X8 PWM pins.
  • the left hand side 4 vertical PCB track are I2C extensions in place for the URF, but the space is needed for the the front X8 PWM pins so the I2C extension is moved to the bottom edge and will be used for the PIX4FLOW.

Here’s the first draft of the revised PCB:

Hermione PCB beta

Hermione PCB beta

PIN usage:

  • pins 4, 6, 8, 10 and 12 are used for LEDDAR as now but extended outwards
  • the GPIO pins for PWM are completely reworked for X8 format as is the MPU9250 interrupt pin; I’ll probably end up adding X8 before I add Scanse Sweep simply to fill the gap between now and its delivery
  • I2C is extended on the lowerside for the PX4FLOW
  • That leaves a selection of pins and space on the topside for Scanse Sweep – I need to get wiring specs for this; and alternative is via USB using a UART to USB converter – I have one of these already for use configurating LEDDAR by my Windows PC.
  • GPS will also be via USB, assuming the WiFi is now build into the A3 board or I might use a mini USB hub like on of these that I used already for other projects.

Regarding WiFi, to extend the range, I’m going to replace the (hopefully) on board antenna with a HiRose U.FL connector, as per here.  That will then allow me to connect to a U.FL to RP-SMA cable, and place a higher gain antenna on the board.

I’ve still  left a few breadboard pins at the base as they may turn out to be useful for LEDs, buzzers etc.

As you can see, there’s a lot that needs to be done, but it breaks down into lots of separate blocks to keep me busy until the A3 and Scanse Sweep arrive.  The first step is simple: move Chloe’s HoG over to Hermione’s frame, and get her stable.

*Penelope (as in “Pitstop”) was a close runner up, but with my existing HoGWARTs WAP installation notes, Hermione (as in “Granger”) won the ballot outright.

The end of a project…

The first project I did was a turtle, with a Lego frame, Raspberry Pi plus 74HC595 serial parallel latch, ULN2801A darlington ampplifiers powering two stepper motors, with a Wifi connection to another RPi application where you can type in commands.  It was all powered by a 7.4v  Lithium Ion battery via a LDO Switching regulator.

This was done very much step by step, using much of the same circuitry from 25 years ago when I did one at school driven by a BBC Micro, starting first with driving LEDs, then progressing to steppers and then finally seating it in a Lego Techic body.

My Turtle

My Turtle

The commands are sent over a TCP connection from the control machine to the turtle.  The turtle was powered by a LiPo battery.  If you want more details, click on the TurtlePi category on the right.

I ended up buying lots of little bits of Lego from ebay to get the best combination of gears etc to ensure the large torque needed by the wheels didn’t break the gears or their axles.  But one piece didn’t exist: a flat yellow flat dome to drag on the floor under the batteries.  At some point, I got hold of a clear yellow one which was ‘good enough’ for the moment but my OCD – every programmer must have OCD to some extent – wouldn’t let it go until I had the correct one in the matching opaque yellow as the rest of the Turtle.  One turned up on ebay the other day – I’d kept the watch running – and I couldn’t believe it!

Compromised and Correct Lego domes

Compromised and Correct Lego domes

So now I’m a very happy person, and can concentrate 100% on Phoebe!

P.S. I had intended to show a video here, but as I powered up the Turtle, the circuitry heated up, and I think I’ve just blown the 3 stacked ULN2801 darlington drivers – hopefully the 74HC595 survived .  Definitely the end of the project for the mo’ though! Oops

Appendix 1: Next steps

While it’s clear from the Epilogue that more work is needed on the drift PIDs, the concept is proven, and the project moves on in order of feasability, importance and cost.

  • I’m still obsessed about noise suppression for the accelerometer along with weight reduction, so I’ve reworked the breadboard to use a smaller one, and intend to seat it on a carbon fibre platform that has a 10mm silicone foam layer between it and the platform seated between her legs. That platform itself will also be replaced with a carbon fibre equivalent- I’m just waiting for the CF sheet to complete that.
  • No drift in windy conditions uses the same PID logic as deliberate movement in non-windy conditions: a horizontal speed PID target of zero meters per second in windy conditions keeps the PID stable by dipping Phoebe’s nose down into the wind; a horizontal speed target of non-zero means Phoebe’s nose will drop in the desired direction of movement.  That opens up the option of user control via WiFi radio / remote control to set a desired target for the PIDs; I’m already 50% there on the physical build / components – 2 joysticks control the desired speed along the X, Y and Z axes, allowing horizontal movement and ascent / descent.
  • Turning left / right (as opposed to moving left or right) will need a yaw PID which takes a target from the remote control as the desired angle of turn.  Then as she moves forwards with her nose down, Phoebe’s yaw will change the direction her power is applied and she’ll turn as expected.  That outer PID to rotate by a fixed angle doesn’t exist yet, only the inner one to stabilize the yaw.
  • Takeoff from a non-horizontal platform requires the ability to measure the takeoff angle using a compass; the MPU9150 is pin compatible with the MPU6050 I use for accel / gyro but also contains the compass – breakout boards are available but not in the style matching my MPU6050 breakout, so I’m investigating building my own.  The compass will also be useful for the new yaw PID for turning corners by a fixed angle.
  • Phoebe needs protection against power and RC connectivity failure to trigger a stable landing
  • Adding a GPS would allow her to track her path, either just for display, or to allow her to return to base under problem conditions like above.  She could also follow apre-programmed path autonomously.

So plenty to keep me busy despite the winter weather.  But first I need fine tuning on the drift on longer flight times so I can confirm Phoebe’s suitability for a move into the garage.

Super duper WiFi dongles

I have a range of WiFi dongles I use with my various RPi projects, which I thought I’d share as my choices have evolved as my requirements got more refined.

First off is the Edimax Nano dongle – an absolute cracker – tiny, yet supports soft AP (WAP).  The only reason I moved on from here is the drone needs 360 degrees line of sight meaning I wanted a dongle with antenna to achieve better reach and signal strength.

That led me to these Edimax EW-7612UAn V2 dongles.  They support soft AP (WAP) although I didn’t have that requirement yet.  They worked great, until I realized that when in flight, even with the antenna, the signal would be poor due to its position on the drone blocking line of sight to the controller.  It also suffered during the couple of gravel crashes the drone took.  So I needed a detachable antenna that I could attach between the drones legs.

Which brought me to the EDUP range – my first purchase was the EP-MS150N.  A cracking dongle with a small body, small USB connector, 150m range and detatchable antenna allowing for a separate wired antenna.  Lovely jubbly – except they seemed to vanish from Amazon and ebay shortly after I found them (partly my fault), and they don’t support soft AP / WAP.  So when I came to setting up my test WAP, these didn’t work.

On the plus side that did lead me to the EDUP site and to the EP-MS15003 – a cracking dongle – like the MS150N but double the range and with soft AP support.  But unavailable outside of China / HongKong – shame.

Which finally led me to the EDUP EP-MS1537 – also 300m range, soft AP support, and available on ebay (from HongKong), so I ordered a couple and they’re on there way now  from China.

But I’m impatient, and liked the white colouring of the EP-MS15003, it’s smaller size and cropped USB plug, so carried on grubbing around on google and found these guys in Hong Kong stocking the EP-MS15003, and offering DHL delivery at a sensible price meaning delivery within a week rather than a month.  Sorted!

One week later, it’s arrived and installed and running the drone WAP like a dream.

P.S. All the above dongles use the Realtek chipset, so, where soft AP is supported, can be used as a WAP using these instructions if you need a bridge to the internet, or mine, if you want your WAP to be in a completely isolated secure network like I want for the drone.