add BatteryStates msg

[YaraShahin]

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 controller.
• This message will be used by the upcoming battery_state_broadcaster in ros2_controllers.

Contributions via pull requests are much appreciated. Before sending us a pull request, please ensure that:

1. Limited scope. Your PR should do one thing or one set of things. Avoid adding “random fixes” to PRs. Put those on separate PRs.
2. Give your PR a descriptive title. Add a short summary, if required.
3. Make sure the pipeline is green.
4. Don’t be afraid to request reviews from maintainers.
5. New code = new tests. If you are adding new functionality, always make sure to add some tests exercising the code and serving as live documentation of your original intention.

To send us a pull request, please:

• Fork the repository.
• Modify the source; please focus on the specific change you are contributing. If you also reformat all the code, it will be hard for us to focus on your change.
• Ensure local tests pass. (colcon test and pre-commit run (requires you to install pre-commit by pip3 install pre-commit)
• Commit to your fork using clear commit messages.
• Send a pull request, answering any default questions in the pull request interface.
• Pay attention to any automated CI failures reported in the pull request, and stay involved in the conversation.

[christophfroehlich]

For reference, there is an ongoing discussion in extending the upstream message
ros2/common_interfaces#299

[YaraShahin]

For reference, there is an ongoing discussion in extending the upstream message ros2/common_interfaces#299

Thanks for the pointer! I had a look at ros2/common_interfaces#299, from what I see, that discussion is about extending the fields inside sensor_msgs/BatteryState.

My PR here is introducing BatteryStates, which is just a container for multiple BatteryState messages. As long as the upstream keeps the existing fields (and only adds new ones), this stays fully compatible.

In my use case (Battery State Broadcaster), I can later extend the broadcaster to also publish any new fields that get added upstream, but that doesn’t affect the current functionality of this message.

[nnarain]

As part of the work @cmccrave-CPR is working on we also need a topic with a list of battery states. So this work will be useful to us as well

[saikishor]

Shouldn't this be in the sensor_msgs itself?.

I understand that this is made for the broadcaster, but we can always create multiple instances of the broadcaster to publish info on multiple topics in the meantime

[YaraShahin]

Shouldn't this be in the sensor_msgs itself?.

I understand that this is made for the broadcaster, but we can always create multiple instances of the broadcaster to publish info on multiple topics in the meantime

Thanks @saikishor for your comment. I see what you mean, but running multiple broadcaster instances wouldn't quite work for this use case. The broadcaster not only publishes multiple battery states, but also performs aggregation across all batteries.

Specifically, it publishes:

• A control_msgs/BatteryStates message for each battery (array of per-battery data).

• An aggregated sensor_msgs/BatteryState message with system-level metrics (averages, sums, combined status and health).

With separate broadcaster instances, you'd only get the individual battery states and lose the synchronized, aggregated system-level view — which is one of the core features.

I kept BatteryStates in control_msgs since it’s specific to the broadcaster and how it structures its multi-battery data but I’m open to moving it if you think sensor_msgs would make more sense long-term.