QGC Vistual Stick take control Ardupilot after takeoff 10s

[bys1123]

QGC Vistual Stick take control Ardupilot after takeoff 10s makes drone full speed flight backwards and hit the pilot.

This maybe mostly the pilot's mistake but I think if ArduPilot wouldn't disarm or QGC wouldn't take control especially after 10 seconds that will give more safety and prevent this unsafety happen.

Firmware: Ardupilot
OS: MacOS
Log: 2020-05-24 16-08-59.zip

Vistual Stick looks like this on MacOS, no auto-center, but the pilot forgot it:

[bys1123]

tlog playback: https://youtu.be/bHAEzjJyW0k

[DonLakeFlyer]

Hmm, haven't look at virtual joystick in ages. I believe the right stick it supposed to auto-center though. So when you let you it should go back to neutral. I'll take a look at what is going on there. I think the auto-center is broken.

[DonLakeFlyer]

No, the right stick doesn't auto-center. Only the left stick yaw auto-centers. Trying to remember why. I think it relates to fixed wing versus multi-rotor usage. I think it makes sense to have a setting to auto-center the right stick in both axes. That setting should default to on. Does that make sense?

[bys1123]

Thanks for reply. The most important part that I'm wondering is why it take control the drone from RC after takeoff few seconds. This could make lots of troubles,
And the doc said it only can control PX4.

[DonLakeFlyer]

The most important part that I'm wondering is why it take control the drone from RC after takeoff few seconds. This could make lots of troubles,
And the doc said it only can control PX4.

ArduPilot added support for the mavlink MANUAL_CONTROL message a while back which means that joystick both real and virtual are now supported. The docs are out of date. As to why there is a delay, I don't know. Could be some ArduPilot quirk/bug. I can do some SITL testing to verify.

[DonLakeFlyer]

I believe the right stick it supposed to auto-center though.

The auto-center support was broken in the 4.0 code. It's supposed to do this all the time.

[wolfling-052]

The most important part that I'm wondering is why it take control the drone from RC after takeoff few seconds. This could make lots of troubles,
And the doc said it only can control PX4.

ArduPilot added support for the mavlink MANUAL_CONTROL message a while back which means that joystick both real and virtual are now supported. The docs are out of date. As to why there is a delay, I don't know. Could be some ArduPilot quirk/bug. I can do some SITL testing to verify.

I'm sorry that I was the person who had the accident. This time my aircraft was just manually unlocked using RC and flew up. 10 seconds after take-off, the aircraft suddenly came to me out of control and injured my right hand. This is a serious problem.

[wolfling-052]

The most important part that I'm wondering is why it take control the drone from RC after takeoff few seconds. This could make lots of troubles,
And the doc said it only can control PX4.

ArduPilot added support for the mavlink MANUAL_CONTROL message a while back which means that joystick both real and virtual are now supported. The docs are out of date. As to why there is a delay, I don't know. Could be some ArduPilot quirk/bug. I can do some SITL testing to verify.

After I analyzed the aircraft log files, it was determined that QGC took control of my RC after ten seconds.

[bys1123]

@wolfling-052 sorry for that happen, but it could be an Ardupilot bug. QGC just send the mavlink message nothing hacks.

[DonLakeFlyer]

As to why there is a 10 second delay I don't know yet. The bug is that the right virtual stick doesn't auto-center. So it starts out in the full down position which is pitch back. Very sorry for the bug. It's been fixed and will show up in stable/daily soon.

it was determined that QGC took control of my RC after ten seconds.

How did you determine that it only took control only after 10 seconds? With virtual joystick on, it should have happened right away. Did you takeoff using the guided ui controls or did you takeoff using the virtual joystick?

[bys1123]

@DonLakeFlyer He used traditional radio controller to takeoff.

[bys1123]

[bys1123]

[DonLakeFlyer]

He used traditional radio controller to takeoff.

Hmm. I think PX4 disallows MANUAL_CONTROL is there is an RC connected as well. I'd have to check.

[bys1123]

@DonLakeFlyer Thanks, just did a quick search. Through this PR, looks the MANUAL_CONTROL in ardupilot still have bugs: ArduPilot/ardupilot#14390

[bys1123]

https://github.com/ArduPilot/ardupilot/pull/14390/files#diff-560274335543b120cc223a5f60cd21e0L71
I guess the reason that Virtual Stick takes control because of he moved all RC sticks to center, then Virtual stick override the control.

