New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[mavlink] Parameter to always start on USB #22234
base: main
Are you sure you want to change the base?
Conversation
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. |
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:
I did not test ublox serial passthrough. |
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
|
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. |
9782ccb
to
a16232b
Compare
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. |
23ade98
to
3dbba38
Compare
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 This doesn't work
@dagar do you know how to do this properly? |
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. |
I think it doesn't work because SYSTEM_CDCACM is part of the nuttx Kconfig not PX4 |
f8ab9be
to
5683150
Compare
Yeah NuttX kconfig isn't exposed to PX4 Kconfig. |
22383ef
to
2d7412a
Compare
@dagar let me know if there's any further changes you want to see here! Otherwise this is good to go. |
1b44427
to
ab66e46
Compare
@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. |
@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. |
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. |
38c0ed8
to
6fe0b25
Compare
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 |
Refactored cdcacm_init into a module and added a paramter to allow always starting mavlink on USB, also added a paramter to choose the mode. The current default behavior is to wait and listen for data on USB and auto-detect the protocol (mavlink, nsh, ublox). This results in the mavlink stream not starting until something else on the mavlink network sends a packet first. The new default behavior is to always start mavlink. Added parameters MAV_USB_ENABLE -- default 1 (always start mavlink on USB) MAV_USE_MODE -- default 3 (onboard)
054840f
to
71d15bc
Compare
…s with CONFIG_CDCACM in their nsh/defconfig
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. |
This pull request has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there: |
Let's make sure the old parameters are still there. @dagar will check |
I took care of it |
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
Closes #20631