Please see https://drive.google.com/file/d/1FqMXyeUxchS2Cz6tPr9zRvX3GseMFpB_/view?usp=sharing
The plane started to fly sideways in a futile attempt to navigate to cancel drift during takeoff. (most likely caused by a cable moving lose to the magnetometer)
I also doubt that ARMING_CHECK=1 would have prevented it (?)
(Of course, the pilot could easily have saved the day)
@rmackay9 - you demonstrated a very robust handling of compass errors on Copter, which AFAIK is not in any release yet… I guess that could save the day.
Hi Andre,
Yes, flying with ARMING_CHECK set to 0 is a bad choice. However, something changed on channel 8 to invoke QLOITER mode and then resume back to AUTO mode. Was the QLOITER mode done via the R/C transmitter? And then back to AUTO mode by the GCS?
ARMING_CHECK,0
This was an automatic takeoff, as it went bad, the RC pilot in desperation switched to QLOITER, then AUTO.
Yes, QHOVER or QSTABILIZE would totally save the day, this is an event that will most likely be repeated by others, and I hoped that @rmackay9 had some ideas on how it could be handled (automatically)
Yes, Copter/Plane/Rover-4.1 will include GSF which automatically detects a bad heading and resets the yaw although it still takes a few seconds. We hope to start beta testing 4.1 in 4 to 6 weeks although we still have some important developments to get in on the Copter side at least. I suspect Plane will start beta testing before Copter but that’s up to Tridge of course.
Thanks, @rmackay9 how confident are tiy that GSF would have saved the day in this case ?
The lateral speed seems to me to enable GSF to get some data to work with - I am less sure what would have happened if it got much higher before drifting off (hance had longer time while the bad compass data apparently converged with reality) - is GSF always ready to act in any step of the flight, and as many times as needed ?
The GSF init procedure with walking the circle would never happen, but it seems to me that the long drift could provide decent data.