Skip to content

Result.msg for Service Responses #279

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: rolling
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions std_msgs/CMakeLists.txt
Original file line number Diff line number Diff line change
Expand Up @@ -37,6 +37,7 @@ set(msg_files
"msg/Int8MultiArray.msg"
"msg/MultiArrayDimension.msg"
"msg/MultiArrayLayout.msg"
"msg/Result.msg"
"msg/String.msg"
"msg/UInt16.msg"
"msg/UInt16MultiArray.msg"
Expand Down
1 change: 1 addition & 0 deletions std_msgs/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,7 @@ For more information about ROS 2 interfaces, see [docs.ros.org](https://docs.ros
* [ColorRGBA](msg/ColorRGBA.msg): A single RGBA value for representing colors.
* [Empty](msg/Empty.msg): Does not hold any information, useful when the sending of a message would provide sufficient information.
* [Header](msg/Header.msg): Standard metadata for higher-level stamped data types used to communicate timestamped data in a particular coordinate frame.
* [Result](msg/Result.msg): Basic structure for returning information in a Service Response.

### Primitive Types
`std_msgs` provides the following wrappers for ROS primitive types, which are documented in the msg specification. It also contains the Empty type, which is useful for sending an empty signal. However, these types do not convey semantic meaning about their contents: every message simply has a field called "data". Therefore, while the messages in this package can be useful for quick prototyping, they are NOT intended for "long-term" usage. For ease of documentation and collaboration, we recommend that existing messages be used, or new messages created, that provide meaningful field name(s).
Expand Down
41 changes: 41 additions & 0 deletions std_msgs/msg/Result.msg
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
# Result code and message for service calls.
# Note that additional codes for specific services can defined within the service definition.
# For example, you could define a service CalculateSquareRoot.srv as
# float64 value
# ---
# int32 CODE_NEGATIVE_VALUE = -110
# std_msgs/Result result
# float64 root
#
# If a negative value is provided, the server could return the generic CODE_INVALID_ARGUMENT
# as result.code, or it could provide more context with CODE_NEGATIVE_VALUE.
#
# As a general guideline,
# Positive values are successes
# Negative values are failures
# Values between -1 and -100 are for some generic high-level failures
# Values between -101 and -1000 are for client (caller) errors (a la HTTP 4XX errors)
# Values between -1001 and -2000 are for server errors (a la HTTP 5XX errors)

int32 CODE_UNKNOWN = 0
int32 CODE_OK = 1

int32 CODE_GENERAL_FAILURE = -1

# Client Errors
int32 CODE_CANCELLED = -101
int32 CODE_INVALID_ARGUMENT = -102
int32 CODE_NOT_FOUND = -103
int32 CODE_ALREADY_EXISTS = -104
int32 CODE_PERMISSION_DENIED = -105
int32 CODE_FAILED_PRECONDITION = -106
int32 CODE_OUT_OF_RANGE = -107

# Server Errors
int32 CODE_INTERNAL = -1000
int32 CODE_UNIMPLEMENTED = -1001
int32 CODE_UNAVAILABLE = -1002
int32 CODE_DEADLINE_EXCEEDED = -1003

int32 code # Code number to be checked on return from service interface call
string error_message # Additional error description when useful.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

result and constants looks simulator specific, i do not think those are generic service response message in system layer. btw, do we not have something like error_message description when the service server returns the error? if that is missing, i think that would be useful for system? (user can leave it empty if they do not use it?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

result and constants looks simulator specific

As discussed in the PMC, I copied it over "as-is". It's updated now.

btw, do we not have something like error_message description when the service server returns the error? i

That existed in ROS 1 but cannot exist in ROS 2 because of the DDS spec (someone else can probably back it up with more precise language)