Copter crash in RTL mode

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…

I plotted the desired yaw (DesYaw)

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?

BR,
Riku

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?

Here is a complete parameter list all in one place.
http://ardupilot.org/copter/docs/parameters.html

Okay thanks. The parameter list does not however seem to describe these logging parameters.

I plotted the RCIN group C1-C4. I think these must be the inputs from the controller. These stop before the copter entered to the RTL mode.

RCIN vs DesYaw:

Hmm, any idea why the copter thinks it needs to spin around CCW?

It’s spinning due to the higher than average value of motor 2.It’s like this all the way through the flight.Maybe a bit of twist on it.Hardware problem I think.

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.

Here’s a discussion on the default settings:

Thanks for the good info!

I’m not using a R/C receiver (don’t actually even own one…). Using only Mavlink to control the copter.

I don’t however quite understand why the yaw behaves differently than pitch or roll. If all RCIN parameters went to zero why only yaw was not controlled by the RTL?

Is it possible to set the values where arducopter defaults to or is there some other workaround to overcome the problem with the yaw?

-Riku

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.

Did you use mission planner or qgroundcontrol?
As far as I know, they use different mavlink control methods and commands, and MP use beyond control to cover rcin. http://mavlink.org/messages/common#RC_CHANNELS_OVERRIDE
But QGC is different, its virtual joystick use another command. http://mavlink.org/messages/common#MANUAL_CONTROL

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.

-Riku

I looked the mode_rtl.cpp

And it seems it checks the copter.failsafe.radio variable in few places and if it is false it reads pilot’s yaw input:

   // process pilot's yaw input
   float target_yaw_rate = 0;
   if (!copter.failsafe.radio) {
    // get pilot's desired yaw rate
       target_yaw_rate = get_pilot_desired_yaw_rate(channel_yaw->get_control_in());
       if (!is_zero(target_yaw_rate)) {
           set_auto_yaw_mode(AUTO_YAW_HOLD);
    }

Can I control this variable with arducopter parameters somehow without changing the source code? So it would be true always?

-Riku


I just have ever use it on ardurover3.2. It works very well. Seems that arducopter also support it. I think it is more safe than beyond control. No matter how, covering rcin is dangerous.

I wonder if this scenario can be modeled in the SITL so it can be repeatable, without having to crash a drone…

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 :slight_smile:

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.:sweat_smile:

I wonder if the RC failsafe didn’t activate since FS_THR_ENABLE=0. You have to set it to 0 to arm the copter without and R/C.

hmm, yes I have set ARMING_CHECK bitmask to exclude RC failsafe. Maybe I can try what happens with the FS_THR_ENABLE. Will it trigger immediately or only when Mavlink rc override stops…

-Riku

If FS_THR_ENABLE is enabled, it will FS when no R/C is detected.

If you have an R/C connected and the telemetry fails and you’re not in guided mode, the telemetry fail safe will not activate since there is an assumption that the R/C can be used to control the bird.

Here is the logic:

There is still an assumption that there is always an R/C, which may not be the case these days. There probably needs to be a discussion with the ardupilot team to flesh out all the edge conditions.