[peterbarker]

I believe that discontinuity is where takeoff takeover occured.

The second graph there shows the incoming packet rate to the autopilot. I think it reasonable to assume those are MANUAL_CONTROL or RC_OVERRIDE packets starting to come in?

Could we grab the tlog, please - rather than a playback?

[DonLakeFlyer]

Was the virtual joystick turned on already before connecting to the vehicle. Or was it turned on while the vehicle was in the air?

[wolfling-052]

Was the virtual joystick turned on already before connecting to the vehicle. Or was it turned on while the vehicle was in the air?

Hello, I enabled the virtual joystick after opening QGC.

[wolfling-052]

Was the virtual joystick turned on already before connecting to the vehicle. Or was it turned on while the vehicle was in the air?

The virtual joystick is always on

[bys1123]

2020-05-24 20-17-50.zip
@peterbarker Thanks, tlog is here.

[DonLakeFlyer]

So I can see from the tlog that QGC started sending MANUAL_CONTROL messages to the vehicle immediately. If that is the case then how come the RC was allowed to take control? I thought MANUAL_CONTROL would take precedence?

[DonLakeFlyer]

Double-checked again and MANUAL_CONTROL is being sent to Vehicle as soon as the connection starts.

[peterbarker]

Best I have so far is that the autopilot doesn't appear to have been receiving messages from the GCS , despite the tlog clearly showing continuous manual_control messages.

This is from the onboard log:

no messages... and then we start to receive messages and everything goes to hell.

[DonLakeFlyer]

Hmm, ok. So other than the right stick centering problem. I'm not seeing anything else wrong from the QGC side. The one thing though is that although unrelated to this specific problem it seems unsafe to be able to turn on virtual joystick while the vehicle is already armed. It could be in the air and cause badness.

[peterbarker]

@DonLakeFlyer yeah, this is a nasty one. And yes, perhaps requiring the user to specify they want to use the virtual joystick before arming would be good.

@bys1123 - is your machine in a state that you can thoroughly test the telemetry on it? It's possible this link was asymmetric - packets arriving from the vehicle but not not arriving at the vehicle. It looks like you may have been using some sort of non-SiK radio telemetry here - esp8266 or similar? Could you describe that system, please?

There are some things we could consider doing on the ArduPilot side.

The second is as @bys1123 to turn on GCS failsafe; if I'm correct that packets weren't getting through then that should have triggered before bad stuff happened

The third is that we could consider becoming much more strict under what conditions we might accept manual (and perhaps RC override) messages. So, for example

• we could have a parameter to enable them
• when enabled we must see them within trim values, or within a deadzone of the current RC inputs before we start to accept them
• we could not accept manual_control messages unless there's no RC input (RC failsafe or never seen a receiver), or that RC input is inactive (within deadzones on rpy). This is fraught - you could end up with significant changes in control input when switching back from MANUAL_CONTROL to RC input
• if an RC receiver is present before arming then we could require the RC channel option 46:RC Override Enable be present and on a switch before arming

None of these are easy stories to tell users.

[bys1123]

The pilot @wolfling-052 is using CUAV Wifi Telemetry.

[DonLakeFlyer]

@peterbarker To me, the concept of allowing both RC and joystick style input at the same time with some sort of internal mechanism as to when one is in control over the other is fraught with danger. I can see where that could be useful in some edge cases, but in most cases it just seems wrong. Which leads me to think it's safer to make this be off by default, with some sort of parameter setting or something to allow it.

[auturgy]

Agreed re mixing MAVLINK and RC Control - some thought into how to harden it is warranted, although the "edge case" is quite common - it is not unusual for aircraft where the control station is physically separate from the launch/recovery site to have a separate pilot with RC control for takeoff and landing. This use case needs to be preserved.
In this particular incident, I would not be surprised if the CUAV WiFi telemetry module is contributory - the firmware they ship with uses TCP, rather than UDP. This can cause out of order and late arrivals, and should never be used for MANUAL_CONTROL or RC_OVERRIDE. MAVESP firmware is available (here https://github.com/dogmaphobic/mavesp8266 or https://github.com/ArduPilot/mavesp8266) which can be flashed to the module, is widely tested and uses UDP.
(edit: Clarification - seems at least some CUAV wifi modules now ship with a UDP firmware, so that needs to be clarified with the user. The one I have arrived using TCP, so I reflashed it with MAVESP8266 firmware).