manifest: support hardware/integration metadata

[ES-Alexander]

Device integrations would benefit from having consistent ways of linking to information about the product being integrated, integration guides (perhaps we should prefer markdown but also allow PDFs), and things like CAD file links for mounting hardware, which we could then present nicely, and allow locally downloading and storing with the extension (see bluerobotics/BlueOS#1640) as appropriate (like we're planning to do for READMEs).

I'm thinking something like

LABEL hardware='{\
    "integration": "https://docs.company.com/dvls/integration_guide.md",\
    "components": [\
        {\
            "product": "My DVL 100",\
            "manufacturer": "My Company",\
            "details": "https://store.com/my-dvl-100",\
            "image": "https://store.com/images/my-dvl-100.png",\
            "purpose": "sensor for velocity measurement/positioning",\
            "groups": [1]\
        },\
        {\
            "product": "My DVL 250",\
            "manufacturer": "My Company",\
            "details": "https://store.com/my-dvl-250",\
            "image": "https://store.com/images/my-dvl-250.png",\
            "purpose": "sensor for velocity measurement/positioning",\
            "groups": [2]\
        },\
        {\
            "product": "Megamount3000",\
            "manufacturer": "3D printed",\
            "details": "https://printables.com/my-dvl-mount",\
            "image": "https://...",\
            "purpose": "attaching DVL to a vehicle",\
            "groups": [1, 2]\
        }\
    ]\
}'

[ES-Alexander]

On revision from some initial internal feedback:

LABEL hardware='[\
    {\
        "item": "My DVL 100",\
        "manufacturer": "My Company",\
        "details": "https://store.com/my-dvl-100",\
        "image": "https://store.com/images/my-dvl-100.png",\
        "purpose": "sensor for velocity measurement/positioning",\
        "groups": [1]\
    },\
    {\
        "item": "My DVL 250",\
        "manufacturer": "My Company",\
        "details": "https://store.com/my-dvl-250",\
        "image": "https://store.com/images/my-dvl-250.png",\
        "purpose": "sensor for velocity measurement/positioning",\
        "groups": [2]\
    },\
    {\
        "item": "Megamount3000",\
        "manufacturer": "3D printed",\
        "details": "https://printables.com/my-dvl-mount",\
        "image": "https://...",\
        "purpose": "attaching DVL to a vehicle",\
        "groups": [1, 2]\
    }\
]

It would be good to have some way of specifying required hardware/groups. Possibly via something like LABEL required_groups="1|2", to indicate that the extension requires at least the group 1 hardware or the group 2 hardware. We could include & and brackets () as an option for groups that need to be present together.

It would also be nice if there was some way for an extension to hook into the displayed 3D model in the Vehicle Setup page, even if only by specifying a material name that gets hidden when the extension is disabled (and maybe if it's not detected, if we can standardise an API for device integration extensions to announce whether they're actively connected), and gets highlighted when the user mouses over a box for the extension. That would likely require the user to include the model of the relevant product in their custom 3D model (IIRC we can't easily dynamically add extra objects to an existing .glb file), but it would still be a nice touch. Idea needs further discussion.

[matt-bathyscope]

Can this concept be extended to support showing an extension to a specific BlueOS platform? For example, I have a FLIR IP camera integration for BlueOS on BlueBoat but that would never be targeted at BlueROV2.

[ES-Alexander]

Can this concept be extended to support showing an extension to a specific BlueOS platform?

@matt-bathyscope that seems reasonable to me :-)

Do you think an appropriate variable for that would be something like vehicle-types (e.g. with distinctions between ROV, AUV, Boat, Rover, Copter, Plane, etc), or does it make more sense to just do vehicle-domains (e.g. underwater, water-surface, in-air, on-ground)?

I like the simplicity of the vehicle domain approach, but am unsure on whether it's sufficiently expressive for the kinds of differentiation we'd want to do. Can you think of any that would require choosing between vehicle types?

[ES-Alexander]

Adding to this, it would be useful if this allows restricting extensions/add-ons to particular hardware+software versions more generally (e.g. via hardware-version and firmware-version variables in this metadata).

Given the hope is to have a BlueOS docs extension that can dynamically host and display externally added docs, it would be nice to cut down on which of those are offered to be added by the user based on only the device, software, and firmware versions they have installed (e.g. don't offer to install ArduSub 4.0, or ArduCopter docs if they have ArduSub 4.1 installed).

That could be quite challenging to implement, but would also be really handy. As something of a fall-back (since classification systems can fail, especially when they involve complex logic), we may want to implement a traffic-light type system, where green versions are "definitely supported/compatible", orange versions are "ambiguous compatibility", and red versions are "markedly incompatible with something that's already installed" - that way the user can choose to still install a potentially incompatible version if it's the only one available, or if they know that it actually should be ok for their use-case.