Option to use position for fixed wing nav altitude control

[breadoven]

Adds an option to use position based nav altitude control on fixed wing instead of velocity based control which doesn't appear to work reliably on some plane types. Option enabled with new setting nav_fw_alt_use_position (OFF by default).

nav_fw_alt_control_response still works with the position based control in the same way as for velocity based control.

Only tested on HITL so far where it seems to work well. The new method of controlling altitude rate appears to be a big improvement on the old position based altitude control method with rates being held more accurately with limited pitching oscillations compared to previously. PID values may need further fine tuning.

[breadoven]

@sensei-hacker It needs testing but it's not experimental. Pretty much as it was before #9471 but with some improvements for rate control.

[ProfDrYoMan]

There is an issue open which might be relevant for this one:
#10773

[Jetrell]

@breadoven I flew a few flights today with one of the planes that had tuning issues using the velocity altitude controller.
I used the OSD/Adjustments for inflight tuning. Starting out with the PID's that I had set for the Vel controller, which still caused it to pitch oscillate. P = 18, I = 8, D = 2

After enabling nav_fw_alt_use_position. I noticed oscillations where no longer there... But as expected, it was very loose with that tune.
After playing around for a while in Cruise, RTH and Loiter. I settled on P = 32, I = 9, D = 8. And nav_fw_alt_control_response = 24.

When entering a descending loiter and then watching it level out at nav_rth_home_altitude. I was surprised when it consistently only went 2 - 3m below the target, and recovered in half a loiter circuit... I seem to recall the old altitude position controller was often much worse.
I will add to this. That I have my DIVE angle at 17° and from the EXTRA altitude. It was descending 60m. So it gets-up some momentum.

I could have tuned it a bit tighter and you would never have noticed any problems. But when panning the camera back to look at the elevator. I could see slight oscillations. That's why I settled with the values I have.

So it seems beneficial for this plane.. I'll be interested to hear what others think.

[breadoven]

@Jetrell You could set nav_fw_alt_control_response lower if you want to limit overshoot even more. One thing of note is the D term used internally by the PID loop is effectively 3x larger than the value used previously for the old position based altitude control. Seems to work better I thought with higher D terms. I was using setting values of 70 before without any issues although that was probably overkill. With default values you got a lot of altitude oscillations during position hold.

Good to see this works especially the new method used for rate control. Much better than the old method.

[majianjia]

I like the idea with rate control vertical speed. However, I think the default value can be improve. The new default was a bit on the aggressive side.

[Jetrell]

After running some more tests with this today. And proceeding to increase the gains. There was no possibility of getting near what could be achieved with the old nav_fw_pos_z controller.
For name sake; I'm leaning towards this still having more in common with the velocity controller, than the old Position controller, when it comes to tuning.

If I had to rate it in tuning similarity from 1 to 10.. 1) Position and 10) Velocity. I'd say it's an 8.
With nav_fw_control_smoothness playing a huge part in its tuning. A nice tune with it set to 9, goes very pear shaped if that setting is dropped down to 2 or less.

However it has still taken the edge off those harder to tune planes. But it's not as care-free as the old position controller. But it's also more precise than it was.

[breadoven]

After running some more tests with this today. And proceeding to increase the gains. There was no possibility of getting near what could be achieved with the old nav_fw_pos_z controller. For name sake; I'm leaning towards this still having more in common with the velocity controller, than the old Position controller, when it comes to tuning.

If I had to rate it in tuning similarity from 1 to 10.. 1) Position and 10) Velocity. I'd say it's an 8. With nav_fw_control_smoothness playing a huge part in its tuning. A nice tune with it set to 9, goes very pear shaped if that setting is dropped down to 2 or less.

However it has still taken the edge off those harder to tune planes. But it's not as care-free as the old position controller. But it's also more precise than it was.

Is this related to rate control behaviour or maintaining an altitude such as during cruise or both ?

If it's an issue during cruise when it's trying to maintain an altitude then the only things that are different to the old postion based control are:

1. D term is based on error rather than measurement. I'll switch this back to measurement and see if it changes anything.
2. As mentioned above the D term factor is roughly 3 times more effective than previously. It should be possible to compensate for this simply by reducing the D term by a factor of 3.
3. PID factors are 10 times smaller than used previously because the target and measured values used in the PID loop are 10 times bigger (because of a gravity factor used for the old energy balance calcs used for position based control). Theoretically these differences should cancel out but maybe they subtly don't for I and D. You could change things back so it's the same as before by factoring up the target and measured altitudes by 10 and reduce PID factors accordingly. We could certainly try this, might be interesting to see if that's the issue.

If the above changes are made then the PID control will be exactly the same as before. If it still behaves differently then I'm afraid it'll be down so some other change that's come in at version 8.0.0 because as far as the PID controller is concerned inputs and the PID factors will be the same as before so it should output the same pitch control demands as previously.

[Jetrell]

Is this related to rate control behaviour or maintaining an altitude such as during cruise or both ?

It was related to both.

Yesterday I started out with P = 30, and had I and D set to the old defaults for the Position controller, 5 and 10.
With it causing wild oscillations as soon as I entered Cruise mode.
So I landed and reduced D = 5 and set nav_fw_alt_control_response = 14.. And that was with nav_fw_control_smoothness = 3, which is what I run it on this plane.
The result was, the oscillation where 90% gone in Cruise.. So I landed again and reduced P =25, D = 2.
This smoothed out Cruise mode and WP linear climbs. But didn't remove oscillations when max nav_rth_alt_mode = EXTRA was called.
So I increase nav_fw_control_smoothness = 5, which reduced it by maybe 50%... Although it shouldn't have to rely on a work-around.

D term is based on error rather than measurement. I'll switch this back to measurement and see if it changes anything.

Judging by how much effect D-term has on this controller. I'd say this is likely the case. Being that the tune didn't end up much different to the velocity altitude tune,

[rts18]

As a late comer to the party. My tests show the same. The required tune for the position z changes where practically the same as that of the velocity z tune. However it appeared to calm things a little.

I have not had the opportunity to test the changes made in commit 83d162c