[mavlink] Parameter to always start on USB

[dakejahl]

Added parameter and logic to always start mavlink on USB instead of auto-detecting the protocol. The mavlink mode can now be selected as well. I also refactored the code into a module and moved it into the LP px4 work queue. I refactored everything into functions and a state machine.

Added parameters SYS_USB_AUTO USB_MAV_MODE

The problem being solved When running mavlink-router on a companion computer, no data will be routed until a GCS connects. This is because in typical mavlink-router configuration there is only one Server endpoint which corresponds to the GCS. The GCS will send a heartbeat over the mavlink network which triggers the FMU to start mavlink on USB.

PX4 Behavior before PR PX4 waits to receive data on USB and auto-detects the protocol (mavlink, nsh, ublox serial passthru).

PX4 Behavior after PR SYS_USB_AUTO is set to Mavlink by default. The mavlink instance will be started as soon as USB is available rather than wait and auto-detect the protocol. This is better default behavior for users and end products.

How it was tested ARK Jetson (v6x) : Validated mavlink-routerd initates comms after immediately receiving data on USB. Pixhawk4 (v5): Validated connection to QGC, picocom, and u-center

• [x] (SYS_USB_AUTO=2) Start mavlink
• [x] (SYS_USB_AUTO=1) Detect mavlink
• [x] (SYS_USB_AUTO=1) Detect nsh
• [x] (SYS_USB_AUTO=1) Detect ublox

Closes #20631

[dagar]

Thanks @dakejahl.

How about we simply handle sercon + mavlink USB start in rcS if the parameter is set? Then the relatively low level autostart code doesn't need to poke into parameters, and we just need to make sure it stays quiet and out of the way if sercon is already started.

[dakejahl]

I've updated the PR. I moved the autoselect driver into a runtime work_queue module and added the mavlink startup into rcS. I also introduced another parameter to allow selecting the mode for the USB mavlink.

Tested succesfully:

• mavlink force start w/ multiple modes
• autostart mavlink
• autostart nsh

I did not test ublox serial passthrough.

[dakejahl]

Starting the mavlink stream in rcS actually won't work on boards that don't have VBUS connected when the flight controller boots (ark jetson carrier). The linux side enables the VBUS after it boots, which means USB shows up later after the start mavlink /dev/ttyACM0 in rcS has already failed. I didn't catch this initially because I was just rebooting the FC and not the entire board. If you try to start it in rcS before VBUS is high sercon && sleep 5 && mavlink start -d /dev/ttyACM0 fails to open the port

ERROR [mavlink] could not open /dev/ttyACM0

[mcsauder]

This can only be done if the driver is started in the rcs and runs an retries continously. I know this because of the year I spent rewriting rcs.

[mcsauder]

Rcs runs once. You get one chance at boot. If you want anything to start after boot you need to kick off a process that monitors and doesn't die until shutdown.

[dakejahl]

The only piece I can't figure out is how to make the cdcacm_autostart/Kconfig depend on SYSTEM_CDCAMC and MODULES_MAVLINK. It would be nice to use the depends on property but it doesn't seem to work. The alternative is going through every .px4board and adding DRIVERS_CDCACM_AUTOSTART=y where appropriate, but this seems fragile and a PITA.

This doesn't work

menuconfig DRIVERS_CDCACM_AUTOSTART
	bool "cdcacm_autostart"
	default y
	depends on SYSTEM_CDCACM && MODULES_MAVLINK
	---help---
		Enable support for cdcacm_autostart 

@dagar do you know how to do this properly?

[PetervdPerk-NXP]

Your KConfig sample looks to okay. @dakejahl in boardconfig you can select the symbol and type the ? key. There you can see how the dependencies are resolved.

[dakejahl]

I think it doesn't work because SYSTEM_CDCACM is part of the nuttx Kconfig not PX4

[PetervdPerk-NXP]

I think it doesn't work because SYSTEM_CDCACM is part of the nuttx Kconfig not PX4

Yeah NuttX kconfig isn't exposed to PX4 Kconfig.

[dakejahl]

@dagar let me know if there's any further changes you want to see here! Otherwise this is good to go.

[AlexKlimaj]

@dagar Testing this now on the HaLow radios and its needed. Working well. onboard default mavlink usb brings the HaLow radios CPU to 100%. With this PR and minimal mavlink mode on the usb it works well.

[dakejahl]

@dagar mentioned there is a script that auto sorts the KConfig files and suggested I make sure this PR matches that. I'm not sure where said script is to be found. The DRIVERS_CDCACM_AUTOSTART only needs to be applied to boards with USB. I can remove the alphabetization of the KConfig files if that would make it easier to merge.

[dakejahl]

This continues to be a problem. Honestly I'd say we backport to 1.14 so that newbies don't struggle so hard with this. https://discord.com/channels/1022170275984457759/1169554115827876001

[DronecodeBot]

This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/issue-with-waiting-for-heartbeat-message-in-uav-project/36858/2

[dakejahl]

I removed the PGA460 driver from COMMON_DISTANCE_SENSOR and the LIS2MDL from COMMON_MAGNETOMETER to save 7.6KB flash. The PGA460 driver was only ever used on the Teal One. The LIS2MDL is not used on any other boards.

[DronecodeBot]

This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-sync-q-a-may-15-2024/38773/1

[mrpollo]

Let's make sure the old parameters are still there.

@dagar will check

[dakejahl]

I took care of it