Servers by jDrones

Smart RTL Failure Cause?

(Hayden) #1

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.


This post from January shows the same behavior with no resolution:

(Luís Vale Gonçalves) #2

Thanks

Can you please provide both the log file and the tlog ?

(Hayden) #3

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.

(James Pattison) #4

@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

(rmackay9) #5

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 again for the report.

(Hayden) #6

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.