Support non-navigator linux boards (initially Argonot)

[rafaellehmkuhl]

With this small change, we can support running Ardupilot Linux-based firmwares for boards other than the Navigator.

This was motivated to support the Argonot system, from SymbyTech (a request from @DevinNorgarb).

The only downside for now is that when there's no firmware installed for that board, we will use the one we have stored for Navigator.

The PR is in draft mode until we confirm the sensors used to identify this board.

Fix #1623.

[patrickelectric]

I believe that would be more future proof to do what we currently do by default, and if there is a binary under userdata, run the binary if its valid.

[rafaellehmkuhl]

I believe that would be more future proof to do what we currently do by default, and if there is a binary under userdata, run the binary if its valid.

But in this case, we wouldn't offer the firmware download/update nor the board identification features to those.

[patrickelectric]

I believe that would be more future proof to do what we currently do by default, and if there is a binary under userdata, run the binary if its valid.

But in this case, we wouldn't offer the firmware download/update nor the board identification features to those.

That'll be more related to: #1624, on the idea of the manifest file

[rafaellehmkuhl]

I believe that would be more future proof to do what we currently do by default, and if there is a binary under userdata, run the binary if its valid.

But in this case, we wouldn't offer the firmware download/update nor the board identification features to those.

That'll be more related to: #1624, on the idea of the manifest file

Didn't quite get it. Why not use the ardupilot one if it exists?

[patrickelectric]

I believe that would be more future proof to do what we currently do by default, and if there is a binary under userdata, run the binary if its valid.

But in this case, we wouldn't offer the firmware download/update nor the board identification features to those.

That'll be more related to: #1624, on the idea of the manifest file

Didn't quite get it. Why not use the ardupilot one if it exists?

1. 3rd party companies when releasing a product will rarely do a firmware update, that's the most common use case.
2. If we rely only in ArduPilot manifest we and others will be stuck with it, the code review process, the release cycle and more. Custom binaries will be heavily expensive to maintain over it, and new binaries may not be supported by the 3rd party companies or validated, making the release cycle out of the companies to the hand of the ArduPilot organization.
3. Having our own manifest will help 3rd party companies to release their own binaries and have total control over it, including providing not open source versions of ArduPilot firmwares.

[rafaellehmkuhl]

I believe that would be more future proof to do what we currently do by default, and if there is a binary under userdata, run the binary if its valid.

But in this case, we wouldn't offer the firmware download/update nor the board identification features to those.

That'll be more related to: #1624, on the idea of the manifest file

Didn't quite get it. Why not use the ardupilot one if it exists?

1. 3rd party companies when releasing a product will rarely do a firmware update, that's the most common use case.
2. If we rely only in ArduPilot manifest we and others will be stuck with it, the code review process, the release cycle and more. Custom binaries will be heavily expensive to maintain over it, and new binaries may not be supported by the 3rd party companies or validated, making the release cycle out of the companies to the hand of the ArduPilot organization.
3. Having our own manifest will help 3rd party companies to release their own binaries and have total control over it, including providing not open source versions of ArduPilot firmwares.

I agree we should support this alternative. I just don't get why not to do both.

[patrickelectric]

I believe that would be more future proof to do what we currently do by default, and if there is a binary under userdata, run the binary if its valid.

But in this case, we wouldn't offer the firmware download/update nor the board identification features to those.

That'll be more related to: #1624, on the idea of the manifest file

Didn't quite get it. Why not use the ardupilot one if it exists?

1. 3rd party companies when releasing a product will rarely do a firmware update, that's the most common use case.
2. If we rely only in ArduPilot manifest we and others will be stuck with it, the code review process, the release cycle and more. Custom binaries will be heavily expensive to maintain over it, and new binaries may not be supported by the 3rd party companies or validated, making the release cycle out of the companies to the hand of the ArduPilot organization.
3. Having our own manifest will help 3rd party companies to release their own binaries and have total control over it, including providing not open source versions of ArduPilot firmwares.

I agree we should support this alternative. I just don't get why not to do both.

[patrickelectric]

@DevinNorgarb was it tested ?

[joaoantoniocardoso]

The changes seem good, adding ad-hoc code to support boards is a good solution until we have the need for something like Kraken but for 3rd party boards

[patrickelectric]

Approved by user