The GripperCommand message and arbotix_ros package

[Patrick Goebel]

Hello,

I am using MoveIt (ROS Hydro debs, Ubuntu 12.04) with the arbotix_ros package to control my 6-dof Dynamixel arm.  I also have a single-servo gripper on the end of the arm.  The gripper has one fixed finger and one movable finger attached to the servo. (So it is not a parallel gripper.)  The GripperCommand message is defined as:

[control_msgs/GripperCommand]:
float64 position
float64 max_effort

Does the position field here correspond to the joint position in radians or the distance in meters between the fingers?  I ask because the arbotix gripper controller code seems to imply that the input is a desired distance between the finger tips rather than the joint position.

Thanks!
patrick

[Martin Günther]

On Mon, 26 May 2014 07:25:22 -0700
Patrick Goebel <pat...@pirobot.org> wrote:

> Hello,
>
> I am using MoveIt (ROS Hydro debs, Ubuntu 12.04) with the arbotix_ros

> <https://github.com/vanadiumlabs/arbotix_ros> package to control my

> 6-dof Dynamixel arm. I also have a single-servo gripper on the end
> of the arm. The gripper has one fixed finger and one movable finger
> attached to the servo. (So it is not a parallel gripper.) The
> GripperCommand message is defined as:
>
> [control_msgs/GripperCommand]:
> float64 position
> float64 max_effort
>
> Does the position field here correspond to the joint position in
> radians or the distance in meters between the fingers? I ask because
> the arbotix gripper controller code

> <https://github.com/vanadiumlabs/arbotix_ros/blob/hydro-devel/arbotix_controllers/bin/gripper_controller.py#L117>

> seems to imply that the input is a desired distance between the
> finger tips rather than the joint position.
>
> Thanks!
> patrick
>
>

Hi Patrick,

that's a very good question. GripperCommand.msg doesn't say, but
GripperCommand.action has this (for the result + feedback):

float64 position # The current gripper gap size (in meters)

This seems to imply that the request position is probably also in
meters.

I just checked, and my implementation of the GripperCommand action
server interprets this as radians. This works because my code that
computes the grasps also interprets this as radians, and I think MoveIt
just passes that through without looking at it. I should probably still
fix my implementation at some point.

Cheers,
Martin

[Patrick Goebel]

Thanks Martin,

That makes sense and also explains the different gripper motions I see
when running my pick-and-place application in demo mode compared to
using the arbotix controller. I'm guessing demo mode doesn't know
anything about the geometry of my robot's gripper action (i.e. the
mapping from width to joint angle) whereas the arbotix gripper
controller does.

Cheers,
patrick

[Patrick Goebel]

I have a follow up question regarding the control of the gripper.
Suppose I have defined a move_group for the gripper when running the
MoveIt Setup Assistant. Now I would like to set target configurations
for the gripper in my Python script. While I can use the
set_joint_value_target() function successfully, I can't get the
set_pose_target() function or the set_position_target() function to work
without an error. In both cases I think the arguments (xyz triple in
the first case and pose in the second) don't make sense for a gripper
controller which expects the target to be the distance between the
fingers. So is there a way to set the desired distance between the
fingers using the Python API? Or can one only set the angle of the
joint using the set_joint_value_target() function?

Thanks!

patrick

On 05/26/2014 07:46 AM, Martin Günther wrote:

[Martin Günther]

Hi Patrick,

I just checked my code again, and now I'm also confused. Maybe somebody
else here can help us out. :-)

The way that I use MoveIt for moving the gripper is through the C++
move_group.pick() function. It expects a list of moveit_msgs/Grasp,
which has a field grasp_posture, which gives a desired configuration of
the gripper. The thing is that grasp_posture is a
trajectory_msgs/JointTrajectory; I fill it like this:

grasp.grasp_posture.joint_names.push_back("katana_l_finger_joint");
grasp.grasp_posture.joint_names.push_back("katana_r_finger_joint");
grasp.grasp_posture.points.resize(1);
grasp.grasp_posture.points[0].positions.push_back(-0.44);
grasp.grasp_posture.points[0].positions.push_back(-0.44);

The reason that I'm confused is:

