One Zero is for showing off at the next Cotswold Jam, along with the new higher-resolution 8 megapixel camera module. Perhaps set up as a tiny onesie cam?

The other is for Zoe – and maybe another camera too, once I’ve overcome the problem with WAPping the latest jessie, the use of which is mandatory if I want to use the new higher-res camera with her purely for FPV videos. The new camera slot points horizontally which is great for retaining the low profile of the Pi Zero.

The unicorn and diffuser are mostly just for playing with on my main Pi.

Next frenzy will start when they launch the A3 which I’ll be transferring Phoebe to for the extra CPU cores and processor speed needed for the two LiDAR units I’ll eventually be installing.

This is a long detailed post – grab a cuppa if you intend to plough through.

Here’s the plan for Phoebe.

There are 3 downward facing red lasers. Two are attached to the underside of her rear arms both pointing in parallel along Phoebe’s Z axis i.e. if Phoebe is horizontal then the laser beams are pointing vertically downwards. The third laser is handheld by a human. All are probably 5mW / Class 2 – although the power rating may need to be reduced to conform with legislation which is unclear. 5mW is safe due to the human blink reaction; 1mW is safe as long as it’s not viewed through a focusing device such as a lens.

The RaspiCam with NoIR filter is fitted in the center of Phoebe’s lower plate, also facing along her Z axis. A red camera-style gel filter is fitted over it in the expectation that this will increase the contrast between the laser dots and the rest of the background. The camera is set to ISO 800 – its maximum sensitivity. The photos are low resolution to reduce the processing required. Each shot is taken in YUV mode, meaning the first half of the photo data is luminance / brightness / contrast information. Photos are taken as fast as possible, which may actually be only a few per second due to the lighting conditions. The camera code runs on a separate thread from Phoebe’s main flight control code.

A typical flight takes places as follows:

Immediately prior to each flight, the camera is turned on and feeds its output into an OS FIFO.

Once at hover each motion processing loop, the motion processing code checks whether the FIFO is not empty, and if not empty, it is emptied and the last batch of camera data (i.e. the last shot taken) is processed.

It is scanned for bright dots and their position in the frame stored. By using the red filter and the Y channel (brightness / contract / luminance of YUV) from the camera, and because the lasers are fixed in Phoebe’s frame with respect to the camera, the dots should stand out in the photo, and lie between the center and the bottom corners of the photo. If bright spots are detected in this area, there is a very high level of confidence that these are the red dots from the frame lasers. The distance between the dots in pixels is proportional to the actual height in meters based upon the camera lens focal length.

This pixel-separation height is saved at the first pass in the hover phase and used thereafter as the target height; deviation in the separation of the dots compared to the target dot separation means a height error which is fed as target change to the vertical velocity PID.

Once the height is processed as above, any third similarly bright dot is assumed to be from the human laser. If such a dot is not found in 5 seconds, the code moved irreversibly to descent mode.

However if a 3rd dot is found in that 5s period then it’s position relative to the frame laser dots provides targets to

the yaw PID so that the 3 dots form an isosceles triangle with the quad laser dots at the base and the human dot is at the peak

the horizontal velocity PID so that the 3 dots form an equilateral triangle.

Loss of the human dot returns to frame laser dot mode for 5 seconds to reacquire the lost human dot which if not found, triggers the irreversible standard descent mode based upon the flight plan alone.

Similarly, loss of either of the frame laser dots triggers irreversible standard descent mode but without any wait for reacquisition of the missing frame dot.

This should provide stable hover flight for as long as the battery lasts, with the option of following the human dot to take the Quad for a “walk” on a “laser leash”.

Sounds like a plan, doesn’t is? Some details and concerns, primarily so I don’t forget:

-l per-flight command line control of laser tracking mode

mosfets to switch on lasers based on the above? Depends on whether GPIO pins can drive 2 10mA lasers

Is a new PCB needed to expose GPIO switch pin for lasers? If so, don’t forget the pull down resistor!

Prototype can be done in complete isolation from Phoebe, using one of my many spare RPi’s along with some LEGO and my as yet unused PaPiRus e-paper screen to show dot location. This could could then be easily battery powered for testing.

Constraints:

Merging a successful prototype into Phoebe requires an ‘A3’ and a rework of the PSU – currently direct feeding 5V into the RPi backfeeds the regulator (which would normally be taking input from the LiPo) causing to heat up significantly

I’ve just quit smoking saving myself £300 a month, and I was going to treat myself to a new vacuum cleaner as a reward – I have an older version of the same and it’s fab but this one is even fabber.

But I’ve also started putting together a new python + electronics tutorial for the next Cotswold Jam at the end of April, both setting up my own prototype, and collecting components for 24 kits to be given away to tutorial participants. Sadly, this has taken a significant proportion of my Dyson money, but I think the result of my prototype looks pretty cool, literally:

The give away kits will have smaller breadboards instead of the cakeboard shown above, but they’ll all come with the doors with neodymium magnets as the door knobs, reed switch, buzzer, on-off switch and wires.

Zoe did her stuff at the Cotswold Jam reasonably well, but she consistently drifted to starboard (right), even when I was safety testing her outside before hand at a much lower temperature.

The previous day, I’d also safety tested her indoors and she drift consistently backwards are about the same speed.

The setup and software for the two days was the same, except I’d removed the props for transit to the jam.

Could the difference in drift direction simply be the props? Had I rebuilt her at the jam with one diagonal pair of the props swapped compared to previously? That could account for the 90° change of drift. Certainly the change in drift does point heavily at the props. The props are plastic and they bend easily and permanently. So I now have some sturdy CF props on the way which I hope will limit the drift in time for my work engineering conference at the end of the week.

So the spoiler in yesterday’s photo was another quadcopter flight controller to the left of the keyboards, pending the release of a fantastic new range of quadcopter frames which is being launched next month. More on that once I’ve got my grubby mitts on one.

But that A+ controller has now been flushed down the pan with the launch of the Raspberry Pi Zero, smaller than an A+, double the memory and just as powerful in every other way. I really have know idea how they halved the size of the PCB and yet kept all of the function. And it’s £4 (yes, that’s not a typo, four quid for a computer that runs Linux happily!), and free if you buy this month’s copy of the MagPi magazine.

So I now need to redo the design for the beret board, to shrink it down to the Pi Zero size!

I’ve flying Phoebe virtually every day the weather allows in preparation for the indoor demo flight for the CotswoldJam on 26th September 1pm – 4pm at the University of Gloucestershire in Cheltenham. I can confidently say she’s safe.

P.S. Sorry about the video quality, the camera really didn’t the shoot in the shade with sunshine back light.