Autostart: load all airframes IDs with priority ROMFS -> SD card

[MaEtUgR]

Solved Problem

When updating a vehicle configuration I had the requirement to not change the startup ID (SYS_AUTOSTART) but want to move the airframe file from the SD card to ROMFS.

Of course I can just remove the logic to load any airframe from the SD card from that vehicle but that would make that part custom. While going through what prevents the current logic from achieving the goal I stumbled across the number partitioning of external airframes needing to have numbers > 1'000'000 which was already talked about here: #18459 (comment) I talked with @ThomasDebrunner about why there's no fallback for looking for airframes in the currently available two locations ROMFS and SD card except for when the SD card is completely missing.

Solution

My proposal is to look for airframes first in ROMFS and then on the SD card independent of their numbering. The error handling for the case where no airframe was found is moved outside of the generated rc.autostart.

Changelog Entry

Improvement: Look for airframe files in ROMFS and then SD card independent of the autostart number.

Alternatives

We could also swap the priorities to look first on the SD card and then in the ROMFS. I'm not a fan of this because:

• Existing airframe IDs could be overridden with an airfame file on the SD card

• This could lead to confusion
• It's more likely to have a version mismatched airframe on the SD card if there is also one in ROMFS
• In case the SD card is available but the corresponding file missing or corrupted it would silently load the internal airframe which could lead to unexpected behavior and even be safety relevant

Test coverage

I tested this on a vehicle with fmu-v5x. Like expected if the corresponding airframe is available in ROMFS it's loaded with priority
with the message Loading airframe: /etc/init.d/airframes/000_XXX, if it isn't part of rc.autostart in ROMFS it's loaded from the SD card with only the message that's part of the SD card autostart file. And if there is no matching airframe you get the error ERROR [init] No airframe file found for SYS_AUTOSTART value and SYS_AUTOSTART is reset to the value 0.

[dagar]

Does resetting SYS_AUTOSTART to 0 actually accomplish anything or should we just leave it alone to keep things simple (development workflows, avoiding unnecessary resets jumping between versions, etc)?

[MaEtUgR]

Resetting it to zero flags that the autostart wasn't loaded. When I talked to @bkueng he was stressing that this should be retained for the case someone updates but the airframe he used is gone from the new version. I remember I was once glad that I saw the ID go to zero in one of my tests. Not sure if that couldn't be solved even more user friendly e.g. by messageing the user that there's no airframe with the ID but not changing the parameter.

For reference this was introduced here: https://github.com/PX4/PX4-Autopilot/pull/13772/files#diff-c0c83e328e28cbd2f7c7ad46bbb6369024ed63daa3f9dc8cf89ac79125183e1dR82
I did not change it but am open to discussion. I feel it's more accessible to change now.

[sfuhrer]

I'm okay with the change to always check both ROMFS and SD card, cannot think of a workflow that would break with it. And I like that we remove the >1000000 condition, that seems to me an unnecessary complication based on a random threshold.

[MaEtUgR]

Thanks for reviewing! The only thing I changed is adding this comment to clarify the step in the rcS autostart file:
https://github.com/PX4/PX4-Autopilot/compare/479c4520de678d1fae6448397ad503d1c7a12d82..90bb4d9b963999d841a6ccb9d92a1c201ee07152#diff-79d1b15d9113e00d9a6d3e26a9107a1cf5a5782188bfb18ee21b2fe34bdbee3aR220