Whether ’tis easier for the macro-blocks to track
The clovers and daisies of contrasting colour..”
The answer is no, I shouldn’t have mown the lawn. With the kids’ toys moved out of the way, and any ungreen contrasting features slain, there was nothing to distinguish one blade of shorn grass from another and Hermione drifted wildly. Reinstating the kids’ chaos restored high quality tracking over 5m.
The point of the flight was to compare GPS versus macro-block lateral tracking. Certainly over this 5m flight, down-facing video beat GPS hands down:
My best guess interpretation of the GPS graph is that the flight was actually from the 2 – 7m diagonally heading north west. The camera POV doesn’t include compass data, so it’s correctly showing her flying forwards by 5m. The compass code is not working accurately yet – it needs more investigation why not – it was showing ~90° (i.e. East) rather than the true 45° (i.e. North East) shown by the GPS and a handheld compass.
I’ve done some more refinements to scheduling the sensor reads, and also accuracy of GPS data streamed from the GPS process. It’s worth viewing this graph full screen – each spike shows the time in seconds between motion processing loops – i.e. the time spent processing other sensors – 10ms indicates just IMU data was processed. The fact no loop takes more than 0.042s* even with full diagnostics running means I could up the sampling rate back to 1kHz – it’s at 500Hz at the moment. More importantly, it shows processing is nicely spread out and each sensor is getting it’s fair share of the processing and nobody is hogging the limelight.
As a result, I’ve updated the code on GitHub.
*42ms is the point where the IMU FIFO overflows at 1kHz sampling – 512 FIFO size / 12 bytes sample size / 1kHz sampling rate
I’m doing some very careful testing before I set Hermione loose live to fly in a circle. This morning, I’ve confirmed the video lateral motion block tracking is working well.
For this first unpowered flight, I walked her forwards about 3m and then left by about the same. Note that she always pointed in the same direction; I walked sideways to get the left movement:
Forward – Left
For this second unpowered flight, again, I walked her forwards about 3m, but then rotated her by 90° CCW before walking another. Because of the yaw, from her point of view, she only flew forwards, and the yaw is not exposed on the graph. This is exactly how it should be:
Forward – Yaw 90° CCW – Forward
So I’m happy the lateral motion tracking is working perfectly. Next I need to look at the target. I can go that with the same stats.
The only problem I had was that the sun needs to be shining bright for the video tracking to ‘fly’ above the lawn; clearly it needs the high contrast in the grass when sunlit.
By lowering the video frame rate to 10Hz, I’ve been able to increase the video resolution to 720² pixels. In addition I’ve increased the contrast on the video to 100%. Together these now provide enough detail to track lateral motion on the lawn. Drift with hover is non-existent, so next step was to try a flight around a 2m square. That’s where the disagreement showed itself:
Difference of opinion
- Top left is the flight plan up to the point I killed the flight: 2 meters forwards and left by 0.35m
- Top right shows the 90° anticlockwise yaw so she points the way she’s going
- Bottom left is the track picked up by the PiCamera macro-blocks
- Bottom right is the track derived by double integrating the accelerometer.
Both agree on the forward motion of about 2 meters, but the disagreement arises at the point she turns left. The right of the pair is correct based on my independent third-party view of the flight; although she was pointing left, she flew right from my point of view i.e. backwards from her point of view. I’ve clearly got the maths back-to-front in the lateral motion tracking. I’m pretty sure of the offending line of code, and the fix is trivial, but I’m really struggling to convince myself why what’s there is wrong.
Luckily, during the flights, there were a number of high-torque landings which ultimately broke the bracket for one of Hermione’s legs. Until the replacement arrives from Poland, I have plenty of time to kill convincing myself why the existing code is wrong.
For the first time in 4 years, I tried a lateral flight plan, fairly confident in the belief that stable hover in a headwind is no different to intentional movement forward in no wind. The flight plan was:
- Climb at 30cm/s for 2s
- Hover for 1s
- Move forwards at 30cm/s for 2s
- Hover for 1s
- Move backwards at 30s/s for 2s
- Hover for 1s
- Descend at 30cm/s for 2s
Was I right? You tell me: