First start mavlink on serial port: mavlink start -x -d /dev/ttyACM0
Then starting mavlink on udp port: mavlink start -u 14556' will fail with port 14556 already occupied due to get_instance_for_network_port here
https://github.com/PX4/Firmware/blob/d3a1225c98076c626d601e01e1f785066122a5b7/src/modules/mavlink/mavlink_main.cpp#L2104-L2106
check only _network_port variable without checking type of mavlink instance
https://github.com/PX4/Firmware/blob/d3a1225c98076c626d601e01e1f785066122a5b7/src/modules/mavlink/mavlink_main.cpp#L349
I suppose _network_port should be 0 initialized and only further set to 14556 by default for net mavlink instances.
https://github.com/PX4/Firmware/blob/d3a1225c98076c626d601e01e1f785066122a5b7/src/modules/mavlink/mavlink_main.h#L622
Thanks for the issue @lukegluke.
@lukegluke what platform are you using?
@julianoes I'm using custom board with ethernet quite close to px4 fmu-v5.
I can't reproduce it right now because I don't have a board like that at hand. Would you mind creating a pull request which fixes the issue for you?
I think any board with etherhnet will fit. For now for myself I workaround the issue just by reordering starts of mavlinks.
But I suppose simple fix will be:
if ((inst->_protocol == Protocol::UDP) && (inst->_network_port == port)) {
https://github.com/PX4/Firmware/blob/d3a1225c98076c626d601e01e1f785066122a5b7/src/modules/mavlink/mavlink_main.cpp#L349
Cool thx, if that works for you, then I'd appreciate a pull request.
Yes, it works, I rechecked. Here PR https://github.com/PX4/Firmware/pull/15623
Thanks @lukegluke!