I am trying to get to the bottom of some strange behaviour observed during a flight test where a transition was made from loiter to mission.
MIS_TAKEOFF_ALT was 80m
First waypoint ALT was 75m
Initially loitering was at about 60m before transitioning to mission, the aircraft made a shallow descent to around 10 - 15m before climbing to the first waypoint altitude of 75m.
So on further investigation, GPSP.Alt gets set to 0 coming out of loiter and remains at 0 for approx 10secs before being set to the altitude of the first waypoint.
Anyone have any ideas on why there’s a huge delay in setting the GPSP.Alt?
There was no take off waypoint, just 4 basic waypoints @ 75m agl and a repeat waypoint of 20 at the end. There is a log available (possibly 3) but will have to get permission before I can release it. Tuesday will be the earliest I will have access to it (it’s a bank holiday here).
It’s possible, I’ll have to go back and check our old flight logs for when the aircraft crashed. It was believed that the mission hadn’t loaded correctly for these flights - but now I’m not so sure.
Using stable (1.4.4) I went through a few variations of what you described and couldn’t reproduce any loss of altitude. Please share the log if you can.
It’s a problem with the navigator logic that changes the altitude linearly between waypoints. It’s only an issue if you first switch to loiter and then mission.
As a temporary work around either set param MIS_ALTMODE 0 or avoid transitioning directly from loiter to mission. Stab -> mission should be fine. The MIS_ALTMODE change may be more noticeable as your climb/descent between waypoints will now be based on the full TECS limits.
Thanks for fixing this so quickly. I will merge the fix into our codebase, but it might be a while before we flight test as we broke an aircraft last night.
FYI, we flew a similar mission last night but with a takeoff waypoint first. Also the transition ended up being from Manual to Mission. This seemed to work fine with out problems.