-
Notifications
You must be signed in to change notification settings - Fork 21
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
Update REP-I0001 with implementation-related changes/clarifications #13
base: master
Are you sure you want to change the base?
Conversation
- add missing fields to Dynamic_Joint_State, to match ROS API - reorder/add fields in Dynamic_Group_Status, to match existing RobotStatus msg - rework configuration parameter, to minimize duplication - elaborate on operation, configuration, usage, and backwards compatibility
@@ -62,8 +62,7 @@ The industrial robot controller motion interface shall meet the following requir | |||
|
|||
Design Assumptions | |||
========= | |||
The following assumptions are inherent in the client/server design: | |||
* All joints (regardless of group) shall be uniquely named. | |||
None at this time. |
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.
Could you clarify why you removed that assumption? I can see why it would make sense to remove the regardless of group bit, but now it allows for multiple joints in the same group being identically named. Is that intentional?
@JeremyZoss wrote:
The |
@@ -42,7 +42,7 @@ The following definitions are used throughout: | |||
Motivation | |||
========== | |||
|
|||
The first version of the motion/status interface (loosely documented in code and wikis) worked well for single arm manipulators. Multi-arm (asynchronous or synchronous) was not supported in a generic manor that could be used across all platforms [#discuss]_. Some attempts were made to support multiple arms using the existing interface, but these often required multi-arm joint states which could exceed the max number of joints and did not allow for mixed multi-arm/single-arm motion. The intent of this REP is to define a new set of simple messages[#simp_msg]_ for multi-arm control. These messages will replace existing motion control message (they will be deprecated). The approach taken in the REP is one that creates a new set of clients for robot motion. The underlying simple message libraries will remain unchanged (except for the addition of new messages). | |||
The first version of the motion/status interface (loosely documented in code and wikis) worked well for single arm manipulators. Multi-arm (asynchronous or synchronous) was not supported in a generic manner that could be used across all platforms [#discuss]_. Some attempts were made to support multiple arms using the existing interface, but these often required multi-arm joint states which could exceed the max number of joints and did not allow for mixed multi-arm/single-arm motion. The intent of this REP is to define a new set of simple messages[#simp_msg]_ for multi-arm control. These messages will replace existing motion control message (they will be deprecated). The approach taken in the REP is one that creates a new set of clients for robot motion. The underlying simple message libraries will remain unchanged (except for the addition of new messages). | |||
|
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.
Missing space between messages and [#simp_msg]_
(in "new set of simple messages[#simp_msg]_ for multi-arm control").
In the Dynamic Group Status section, there is a missing space between message and |
Would it be an idea to increase the visibility of the sentence:
by putting it under Assumptions or giving it its own paragraph/section somewhere? That is a rather big change from how |
- update header lines to meet RST spec - re-add unique joint-name assumption - fix literal-text to RST syntax - misc spaces and typos - add example for namespace-mapping config/behavior - add more discussion of `valid_fields` feature
This just caught my eye, and although I know this was already in the original, I thought this PR would be a good time to bring it up (also as there are no actual implementations currently using any of the structures defined in the REP). Do we really need all of the |
Also: all msg structures have a |
Also: no mention of units to be used in any of the fields. Suggest adding that to an Assumptions section, or stating it somewhere near the structure definitions. I assume it's going to be something like:
|
@gavanderhoorn wrote:
@JeremyZoss: could you address this one? I think my email already made it clear that it's a good idea to give this a more prominent place in the REP :). |
I thought I had sufficiently clarified this in my last commit (af8a3ca, line 72). Let me know if you have suggestions for improvements. Maybe it needs to be shorter, like a bullet point? Or repeated under "assumptions"? |
@JeremyZoss: perhaps we could add subsections to the Simple Message Structures section that detail the differences between v1 and v2 (this REP). We could also document the bit positions defined for |
@gavanderhoorn, you are correct. The reason they were all included was to mirror the JointTrajectoryAction feedback. In the interest of reducing the the packet size, we could remove one. |
@shaun-edwards: ok, then I propose we remove the Thoughts? |
Question: was not including any specs on the types of fields (sizes, signedness, etc) on purpose? |
Sorry for all the posts, but: both We've been conservative with timestamps in the protocol (as clocks with sufficient resolution might not be common), but as the One issue with a timestamp is the requirement for common clocks, which may be unrealistic. ROS depends on NTP, which some robot controllers support, but that is probably not a good idea (I can imagine NTP not being usable in factory contexts). An alternative to common clocks is to establish the offset between two clocks and compensate for that on reception of msgs. There are established algorithms for that, and it would involve some simple message exchanges. Adding the |
@gavanderhoorn wrote:
Actually, the I don't know that it makes sense to timestamp the data being sent to the controllers ( In the ROS side, this timestamp would be most-logically integrated into the My vote would be to leave the |
@JeremyZoss wrote:
That is probably true for
Yes, in the current bridging / client-server design, it would mostly make sense for data server->client.
Well, as I said, syncing is not required, offset calculation would also work. Another alternative could be to not sync anything, but to make sure that delta T between bridged messages is consistent. The ROS node would then use the incoming
Hm, I'm not too much of a fan of adding fields later. Many controllers do not support things like byte buffers, which make it easy to 'ignore' data 'at the end' that they don't know how to serialize. For Fanuc fi, the deserialiser would have to be designed with that functionality in mind, as it will have to read any excess bytes out of the socket. If we want that, that is fine, but then this REP (or maybe a future one, documenting the bytestream itself) should explicitly state that. |
--------- | ||
The dynamic group status is meant to mimic both the ROS-I RobotStatus message. See the RobotStatus message[#rbt_stat]_ for field descriptions.:: | ||
-------------------- | ||
The dynamic group status is meant to mimic both the ROS-I RobotStatus message. See the RobotStatus message [#rbt_stat]_ for field descriptions.:: |
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.
"meant to mimic both the ROS-I RobotStatus message": is something missing here? Mimic both RobotStatus and what other message?
Another question: should we address ros-industrial/ros_industrial_issues#27 (add support for linear (or: non-revolute) axes) in this update to this REP? Or at least make sure there is nothing preventing us from supporting that in a future extension? Linear axes should map into prismatic joints in a urdf, and joint states reported for them should be in meters. As the issue asks: is there any special infrastructure and / or functionality required for support of linear axes? I think on the ROS side, the urdf would contain the required information. The robot driver is out of scope for this document. Should the group config file format get any special elements? @JeremyZoss? |
And another question: should we support 'real' point-to-point streaming (ie: points not part of a trajectory, but generated on the fly by some process)? The I'm thinking specifically of use cases like those covered by the fs100_motoman pkg, and the adaptations to the |
|
||
Dynamic Joint Point | ||
--------- | ||
------------------- | ||
The dynamic joint point is meant to mimic the ROS JointTrajectory message structure [#traj_msg]_. A one-to-one mapping of the joints included in the ROS message to the simple message shall be created. By encapsulating the entire trajectory in a single message, synchronized motion is possible.:: |
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.
By encapsulating the entire trajectory in a single message, synchronized motion is possible.
Isn't synchronised motion only dependent on the trajectory point containing info for all groups that are to be part of the motion? A Dynamic Joint Point
is still just one point, right?
Would there be interest in continuing / wrapping up this discussion? I think there was some really good progress made in this PR. |
I'm working to implement this REP, and had a few suggestions for how it might be changed to improve flexibility and ease-of-use. I also wanted to add a bit more explanation about intended usage and operation, to make sure we're all on the same page.
Summary of the updates:
RobotStatus
msgNot to re-open something that's already been finalized, but I'd rather have input before everything's been implemented...