Add BatteryStates msg

[YaraShahin]

Description

This PR introduces a new message definition: BatteryStates.

• BatteryStates contains an array of sensor_msgs/msg/BatteryState messages.
• The purpose is to support broadcasting the status of multiple batteries from a single source.
• This message will be used by the battery_state_broadcaster in ros2_controllers: ros-controls/ros2_controllers#1888.

Is this user-facing behavior change?

No

Did you use Generative AI?

No

Additional Information

This PR is being opened following discussion in ros-controls/control_msgs#250. The BatteryStates message was initially proposed for control_msgs, but @saikishor recommended placing it in sensor_msgs instead, since:

• It's built on top of sensor_msgs/BatteryState.
• It represents sensor data rather than control-specific info.
• Other projects beyond ros2_controllers may have similar use cases for representing multiple battery states.

[gavanderhoorn]

Perhaps it was already discussed in the issues/PRs you link, but would publishing multiple BatteryState messages "at the same time" not be an option (perhaps even with a shared timestamp)?

[nnarain]

At my work, we originally subscribed to a list of individual battery state topics. However what we are moving to now is a list of battery states like this because it makes for a cleaner interface.

[gavanderhoorn]

Couldn't you publish to the same topic?

There is no 1-to-1 requirement for this to work.

[YaraShahin]

Perhaps it was already discussed in the issues/PRs you link, but would publishing multiple BatteryState messages "at the same time" not be an option (perhaps even with a shared timestamp)?

Thank you @gavanderhoorn for the great question! You're right that we could technically publish individual BatteryState messages in the same update loop. However, there are some important considerations, particularly from the ros2_control perspective:

• Guaranteed delivery and synchronization: With an array, subscribers receive all battery states in a single callback, guaranteed to be from the same sampling cycle. If we instead published separate messages (even with identical timestamps), subscribers would need extra logic (message filters, buffers) to synchronize them, and risk processing incomplete sets if one message drops.

• Deterministic ordering and lookup: The array provides a defined and stable order, allowing users to look up each battery state by index (aligned with the controller’s state_joints parameter). With individual messages, users would need to parse frame IDs to match the batteries, as the message arrival order is not guaranteed even if they are published sequentially in the same loop.

• Consistent pattern: Similar to messages like sensor_msgs/JoyFeedbackArray, diagnostic_msgs/DiagnosticArray, and visualization_msgs/MarkerArray, this approach groups related elements into a single message where order and synchronization matter.

While this design was motivated by ros2_control, it also benefits other applications that need to handle multiple batteries as one system. This structure also leaves room for future extensions, such as including common system-level metadata.

I hope this clarifies the reasoning! Happy to discuss further if you have other thoughts.

[fujitatomoya]

just some comments, i do not have any objections against this suggestion, especially for consistent pattern.

risk processing incomplete sets if one message drops.

i do not think this is not responsibility for the message type, this sounds pretty much for QoS Reliability.

The array provides a defined and stable order, allowing users to look up each battery state by index (aligned with the controller’s state_joints parameter).

i would use serial number or location as identification instead of application specific and static index order, so that subscription can be more flexible?

it also benefits other applications that need to handle multiple batteries as one system.

and there can be also applications that just want to receive the specific battery state message only, right?
in that case, they also need to receive unnecessary messages from the array... i think this is wasting the resources.

after all, i would do,

• publish indivisual battery state to single battery topic.
• set QoS Reliability for battery topic.
• if necessary, configure the content filtering based on location or serial number on the subscriptions.