I believe that Smart RTL is almost useless as is. It quickly runs out of buffer space, but this is not the worst part. You usually would want to use Smart RTL when the aircraft looses the signal, and that usually occurs when you fly behind some obstacle, like entering a canyon with steep slopes.
Instead of storing a stream of data points, and then telling that the buffer is full, once the buffer fills up, AP should rather push the old data out and store the new data on top, and the Smart RTL would always be available.
That would allow 99 % of users (except for Rover) to use Smart RTL just to retrace the last few dozens of seconds, and then to continue with normal RTL. That is, the system would follow back the path until all data points are flown, and then switch automatically to RTL.
(I simply set the normal RTL behaviour as climb 100 meters before heading back, that does the same trick (usually, unless you fly behind a Burj Khalifa building), and I disable the Smart RTL.
Basically, any longer flight (my last copter has hover time of 65 minutes, and planes usually 3…4 hours) will bust the point limit. RTL_CLIMB_MIN is set to 100 m in my case.
Did not understand that… The objective of SRTL or RTL is to bring back a vehicle which ran into some problem with control signal.
The problem with long stream of SRTL data is that it could take the aircraft on a very long and winded back jorney…
What I think should be done is to have SRTL just to take the vehicle out of the zone where the signal was presumably obstructed, and that is usually the last 10, 20 seconds at most.
If the signal is not recovered after that that usually means that there is some hardware problem, and the vehicle must continue back, either in SRTL mode or in RTL mode.
So I absolutely DISAGREE WITH YOU THAT STRL SHOULD NOT AUTOMATICALLY SWITCH TO RTL MODE.
The ideal behaviour is a short SRTL loop, with maybe a max of 60 seconds of flight or some 30 points, and then mandatory RTL
SRTL is Smart Return to Launch, it is not “smart seek RC signal” mode. The critical obstacle may be located at any point in the potential return path including closer than proposed SRTL buffer exit point and between said point and between said point and the landing point. In such case the proposed solution will by design fly into the obstacle if link could not be reestablished for example due to hardware malfunction.
SRTL assuming any unchecked (not visited, forgotten etc.) part of the path is safe is inherently unsafe and can lead to a dangerous crash.