mavlink / qgroundcontrol

Cross-platform ground control station for drones (Android, iOS, Mac OS, Linux, Windows)
http://qgroundcontrol.io
3.31k stars 3.63k forks source link

QGC Vistual Stick take control Ardupilot after takeoff 10s #8774

Open bys1123 opened 4 years ago

bys1123 commented 4 years ago

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

bys1123 commented 4 years ago

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

DonLakeFlyer commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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. 461590416077_ pic

wolfling-052 commented 4 years ago

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 commented 4 years ago

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

DonLakeFlyer commented 4 years ago

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 commented 4 years ago

@DonLakeFlyer He used traditional radio controller to takeoff.

bys1123 commented 4 years ago

image

bys1123 commented 4 years ago

image

DonLakeFlyer commented 4 years ago

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 commented 4 years ago

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

bys1123 commented 4 years ago

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 commented 4 years ago

image

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

DonLakeFlyer commented 4 years ago

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 commented 4 years ago

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

peterbarker commented 4 years ago

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:

image

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

DonLakeFlyer commented 4 years ago

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 commented 4 years ago

@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

None of these are easy stories to tell users.

bys1123 commented 4 years ago

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

DonLakeFlyer commented 4 years ago

@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 commented 4 years ago

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).