Proposal: Add SetString.srv to std_srvs
Summary
I would like to propose adding a simple SetString.srv definition to the std_srvs package, similar in spirit to the existing SetBool.srv.
Motivation
std_srvs/SetBool provides a minimal and widely reusable pattern for simple command-style services:
bool data
---
bool success
string message
In practice, many systems require a similar pattern but with a string payload instead of a bool. A common example is mode switching, command dispatching, or passing standardized string-based instructions (e.g., from external protocols or industrial specifications).
Currently, developers must repeatedly define custom services such as:
string data
---
bool success
string message
across multiple packages and projects. This leads to unnecessary duplication of identical interface definitions and reduces interoperability.
Use Cases
Typical use cases include:
- Setting a mode by name (e.g.,
"AUTO", "MANUAL", "PAUSE")
- Forwarding externally defined string commands
- Bridging industrial communication standards that rely on string-based command semantics
- Rapid prototyping and testing via CLI tools
In many real-world integrations (especially when ROS 2 is used as an interface layer rather than a full application framework), a generic SetString service would reduce friction and boilerplate.
Proposed Definition
string data
---
bool success
string message
This mirrors the structure and philosophy of SetBool, maintaining consistency within std_srvs.
I appreciate any feedback from maintainers and the community.
Proposal: Add
SetString.srvtostd_srvsSummary
I would like to propose adding a simple
SetString.srvdefinition to thestd_srvspackage, similar in spirit to the existingSetBool.srv.Motivation
std_srvs/SetBoolprovides a minimal and widely reusable pattern for simple command-style services:In practice, many systems require a similar pattern but with a
stringpayload instead of abool. A common example is mode switching, command dispatching, or passing standardized string-based instructions (e.g., from external protocols or industrial specifications).Currently, developers must repeatedly define custom services such as:
across multiple packages and projects. This leads to unnecessary duplication of identical interface definitions and reduces interoperability.
Use Cases
Typical use cases include:
"AUTO","MANUAL","PAUSE")In many real-world integrations (especially when ROS 2 is used as an interface layer rather than a full application framework), a generic
SetStringservice would reduce friction and boilerplate.Proposed Definition
This mirrors the structure and philosophy of
SetBool, maintaining consistency withinstd_srvs.I appreciate any feedback from maintainers and the community.