std_srvs: add SetFloat32, SetInt32, SetString, SetUInt8, SetUInt8Array services

[xbroquer]

Summary

Add SetFloat32, SetInt32, SetString, SetUInt8, and SetUInt8Array service files.

Description

This PR extends std_srvs with five additional setter-style services and wires them into interface generation.

Changes:

• Add new service definitions:

  • std_srvs/srv/SetFloat32.srv
  • std_srvs/srv/SetInt32.srv
  • std_srvs/srv/SetString.srv
  • std_srvs/srv/SetUInt8.srv
  • std_srvs/srv/SetUInt8Array.srv

• Update std_srvs/CMakeLists.txt to generate interfaces for all new services.

• Update std_srvs/README.md to document the new services with usage-oriented descriptions.

• Update std_srvs/CHANGELOG.rst under Forthcoming.

Is this user-facing behavior change?

Yes.
New service interface types are now available in std_srvs for package users. Existing services are unchanged.

Did you use Generative AI?

Yes.
Tool: GitHub Copilot
Model: GPT-5.3-Codex
Usage: Assisted with writing the PR description

Additional Information

• Change is additive and non-breaking for existing std_srvs users.
• Verified in local workspace with colcon build for std_srvs and a dedicated test package exercising all new services.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request

[asymingt]

Hi @xbroquer. First off, thank you for the contribution. We have to be very careful with changes like these because they set a precedent about what should be accepted into the core message libraries. To be a good fit here, we have to make sure that the usefulness brought to the wider community outweighs the additional compilation time.

For this reason I need to know a few things about why you added these messages.

1. All ROS nodes have a parameter mechanism, which allows other entities to get and set values. I have a hunch that this mechanism might be what you are after. Here's an introduction to them: https://docs.ros.org/en/lyrical/Tutorials/Beginner-CLI-Tools/Understanding-ROS2-Parameters/Understanding-ROS2-Parameters.html.
2. Assuming that the parameter mechanism doesn't work for you, can you justify why you aren't able to create and use your own custom messages in you own custom ROS package to achieve what you need. See: https://docs.ros.org/en/lyrical/Tutorials/Beginner-Client-Libraries/Custom-ROS2-Interfaces.html

If you still think that these messages are useful in some way that I haven't covered in the two points above, can you prepare a justification and I will bring this PR to the ROS PMC for discussion.

[xbroquer]

Hi @asymingt ,

Thank you for the review. I agree this change requires strong justification as it impacts core interfaces.

Context: I am a software engineer at Renault Group, leading a ROS-based platform for ADAS prototyping. We started on ROS 1 Kinetic, then migrated through each ROS 2 LTS generation. We are currently on Jazzy and have already begun supporting Lyrical. We use ROS 2 parameters extensively for configuration and runtime algorithm tuning.

This proposal is not intended to replace parameters, but to address a different interface contract.

Rationale:
Parameters are suited for node configuration and state, while Set* services are for immediate command calls with typed input and direct feedback (success/message). Parameters remain the default for configuration and tuning, and Set* services are only used for command-style RPC interactions.

Why parameters are not sufficient for this subset of interactions:

1. Some interactions are commands, not configuration updates.
2. We need immediate per-call feedback (success/failure + message), not just changed state visibility.

Concrete examples:

1. SetUInt8Array: gateway unlock/control where the client sends a byte payload and gets immediate success/message feedback.
2. SetString: command inputs such as profile or mode selection, or file-load requests, where the result must be returned synchronously.
3. SetUInt8: compact command APIs where the value represents an enum-like command (e.g., start/stop/mode/action selection) and the caller needs immediate feedback that the command was accepted/executed (bool + message).
4. SetInt32: diagnostic command APIs where the int32 request carries a numeric identifier (e.g., a DID in automotive DoIP diagnostics) and the service returns immediate success/message feedback containing the result or diagnostic error.

Why upstream instead of keeping private duplicates:

1. We already maintain an internal xxx_std_srvs package extending std_srvs with generic Set* primitives.
2. These interfaces are not domain-specific and represent recurring patterns duplicated across packages.
3. This proposal extends existing primitives (e.g., Empty, SetBool, and Trigger).
4. Upstreaming avoids repeated redefinition of identical simple RPC interfaces (primitive payload + bool/message response).
5. As standardized interfaces, these services can improve interoperability and benefit the wider ROS community.

Optional scope note: SetFloat32 is included for completeness of scalar primitives, but can be omitted if needed to keep the scope minimal.