Hello, I was testing Smart RTL along a relatively straight flight path by flying out about 2 miles in auto mode and returning in SRTL. Shortly after switching Smart RTL at the far point, the aircraft abruptly stopped and began descending. No flight mode change or error was shown in MP at this point. I switched into loiter mode and brought it back manually.
Upon reviewing the log, I noticed that SRTL.Action switched to state 5 at the exact moment the descent started. I have a dozen other identical flights that worked fine and never went to state 5. From what I see in the source, it looks like 5 refers to “SRTL_POP_FAILED_NO_SEMAPHORE”, and landing is the desired action in this case, but the comment also says “this can only happen if we fail to get the semaphore which should never happen but just in case, land”
Anyone know what could cause this case, and hopefully how to prevent it in the future? Landing two miles away in this case would have been dangerous, so fortunately we were closely monitoring it and recovered the aircraft.
Hi LuĂs, I cannot post the log files unfortunately. However I have thoroughly reviewed the logs and identified what happened in flight which is why I’m asking about the code itself and not the flight. If any specific screenshots would help I can provide those.
@hjpernia plot.dron.ee has an option to randomise localisation data on log upload. That might be worth considering regarding being able to share a log. @rmackay9 and @khancyr might be able to shed some light on the behaviour, but without the log it would be speculation
Thanks for the report, I’ve added an issue here which includes some advice on how we could resolve this. In short, it seems like a bug… We were not expecting that getting the semaphore would ever fail because the background thread should have already completed it’s calculations on the return path.
If we can fix it in the very short-term we can back port it to Copter-3.6 but failing that I hope/expect we can fix this for Copter-3.7 that will begin beta testing in a few weeks or as soon as we can get support for no-fly-zones completed. Not saying that we will have a fix in a few weeks, but hopefully before Copter-3.7 goes live at least.
Thanks for the quick reply and opening the issue for this! Is there any chance this could be hardware related like a memory read/write issue or is it strictly software? We will definitely continue testing with SRTL and I’ll gladly provide any information that would help debugging.
This code now allows for indefinite attempts at getting the next waypoint (if one exists) instead of landing. The drone will just wait at the current waypoint.
I’ve tested this and so far it has worked. It took about 12 test flights before I encountered the “SRTL_POP_FAILED_NO_SEMAPHORE” message again, but I can confirm that this time the drone didn’t land and did get the next available waypoint.
We’ve got a fix for this in master now so it will go out with Copter-4.0.6 assuming there is one. Failing that it will go out with Copter-4.1. Thanks very much to @jasclarke308 for digging into this!
