Plane: Gliding with TECS

[samuelctabor]

This PR enhances the TECS airspeed/pitch handling when in pure gliding flight.

• Changes the Mavlink message to send the rate-limited target airspeed rather than the raw target airspeed.
• Adds a feed-forward term to apply pitch based on demanded airspeed.
• Fixes an error in the feed-forward term for rate of change of airspeed.
• Uses the FLIGHT_STAGE mechanism to handle gliding rather than using the soaring_active flag.

Using FLIGHT_STAGE makes the gliding capability independent of the soaring feature. This will be useful for future features e.g. automated response to engine failure.

The changes to pitch control improve the response to demanded airspeed changes. This is particularly important for soaring as large airspeed changes are typically made. In a glider airspeed is 100% controlled by pitch, so it is appropriate to set the pitch approximately (a linear dependence is assumed) and allow the integrator to trim about this. This is a lot quicker than waiting for the pitch integrator to adjust attitude by itself.

The effect of the changes to the pitch control are shown in the plot below. A step change in target airspeed from 8m/s to 20m/s is applied (in simulation).

In the "Baseline" case, too much nose-down pitch is applied in response to the demanded acceleration. This is compensated for by an increase in the pitch integrator. When the rate-limited target airspeed reaches 20m/s and demanded acceleration goes to zero, the FF term goes to zero and the integrator build-up causes a nose-up pitch. The airspeed hasn't reached the target, and the pitch integrator must now unwind and go negative to get the nose down. The result is a slow response to the step change in target airspeed.

In the "Bugfix" case, the applied pitch FF is appropriate for the demanded acceleration. This removes the positive integrator build-up, but the integrator still needs to go negative to get the nose down. The response is improved.

In the "Pitch FF" case, a nose-down pitch angle is applied based on the (rate-limited) target airspeed. This avoids the need for the integrator to build up to achieve the target airspeed. The response is further improved.

[samuelctabor]

Rebased on latest master. Any timeline for a review @tridge ?

[magicrub]

@samuelctabor I'm not sure how I feel about a flight stage like this. I do agree we need to decouple the soaring library from the gliding property, but this still relies on the soaring library. At least TECS doesn't know about soaring, that's progress. What if the aircraft is gliding but without soaring enabled such as in an engine failure?

[samuelctabor]

@magicrub it seemed like a suitable existing mechanism - an alternative would be to pass in a flag for gliding, replacing the previous soaring_active. As it is, in the engine failure situation the flight stage can be set to GLIDE by the code or library responsible for detecting this situation. I don't think such a detection feature is currently implemented?

[samuelctabor]

Rebased on master.

[tridge]

sorry for slow response. This came to my attention after the recent bug fixes in TECS.
The problem with a flight stage for gliding is that you could be gliding while also doing some other flight stage. For example, gliding and landing aren't mutually exclusive. There are projects using ArduPilot for automatic missions after a balloon drop, where the last mission item is a landing.
I think we need to set the "gliding" flag under 3 circumstances:

• soaring is active
• thr_max is zero (ie. has no motor ever)
• the plane has a motor but it has failed (maybe detected with RPM?)
  maybe there are others?

[samuelctabor]

Thanks tridge. I understand your point about gliding being orthogonal to the existing flight stages. I'll rework this (probably tomorrow) to use an extra member of the flags structure to indicate gliding flight, and an access function.

[samuelctabor]

I added three booleans to the TECS flags -

• whether gliding is requested e.g. by soaring;
• whether propulsion has failed;
• whether gliding will actually be used.

The first two can be set using methods on the TECS class, and the last is true if either of the first two is true, or if THR_MAX = 0.

Comments please.

[samuelctabor]

Rebased on master. I'm happy to split this up if that would make it easier to merge.

[robustini]

@samuelctabor is there a way to eliminate/reduce that roll wobbling as soon as it goes into Loiter because it found a thermal?
I don't think it's a tuning problem, but a SOAR code issue.
He has the same behavior even while in Loiter he continues to try to follow her.
At 8:48: https://youtu.be/5ixXBYsCtFc?t=525
Here the df log:
2019-05-15 16-14-05.zip

[samuelctabor]

@samuelctabor is there a way to eliminate/reduce that roll wobbling as soon as it goes into Loiter because it found a thermal?
I don't think it's a tuning problem, but a SOAR code issue.
He has the same behavior even while in Loiter he continues to try to follow her.
At 8:48: https://youtu.be/5ixXBYsCtFc?t=525
Here the df log:
2019-05-15 16-14-05.zip

Hi Marco,

Some strange issues there. Could you try my development branch? There are a few things fixed or improved in there that may help.

https://github.com/samuelctabor/ardupilot/tree/SoaringImprovements-398

Thanks,
Sam

[robustini]

Hi Sam, where I'm now I don't have the compilation environment, if you compile it for "Pixhawk1" I can try it.

Marco

[samuelctabor]

Hi Sam, where I'm now I don't have the compilation environment, if you compile it for "Pixhawk1" I can try it.

Marco

Hi Marco,

Created an issue here #11406 and added binary for Pixhawk 1.