This is my first copter and first time flying. I’m flying with gamepad over 4G. The computer I was using as CGS died due the cold weather and the copter went to FAILSAFE_CGS and to RTL mode as it should. RTL mode however caused copter to immediately start spinning very fast and a crash.
Can you guys help me to understand what went wrong with the RTL?
Hardware= Quadcopter with Raspberry Pi and Navio Hat, control over Mavlink
Arducopter firmware: V3.5.2
I cannot view your logs at the moment because i’m at work, but i’m going to make a suggestion so you can look at the parameters in the log. Since you were flying over MAVLink using a game controller, perhaps when it went into RTL due to loss of comms with the computer, it kept the last controller input in memory and continued to act upon it. When in RTL, you can still override the controls using a controller while it is coming in. There is a chance that is what was happening. I’m not sure how MavLink handles the “last user input” when it suddenly loses signal.
Hmm, well your explanation sounds logical compared how it behaved. But keep repeating the last input received when missing the whole communication channel (heartbeat) does not sound like desired behavior…
Does it mean that it thinks that this is the user input even it has lost the connection to CGS and it is overriding the “autopilot”? Where would the inputs generated by the “autopilot” when flying in RTL show up?
someone smarter with all the parameters would have to answer that…sorry. I would imagine all the modes (auto/manual) would use the same common parameter, eventually. So, for example if I’m in RTL, I can still input all 3-axes on my controller and it’ll do what i say, but when i let go the sticks, it returns to doing it’s auto thing. My guess is my inputs eventually get into the “desired” parameters, regardless of the mode I’m in, and their weighting are influenced by the mode.
By the way, lookng at the graph, DesYaw is in Units Degrees. Which means this is the Desired Direction of the Quad. This isn’t showing the actual Yaw inputs. It does indicate that at RTL the quad’s desired yaw was spinning around the 360 degrees in a counter-clockwise (as seen from the ground) direction. So right stick input?
Was your R/C turned on? What kind of R/C receiver do you use on the copter?
From the log below, all R/C inputs went from trim values to 0 at the FS. This behavior has caused much havoc in the past with my copters as well if I had the R/C turned off and didn’t override all inputs and I was using the Spektrum satellite receiver that doesn’t remember the trimmed radio settings. Ideally, Arducopter would default to trim values rather than 0 when there is no input from R/C overrides or from the R/C receiver itself. Defaulting to 0 is catastrophic. The RTL took over the pitch and roll control, but yaw defaulted to 0, which led to a maximum yaw rate command.
It’s probably because during RTL, the copter (at least my quad) flies in a “headless mode” back to the home point so the FC is processing a “desired track angle” which doesn’t necessitate yawing the vehicle. And with rrr6399’s observations, if you’re flying without an R/C then you are in a perfect storm of a system that has set the Yaw to “full” in that direction since there was no R/C to give it the “middle” value. Even if you had a really good headless mode, it would have little chance of guiding the quad when spinning that fast.
Pitch and Roll don’t require any external input since the RTL flight mode is controlling those to get home. Yaw is not controlled so that the pilot can rotate the copter while in loiter (and most other flight modes).
Without modifying the firmware, the only way I know of to prevent this is to add an AR8000 receiver (or equivalent) to the Pixhawk that sends the trim settings continuously.
I’ll take a look at the source code to see if there are other options. I’m a little perplexed as to why the manual overrides dropped to 0 since your GCS just died and didn’t likely have any chance to send a clear manual overrides command. Maybe the firmware resets the overrides if there is a GCS FS, which would be probably the wrong thing to do when there is no R/C.
Okay, thanks guys for explaining the RTL’s role to yaw.
BTW, I’m not using Pixhawk. I’m running Arducopter on Raspberry PI with Navio2 hat. If that affects to the RC input behaviour. Maybe there is something that could be than on that side also to emulate 1500 input for Arducopter even if there is no real input.
I think with zero value for RCIN Arducopter should detect that there is no input from receiver and stop interpreting the input. But that seems not to be the case. Maybe it’s possible to modify the source code and hard code the 1500 “middle value” as a constant somewhere? I my case it does not even matter if that breaks the possibility to use a R/C receiver.
And for the CGS question, I’m using APM planner 2.0. Qgroundcontrol uses the MANUAL_CONTROL messages as you said but those messages are not supported by the Arducopter.
Oh okay! I was just looking for manual_control but did not find it for some reason… It seems that it is added already one year ago to the copter also. Thanks for clearing that out. I have to try it. Not related to the RTL issue however, I think
Yes, I actually just found out about the SITL and I was planning to try to simulate this. Not sure however is it possible to repeat this in the simulator, if the simulator software handles the R/C inputs differently than my real hardware…
I think the problem is that when your GCS crash, and when you use override control. The copter.failsafe.radio has not been set to 1.
It looks more like a bug.
FC knows the GCS_failsafe, so it RTL. But it judge the radio_failsafe rather than GCS_failsafe, so it thinks the pilot still control yaw.