* JointTrajectory expects joint angles in radian (here: -0.44)
* the GripperCommand action seems to expect gripper gap size in meters
(but my implementation interprets it as radians, that's why it works)

Since MoveIt has no way of converting these things, I think it just
passes one of the joint angles (which one?) from the grasp_posture as a
gap size to the GripperCommand action.

If that's really how it works, using radians and meters interchangably
is a horrible hack. I hope I'm wrong. :-)

If I'm not wrong, you should just make up your mind whether you'll want
to interpret the whole thing as meters or radians, and stick with it.
In either case, you can just use the set_joint_value_target() function.
Just keep in mind that what it really does is call the GripperCommand
action with that value. And you're right that set_pose_target() and
set_position_target() can't be used with a gripper, obviously.

Cheers,
Martin

[Patrick Goebel]

Thanks Martin,

Yeah, it would be great if one of the MoveIt gurus would clarify how it
is supposed to work. But for now at least I can use your hack to get
things going.

--patrick

[Michael Ferguson]

RE: gripper messages

Yes, the GripperCommand spacing is set in Meters, this is a carryover from the PR2 message, and is basically designed for grippers like the PR2 or UBR-1 where there are two parallel jaws and the spacing between the fingers fully defines the pose of the gripper. The simple plugin has a "parallel mode" where you specify two joint names (on UBR-1 this is left_finger_joint and right_finger_joint) and the command is the sum of the two positions (which works for our parallel gripper, where the joints are actually prismatic). When not using the parallel mode, you can set a joint name to use, which could be an existing joint or a made up one (I think that should still work, but not sure after the RobotState rewrite, I've only used parallel mode recently). In this case, if you don't have a prismatic gripper joint, you will be mixing the rotation/translations. It's not pretty, but it is the current state of things.

A while back there was a discussion about creating a new gripper message (that would be more like the Grasp message) but that discussion mainly fell flat with the exception of adding Effort to joint trajectories so that gripper efforts could propagate through the moveit system.

-Fergs

[Patrick Goebel]

Thanks Fergs--this really helps.  So do you happen to know what model of gripper is assumed when you are running MoveIt in demo mode and using the fake controllers?  Since I have a one-sided gripper with a single joint, my fake_controllers.yaml file looks like this:

controller_list:
  - name: fake_right_arm_controller
    joints:
      - right_arm_shoulder_pan_joint
      - right_arm_shoulder_lift_joint
      - right_arm_shoulder_roll_joint
      - right_arm_elbow_flex_joint
      - right_arm_forearm_flex_joint
      - right_arm_wrist_flex_joint
  - name: fake_right_gripper_controller
    joints:
      - right_gripper_finger_joint


--patrick

[Michael Ferguson]

I think the fake controller doesn't distinguish between grippers/arms and simply publishes a joint_states message with your last position https://github.com/ros-planning/moveit_plugins/blob/hydro-devel/moveit_fake_controller_manager/src/moveit_fake_controller_manager.cpp#L68

[Patrick Goebel]

Thanks Fergs!

After reading through what you and Martin have written on this thread, I thought I would test a theory that seems to work.  I commented out the launch of the arbotix single-sided gripper controller and instead I ran a trajectory follow controller using the right gripper joint.  That way I figured I could just use joint angles everywhere.  I changed my controllers.yaml file to:

controller_list:
  - name: right_arm_controller
    action_ns: follow_joint_trajectory
    type: FollowJointTrajectory
    default: true

    joints:
      - right_arm_shoulder_pan_joint
      - right_arm_shoulder_lift_joint
      - right_arm_shoulder_roll_joint
      - right_arm_elbow_flex_joint
      - right_arm_forearm_flex_joint
      - right_arm_wrist_flex_joint
     

  - name: right_gripper_controller
    action_ns: follow_joint_trajectory
    type: FollowJointTrajectory
    default: true
    joints:
      - right_gripper_finger_joint

Then I ran my pick-and-place test script and everything seems to work as expected.  The only oddness is that there is a 7 second delay before every gripper motion (e.g. open on approach to target, close on the target, open on release of the target).  I can set the time_from_start on the gripper posture joint trajectory to a smaller value and the gripper does open and close faster, but the delay *before* the movement begins seems to be fixed at about 7 seconds.  Does anyone know how to change this?

--patrick