ArduPlane Terrain Following not functional in Guided mode

[iNotMario]

Issue details

It appears that the terrain following functionality does not actually follow the Terrain in either Guided or Circle modes.
All terrain blocks are loaded, none pending.
It works perfectly in Cruise, FBW-B, Loiter, QRTL, RTL Modes.

SITL Command:
sim_vehicle.py -v Plane -f quadplane

GCS: QGroundControl

Please see this discussion for other reports:
https://discuss.ardupilot.org/t/terrain-follow-in-guided-mode/91703/16

Version
4.5.1
Probably Earlier

Platform
[ ] All
[ ] AntennaTracker
[ ] Copter
[X] Plane
[ ] Rover
[ ] Submarine

Airframe type
QuadPlane (QuadRotor VTOL)

Hardware type
SITL, CUAV-X7

Logs
My Current log is 1GB+. I will do a more concise simulation and upload for your viewing pleasure.

[iNotMario]

Log Attached... you must bunzip2 it. It's actually a .bin. Or just use SITL ... i can't get it to work under any circumstances - except for a different mode.
log_7_2024-5-2-14-59-12.bin.bz2.log

[LupusTheCanine]

Circle is a non-gps mode therefore it cannot provide terrain following.

[iNotMario]

Circle is a non-gps mode therefore it cannot provide terrain following.

Boy, it sure could fool me - it holds the path like it's laser guided. Anyway, that being the case, we could just ignore that part of the issue.

I definitely think it's an issue that guided mode doesn't honor it. Unfortunately, i suspect there are some seriously complicating factors involving the GCS softwares and how the target coordinates are specified, but it seems to me this is an issue that could cause some costly disasters - and it's worth figuring out a way to deal with it.

[Ryanf55]

According to this documentation, GUIDED should support terrain following:
https://ardupilot.org/plane/docs/common-terrain-following.html#terrain-following-flight-modes

Did you enable bit 6 of TERRAIN_FOLLOW?

It would help if you could give us the steps to reproduce this in SITL.

[rmackay9]

@iNotMario, I'm not a Plane expert but I think @LupusTheCanine's comment may not be correct. I'm pretty sure that Circle mode (on plane) uses a GPS if present. It probably also works while deadreckoning but if a GPS is present surely it uses it.

[Ryanf55]

@iNotMario, I'm not a Plane expert but I think @LupusTheCanine's comment may not be correct. I'm pretty sure that Circle mode (on plane) uses a GPS if present. It probably also works while deadreckoning but if a GPS is present surely it uses it.

According to the wiki, terrain following is not supported in Circle mode.

[iNotMario]

According to this documentation, GUIDED should support terrain following: https://ardupilot.org/plane/docs/common-terrain-following.html#terrain-following-flight-modes

Did you enable bit 6 of TERRAIN_FOLLOW?
Both bit 0 (all) and bit 6 have been tried.

It would help if you could give us the steps to reproduce this in SITL.
Well honestly, there's not much to describe, but here's a basic set of steps:

1. Have Ardupilot Dev Environment (My environment is Fedora, which probably noone here is using, so set it up per the wiki)
2. $ sim_vehicle.py -v ArduPlane -f quadplane -w
3. Use your preferred GCS to Connect and Set:
   3a) TERRAIN_ENABLE=1
   3b) TERRAIN_FOLLOW=1
4. Wait for Terrain Download (Use your GCS to view the terrain block information if desired)
5. QLOITER to an altitude of 100ft.
6. Set a waypoint on the far side of Mount Jerrabomberra, and execute.
7. Plane should switch to Guided, Transition to Fixed Wing and crash directly into mountain. You can also monitor Alt Above Terrain with your GCS. Watch it slowly go to 0 - it doesn't react to it

Also, for the record re. Circle mode.
CIRCLE is bit 8 in TERRAIN_FOLLOW. Whether it's supposed to work or not, it is nevertheless listed.
QLand is bit 10 ... \o.O/ ... perhaps this param was a bit eager-beavered.

[Ryanf55]

Which GCS did you test with? The MAVLink message may be using AMSL instead of AGL altitude.

[iNotMario]

QGroundControl ... However, notably, others have had issues with Mission Planner (see discussion linked in OP).
I can't seem to find any way to change that. But assuming it is sending AMSL, is it really correct to ignore the TERRAIN_FOLLOW flag? After all, i presume the AMSL would be of the destination, not of the path there, so why not follow the terrain until reaching the target at the specified AMSL?

