Skip to content

Add error message string to MoveItErrorCode msg#171

Merged
sjahr merged 5 commits intomoveit:ros2from
Abishalini:pr-add-error-string
Nov 14, 2023
Merged

Add error message string to MoveItErrorCode msg#171
sjahr merged 5 commits intomoveit:ros2from
Abishalini:pr-add-error-string

Conversation

@Abishalini
Copy link
Copy Markdown

When planning with MoveIt and MTC, we often assign the FAILURE error code. This is in an effort to add more description on why planning/execution failed.

Copy link
Copy Markdown

@sjahr sjahr left a comment

Choose a reason for hiding this comment

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

What do you think about adding an optional source string too?
E.g. like this:

// Name of the component that created the status
string source;

Copy link
Copy Markdown

@sjahr sjahr left a comment

Choose a reason for hiding this comment

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

Nit: Maybe consider removing the error_* prefix to avoid code like this:

MoveItErrorCode error_code;
error.error_message = "Ahh";

Copy link
Copy Markdown

@sea-bass sea-bass left a comment

Choose a reason for hiding this comment

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

I think this is conflating a bunch of things.

It makes more sense to me to have a MoveItError message which contains the MoveItErrorCode code plus a string message?

@adlarkin adlarkin self-requested a review November 10, 2023 16:15
Abishalini and others added 2 commits November 10, 2023 09:19
Co-authored-by: Sebastian Jahr <sebastian.jahr@tuta.io>
Co-authored-by: Sebastian Jahr <sebastian.jahr@tuta.io>
@sjahr
Copy link
Copy Markdown

sjahr commented Nov 10, 2023

I think this is conflating a bunch of things.

It makes more sense to me to have a MoveItError message which contains the MoveItErrorCode code plus a string message?

We'd need to do a lot of integration work by introducing an additional message type for that. What I like about having it in this message is that the message + the source information is immediately everywhere available where this message is used and we don't need to break anything

@simonschmeisser
Copy link
Copy Markdown

Please consider extending the 'enum' where necessary as well. Strings are hard to translate and error prone to handle in logic/error mitigation

@sea-bass
Copy link
Copy Markdown

What I like about having it in this message is that the message + the source information is immediately everywhere available where this message is used and we don't need to break anything

If this error message will be used as the "human-readable" description of the enum, that's very good and let's go ahead.

@rhaschke
Copy link
Copy Markdown
Contributor

If this error message will be used as the "human-readable" description of the enum, that's very good and let's go ahead.

The message shouldn't serve as a description of the enum - this can be created statically and we already have a method to do so. Rather, the message should be used (if at all) to provide some more specific reason of the failure, e.g. why planning failed.

@sjahr sjahr merged commit 2cbb6fd into moveit:ros2 Nov 14, 2023
@Abishalini Abishalini deleted the pr-add-error-string branch November 14, 2023 14:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants