REP for Cartesian moves in Simple Message

[frederickproctor]

This is a REP for adding Cartesian Moves to the Simple Motion protocol.

[gavanderhoorn]

Bit nitpicky perhaps, but REPs can only be assigned a nr once they've been accepted and are made active.

That is not actually true, see REP-001: REP work flow. I'm not too sure how much we actually follow all of that though.

[gavanderhoorn]

Thanks for this REP/PR, Cartesian motion primitives are certainly something that is needed in Simple Message.

Some additional comments / questions:

• the REP does not say anything about the units used for any of the fields. Even if they use SI units (meters, radians), I think this should be mentioned somewhere to avoid possible confusion.
• no support for multiple motion groups: is that intentional? Can you clarify how implementations should handle multiple independent motion groups with Cartesian moves (ie: N-arm setups without coordinated motion)?
• can you give some concrete examples of where Object State is necessary? Could the same use cases not be covered by multi-group support in all other Cartesian messages, similar to how JOINT_FEEDBACK or JOINT_FEEDBACK_EX work?

[shaun-edwards]

In implementing the multi-robot interface, we have come across issues in the byte array library that make it difficult to have variable length messages. @JeremyZoss, can provide some insight here. This will be fixed. I'm curious if you guys ran into the same issues.

[JeremyZoss]

The issue we ran into with rep-I0001 was that the ByteArray class is written to parse a message by popping data off the message array. The internals use a simple fixed-length array, which makes it trivial to read data off the end of the array, but expensive to read data from the front of the array. All current messages load data into the ByteArray start->finish, but read data out the array finish->start.

This pattern is difficult for dynamically-sized arrays, which typically place the dynamic array-size near the start of the message. This proposed message type would not be too bad to parse using the current ByteArray, but rep-I0001 requires parsing the entire message from the front. I'm working on a fix to the internal data structures that will allow for low-cost reading from either the front or end of ByteArray, which should eliminate this issue.

[shaun-edwards]

Regarding

no support for multiple motion groups: is that intentional? Can you clarify how implementations should handle multiple independent motion groups with Cartesian moves (ie: N-arm setups without coordinated motion)?

I'd like to avoid mixing these two. I'd rather get a single robot version that work well, and then extend it just like we did with joint motion.

Some ideas for things that are missing:

• No defined tool/object frames. A Cartesian move should be defined for a tool with respect to an object frame. Is it assumed or specified somewhere?
• Orientation interpolation method not specified. I'm not hung up on this, but should we specify how the robot controller performs the orientation motion? I'm not sure we have this level of control, so maybe we should just say it's up to the controller.
• Should we specify the other mixed motion commands, ex:
  • Joint move to joint point (already exists)
  • Cart move to Cart point (proposed)
  • Joint move to a Cart point (not specified)
  • Cart move to Joint point (not specified)

[JeremyZoss]

I'd like to add my +1 to several of the points raised earlier:

• Orientation
  • native representation may be different per-controller
  • only ABB supports quaternions natively?
  • conversion to/from quaternions on-controller may be difficult (limited math support)
  • recommend: float[4] array for orientation. Meaning is controller-specific. Could be used for Euler angles (any convention) or quaternions. Robot-side driver can convert to std ROS orientation.
• Missing Fields
  • tool/user frame assumptions
    • integer IDs preferred (not explicit XYZ values), for simplicity robot-side?
    • requires ability to read frame info (by ID) from robot: service call preferred?
  • configuration flags (elbow up/down, wrist flip, etc)
    • very robot-specific, both in meaning and representation. How to do cross-platform?
  • multi-turn flags (for joints with >360 range)
• Motion Type
  • it may be helpful to distinguish between motion type (linear) and target-position format (cart vs. joint)
    • linear motion to target joint point would be an easy extension from current messages
    • cartesian position requires tackling more "issues": orientation format, config flags, etc.
  • better to use one message type per "mode", or a single message type with "mode flags"?
• Multi-Group Support
  • it would be cleaner to include multiple motion-group support from the start, rather than adding later
• Cartesian Feedback
  • this should be broadcast in sync with joint_state, not tied to motion command
    • doesn't need a sequence field
  • is it acceptable to publish separate joint/cart feedback messages back-to-back, or should we consolidate into a single feedback message (for synchronization)?
• Object State
  • is this general-use enough to warrant adding to the standard message set, or is this an application-specific message?

Also, I think it's worth emphasizing that the same cartesian point representation be used in all the types of messages that require it, for standardization. I'm thinking something similar to how joint_data is used in the current simple_message types. We should define this type (not a full message in its own right) in this REP, and then use that type in the different message-format descriptions that require it.

Sorry this sounds like a lot of criticism! We knew this would be a tough message type to standardize, which is part of why it hasn't been included yet.

[frederickproctor]

