I’m doing navigational fine tuning on a sub250g ZOHD Drift and horizontal navigation is excellent in tight spaces.
However the altitude accuracy is poor if the plane glides to a waypoint with lower altitude.
In my case the altitude of a ascending waypoint is hit very well while the descending waypoint gets missed by a couple of meters.
I don’t see any parameter to tweak in particular to compensate and would like to ask for advice.
From my analysis it is the combination of the glide slope TECS.hin that is two-point filtered with TECS_HDEM_TCONST and therefore TECS.hdem follows but cannot reach the waypoint’s altitude target. As seen in the ascending waypoints the jump of TECS.hin converges much better to target altitude.
Jump to the edit, I’m rethinking this and I think you have the basics done already..
I think it’s going to be the balance between PTCH_LIM_MIN_DEG, TECS_SINK_MAX, and AIRSPEED_MAX. The plane looks like it’s following it’s demanded height well, but the demanded height is limited by TECS and can’t reach the requested height (HIN), so there might be some room to increase the sink rate or decrease the pitch limit.
How was the speed of the plane on the descent? Because if it’s hitting it’s max speed that might be further limiting the pitch.
I find descent tuning on something like this (light, no range finder, often no airspeed sensor) to be the most frustrating, because local conditions can just mess it all up. Dialed in one day, but a patch of black dirt on a sunny day and it all changes.
EDIT:
Thinking more and re-reading your situation…
TECS_OPTIONS,2 (allow plane to speed up) or playing with the TECS_HDEM_TCONST might be what you’re looking for.
I’ll check the TECS_OPTION although it does not seem to be used in hdem update but in spdem, maybe an airspeed sensor only feature.
That descent is well within the flight envelope. The plane is accurately tuned to hold 10m/s but measurements are typically all over the place unless it’s calm.
That was about 1m/s wind in the morning, about the only time to get reproducible measurements as I recently have upwind and downwind sections on that field during the day, really annoying.
Some intermediate result, just changing TECS_HDEM_TCONST from 3(default) to 2 makes it follow the glide slope closer but has downsides on the following climb. I was expecting a linear climb but got an immediately climb instead, maybe another altitude bug in ap4.6b5.
EDIT: Turns out to be yet another undocumented feature…
BTW: I went down to 10m to have more vertical distance in the glide slope, but doesn’t do much in the end.
I wonder if there is more low-alt specific code, because there are separate TECS parameters for landing that might work around that (but you need to be in a landing sequence so they won’t be any use wp to wp). The descent from 40 to 10 looks consistent so maybe just go down to 20 or 25 and see how that handles it.
Just me two cents on this - I feel like the arbitrary 20m altitude that changes how the controller acts is bad code (unless documented clearly). IMO if the operator decides to put two waypoints at low altitude where the slope could potentially be in the way of an obstacle - that is their own fault. Rather have the controller act consistently and predictably than try to put in “safeguards” to prevent operator error.
Its far worse then you think. Terrain Follow is another culprit to completely change the altitude behavior. When you approach a WP with terrain alt and switch to RTL, the plane jumps to RTL altitude instead of linear descending which can be a real issue on the video link.
IMO the WP parameters should set if a slope is intended or a jump to the altitude.
I tried several variations and I always end up with ~10-20% too less descent at the wp.
It is likely the two point moving average that follows the slope and therefore cannot reach the target altitude at the WP.
To me it’s a design issue that I can work around by setting a separate WP target for the descent before the turn.
Another session with TECS_HDEM_TCONST=1.0 which in combination with the I-Gain even manages to go below the slope and undershoot the target altitude slightly.
It also leads to some really aggressive moves on climb only limited by TECS_CLIMB_MAX.
BTW: I don’t understand why the slope does not end on the target alt but above that, it seems to be a wrong calc IMO.
The slope line connects the waypoints. When the aircraft comes to the “Acc radius” in front of the target waypoint, it is considered to have reached the target waypoint, and the slope line ends there.
A smaller “Acc radius” would improve this situation.
I agree. We should never have an arbitrary magic number.
Either we should remove this “feature” entirely and stop attempting to protect the user from himself, or we should make this an adjustable parameter. Last relevant commit was long ago, so @tridge is probably best suited to take a look.
My own philosophy (stemming from professional work in this field): sometimes you have to let the pilot do pilot things. You can’t safeguard against everything, and if you try, some well-intentioned safeguards end up with edge cases where they are at best undesirable, and at worst, impact safety of flight. Sometimes you have to just (rhetorically) tell the pilot not to crash and trust he will plan and operate accordingly!
Thanks, much appreciated.
But actually it’s fools luck. I had a facepalm moment realizing that the whole thing converges because of Acc Radius sets the same altitude again for the next waypoint.
Plane flies with 10m/s and at WP_RADIUS 20m it gives the two points within 1.5 seconds for the moving average at target altitude. Otherwise it would not work out the way it does.
