Add Keys and Float64Values messages

[saikishor]

This PR adds the StringArray and ValuesArray message needed for the generic state broadcaster or the interface state broadcaster

[christophfroehlich]

shouldnt the names be more specific? Like interface_names and interface_values or something like this? And why using two messages? If you want to go in the direction of pal_statistics, why not just use the messages from there?

[saikishor]

shouldnt the names be more specific? Like interface_names and interface_values or something like this? And why using two messages? If you want to go in the direction of pal_statistics, why not just use the messages from there?

I thought of having new messages that are generic and fix different use cases at the same time. The idea of using 2 messages is to reduce the size of the message. As per @bmagyar suggestion, I think it is a good idea to go with 2 different publishers, one as a transient_local for names and another for the list of values

Regarding pal_statistics messages, I didn't want to depend on pal_statistics messages per se, as they semantically do not fit the current use case. Moreover, we will have only 1 version and won't be using the version tag

[christophfroehlich]

I thought of having new messages that are generic and fix different use cases at the same time.

Following the strategy of removing generic message types from std_msgs, I'd avoid "generic" messages but be more descriptive here.

The idea of using 2 messages is to reduce the size of the message. As per @bmagyar suggestion, I think it is a good idea to go with 2 different publishers, one as a transient_local for names and another for the list of values

This is fine.

Regarding pal_statistics messages, I didn't want to depend on pal_statistics messages per se, as they semantically do not fit the current use case. Moreover, we will have only 1 version and won't be using the version tag

Ok.

[saikishor]

Following the strategy of removing generic message types from std_msgs, I'd avoid "generic" messages but be more descriptive here.

@christophfroehlich What you say is very valid. I understand it. I was about to make the change and unfortunately found this InterfaceValue.msg this doesn't allow me to rename the message. Any help with alternative naming?

[christophfroehlich]

Maybe InterfaceNames and InterfaceValues? This would be similar to pal_statistics_msgs?
Or InterfacesNames and InterfacesValues?

[christophfroehlich]

pre-commit, apart from that LGTM

[Juliaj]

LGTM.

[tfoote]

I would recommend a lot more documentation about when/where to use this and how it compares to InterfaceValue.msg which is a neighbor and appears equivalent. When should one be used versus the other?

I believe that these are assuming correlation of ordering and length between these two messages. That should be documented.

Will it make sense to capture a sense of scope for what these interfaces are covering? If I was introspecting a rosbag I'm not sure that I could render these values helpfully without more information.

[christophfroehlich]

I understand your point of view. We just maybe are thinking from the other end, we plan to implement a new broadcaster: Together with its usage the message make sense (for us). With having a look on the messages only, it might not.
We can at least document the advantages of the name-value messages in the msg file itself?

[saikishor]

As per the voting to rename the messages during the last PMC meeting (03rd December, 2025) I renamed the messages to Keys.msg and Float64Values.msg