Servers by jDrones

Smart RTL Failure Cause?

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:

Thanks

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

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

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.

Hi, any more info on this? Is SRTL really safe to use?

Hi all, I encountered this problem today as well (albeit on 3.6.12). It looks like a fix hasn’t made it in to master or 4.0.3; @rmackay9 are you able to confirm if your fix https://github.com/rmackay9/rmackay9-ardupilot/tree/smartrtl-semaphore-fix works? I’m willing to give it a try and report back.

Cheers
Jason

This should fix the problem: https://github.com/jasclarke308/ardupilot/commit/c203ad429447d1592633bf1a66b230a2f4100ead

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.

Have to made a pr for the fix?

I have now, see https://github.com/ArduPilot/ardupilot/pull/14420

1 Like

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!

Servers by jDrones