Loss of MAVLink transmission when enabling joystick

[MaEtUgR]

Expected Behavior

Gamepad style joystick when calibrated and activated provides manual control stick input to the autopilot and doesn't interfere with other functionality.

Current Behavior

When I have a Joystick (Microsoft XBox 360 controller I'm always using) connected, calibrated (tried recalibration) and activated (doesn't happen when the gamepad is connected but the checkbox is off since QGC start) that MAVLink transmission stops working. As soon as I'm once in this state no command gets sent anymore (I tried mode switch, parameter request, reboot, arm), MAVLink shell doesn't react anymore and when I start QGC in this state the "Vehicle 1 did not react to parameter request" message gets shown. Only solved by unplugging or disabling the joystick device and restarting QGC.

• The onscreen virtual joystick does not suffer from this

Steps to Reproduce:

1. Plug USB gamepad that was not configured in QGC before
2. Start QGC
3. Plug pixhawk autopilot to computer
4. See autopilot connected and everything (MAVLink commands) working
5. Calibrate and enable joystick
6. Get stuck in a state where no commands are sent to the autopilot anymore, telemetry still shows

System Information

• Operating System: Verified the same behavior on Windows 10 and Manjaro Linux VM

• QGC Version:
  

• QGC build: Downloaded from https://docs.qgroundcontrol.com/master/en/releases/daily_builds.html

• Flight Controller: Pixhawk 4 mini

• Autopilot (with version): PX4 latest master (PX4/PX4-Autopilot@979243f)

Misc Context

I was testing calibration and noticed I have manual control lost at the end of every calibration: PX4/PX4-Autopilot#15235 (comment) and wanted to check if with a real instead of virtual joystick I'll have the same problem.

[MaEtUgR]

I checked again on latest QGC daily:

And it still has the issue.

[DonLakeFlyer]

Does that happen on SITL as well? Would be way easier to debug there.

[BrummbQ]

I can confirm this issue. How can I test it on SITL?

[DonLakeFlyer]

The PX4 Dev guide has instructions on how to setup and use PX4 SITL.

[MaEtUgR]

I remember explicitly testing against SITL and not seeing the issue. I could repeat the test to make sure you're not trying to reproduce something that already got fixed. Presumably, there were some changes in USB communication.

[qbazd]

Hi, stumbled on something pretty similar.

My research found that no matter of PX4 version (1.10.x, 1.11.x, on Pixhawk 2 Clone and Holybro Kakute F7) and QGC (stable or daily, windows or linux version - todays downloads).
PX4 connected trough USB /dev/ttyACMX serial device (auto or defined connection).
It looks like some of output msgs gets not send after enabling Joystick, even virtual.
FC parametars won't update, Plan can't update mission to FC, nsh don't work.
But FC is sending normal set of msgs, HUD and other statuses work.

But when using UDP communication:
QGC -(UDP)- MavProxy or mavlink-routerd -(ACM)- PX4
It seams to work OK.

[patrickelectric]

Maybe it's related to #9484

[hknaio]

Hi Everyone

I have encountered too that issue with same configuration (QGC V4.1.1 Stable). I realized that it is related to new approach writeBytesThreadSafe function in LinkInterface. When Joystick connect to QGC, a new QThread starts. Then it begans to send manual control messages using SerialLink. After Joystick Thread use the QSerialPort::write function, sending mavlink messages stopped and The Link behaves like High Latency Link. I think it is about to thread safety or thread affinity somehow. Because of this, undesired behaivour is emerging. On SITL with UDP Link , there is no issue.

There was no problem in old versions of QGC (for example V3.5). I changed the function with old version writeBytes function then it worked correctly.

I hope it helps.

[Dule-sat]

Hi Everyone

I have encountered too that issue with same configuration (QGC V4.1.1 Stable). I realized that it is related to new approach writeBytesThreadSafe function in LinkInterface. When Joystick connect to QGC, a new QThread starts. Then it begans to send manual control messages using SerialLink. After Joystick Thread use the QSerialPort::write function, sending mavlink messages stopped and The Link behaves like High Latency Link. I think it is about to thread safety or thread affinity somehow. Because of this, undesired behaivour is emerging. On SITL with UDP Link , there is no issue.

There was no problem in old versions of QGC (for example V3.5). I changed the function with old version writeBytes function then it worked correctly.

I hope it helps.

Would you be so kind and give instructions on how to change linkinterface?
Thank you!

[rajeshroy402]

Does that happen on SITL as well? Would be way easier to debug there.

No, it works fine with the SITL.

