[Get yourself a cuppa – this is a long boring witter by me as I think through several related problems out-loud]
For months I’ve been trying ways to get Phoebe to take-off in a controlled manner (i.e. using the sensors and PIDs etc). But it never worked; the only way I could get her up in the air was simply to kick her – i.e. boosting here propeller power a significant amount in one big step; I didn’t like this way as it was not elegant, but any other way resulted in a crash; essentially Phoebe needs to leap into the air with passion and commitment; this is done simply by taking her motors PWM ratio from 55.0% (stable on the ground) to 60% (more than enough power to get airborne) in a single PWM update.
Any less commitment would always lead to a flip and crash; I never bothered investigating as I had bigger problems on my mind at the time; I just took it as read and moved on.
Which brings us to yesterday; yet more test flights tinkering with take-off speeds, flight lengths – primarily so I could get a better video to post. Each flight shared a common factor – a quite gymnastic head-stand, plus lawn-mowing on landing. The one common factor on hitting the ground was that the sensors reaction was a factor of 10 larger than when Phoebe flew, and once more, this could be guaranteed to result in a headstand! Very much like the attempt at controlled take-offs abandoned months ago.
Which got me thinking that any attempt at stability control when there’s any contact whatsoever with the ground is anathema with stability control when flying free – the order of magnitude of the sensor values is too disparate; so forget cunning takeoff and landing scheme’s – just K.I.S.S.
So once more, hover at a stable height combined with no horizontal drift have arrived at the top of the list again; and I think finally I have a solution for hover at a stable height that I can believe in. Consider the roll, pitch and yaw stability solution:
The gyro measures angular speed in 3 dimensions. The PID uses this to define the error with the desired angular speed, and control the motors as a result to reduce the error. Careful tuning of this PID means that not only is rock solid angular speed stability possible, if there is a perturbation, the angle itself will be returned to pre-perturbation value.
Now swap “angular” speed with “vertical” speed – this then describes the behaviour needed for a good hover: rock solid stable zero vertical speed plus return to same height hover on perturbation. The only trouble is, although the gyro measures the speed of angular change, the accelerometer measure the acceleration, and even worse, it’s nigh on impossible to read anything meaningful due to the noise.
Ah but, that’s actually the point (phew): the vertical speed comes from the integral of the accelerometer outputs and drift (due to summing acceleration over δt != integrating acceleration over dt) doesn’t look too bad (look a picture for those of you who’ve stuck this out – was it worth waiting for?).
The black dotted line is the PWM power shown on the right axis – 2s @ 600, 2s @ 590 and the rest up to the crash @ 585 – this represents (loosely) take-off, hover and landing.
The interesting pieces are vertical acceleration in g’s in blue, vertical speed in meters / second in red, and height in meters in green. For the first 2 seconds, extra power is applied, vertical speed (red) rises to a peak and then starts to fall; height (green) continues to climb throughout. At 2 seconds the power drops; vertical speed continues to drop (though is still positive due to momentum), and as a result, height continues to rise. The interesting point is at about 2.6 seconds, when height peaks and vertical speed passes through zero – it’s this point where I believe the new vertical speed PID needs to kick in to maintain the vertical speed at zero, and therefore the height stable.
2 further minor comments: 3.75s is the point Phoebe hits the ground and all hell breaks loose as a result. For the moment, I’m OK with that; slightly more interestingly, the height is still > 0 at this point – I think I know why – some compensatory code I added which is actually making things worse not better. If I’m right, that means I can infer height above the ground (assuming it’s level of course), and kill the motors if it gets too close – which should stop the headstands and lawn-mowing at least short term until I add a set of proximity detectors.
Altogether that means I know what changes I need to add to the code to catch the max height (0 vertical speed) point and kick the PID off – it’s only a few lines of code, so may be able to get it done for testing in the next day or two. Fingers crossed!