As has been discussed before (Terrain following question - #19 by Webillo), the transition down into Terrain altitude from absolute or relative altitude waypoints can be a little tricky - basically, you have to be within rangefinder range, otherwise, you’ll get a terrain failsafe and an RTL.
This doesn’t seem too bad (just make sure the last non-terrain altitude waypoint is within rangefinder range), unless you’ve accumulated barometer drift, and are running a relatively short-range rangefinder - when trying to get in the AGL ‘bucket’, controlled flight into terrain (CFIT) becomes a very real possibility. For me, this crops up more than one might expect, since I prefer not to do long vertical descents when landing (vortex ring state, etc.), instead, shooting a translating approach to about 4-5 ft. AGL, and then landing from there. Obviously, barometer drift can easily eat up 4 ft., and there’s no native TCAS (terrain collision avoidance system) option to guard against CFIT.
I’ve been playing around with Lua scripts that work around this, using a few different methods:
(1) When the current WP is Relative, and the next WP is Terrain, watch the AGL reading. When it approaches the target terrain WP height, jump to the next WP - you’re within rangefinder range, so there’s no chance of a terrain failsafe. This works great, except the waypoint jump produces a very abrupt stop/start, which is less than ideal.
(2) When descending to a WP (Terrain WP or not), watch the AGL reading. If AGL falls below a threshold, update the current WP altitude to equal the current vehicle altitude, arresting the descent before CFIT, without ever actually using a Terrain WP. Effectively a very simple/limited TCAS. This also works quite well, but shares the problem with (1) - when the waypoint is modified, the aircraft does some rather abrupt speed/attitude changes.
(3) When descending (Terrain WP or not), watch the AGL reading. If AGL falls below a threshold, modify the BARO_ALT_OFFSET, to force an agree between the home altitude (zero) and the measured AGL - thus preventing CFIT, assuming the WP altitude isn’t negative. This is kludgy barometer drift compensation, and makes some assumptions I don’t much care for (takeoff and landing occur at the same altitude, relatively level terrain, etc.), and since BARO_ALT_OFFSET is blended in over time, it isn’t particularly responsive; however, it does avoid any abrupt maneuvers, while allowing ‘guarded’ non-terrain approaches to within rangefinder ranges.
I can post the scripts if anyone is interested, they’re not perfect, but have been flight-tested on real hardware, etc. I’ve found (2) to actually be quite practical at preventing accidents when shooting low landing approaches, but when it intervenes, it definitely isn’t a nice smooth S-curve maneuver, haha.
Anyway, all that to provide the background for three questions:
(a) Is there any way to perform Lua flight plan jumps, modifications or altitude setpoint injections without the abrupt stop-start in the AUTO trajectory? (I suspect not, but no harm in asking.)
(b) Rather than an automatic RTL on a terrain failsafe due to AGL being out-of-range, might a future version permit a “continue” option, much like we already have for battery failsafe, GCS failsafe, etc? Say you were at 50 ft. on a relative altitude WP (and above rangefinder range) - the next waypoint is a Terrain WP at 10 ft… Rather than a failsafe and RTL, I’d like to descend towards the 10 ft. Terrain WP (effectively treating it like a relative altitude WP), until valid AGL data is available, and then continue flying with reference to terrain. Intuitively, this should be reasonably safe, since AGL data will always be available before CFIT. (Barring cliffs, etc., which the current system doesn’t work well with anyway.)
(c) If (b) is impractical/untenable, perhaps a very basic TCAS provision would be an option? (i.e. “In AUTO, never descend below x meters AGL, regardless of waypoint type, except for landing”.) I can’t think of any case where it would be desirable to descend into terrain, other than when landing. This would be very similar to script approach (2) above, but presumably with proper trajectory blends.