Hermione is still causing trouble with yaw control flights despite lots of refinements. Here’s the latest.
@3s she’s climbed to about a meter high and then hovered for a second. All the X, Y, and Z flight plan targets and sensor inputs are nicely aligned.
The ‘fun’ starts at 4 seconds. The flight plan, written from my point of view says move left by 1m over 4 seconds. From Hermione’s point of view, with the yaw code in use, this translates to rotate anti-clockwise by 90° while moving forwards by 1m over 4 seconds. The yaw graph from the sensors shows the ACW rotation is happening correctly. The amber line in the Y graph shows the left / right distance target from H’s POV is correctly zero. Similarly, the amber line in the X graph correctly shows she should move forwards by 1m over 4s. All’s good as far as far as the targets are concerned from her and my POV.
But there’s some severe discrepancy from the sensors inputs POV. From my POV, she rotated ACW 90° as expected, but then she moved forwards away from me, instead of left. The blue line on the Y graph (the LiDAR and ground-facing video inputs) confirms this; it shows she moves right by about 0.8m from her POV. But the rusty terracotta line in the Y graph (the double integrated accelerometer – gravity readings) shows exactly the opposite. The grey fusion of the amber and terracotta cancel each other out thus following the target perfectly but for completely the wrong reasons.
There are similar discrepancies in the X graph, where the LiDAR + Video blue line is the best match to what I saw: virtually no forward movement from H’s POV except for some slight forward movement after 8s when she should be hovering.
So the net of this? The LiDAR / Video processing is working perfectly. The double integrated IMU accelerometer results are wrong, and I need to work out why? The results shown are taken directly from the accelerometer, and double integrated in excel (much like what the code does too), and I’m pretty convinced I’ve got this right. Yet more digging to be done.
In other news…
- Ö has ground facing lights much like Zoe had. Currently they are always on, but ultimately I intend to use them in various ways such as flashing during calibration etc – this requires a new PCB however to plug a MOSFET gate into a GPIO pin.
- piNet has changed direction somewhat: I’m testing within the bounds of my garden whether I can define a target destination with GPS, and have enough accuracy for the subsequent flight from elsewhere to get to that target accurately. This is step one in taking the GPS coordinates of the centre of a maze, and then starting a flight from the edge to get back there.
That’s all for now, folks. Thanks for sticking with me during these quiet times.
P.S. I’ve got better things to do that worry about why everything goes astray @ 7s, 3s after the yaw to move left started; it’s officially on hold as I’ve other stuff lurking in the background that’s about the flower.