PX4
RTL params: increase max of RTL_RETURN_ALT and improve description
It's completely valid to have a RTL_RETURN_ALT of much higher than the current 150m, so I increased it to 1000 here. E.g. for a vehicle flying in hilly/mountainous terrain you would want to set RTL_RETURN_ALT above the highest terrain in the flight area (relative to Home or the safe landing spot defined).
@sfuhrer this is a "relative" alt right? one reason the 150m may have been there before is regulations. we may want to try and switch a lot of this kind of logic to AGL. (though this requires DEM).
@sfuhrer this is a "relative" alt right? one reason the 150m may have been there before is regulations. we may want to try and switch a lot of this kind of logic to AGL. (though this requires DEM).
It's "relative to the landing destination". I tried making it a bit clearer by adapting the param description. As the regulations are usually limiting the flight altitude above terrain a proper terrain following RTL would help there, but for now with the current basic RTL that just climbs to a fixed altitude we can't limit it.
if we don't put a maximum for the regulation -- then would it make sense just to omit the maximum from the description? as any arbitrarily large number doesnt break anything in the code. This was the original reason for revising these parameters right? that limits are set to constrain anything that breaks things, but not to force the user to our conception of a "reasonable" value? (the latter to go into documentation)
if we don't put a maximum for the regulation -- then would it make sense just to omit the maximum from the description? as any arbitrarily large number doesnt break anything in the code. This was the original reason for revising these parameters right? that limits are set to constrain anything that breaks things, but not to force the user to our conception of a "reasonable" value? (the latter to go into documentation)
Fair point. I'm usually all in favor of only constraining only where needed to avoid known issues, not to "reasonably values for 99.99% of the cases". Let's start with something here: bbbbf20ae75fb040e6d734be0165d7a6de85fb4d
not to "reasonably values for 99.99% of the cases"
I'm more on the constraining side for safety/dummy proofness. I'd prefer to use an autopilot which when I accidentally set the RTL altitude to be 10000km warns me that this is not a common thing to do. That's e.g. also why there's a maximum radius for the Orbit and so on. It should not prevent any use cases but if possible warn me before I accidentally do something really bad since I'm working with safety critical systems.
I'm more on the constraining side for safety/dummy proofness. I'd prefer to use an autopilot which when I accidentally set the RTL altitude to be 10000km warns me that this is not a common thing to do. That's e.g. also why there's a maximum radius for the Orbit and so on. It should not prevent any use cases but if possible warn me before I accidentally do something really bad since I'm working with safety critical systems.
I think it will just be very hard to find constraints that are dummy proof and still cover all possible flights scenarios. And for me the "force save" option is not a viable option for end users, and thus shouldn't be exposed to them. Thus for me the only viable way is to open up the constraints to cover all possible scenarios.