[JTC] Error codes for trajectory message rejections
#700 aberto em 14 de jul. de 2023
Métricas do repositório
- Stars
- (810 estrelas)
- Métricas de merge de PR
- (Métricas PR pendentes)
Description
I copied the comment from @gavanderhoorn into a new issue, open for discussions.
The message will be rejected, which means that nothing moves and the user will have a look in the command prompt.
I guess I would phrase this as:
The message will be rejected, which means that nothing moves and the user will have to look in the command prompt.
that's what I meant when I wrote:
A single error line in the controller's terminal is probably not sufficient to prevent surprises / confused users.
I've been such a confused user in the past, hence my comment.
Using action interface,
rclcpp_action::GoalResponse::REJECTis the result for the action client.Last time I checked, there was no support for setting the error_code or the error_string as part of the rejection, as you could in ROS 1 (https://github.com/ros2/rclc/issues/271).
That complicates things, but a work-around I've seen is to accept the goal, then 'abort' by never processing it and immediately sending the final result, in which you set the
error_codeanderror_stringto a meaningful value.Clearly a work-around, and I still consider the limitation discussed in the linked issue a serious design flaw, but it seems without some work, the best you can do.
The advantage of doing something like this is that clients would have machine readable information about what happened to their goal.
"the human needs to look at the command line" is not a viable error handling / recovery strategy in many cases, so should be avoided as much as possible. The
error_codefield could be used by clients to implement automated recovery, or at the very least promote the error returned by the JTC in a way easily visible to users (using some form of UI, or perhaps still anERRORin a log somewhere, but at least not hidden in the rest of the output).
Originally posted by @gavanderhoorn in https://github.com/ros-controls/ros2_controllers/issues/699#issuecomment-1635574490