Plane: fixed terrain guided target intermediate alt handling - #29685
Conversation
f720093 to
fe91b01
Compare
|
Have you seen this @Ryanf55 ? Any thoughts? |
IamPete1
left a comment
IamPete1
left a comment
There was a problem hiding this comment.
Looks OK, this altitude stuff is always tricky, I the key thing is just to test each case.
| alt_cm = gps.location().alt; | ||
| } else { | ||
| loc.alt = baro.get_altitude() * 100 + AP::ahrs().get_home().alt; | ||
| alt_cm = baro.get_altitude() * 100 + AP::ahrs().get_home().alt; |
There was a problem hiding this comment.
I know this is existing code, but I wonder if it should be baro.get_altitude_AMSL() The difference is home altitude vs the set field elevation.
There was a problem hiding this comment.
wouldn't that mean we'd have home alt in there twice?
I also think it should be a separate PR if we change it
|
need to fix RockBlock.lua |
for QGuided mode with terrain target we were applying the home -> current terrain offset twice
fixed bug in intermediate altitude for DO_REPOSITION with terrain
the Location object does not handle this combination. Throw an internal error and try to cope as best we can
fe91b01 to
9492720
Compare
peterbarker
left a comment
peterbarker
left a comment
There was a problem hiding this comment.
We flight-tested this today
Id like to understand how it was flight tested, and whether there are more cases we want to test. It's not clear from Peter's comment what they tested, and Pete said we want to test each case. Does Peter want us to assume that he tested each case in flight? How do we know if we don't know what was tested. If we have time:
I'm happy to help with any of these in a week. I really like the premise of the PR, but I feel entirely unqualified to approve it without doing any of the above. |
|
@Ryanf55 it has had extensive testing in:
The key cases are:
|
7 participants
introduces a new set_target_altitude_proportion_terrain() which handles the case of a terrain target destination with a source as absolute alt or terrain alt
This also removes (and bans) the use of terrain_alt=1 with relative_alt=0. That combination is not handled by the Location object but was used by plane.
The fundamental problem is that in the Location object, if you have terrain_alt=1 and relative_alt=0 then the get_alt_m() function will get an altitude that is the height of terrain at that location plus the alt field. Plane has always assumed that in this case the altitude is the height of terrain at that location plus the alt field plus the home altitude. This is because we have a rule that when relative_alt=0 we assume that home.alt has been incorporated into the alt field. To square the circle we need to make this combination impossible, which is a major change in the plane code.