[hknaio]

Hi Everyone
I have encountered too that issue with same configuration (QGC V4.1.1 Stable). I realized that it is related to new approach writeBytesThreadSafe function in LinkInterface. When Joystick connect to QGC, a new QThread starts. Then it begans to send manual control messages using SerialLink. After Joystick Thread use the QSerialPort::write function, sending mavlink messages stopped and The Link behaves like High Latency Link. I think it is about to thread safety or thread affinity somehow. Because of this, undesired behaivour is emerging. On SITL with UDP Link , there is no issue.
There was no problem in old versions of QGC (for example V3.5). I changed the function with old version writeBytes function then it worked correctly.
I hope it helps.

Would you be so kind and give instructions on how to change linkinterface?
Thank you!

1- You have to add this line to LinkInterface.h file signal section

void _invokeWriteBytes(QByteArray);

2- Connect this signal to _writeBytes virtual function in LinkInterface constructor

QObject::connect(this, &LinkInterface::_invokeWriteBytes, this, &LinkInterface::_writeBytes);

3- Change writeBytesThreadSafe function with this:

void LinkInterface::writeBytesThreadSafe(const char *bytes, int length)
{
emit _invokeWriteBytes(QByteArray(bytes, length));
}

It should work.

Note: I do not claim that this is the best solution. I'm working on it. But I'm sure it's about SerialLink not UDPLink. It occurs when Joystick and SerialLink Threads work together.

[rajeshroy402]

Hi Everyone
I have encountered too that issue with same configuration (QGC V4.1.1 Stable). I realized that it is related to new approach writeBytesThreadSafe function in LinkInterface. When Joystick connect to QGC, a new QThread starts. Then it begans to send manual control messages using SerialLink. After Joystick Thread use the QSerialPort::write function, sending mavlink messages stopped and The Link behaves like High Latency Link. I think it is about to thread safety or thread affinity somehow. Because of this, undesired behaivour is emerging. On SITL with UDP Link , there is no issue.
There was no problem in old versions of QGC (for example V3.5). I changed the function with old version writeBytes function then it worked correctly.
I hope it helps.

Would you be so kind and give instructions on how to change linkinterface?
Thank you!

1- You have to add this line to LinkInterface.h file signal section

void _invokeWriteBytes(QByteArray);

2- Connect this signal to _writeBytes virtual function in LinkInterface constructor

QObject::connect(this, &LinkInterface::_invokeWriteBytes, this, &LinkInterface::_writeBytes);

3- Change writeBytesThreadSafe function with this:

void LinkInterface::writeBytesThreadSafe(const char *bytes, int length)
{
emit _invokeWriteBytes(QByteArray(bytes, length));
}

It should work.

Note: I do not claim that this is the best solution. I'm working on it. But I'm sure it's about SerialLink not UDPLink. It occurs when Joystick and SerialLink Threads work together.

Has someone tested it?
I don't have a battery... Can someone confirm?

[mnumanuyar]

I had a similiar issue. However I should note that I am using a Custom build.
I observed this on Ubuntu Desktop and kubuntu laptop. testing with sitl/gazebo.
When I connect usb joystick, vehicle becomes unresponsive (cant change mode, cant arm, parameter download frezes etc.) However I can see vehicles messags on mavlink inspector. (and indicators also work normal)

@hknaio s solution solved it for me. Did not tested it extensively tough

[royveshovda]

I am running into a similar issue with joystick and TCP connection.
Joystick + UDP => OK
No joystick (RC) + TCP => OK
Joystick + TCP => Same issue as described above for serial.
I have only tested on latest version on android

[mrpollo]

Perhaps related to PX4/PX4-Autopilot#18054

[GeoSpark]

Running QGC 4.1.4 daily from the linux command line gives me QSocketNotifier: Socket notifiers cannot be enabled or disabled from another thread when I enable joystick input, which results in the same issue. So it looks like @hknaio is right in that it has to do with threads and socket communications.

[DonLakeFlyer]

The problem is this pull: #8835 doesn't work with serial and tcp links. it works fine with UDP links. The reason being that the QIODevice::write happens on the wrong thread. Now the question is whether there is away to get the improved perf while getting things on the right thread.

[DonLakeFlyer]

New daily builds with this fix should be available for download in about an hour. Can folks verify this fix works?

[DonLakeFlyer]

I'll reopen if someone verifies this fix didn't work

[ltrogers98]

Hello, is this feature fixed in the master branch?

[MaEtUgR]

Presumably, I can't test because I can't get the daily build because of #9946