-
Notifications
You must be signed in to change notification settings - Fork 133
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
Action file support #311
Action file support #311
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sservulo I left some comments, nice work!
lines[separator_indices[1] + 1:] + implicit_output) | ||
feedback_msg = parse_message_string( | ||
pkg_name, action_name + ACTION_FEEDBACK_MESSAGE_SUFFIX, message_string) | ||
#---------------------------------------------------------------------------------------------- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sservulo Hmm, implicit fields may clash with explicitly given ones. Action generation in ROS1 would nest message definition as a field of a completely implicit message, see genaction.py sources. Alternatively, we could check for the presence of duplicate entries. @sloretz @jacobperron thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good point. +1 to nesting the user defined message
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed review comments. |
action_name + ACTION_GOAL_MESSAGE_SUFFIX + SERVICE_REQUEST_MESSAGE_SUFFIX, | ||
request_message_string) | ||
|
||
implicit_output = ["bool accepted", "builtin_interfaces/Time stamp"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jacobperron @hidmic Will rcl_actions
associate the service response by mapping goal ID to the request sequence number, or by having the higher level client library get the goal ID out of the message? If the former then these fields should be OK, if the latter then the stamp field should be action_msgs/GoalInfo
so it includes a goal id too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that'd be currently the case (using goal IDs I mean).
action_name + ACTION_RESULT_MESSAGE_SUFFIX + SERVICE_REQUEST_MESSAGE_SUFFIX, | ||
request_message_string) | ||
|
||
implicit_output = ["int8 status"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the status field for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's the goal status as defined in the proposal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoops, I completely forgot about that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jacobperron same question about rcl_actions
using the sequence number vs goal id. If the latter then using action_msgs/GoalStatus here would get that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above.
Besides a couple questions about the implicit fields, I think with a couple unit tests for parsing actions I think this could be merged, and then #310 could be re-targeted at master. |
Added tests to Action parser and included some fixes in implicit field collision logic. Note that the Action messages suffixes were changed in |
@sloretz @jacobperron I'd say we get this one in to unblock the rest. If the current set of implicit fields is later unfit (which I'm inclined to think but we may find out that it's not), we can change them. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the late review.
I think the current set of implicit fields are okay, although we might consider using types defined in action_msgs
so then any changes there are automatically reflected in the generated services/topics. I'm okay with merging this as is pending the one comment regarding the check for implicit field collisions.
# check for field name collision with action implicit parameters | ||
# (e.g. 2 or more occurrences of a field_name contained in ACTION_IMPLICIT_FIELDS, | ||
# including the implicit one) | ||
if field_name in ACTION_IMPLICIT_FIELDS and action_fields[field_name] >= 1: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean that .msg
or .srv
specs containing an implicit action field will also raise a collision exception?
If so, maybe it would be better to pass in a list of invalid fields to the function instead of using ACTION_IMPLICIT_FIELDS
directly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jacobperron It will trigger only if a field named with the same name as one implicit field is in the spec and there are at least two of them (replacing a ValueType
error in this case), to make sure it triggers only when there's duplication, so if you have a field named uuid
used in your msg definition it will not trigger. Should I go with the invalid fields route, then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the clarification. I think it is fine to leave it as-is.
|
||
import pytest | ||
|
||
# from rosidl_parser import InvalidServiceSpecification |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: remove comment
@jacobperron @sservulo looks like this one's ready to go! |
|
||
|
||
def parse_action_string(pkg_name, action_name, action_string): | ||
action_blocks = action_string.split(ACTION_REQUEST_RESPONSE_SEPARATOR) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This logic is incorrect. It e.g. even matches a ---
in a comment. Please use the same logic as for splitting the request and response in a service.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right. I had not considered the possibility of a separator in comments. So it's either above's logic using slices or re.split('^---$', action_string, flags=re.MULTILINE)
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed using re w/ multiline. @dirk-thomas Is this approach OK for you or do you have a strong preference for the slice logic?
This PR closes #305. Added
.action
file parsing to rosidl_parser.CMake preprocessing of .action files into services and messages is coming to this branch from
sloretz/speficication-to-str
.