Use MAVLink v1 only as opt-in

[MaEtUgR]

Solved Problem

I had heard from two completely independent real world use cases now that erroneously defaulted to MAVLink 1 for the connection between autopilot and ground station and this caused the link to get unusable. I'm not aware of any component that does not support MAVLink 2 and assume no one tests MAVLink 1.

Solution

I want to get broader feedback on who is using MAVLink 1 and if they are willing to either upgrade to a protocol version which was introduced 9 years ago (mavlink/mavlink#535) or maintain and test its support while we rather default to MAVLink 2.

Changelog Entry

Use MAVLink 1 only as opt-in

Alternatives

I'm aware that reverting 1493ebf might solve issues but I really doubt this setting is useful if it doesn't get tested and there's no MAVLink 1 use case.

Test coverage

Simulation with QGC works fine. I'll invest more time into testing once this suggestion gets positive feedback.

FYI @vlad-serbanica @jeremyzff @julianoes @hamishwillee

[github-actions]

🔎 FLASH Analysis

px4_fmu-v5x [Total VM Diff: 16 byte (0 %)]

    FILE SIZE        VM SIZE    
--------------  -------------- 
+0.0%     +16  +0.0%     +16    .text
  +0.0%     +12  +0.0%     +12    [section .text]
   +44%      +4   +44%      +4    g_nullstring
+0.0%     +55  [ = ]       0    .debug_abbrev
-0.0%      -2  [ = ]       0    .debug_info
-0.0%      -5  [ = ]       0    .debug_line
  +100%      +2  [ = ]       0    [Unmapped]
  -0.0%      -7  [ = ]       0    [section .debug_line]
-0.2%     -16  [ = ]       0    [Unmapped]
+0.0%     +48  +0.0%     +16    TOTAL

px4_fmu-v6x [Total VM Diff: 0 byte (0 %)]

    FILE SIZE        VM SIZE    
--------------  -------------- 
+0.0%     +55  [ = ]       0    .debug_abbrev
-0.0%      -2  [ = ]       0    .debug_info
-0.0%      -5  [ = ]       0    .debug_line
  +100%      +2  [ = ]       0    [Unmapped]
  -0.0%      -7  [ = ]       0    [section .debug_line]
+0.0%     +48  [ = ]       0    TOTAL

Updated: 2025-10-14T05:04:20

[jsm09a]

The Holybro Micro OSD V2 seems to want MavLInk 1. See https://holybro.com/products/micro-osd-v2 "Download: Holybro_MicroOSD_v2.0_Manual.pdf" page 6. I can try forcing it to MavLink 2 to see if it is supported if you want.

[dakejahl]

I am strongly in favor of this

[hamishwillee]

I am strongly in favor of this

Me too.

[julianoes]

I'm not against it but one way to prevent problems would be to just set MAV_PROTO_VER to 2 by default.

[dagar]

Let's just change the default to 2 and consider dropping the autodetection code.

[jeremyzff]

I like changing the default

[MaEtUgR]

Feedback taken:
There might still be rare non-gcs components only talking MAVLink v1 and hence we keep the option to opt-in using v1. But:

• Default is v2
• Always adapt to v2 once a v2 packet is received (no option to force v1)
• No games with switching back and forth to send the PROTOCOL_VERSION

How about that? The option to not adapt to v2 is not great because the parameter MAV_PROTO_VER affects all instances.

[MaEtUgR]

I addressed previous comments. Changed the wording to hopefully be more understandable and made it spit out a PX4_INFO whenever the "auto-upgrade" to v2 happens.

[github-actions]

No flaws found

[MaEtUgR]

@dakejahl Thanks for merging. I found a bug that spams messages, fix is here: #25758