AP_Vehicle: store currently running firmware version into a parameter #32141

peterbarker · 2026-02-08T05:56:54Z

save the currently running firmware version into a parameter. Into the future we may use this number to prevent a user from attempting to upgrade from a truly ancient version of the firmware to a more modern one where we may have removed parameter upgrade code.

Replaces #32071

save the currently running firmware version into a parameter. Into the future we may use this number to prevent a user from attempting to upgrade from a truly ancient version of the firmware to a more modern one where we may have removed parameter upgrade code.

andyp1per · 2026-02-08T07:36:44Z

libraries/AP_Vehicle/AP_Vehicle.cpp

@@ -290,6 +290,13 @@ const AP_Param::GroupInfo AP_Vehicle::var_info[] = {
    AP_SUBGROUPINFO(rpm_sensor, "RPM", 32, AP_Vehicle, AP_RPM),
 #endif

+    // @Param: FW_VER_LAST
+    // @DisplayName: Last firmware version
+    // @Description: Firmware version that last ran on this board, encoded as major*65536+minor*256+patch. Automatically updated on boot.


Need to describe what happens if it never ran.

I can add words. But whatever I add will really only be useful for devs.

andyp1per · 2026-02-08T07:37:27Z

libraries/AP_Vehicle/AP_Vehicle.cpp

@@ -290,6 +290,13 @@ const AP_Param::GroupInfo AP_Vehicle::var_info[] = {
    AP_SUBGROUPINFO(rpm_sensor, "RPM", 32, AP_Vehicle, AP_RPM),
 #endif

+    // @Param: FW_VER_LAST


Not sure I like the name, quite cryptic. Why not FIRMWARE_VERSION as a corrollory to FORMAT_VERSION?

Not sure I like the name, quite cryptic. Why not FIRMWARE_VERSION as a corrollory to FORMAT_VERSION?

I'm trying to make it clear that the important thing here is that at boot time it's the version that was previously running.

I think I failed, and the fact that the majority of the time it's the current firmware version probably means we can simplify this.

I agree with @andyp1per FIRMWARE_VERSION is clear and simple.

muramura · 2026-02-08T12:55:10Z

Thank you for this PR. This is a very useful addition for GCS-based version management.

I would like to suggest adding an additional parameter for a Custom Firmware Version. Many of us in the community build custom forks for specific hardware or projects, and we need to track our own versioning (e.g., Base: 4.7.0, Custom: 1.1.0).

Following your 32-bit logic, we could represent it like this:

0x04070000 : V4.7.0-DEV
0x04070040 : V4.7.0-ALPHA
0x04070080 : V4.7.0-BETA
0x040700C0 : V4.7.0-RC
0x040700FF : V4.7.0-Release

MEJOR<<24+MINOR<<16+PATCH<<8+FW TYPE

By having a SYS_FW_CUST_VER parameter, manufacturers can easily report their internal build versions via MAVLink without overriding the base ArduPilot version info. What do you think?

Copter
#define FW_MAJOR 4
#define FW_MINOR 7
#define FW_PATCH 0
#define FW_TYPE FIRMWARE_VERSION_TYPE_DEV

mavlink: FIRMWARE_VERSION_TYPE
"0" "FIRMWARE_VERSION_TYPE_DEV" development release
"64" "FIRMWARE_VERSION_TYPE_ALPHA" alpha release
"128" "FIRMWARE_VERSION_TYPE_BETA" beta release
"192" "FIRMWARE_VERSION_TYPE_RC" release candidate
"255" "FIRMWARE_VERSION_TYPE_OFFICIAL" official stable release

peterbarker · 2026-02-08T21:04:51Z

Thank you for this PR. This is a very useful addition for GCS-based version management.

I'm afraid this wasn't intended to help GCSs out, and we were intending to hide this parameter from the GCS.

In general a GCS should not be caring about the firmware version on the autopilot - you have pointed out problems when they do care as then someone running their own custom firmware won't see the behaviour they're expecting! Better to look for the specific feature you are interested in then assuming certain firmwares have certain features.

If you want the currently-running firmware version number - well, there's AUTOPILOT_VERSION, which you've already alluded to.

peterbarker · 2026-02-08T21:06:55Z

mavlink: FIRMWARE_VERSION_TYPE "0" "FIRMWARE_VERSION_TYPE_DEV" development release "64" "FIRMWARE_VERSION_TYPE_ALPHA" alpha release "128" "FIRMWARE_VERSION_TYPE_BETA" beta release "192" "FIRMWARE_VERSION_TYPE_RC" release candidate "255" "FIRMWARE_VERSION_TYPE_OFFICIAL" official stable release

Being able to have some sort of custom version number available in the mavlink stream without overriding the ArduPilot version numbers would be nice - maybe as extension fields to FIRMWARE_VERSION?!.

Not really what this PR is about, 'though.

timtuxworth · 2026-02-09T00:09:42Z

In general a GCS should not be caring about the firmware version on the autopilot

That's just not the reality. The GCS does need to care about the version and it doesn't help to pretend that's not true.

Better to look for the specific feature you are interested in then assuming certain firmwares have certain features.

It's not just about that. A feature might be there (or not), but the way it works can be different version by version, the parameters and their names can change (e.g. SR vs MAV). Trying to guess based on some combination of which parameter names or values are what is a hack not an answer.

timtuxworth · 2026-02-09T00:29:17Z

libraries/AP_Vehicle/AP_Vehicle.h

@@ -320,6 +320,7 @@ class AP_Vehicle : public AP_HAL::HAL::Callbacks {
    virtual void init_ardupilot() = 0;
    virtual void load_parameters() = 0;
    void load_parameters(AP_Int16 &format_version, const uint16_t expected_format_version);
+    void check_firmware_version();


It's not actually a "check" - maybe "save_firmware_version()"?

You're correct with the stuff as it currently is.

As soon as we add actual gating on the version it becomes check_firmware_version.

timtuxworth · 2026-02-09T00:34:02Z

By having a SYS_FW_CUST_VER parameter, manufacturers can easily report their internal build versions via MAVLink without overriding the base ArduPilot version info. What do you think?

This is an excellent idea and is going to become more important for regulatory compliance. Regulators (Canada for example), are asking for configuration management plans that document how different versions of firmware running on vehicles are tracked. Yes it will be important to have:

ArduPilot "Base" version - this is what the user will get if they download directly via GCS from our servers. We probably need a way to represent a build from the custom build server.

Customer/Vendor "Fork" version - what you are calling "CUST" might also be a company that runs its own fork for internal use. The fork will be based on a specific version of AP, so we need that, then we need the fork/local version major/minor version information. I know Partners do this and keeping track of what is running on the vehicle is difficult. I'm not sure about the name though.

peterbarker · 2026-02-09T02:29:16Z

In general a GCS should not be caring about the firmware version on the autopilot

That's just not the reality. The GCS does need to care about the version and it doesn't help to pretend that's not true.

For example?

Better to look for the specific feature you are interested in then assuming certain firmwares have certain features.

It's not just about that. A feature might be there (or not), but the way it works can be different version by version, the parameters and their names can change (e.g. SR vs MAV). Trying to guess based on some combination of which parameter names or values are what is a hack not an answer.

For the latter - SR vs MAV is relatively easy to work out from a GCS perspective. Here's an example of MAVProxy magically using ARMING_CHECK or ARMING_SKIPCHK, depending on what's available.

Please give an example of the former. It might inform the way we change the way things behave in ArduPilot.

Also. Moot point as the firmware version is already available in the message specifically to convey that information.

magicrub · 2026-02-09T20:59:59Z

Personally, I don't think this extra parameter is worth it. Better to reallocate 4 bytes (int or 4 uint8's?) into the flash storage page and don't make it visible.. like the missions and DNA list

Let's sneak it in here:
https://github.com/ArduPilot/ardupilot/blob/master/libraries/StorageManager/StorageManager.cpp#L101
If we're consuming a few bytes of flash anyway might as well take it out of the last 4 bytes of StorageParam or StorageParamBak

downside of using the Bak is it's only for larger chips and downside of touching StorageParam is we run the risk of corrupting the whole flash space, and that chance goes up the lower (and thus small memory requirement) we go.

note: once we boot with an old-to-new param value and we do whatever param migrations that are needed then we replace that param with the current version, which is the new default, which then will consume zero storage space

I dunno.. adding a param here just feels like it goes against the don't-add-a-param-unless-you-reaaaaally-need-to methos which we have in place for good reasons.

peterbarker added this to Peter's ArduPilot 4.7 Queue Feb 8, 2026

andyp1per requested changes Feb 8, 2026

View reviewed changes

timtuxworth reviewed Feb 9, 2026

View reviewed changes

AP_Vehicle: store currently running firmware version into a parameter #32141

Are you sure you want to change the base?

AP_Vehicle: store currently running firmware version into a parameter #32141

Conversation

peterbarker commented Feb 8, 2026

Uh oh!

andyp1per Feb 8, 2026

Choose a reason for hiding this comment

Uh oh!

peterbarker Feb 8, 2026

Choose a reason for hiding this comment

Uh oh!

andyp1per Feb 8, 2026

Choose a reason for hiding this comment

Uh oh!

peterbarker Feb 8, 2026

Choose a reason for hiding this comment

Uh oh!

timtuxworth Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

muramura commented Feb 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

peterbarker commented Feb 8, 2026

Uh oh!

peterbarker commented Feb 8, 2026

Uh oh!

timtuxworth commented Feb 9, 2026

Uh oh!

timtuxworth Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

peterbarker Feb 9, 2026

Choose a reason for hiding this comment

Uh oh!

timtuxworth commented Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

peterbarker commented Feb 9, 2026

Uh oh!

magicrub commented Feb 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

muramura commented Feb 8, 2026 •

edited

Loading

timtuxworth commented Feb 9, 2026 •

edited

Loading