Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TECS: Correctly handle Home altitude change #28675

Merged
merged 4 commits into from
Nov 27, 2024

Conversation

Georacer
Copy link
Contributor

@Georacer Georacer commented Nov 19, 2024

Summary

In case where the Home altitude is changed, TECS will now not reset, but offset the relevant attributes instead.

Background

Recently one of our partners flying a quadplane reported that while doing a ship landing, their plane would continuously lose altitude.
image

Details

The reason is that the most minute home altitude changes trigger a TECS reset. This behaviour is about 1 year old.

In the meantime, the ship landing lua script continuously updates the home location.
This code is ~2years old.

The combination results in the TECS constantly switching into a state of rest and becoming effectively paralyzed.

Solution

I added a new method AP_TECS::offset_altitude(const float alt_offset) where TECS is made aware of the change in home altitude and offsets all internal attributes accordingly.

This is a pretty wide-reaching change, so all comments and test proposals are welcome.

Testing

An autotest was created for Plane (SetHomeAltChange2) that, once the plane comes to altitude, it wiggles the home altitude over 10s.
The MAVLink command is set at 10Hz, but it seems to get parsed only at 2Hz.

Still, the results are conclusive:

Before:

  • When the wiggle starts, TECS starts resetting (bottom right)
  • The actual altitude starts climbing, since the trims cause the plane to climb (bottom middle).
  • All TECS quantities start wiggling too, including throttle and pitch. Still, this is an exaggerated case, since home is wiggled by +-40m.

Screenshot from 2024-11-25 16-16-34

After:

  • When the wiggle starts, TECS does not reset (bottom right).
  • The actual altitude stays on target (bottom middle).
  • All TECS quantities are stable, except for altitude (middle left). This is expected, since its frame is home-relative.

Screenshot from 2024-11-25 16-18-47

Alternatives

An alternative would be to just not reset TECS as often in case of home altitude change. But what is a "good" interval? Are we happy with TECS resetting every 10s? 20s?

Another alternative would be to just not allow the user to update home while TECS is running, but that sounds a bit silly to me.

@tridge
Copy link
Contributor

tridge commented Nov 19, 2024

@Georacer really nice work tracking this down!
as I mentioned on discord, I think we need a test for this

@Georacer Georacer changed the title WIP:TECS: Correctly handle Home altitude change TECS: Correctly handle Home altitude change Nov 26, 2024
@tridge tridge merged commit 2f9ff3e into ArduPilot:master Nov 27, 2024
99 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Pending
Status: Pending
Development

Successfully merging this pull request may close these issues.

3 participants