Thanks for all your thoughtful comments on the Cartesian motion REP. Regarding units, I prefer stipulating that all units are SI units (meters for length, radians for angle, seconds for time), rather than adding a field to the message saying what units are being used, or a modal message to set the units for future messages. Are SI units used for all the joint messages?

Regarding orientation representations. quaternions have a lot of advantages over other representations, but if there is a clear winner on the controller side like ZYZ Eulers, that would be OK. I think we should stipulate which one will be used, rather than allow it to be up to the controller. Same for Cartesian XYZ - mostly this never comes up, but there are other representations for location coordinates (cylindrical, spherical) that could be used.

Regarding which frame the poses are relative to, we assumed the world frame. Motion in the tool frame can be accomplished by transforming tool frame poses into the world frame before sending messages. There could be a flag specifying which frame is used: robot base, world frame, tool frame. In the robots I have used, there is a built-in utility for establishing the world frame with respect to the robot base frame, so that you can move the robot around a bit without needing to change the application coordinate values.

Configuration flags are tricky. We did not specify them in the motion messages and assumed that these flags would not change during a Cartesian move. If you wanted the robot to flip to a new set of flags, you would do this with a prior joint move, thus establishing a new set of flags that would be maintained during subsequent Cartesian moves.

Feedback could be a separate message, interleaved with joint state messages. Or, it could replace joint state messages when the Cartesian motion mode has been set. I think it would be helpful if the robot controller streamed back both joint and Cartesian state information always, but having a new message that combines both may be more of a pain than simply saying that both should be sent back continually. The sequence number is handy but not necessary. What about timestamps for every state message?

Regarding how the robot moves when given a Cartesian move, we assume that the XYZ location moves along a straight line, and that the orientation moves about a fixed vector that corresponds to the angle-axis representation of the motion increment. The motion could be specified with a single elapsed time value, or with two speeds, and the linear and angular motion speeds would be scaled so that the faster part is slowed down to arrive when the slower part gets there.

Regarding variable-length messages, if this is hard to achieve and we don't use it, then we should just abandon the 'length' field in messages.

The object state message is strange, I admit. We used it to report the location of objects that the robot new about. It arose when we tied a V-Rep simulation of a workspace to a higher-level controller that had the robot move objects around. Putting this in the Simple Message interface might not be the way to go. Have any of you encountered the need for information about robot objects that the robot controller maintains?

[gavanderhoorn]

@frederickproctor wrote:

Regarding units, I prefer stipulating that all units are SI units (meters for length, radians for angle, seconds for time), rather than adding a field to the message saying what units are being used, or a modal message to set the units for future messages.

I don't think anyone proposed that? My comment was that the current text does not say anything about which units are to be assumed in the messages. A single statement (perhaps in an Assumptions section) would suffice.

Are SI units used for all the joint messages?

yes.

Regarding orientation representations. quaternions have a lot of advantages over other representations, but if there is a clear winner on the controller side like ZYZ Eulers, that would be OK. I think we should stipulate which one will be used, rather than allow it to be up to the controller

What I understood from @JeremyZoss' comment is that we define the message such that the fields are there, but the contents (so order of axes and their interpretation) is left to the driver author. That way, driver authors are free to use a format that fits their controllers best, while still standardising on msg syntax. Obviously, the generic clients in industrial_robot_client would only support a single convention, so if that works with a controller, authors should use that.

I'm not sure whether that is a good approach. I think I'd like to standardise semantics as much as syntax here for these messages. Especially perhaps because there are so many different options.

Regarding which frame the poses are relative to, we assumed the world frame. Motion in the tool frame can be accomplished by transforming tool frame poses into the world frame before sending messages.

I agree that this is a viable approach. Again though, I feel a REP like this should then make that assumption explicit. The text should be updated to remove any ambiguities like this.

In the robots I have used, there is a built-in utility for establishing the world frame with respect to the robot base frame, so that you can move the robot around a bit without needing to change the application coordinate values.

Are there really many robots that can change the pose of their world frames? If you are referring to user or object frames: in that case I think there should actually be a way to make it explicit in which frame a position is defined, as most robots support multiple such frames, and they can be changed at runtime.

Configuration flags are tricky. We did not specify them in the motion messages and assumed that these flags would not change during a Cartesian move. If you wanted the robot to flip to a new set of flags, you would do this with a prior joint move, thus establishing a new set of flags that would be maintained during subsequent Cartesian moves.

Should we then perhaps specify that no Cartesian move initiated by a Cartesian Move Request could ever result in a configuration change? It would then become the path generator's responsibility to deal with this, and it would give the controller a means to report back why a move failed.

Feedback could be a separate message, interleaved with joint state messages. Or, it could replace joint state messages when the Cartesian motion mode has been set. I think it would be helpful if the robot controller streamed back both joint and Cartesian state information always, but having a new message that combines both may be more of a pain than simply saying that both should be sent back continually. The sequence number is handy but not necessary. What about timestamps for every state message?

