qgroundcontrol icon indicating copy to clipboard operation
qgroundcontrol copied to clipboard
verified publisher icon mavlink

QGC appears to open/take control of USB Serial interfaces it isn't configured to use

Open spiderkeys opened this issue 3 years ago • 13 comments

Expected Behavior

If there is not a CommLink automatically configured to use a serial device, nor a box selected under General settings to automatically connect via Pixhawk, then that serial device should never be opened by QGC.

Current Behavior

  • Opened QGC with two serial interfaces connected on host device:
    • /dev/ttyUSB0 (USB serial adapter being used to monitor PX4 debug output on console pins via picocom)
    • /dev/ttyACM0 (USB connection to FMU intended for use by QGC
  • QGC opened /dev/ttyUSB0 despite all auto connections being unchecked and no comm links specified for it (there was one specified for manual, non-auto connection to /dev/ttyACM0
  • Garbage starts spewing out of the console, almost as if the flight controller has been reconfigured for a different baud rate by QGC
  • Upon trying to close and re-open picocom, I am informed Device or resource busy as /dev/ttyUSB0 is being held by QGC
  • Close QGC
  • Re-open picocom and the device is available and comms are back to normal

Steps to Reproduce:

Steps are provided above, but the strangest thing is that the behavior appears to be random. Sometimes it happens, sometimes it doesn't.

Out of 10 tries, 7 didn't cause the issue and 3 did.

System Information

When posting bug reports, include the following information

  • Operating System: Ubuntu 20.04
  • QGC Version: 4.2.0
  • QGC build: Daily AppImage from a few weeks/months ago
  • Flight Controller: Matek H743 Wing v1
  • Autopilot (with version): PX4 master

spiderkeys avatar Mar 10 '22 22:03 spiderkeys

You might have already done this but for reference. If you don't turn of these auto connection options QGC will capture serial connections. image

And you said there is a manual connecting Serial connection in use and you did disable the auto connection on that one. image But it might be the source of the issue. I would try removing it, restarting QGC and see if it persists. Just to see if there's a bug in that part.

MaEtUgR avatar Mar 16 '22 16:03 MaEtUgR

Thanks, the autoconnection box is unchecked for the one serial comm link I have defined (ttyACM0). I have a separate serial adapter (ttyUSB0) which is connected to the console uart pins on my FMU, which is the interface seeing the issue. There is no comm link entry in QGC for ttyUSB0, in this case.

Similarly, all of the auto connection boxes in the QGC general settings are also disabled (pixhawk, SiK, px4flow, etc):

Edit: I will give a try completely removing the manual serial link for ttyACM0 though, just in case that has an effect on the behavior.

spiderkeys avatar Mar 16 '22 16:03 spiderkeys

If you confirm this as a bug and you will describe steps to reproduce and then expected behavior I can fix this as I'm currently making some of my tweaks around serial comm and know this piece of QGC code.

zdanek avatar Mar 17 '22 15:03 zdanek

I can confirm now that it happens whether there are manually created Comm Links or not.

Settings: Screenshot from 2022-03-17 11-33-38

Comm Links: Screenshot from 2022-03-17 11-33-30

Picocom + nsh:

  • nsh works fine and is responsive before opening QGC
  • Open QGC and a few seconds later garbage is emitted in picocom
  • nsh becomes unresponsive Screenshot from 2022-03-17 11-30-35
  • Close picocom and try to reopen (while QGC is still open), ttyUSB0 resource is busy Screenshot from 2022-03-17 11-35-49
  • Close QGC and ttyUSB0 is accessible again and nsh is responsive again Screenshot from 2022-03-17 11-37-01

spiderkeys avatar Mar 17 '22 18:03 spiderkeys

The FMU physical setup, for context: Screenshot from 2022-03-17 11-45-25

spiderkeys avatar Mar 17 '22 18:03 spiderkeys

I have no experience with devices, have you seen anything like this before @DonLakeFlyer?

mrpollo avatar Mar 23 '22 16:03 mrpollo

Shouldn't happen if autoconnect is turned off. Keeping in mind that you need to reboot QGC after you turn autoconnect off for it to take affect.

DonLakeFlyer avatar Mar 23 '22 16:03 DonLakeFlyer

Can confirm that autoconnect is disabled across multiple QGC restarts, w.r.t. this issue.

spiderkeys avatar Mar 23 '22 16:03 spiderkeys

Someone will need to debug through this to figure out what is going on. Maybe RTK code trying to connect?

DonLakeFlyer avatar Mar 23 '22 16:03 DonLakeFlyer

My guesses are similar to yours - either some individual device driver/module is trying to access FTDI devices, or the Firmware Setup subsystem is taking control of it. I've noticed that Firmware Setup also disregards the fact that no manual or autoconnect links are specified.

spiderkeys avatar Mar 23 '22 16:03 spiderkeys

I forgot there was a setting to turn off RTK autoconnect. Only other thing I can think of is Qt NMEA code trying to connect to an external source.

DonLakeFlyer avatar Mar 23 '22 16:03 DonLakeFlyer

This is perhaps not related, but I have seen similar behavior when I connect FMUv5 using USB and NXP UCAN32K via serial2USB. There were some weird behavior on the NSH console of the NXP board. I will need to test again to make double sure.

henrykotze avatar Mar 24 '22 07:03 henrykotze

I'm doing some RTK related changes (actually making RTK run with Android device :D) I think I can dig into it.

zdanek avatar Mar 24 '22 08:03 zdanek

I expected similar issue on QGC 4.0.0. I built QGC myself and on the first launch it was taking serial device (/dev/USB0 in my case). Disabling anything mavlink log related helps me. QGC stop taking /dev/USB0 device.

Image

turneroq avatar Sep 03 '25 09:09 turneroq

Do you know exactly which setting fixes it? I assume either enable automatic logging or enable automatic log uploads?

HTRamsey avatar Sep 03 '25 17:09 HTRamsey