The first thing that comes to mind is to [when TERRAIN_FOLLOW] simply convert the destination to AGL by subtracting the terrain height at that location - then executing as AGL. That would allow terrain following while still honoring the target height.
Of course, right away i find myself wondering how to handle a destination that didn't yet have terrain data - but i think that would be pretty far away...

[Ryanf55]

QGroundControl ... However, notably, others have had issues with Mission Planner (see discussion linked in OP). I can't seem to find any way to change that. But assuming it is sending AMSL, is it really correct to ignore the TERRAIN_FOLLOW flag? After all, i presume the AMSL would be of the destination, not of the path there, so why not follow the terrain until reaching the target at the specified AMSL?

The first thing that comes to mind is to [when TERRAIN_FOLLOW] simply convert the destination to AGL by subtracting the terrain height at that location - then executing as AGL. That would allow terrain following while still honoring the target height. Of course, right away i find myself wondering how to handle a destination that didn't yet have terrain data - but i think that would be pretty far away...

As with many things in MAVLink and guided mode, certain cases like this becomes ambiguous on what the "right" behavior is. Whether or not it should do something is ultimately up to what the docs say, and the docs don't seem to specify.

The best near term action is to reproduce this in SITL to confirm the behavior, then perhaps go speak with the MAVLink maintains to ask for what the expected behavior is. Last thing we want is for people to crash into terrain, but the AMSL guided command may intended to be taken as-is and ignore terrain. In this case, clear documentation, and perhaps some warnings in the GCS, could reduce the risk of a crash.

[iNotMario]

So i believe the mavlink specs are defined here:
https://mavlink.io/en/messages/common.html#MAV_FRAME

From the docs, it appears to not actually say anything about the means of getting there, only the coordinate system of the destination - no matter which system is specified. I would infer this means it's specifying something only about the destination - not about the path that Plane takes to get there - and perhaps that's where the decision rests in Plane's hands.

It looks to me like the current behavior for AGL is, itself, a presumption. (A good one, IMO) If we decide that's true, then i think we should apply the assumption to the other "frames", too.

I will do a little digging into QGC and see what it's sending. You're probably right that it's not specifying AGL, i suspect 0 (AMSL) by default, but that's just a guess for now.

[Ryanf55]

Thanks. I just tried mavproxy and observed that terrain following works ok with the "Fly to" right click until you fly so fast, it can't get terrain. Rather than abort the flight, it just doesn't load the data and then crashes into terrain.

./Tools/autotest/sim_vehicle.py -v Plane --console --map
graph TERRAIN_REPORT.current_height
param set TERRAIN_FOLLOW 1
mode takeoff
arm throttle

RIght click on the map west of CMAC, and click "Fly to". Enter the altitude. Note - this popup does NOT display the datum.

And, watch the plane's MSL altitude in the GUI console and watch the AGL graph. It's not flying MSL direct, it does try to follow terrain, just not well or optimal efficiency.

[iNotMario]

In my case with QGC, all terrain shows as loaded, and i can watch Alt-Above-Terrain drop towards 0 with no change in AMSL. AKA, Blocks Pending = 0, it still doesn't follow the terrain.

It's not clear to me exactly, but is it that you're using --map to do the "fly to"? I've never used that option before. I will try and see how it reacts with QGC also feeding it terrain data.

[Ryanf55]

How are you sending the guided command from QGC? With fly to, I can only fly 3000' horizontally, and mountains are far away

[iNotMario]

QGC has an option in the Application settings for Max distance. "Fly View" -> "Guided Commands" -> "Go to Location Max Distance" (The exact path varies significantly with different versions, i'm describing recent Daily builds)

Mt Jerrabomberra is WSW of the default SITL airport. It's actually pretty close. It's not a very big mountain - but it doesn't need to be.
Edit: My perspective on distance is a probably a bit warped. The mountain is about 3 miles away, so either step your way there with several waypoints, or modify the Max Distance in QGC - which in my case was already set for more than 3 miles.

[davidbuzz]

ArduPilot/MissionPlanner#3294

[tridge]

@Ryanf55 in newer mavproxy you can do this:

 set flytoframe AGL

and guided requests will be AGL. This is needed to get GUIDED mode terrain following
We really need this in MissionPlanner as a drop-down (and QGC).
MissionPlanner issue here: ArduPilot/MissionPlanner#3294

[IamPete1]

Looking in the MAVC log message we can see the commands coming in with absolute altitude of 675m.

QGC needs to send a in terrain frame.