I flew Phoebe earlier with LEDDAR working well. She repeatedly drifted left, and self-corrected as can be seen in the graph below. You can see her repeatedly drifting and stopping. This is the expected behaviour due to the top level PID controlling velocity not distance: drift is stopped, but not reversed. On that basis, I’ve updated the code on GitHub.
To get her back to where she took off from, I need another set of ‘pseudo-PIDs’ to recognise and correct the distance drifted. I’m going to keep this as simple as possible:
- I’ll continue to use my velocity flight plan – integrating this over time will provide the ‘target’ for the distance PIDs in the earth reference frame
- I’ll integrate the velocity (rotated back to earth frame) over time to get the distance PID ‘input’ – although this is double integration of the accelerometer, it should be good enough short-term based upon the close match between the graph and the flight I watched.
- critically, I’ll be using fixed velocity output from the distance ‘pseudo PID’, rotated back to the quad-frame as the inputs to the existing velocity PIDs – the input and target of the distance ‘pseudo PID’ only provide the direction, but not speed of the correction.
This should be a relatively simple change which will have a visible effect on killing hover drift, or allowing intentional horizontal movement in the flight plan.
After that, I’ll add the compass for yaw control so Phoebe is always facing the way she’s going, but that’s for another day.