When I was at the latest Cotswold Jam, one of the regulars suggested adding a camera to one of my piDrones to video its flight firsthand; that planted a seed which blossomed overnight:
Set up a live video stream from a RPi0W attached to one of my piDrones, the output of which is sent over WiFi to a RPi3+ RC touch-screen and display the video on a screen app there
Add on-screen pseudo-buttons to the RPi3+ RC touch-screen and use those to record the video to disk if specified
Add 2 on-screen pseudo-joysticks on the RPI3+ touch-screen RC, sending it to the piDrone, much like the physical joysticks do now
Finally, add IMU / servos hardware / software to keep the camera stable when it’s attached to a flying piDrone – trivial compared to the items above.
I’m completely ignorant how to implement all but the last item, much like the challenge to build the piDrones 6 years ago and hence that’s a fab challenge! And in comparison to the piDrone itself, it’ll be cheap: the parts either I already own, or are cheap to buy. And I like the fact it gives a unique role for Penelope – currently she’s just Hermione without the object avoidance.
First job though is to name the Raspberry Pi’s:
Percy (i.e. Pi Remote Control) is the RPi 3+ with the RPi touch-screen
courtesy of lots of extra layers of the Pimoroni PiBow Ninja. They also did a couple of custom cuts for Penelope’s PiBow so I could lower her by 2 layers (6mm) making space to include the battery warmer. Penelope is however still waiting for the Garmin LiDAR-Lite v3HP.
I wish I could say the same about the software. The problem is how to access these I2C Hall Effect Joysticks. Although “i2cdetect -y 1” can see them, none of three different I2C python libraries (smbus, smbus2 and pigpio) can read the data correctly from them. The problem is that the joysticks’ I2C does not need a register, you simply read two bytes from the I2C address, yet none of these libraries successfully doing this. A google query found my own post high in the rankings which is disappointing when hoping to find someone else’s solution, so I’ve contract Grayhill directly.
Until this is solved, there’s little point adding the code to connect to Penelope (and for her to be listening), nor having Ivy load the code on boot. Very frustrating.
The PC World mention, along with some recent comments got me thinking about why I lack interest in adding an altimeter / magnetometer / GPS / remote control to HoG. After all, it’s the obvious next step.
I have the sensors already, and none of the above would add much in the way of overheads to the code processing – perhaps only 1Hz polls of the GPS, compass and altimeter fused with the existing data from the accelerometer and gyro about orientation, direction and speed feeding into the existing flight targets. All relatively straightforward.
Autonomy vs. remote control was purely a personal decision based upon my ineptness at controlling machines with joysticks. I stopped computer gaming with Half-Life2 2 when I was within seconds of the end and yet lacked the hand-eye coordination to win that final battle to stop the launch of the missile / rocket / bomb.
It’s a combination of time and testing that is the biggest problem. Up to now, all testing happens in the back garden – it now takes me less than 5 minutes to run a flight, and get back indoors to analyze the diagnostics. Even when the weather is terrible, those 5 minute slots exist virtually every day. But with GPS movement tracking resolution of 10m, the garden is nowhere near big enough to test autonomous path tracking – just too many high stone walls to crash into. I could move testing to the village play park a hundred meters down the road, but it’s called a kids play park for a good reason. I could move into the fields a couple of hundred meters away, but that’s just far enough away that time steps in – to-ing and fro-ing between the fields and the “engineering lab” (home office) would just be too inefficient for the limited time available due to a full-time job and two kids under 7. Oh, and the farmers probably wouldn’t appreciate HoG scything down their crops or sheering their sheep!
So I settled on short term autonomous flights within the bounds of the back garden.
Having said all that, I’m off to the kids’ play park tomorrow during school time just to see how long HoG can maintain a stable hover with limited drift, and perhaps add some horizontal movement to her flight plan if all goes well. Weather forecast is good, sunshine and only a gentle breeze so hopefully I’ll be able to get a longer video of what she can do!
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.
I chose the joysticks for my drone remote control from austrianmicrosystems (via proto-pic) because they were digital with an i2c connection, rather than analogue requiring my own A/D converter. Some of decision was based on simplicity, and some simply on breadboard space. The only problem with these is they have tiny 2mm sqaure posts which (I suspected) would make accurate control of the SkySpy tricky. So I needed some knobs to fit on the posts. But the posts are only 2mm square and only 0.9mm high.
I was at a bit of loss how to make these, so I thought I put in a cheeky but honest request to AMS as I’d seen some nice knobs on one of their sales demos…
And AMS were brilliant. Their UK sales rep got hold of a couple and sent them to me. Not only do they look better, they provide a much firmer and finer level of control operating the joystick.
Here’s the remote control I’ve put together. Hardware is complete, and software isn’t too far off; all that missing is the message definitions that the controller sends to SkySpy and the code on the SkySpy to act upon those. But before then, I want to get this controller to be a wireless access point, so that I can test the pair outdoors without needing to somehow connect them via the internet wireless phone hub in the house.
SkySpy remote control
There’s a couple of digital joysticks where each has a switch too. The left-side one will control up and down, the right side, forwards, backwards, left and right, and I’ll be using switches to trigger automated stable take-off or landing plus pressing both together will be an emergency shutdown. It’s the switch actions I’m aiming to achieve first, and I think it’s gonna be a lot of trial and error – hence my need to get out of the house to do the testing, and therefore the independent WAP.
Other minor details – there’s a Ninja PiBow, a Lithium Ion battery and 3 breadboards on here. The boards are particularly perfect as they have six rows of connectors instead of five, and the power track points are aligned with the main board connects. Together that means more connectors, more densely packed, and in this case, that means they fit under the Ninja Pi posts snug as a bug in a rug.
You’ll also note the +3dB antennas used in preparation for outdoor use both on SkySpy and the controller.