Add vda5050 safety state msg

[YaraShahin]

This PR introduces a new message definition: VDA5050SafetyState.

VDA5050SafetyState provides a standardized message for reporting the safety state of a robot or AGV in accordance with the VDA5050 schema. The fields and enumerations in this message are directly derived from the official VDA5050 specification to ensure compatibility with VDA5050-compliant fleet management systems and controllers.

While this message already exists in the ipa320/vda5050_msgs package, it is being added to control_msgs to:

• Enable direct integration with the upcoming vda5050_safety_state_broadcaster in ros2_controllers, and

• Ensure that the message is maintained and versioned alongside other core control interfaces.

---

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.

[saikishor]

LGTM

One curious question, would it make sense to have it within the VDA5050State message?

[YaraShahin]

LGTM

One curious question, would it make sense to have it within the VDA5050State message?

Thanks @saikishor for the review!

I considered including it directly within VDA5050State, but that message doesn’t currently have the same structure as the VDA5050 schema; it only includes a subset of fields and subfields from different sections.

The message in this PR represents the complete safetyState section from the VDA5050 spec, so I kept it separate to stay consistent with the schema’s modular layout.

In the future, if we decided to expand VDA5050State toward full representation, we could rework it to include submessages for each section (like SafetyState, Header, OrderState, etc.), similar to how it’s structured in the original specification.

[saikishor]

The changes of this PR look good to me.

Just curious, if it makes sense to have them as uint8 enums instead of the strings. I also agree that VDA5050State uses strings within it. I just thought about this after looking at the guidelines in the following links

https://coatyio.github.io/vda-5050-lib.js/api/interfaces/SafetyStatus.html#eStop

https://github.com/coatyio/vda-5050-lib.js/blob/80345b2/src/common/vda-5050-types.ts#L1718

[saikishor]

Suggested change

	string e_stop # Enum {autoAck, manual, remote, none} Acknowledge-Type of eStop:
	uint8 e_stop # Enum {autoAck, manual, remote, none} Acknowledge-Type of eStop:

Suggested change

	string e_stop # Enum {autoAck, manual, remote, none} Acknowledge-Type of eStop:
	uint8 e_stop # Enum {autoAck, manual, remote, none} Acknowledge-Type of eStop:

[saikishor]

Suggested change

	# Enums for eStop
	string AUTO_ACK="autoAck"
	string MANUAL="manual"
	string REMOTE="remote"
	string NONE="none"
	# Enums for eStop
	uint8 AUTO_ACK="autoAck"
	uint8 MANUAL="manual"
	uint8 REMOTE="remote"
	uint8 NONE="none"