Added SetForceMode srv #20
Conversation
There was a problem hiding this comment.
High-level comment: the description and field types appear to be almost verbatim copy-pastes from URScript documentation.
Should task_frame and the other fields use appropriate ROS types? I'm thinking geometry_msgs/PoseStamped, geometry_msgs/WrenchStamped, etc.
|
I agree with @gavanderhoorn that we should use ROS types in the service. Using stamped datatypes also removes the ambiguity of the data passed to the service. Obviously this would then have to be transformed before being sent to the robot (But this is more of a driver issue independent of the service definition). |
|
I will have a look at changing |
…hanges to account for changes in msg in PR (ros-industrial/ur_msgs#20)
| @@ -0,0 +1,21 @@ | |||
| # A 6d pose vector that defines the force frame relative to the base frame | |||
| geometry_msgs/PoseStamped task_frame | |||
There was a problem hiding this comment.
I'm not sure whether this makes sense. From what I understand, the target wrench is given in the task_frame, right? So, when using a WrenchStamped for the target wrench, the pose would be given through the frame_id.
| geometry_msgs/WrenchStamped wrench | ||
|
|
||
| # An integer [1;3] specifying how the robot interprets the force frame | ||
| uint8 type |
There was a problem hiding this comment.
The types should probably be explained / use constants.
| # An integer [1;3] specifying how the robot interprets the force frame | ||
| uint8 type | ||
|
|
||
| # 6d vector. For compliant axes, these values are the maximum allowed tcp speed along/about the axis. For non-compliant axes, these values are the maximum allowed deviation along/about an axis between the actual tcp position and the one set by the program |
There was a problem hiding this comment.
| # 6d vector. For compliant axes, these values are the maximum allowed tcp speed along/about the axis. For non-compliant axes, these values are the maximum allowed deviation along/about an axis between the actual tcp position and the one set by the program | |
| # For compliant axes, these values are the maximum allowed tcp speed along/about the axis. For non-compliant axes, these values are the maximum allowed deviation along/about an axis between the actual tcp position and the one set by the program. |
| # A 6d pose vector that defines the force frame relative to the base frame | ||
| geometry_msgs/PoseStamped task_frame | ||
|
|
||
| # A 6d vector of 0s and 1s. 1 means that the robot will be compliant in the corresponding axis of the task frame |
There was a problem hiding this comment.
This is not a 6d vector anymore, a final docstring can be done once we figured out the task frame above.
| bool selection_vector_x | ||
| bool selection_vector_y | ||
| bool selection_vector_z | ||
| bool selection_vector_rx | ||
| bool selection_vector_ry | ||
| bool selection_vector_rz |
There was a problem hiding this comment.
I'm not sure whether "selection_vector" is the best naming. Maybe something like "compliance_x" would be more suitable?
…hanges to account for changes in msg in PR (ros-industrial/ur_msgs#20)
This service is added for PR https://github.com/UniversalRobots/Universal_Robots_ROS_Driver/pull/603