Hi guys,
I need to use my Y6 (APM 2.6; AC 3.1.5) for surveying and need to be able to automate missions, but today my auto mission didn't complete and RTL failed - it was as though the flight mode changed to loiter and ignored RTL signals. I've spent several hours trying to work out what went wrong, but still can't get to the bottom of the multiple failures so I'd really appreciate some input.
I've previously flown successful test missions in Auto mode, which were also designed in MP (V1.3.10) using the Survey(grid) tool. My WP file is attached; I started with a takeoff WP then climbed to the target altitude. WP 2 and 3 should have adjusted the the flight speed and camera triggering distance, and then it should have headed for WP 4. Instead, it just sat at the target altitude above WP1 (as though in loiter). After a few minutes, when it became clear that the copter wasn't going to complete the mission, I tried to initiate RTL (firstly via Ch. 5, then by a Ch. 7 override), but had no effect on the copter so I switched to loiter and landed.
I've got two questions:
(1) Why did the auto mission fail?
(2) Why were the multiple RTL commands ignored?
(I tested the RTL via Ch. 7 a few days ago which worked fine. Subsequent testing shows RTL commands sent from the Tx are received the APM and displayed on the GCS. I thought the most likely explanation was GPS failure had terminated the mission and prevented the RTL, but the copter held position for ~4 minutes in light winds, the sat count was 8-10 and the GPS hdop was <1.80 throughout the entire flight. I don't see why it should matter, but is was ~36 degrees C, and over the coarse of the flight there was ~10 m barro drift.) Reviewing the log (attached) shows the correct flight modes were selected.)
Any guesses?
Replies
I have been having the exact same problem. Thank you for posting the workaround.
You mentioned 10m baro drift. That seems like a lot. Did you check what your altitude was when it was loitering instead of rtl? Also check the log for Ntun DPosX and DPosY to see if it was trying to return to the home coordinates.
@John. I'm afraid I didn't check the that as I was focusing on the other things going awry.
I've just upgraded to AC 3.2_rc10 (beta), and had a couple of flights without observing this - I'll be keeping an eye on it though. Cheers
I just found a nearly identical problem reported on the ArduPilot forum in June; narrowing down the problem to a bug with the ‘DO_CHANGE_SPEED’ command.
From the information on GitHub (#766) and a note on the Wiki, I think the issue might be cause by using the latest MP (v3.1.10) to export commands to an older version of AC (v3.1.5).
It seems AC 3.2 has been modified to use the second parameter field as the new speed value, whereas AC 3.1.5 uses the first parameter field, which is now set to 0 by MP 3.1.10. This would explain the observed problematic behaviours, so tomorrow I’ll try switching the values in the first and second parameter fields and see if this resolves this issue.
That temporary workaround resolved the problem, which won't be present in AC 3.2.