• always stream Cartesian state: agreed
• new combined msg: strongly disagree
• sequence nr / timestamps: perhaps a sequence number / logical timestamp is more practical: timestamps require clocks, and I'm not sure all target platforms expose clocks with sufficient resolution.

The object state message is strange, I admit. We used it to report the location of objects that the robot new about. [..] Have any of you encountered the need for information about robot objects that the robot controller maintains?

I think all of us actually tried to get you to give us some examples of objects where this would be necessary / nice to have :).

Also: what do you mean exactly with 'objects that the robot knew about'? Most robots I've experience with only know about things that are rigidly attached to them, and then mostly via some kind of actuation mechanism. Or is the Object State for things like work pieces that get detected through on-controller robot vision, or by using something like touch sensing?

[gavanderhoorn]

@JeremyZoss wrote:

• Multi-Group Support
  • it would be cleaner to include multiple motion-group support from the start, rather than adding later

+1 to this.

[shaun-edwards]

In general I'm in agreement with @gavanderhoorn.

Regarding frames, specifying the assumed frames in this document should be done. Allowing the user to specify a frame in the message could be helpful, but I'm not sure how we would synchronize names between ROS and the controller (maybe this is what the object state is for). One use case in which this would be useful is for conveyor tracking, where the robot controller can provide better motion synchronization.

Regarding the object state, I think it can be a separate REP, unless it is needed for Cartesian control (see my comment above). I am convinced that such a message is useful.

I'm a -1 on Multi-group support. I haven't seen a clean implementation yet. Without this, I think there is too much burden on creating the Cartesian interface with multi-group support. @frederickproctor, what do you think? (see #13 for the latest discussion on Multi-group)

Do we want to align this work with CRCL? The CRCL pose orientation is too complex for most robot controllers at this point, but we should make certain a "conversion" method can be created (i.e. information isn't missing).

@frederickproctor , the next steps are for you to update the REP based on the feedback. Once we have consensus, we can invite the community to discuss via the mailing list. Normally this is just a heads up to the community, but it might generate more feedback. With agreement from the community, we can move forward with a PR for the actual code.

[shaun-edwards]

@frederickproctor, friendly ping.

[frederickproctor]

I went over the comment history and updated the Cartesian Simple Messages accordingly. The "Assumptions" sections explains how I resolved some of the questions.

[gavanderhoorn]

Did you mean to close this?

[frederickproctor]

Oops, no, I meant to submit the comment.

[frederickproctor]

I just re-opened it.

[shaun-edwards]

Why not send Cartesian pose all the time (specified as tool0 relative to base, see here).

[shaun-edwards]

@frederickproctor, I'm more or less in agreement with this modified approach. It's not everything that everyone wants, but it's a great step forward. @gavanderhoorn's comment about officially requesting a new message number still stands, but we can handle that as this progresses.

[gavanderhoorn]

Is there interest in continuing / wrapping up this discussion? Officially a new REP can only be accepted if there is also a (poc) implementation for it, but I'm guessing that is not something we want/need to stick to.

@shaun-edwards, @frederickproctor ?

[frederickproctor]

I’d like to continue the discussion, but there were enough issues raised that we need to resolve before proposing a new version of Simple Message. I can be the POC for an implementation using some systems we have here, but we don’t have Fanuc expertise. The implementations here would be instrumented so we could get performance numbers. We’ll have a Motoman SIA20F here around September 1. Shaun, did you do the driver for this?

[gavanderhoorn]

I’d like to continue the discussion, but there were enough issues raised that we need to resolve before proposing a new version of Simple Message. I can be the POC for an implementation using some systems we have here, but we don’t have Fanuc expertise.

I can do the Fanuc side, no problem. The issues we can iron out, that's what the poc is for :).

We’ll have a Motoman SIA20F here around September 1. Shaun, did you do the driver for this?

Yaskawa Motoman wrote motoman_driver (or at least, the robot side). All open-source, so we can implement a poc using that as well.

[JeremyZoss]

FYI: I wrote the ROS side of the Motoman SIA20F driver, while Eric Marcil (Motoman) wrote most of the robot-side driver. I believe ongoing support of the Motoman driver has mostly been transitioned to Ted Miller (Motoman), but I still see Eric's name pop up on the mailing list from time to time.

I'm happy to help as needed, though my time may be limited to "consulting" only (no major development).

[frederickproctor]

Thanks, Jeremy. It sounds like Eric Marcil or Ted Miller would be doing the hard work mapping Cartesian moves to Motoman robot-side calls. We will be getting the Motoman SDK with ours when it arrives September 1, so we could do some testing of that.

Fred

[gavanderhoorn]

Closing due to inactivity.

There was some good discussion here, and I believe some of it ended up (at least conceptually) in fzi-forschungszentrum-informatik/cartesian_ros_control/cartesian_control_msgs.