ardupilot: Add variables from non-main sources to the Data Lake

[rafaellehmkuhl]

Today, we completely ignore data comming from sources with systemIDs different from the main one and component IDs different than 1.

This PR reads the messages from those systems and create Data Lake variables for them, so the user can use it on VGIs, Plotters and other components.

To be merged after #1814.
Fix #1809.

[fseegraeber]

Hey, thanks for implementing this. Can confirm that this allows the usage of mavlink messages with a component ID of e.g. 158 (MAV_COMP_ID_PERIPHERAL) for VGIs:

LGTM!

[rafaellehmkuhl]

Hey, thanks for implementing this. Can confirm that this allows the usage of mavlink messages with a component ID of e.g. 158 (MAV_COMP_ID_PERIPHERAL) for VGIs: LGTM!

Nice to hear that!
I will just make sure about the path format, and we can push it.

I'm thinking about doing something like mavlink/ardupilot/system=1/component=158/cmpt_volt, so we only reserve the / character and make it easier to filter for different paths in the future.

@Williangalvani what do you think?

PS: pushed this way in the updated commit.

[ES-Alexander]

Cool! This is also a good start for being able to display non-selected vehicles on the map :-)

I'm thinking about doing something like mavlink/ardupilot/system=1/component=158/cmpt_volt, so we only reserve the / character and make it easier to filter for different paths in the future.

• Is there some way to know whether a MAVLink message comes from an ArduPilot system/component? That seems potentially unnecessary
• Component IDs have default names, which could be worth including
• When we're adding so much length to the paths, Use a tree-view on the VeryGenericIndicator variable selection #539 becomes extra relevant

[rafaellehmkuhl]

Cool! This is also a good start for being able to display non-selected vehicles on the map :-)

Nice! Exactly the idea!

I'm thinking about doing something like mavlink/ardupilot/system=1/component=158/cmpt_volt, so we only reserve the / character and make it easier to filter for different paths in the future.

• Is there some way to know whether a MAVLink message comes from an ArduPilot system/component? That seems potentially unnecessary

You mean removing the /ardupilot right? Makes sense. Will do.

• Component IDs have default names, which could be worth including

I think it would be better if we just leave it non abstracted here and abstract on a higher level.

• When we're adding so much length to the paths, Use a tree-view on the VeryGenericIndicator variable selection #539 becomes extra relevant

Definitely. Let me give a try on that. If I don't see much problems, I will open a PR with the implementation in parallel.

[rafaellehmkuhl]

@ES-Alexander if you want to test it, I have rebased it over master and fixed the conflicts.

[rafaellehmkuhl]

@ES-Alexander I've modified the PR to not inject those variables by default, but instead allow the user to enable it in the MAVLink config menu (under pirate mode).