Around here in the South Cotswold, there are lakes, hundreds of them left behind once the Cotswold stone rocks and gravel have been mined from the ground. People swim, yacht, canoe, windsurf and powerboat race around the area. It’d be cool for a piDrone to fly from one side of a lake to the other, tracking the terrain as shown in this gravel pit just 2 minutes walk from my house. ‘H’ start at the left, move over the pond, climb up and over the gravel and land on the far side:
Surface gravel mining
But there’s a significant problem: neither the ground facing video nor LiDAR work over water. For the down-facing video, there’s no contrast over the water surface for it to track horizontal movement. For the LiDAR, the problem come when moving: the piDrone leans to move, and the laser beam doesn’t reflect back to the receiver and height reading stops working.
But there is a solution already in hand that I suspect is easy to implement and has little code performance impact, but amazing impact over the water survival: GPS is currently used in the autopilot process to compare where she is currently located compared to the target location, and pass the speed and direction through to the motion process; it would be nigh on trivial to also pass the horizontal distance and altitude difference since takeoff through to the motion process too.
These fuse with the existing ed*_input code values thus:
- Horizontally, the GPS fuses always with the down facing PiCamera such that if / when the ground surfaces doesn’t have enough contrast (or she’s travelling too fast for video frames to overlap), the GPS will still keep things moving in the right direction and speed.
- Vertically is more subtle; as mentioned above, the LiDAR fails when the ground surfaces doesn’t bounce the laser back to the receiver perhaps due to a surface reflection problem or simply because her maximum height of 40m has been exceeded. In both cases, the LiDAR returns 1cm as the height to report the problem. Here’s where GPS kicks in, reporting the current altitude since takeoff until the LiDAR starts getting readings again.
Like I’ve said, it’s only a few lines of relatively simple code. The problem is whether I have the puppies’ plums to try it out over the local lakes? I am highly tempted, as it’s a lot more real than the object avoidance code for which there will never be a suitable maze. I think my mind is changing direction rapidly.
The Raspberry Pi camera of course:
RaspiCam Video motion blocks
A very similar walk around the garden as before, but running the Raspberry Pi camera, ground facing, videoing at 10 frames per second at 320 x 320 resolution, producing 16 x 16 macro-blocks per frame, which are averaged per frame and logged.
The macro blocks give the pixel shift between one frame and the next to help with the frame compression; I’m not sure whether the units are in pixels or macro blocks, but that’s simple to resolve. Combined with the height from the LEDDAR, and the focal length of the lens, it’ll be trivial to convert these readings to a distance in meters.
The results here are at least as good as the PX4FLOW, if not better, and the processing of the macro-blocks to distance is very lightweight.
This is definitely worth pursuing as it’s much more in keeping with how I want this to work. The PX4FLOW has served its purpose well in that with my understanding how it worked, it opened up how it could be replaced with the RPi Camera.
There are further bonuses too: because of the video fixed frame rate, the macro blocks are producing distance increments, whereas the PX4FLOW only produced velocities, and that means I can add in horizontal distance PIDs to kill drift and ensure the quad always hovers over the same spot. And even better, I’m no longer gated on the arrival of the new PCBs: these were required for X8 and I2C for the PX4FLOW; I’ll need them eventually for X8 but for now, the current PCB provides everything I need.
We are most definitely on a roll again!
Did some simple testing to determine the camera angle, resolution and suitable dual laser dot separation. Kitty was sat on a stool, looking up at the ceiling, and I was waving the laser around the ceiling watching the curses display. The picture below is upside down!
∧ ^ ^
/|\ 21cm |
/ | \____V |
/ | \ 205cm
/ α | \ |
/ | \ |
/ | \ |
U = camera position
Span of kitty laser dot detection = 170 x 170cm
Test height (camera to ceiling) = 205cm
Alpha = atan(170 / (2 x 205) = 22.5°
Camera height at takeoff = 21cm
∴Camera span at takeoff = 17.4 x 17.4cm
Image size = 32 x 32 pixel
∴Image resolution at takeoff = 0.5 x 0.5cm
Landing leg separation = 23cm
Based on the above, 2 dots spaced by 15cm would make a good laser leash
Image span at 1m hover = 82 x 82cm
Double dot separation viewed from 1m = 15cm / 82cm x 32 pixels ≅ 6 pixels
So minimum capture resolution of 32 x 32 pixels should be fine for 1m hover, but by 2m, the risk of merged dots is too high as they’ll only be 3 dots apart.