raequin's profile - activity

Update 2

Following some advice below I changed the ROS controller from EffortJointInterface to PositionJointInterface and this seems to be a step in the right direction, the object moves vertically a little bit, but it still does not grasp properly. I've varied the joint effort limit and proportional gain but it seems like sometimes the force is too high, causing instability as shown in the animation, or else it is too low and the object just slips out of the gripper. Parameters I've varied are mu, mu2, kp, kd, min_depth, and max_vel, even restoring them to their default values; all to no good effect.

Original question

For an application where a manipulator picks up a cylinder I have created a primitive gripper with a ROS SimpleTransmission and EffortJointInterface. The Gazebo model for the cylinder comes from an STL file. This is using Gazebo 9 and ROS Kinetic. In Gazebo the gripper can push the cylinder around but it does not pick it up; the cylinder just slides through the gripper as shown in the animation.

I've changed the friction coefficients in both the gripper urdf and the cylinder sdf to 100.0 (this question used to say 99999.9 but following an answer below I made them 100.0 instead). I also reduced the mass of the cylinder. The effort limit on the joint I set to 999999.9, just to try to get it to grip really hard. The integral gain is 1.0 and the robot pauses after gripping to give time for the error integral to grow (the cylinder keeps the gripper from closing all the way).

Part of the gripper urdf and the entire cylinder sdf are pasted below the animation. Can you tell me what I need to do to get a gripper to pick up this object?

Update: Because I thought perhaps there was insufficient contact between the cylinder and flat gripper, I changed the object model to a block and made the gripper taller. Like the cylinder, the block has mass of 0.1 and friction coefficients of 100. This animation shows that the result is the same as before.

Here is the result of View --> Contacts.

Part of gripper urdf

  <!-- Prismatic joint -->
  <joint name="gripper_joint" type="prismatic">
    <origin xyz="${2 * gripper_side_block_width + gripper_thickness} 0 0" rpy="0 0 0" />
    <parent link="gripper_wide_block_p" />
    <child link="gripper_wide_block_d" />
    <limit effort="999999.9" lower="-100" upper="100" velocity="0.5"/>
  </joint>

  <transmission name="gripper_joint_transmission">
    <type>transmission_interface/SimpleTransmission</type>
    <joint name="gripper_joint">
      <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
    </joint>
    <actuator name="gripper_joint_motor">
      <hardwareInterface>hardware_interface/EffortJointInterface</hardwareInterface>
      <mechanicalReduction>1</mechanicalReduction>
    </actuator>
  </transmission>

  <!-- High friction on gripper -->
  <gazebo reference="gripper_wide_block_p">
    <mu1>100.0</mu1>
    <mu2>100.0</mu2>
    <minDepth>0.003</minDepth>  
    <maxVel>0</maxVel>  
  </gazebo>

  <gazebo reference="gripper_wide_block_d">
    <mu1>100.0</mu1>
    <mu2>100.0</mu2>
    <minDepth>0.003</minDepth>  
    <maxVel>0</maxVel>  
  </gazebo>    
</robot>

Cylinder sdf

<sdf version='1.6'>
  <model name='Cone100'>
    <link name='Cone100'>
      <pose frame=''>0 0 0 0 -0 0</pose>
      <inertial>
        <pose ...

Grasping is not working in this primitive case I've made. The object is a box of mass 1 and default friction and contact parameters. The gripper uses two prismatic joints to move two c-shaped links together. All these are shown in this image. Note the gripper-joint coordinate frames (the x- and z-direction vectors are visible).

When the gripper closes on the box and the robot then moves upward, the box does not get lifted, as shown in this animation (it's for a taller gripper than above but the behavior is identical, also the gripper in the animation used just one prismatic joint). Since the normal force between the gripper and box is 200 N (that's what I have the joint effort set at, as shown in the sdf below) then the lifting force should be at least 200 N, while 9.81 N should suffice to lift the box. Do you have an idea why the box doesn't go up?

The following plots were made via

rqt_plot ft_senr_topic_p/wrench/force/x, ft_sensor_topic_p/wrench/force/z, ft_sensor_topic_d/wrench/force/x, ft_sensor_topic_d/wrench/force/z

to graph the x and z components of the joint forces for the two prismatic gripper joints. In this one the joints are controlled with the EffortJointInterface. When the x components drop down, at about 28.6 seconds, that's when the gripper is higher than the box and it closes.

For this plot the gripper friction coefficient is changed to 100, which appears to have made no change.

The final plot is with mu=100 and using the PositionJointInterface. At about 24.4 seconds On this one, the x-components drop down. That's when the robot starts to move upward (prior to that it's stationary with the gripper closed around the box). The spikes after that, at 24.8, are when the gripper clears the box. It's odd to me that one joint has a positive z-component and the other has a negative z-component of force.

Update

In an attempt to circumvent this problem I made an object that's wider in the middle and gripper blocks to match it. In theory, if the gripper stayed at its closed position then friction would not be required for lifting the object. I increased the effort limit on the joints from 200 to 500.

With 'EffortJointInterface' the same problem occurs as with the box, and with the PositionJointInterface the grasp is unstable and the object goes flying away.

To battle the instability I changed max_vel and min_depth on both the gripper and object to 0 and 0.001, respectively. Alas, the simulation remained unstable with PositionJointInterface even with these changes.

Here is an animation and force plot when using EffortJointInterface.

Here is an animation and force plot when using PositionJointInterface.

Here is the sdf of the object.

<sdf version='1.6'>
  <model name='wideCone'>
    <link name='wideCone'>
      <pose frame=''>0 0 0 0 -0 0</pose>
      <inertial>
        <pose frame=''>-0 0 0 ...

The robot tool is a prismatic gripper with four rods that slip into matching holes on the object to be grasped. Using this gripper to move the object works fine for motion perpendicular to the rod axes. In the video, for example, the rods are parallel to the world x-axis so motion in the z-y plane is fine; the robot lifts the object then translates in the negative y-direction okay. I think the problem is that the friction force is not being computed well because when the robot translates in the x-direction the object seems to stay put until it reaches the end of the rod and then it goes berserk. (If you look closely in the second video it can be seen that the gripper starts to move to the right and the object stays still. I guess the object crosses the camera in that video so we get to see the holes and rods inside the object.)

There is a second reason I think the friction calculation is to blame: a different pick-and-place simulation I made this year had problems lifting objects via friction. See Question 1, Question 2, and Question 3.

==========

update: This video where I replaced the gripper with a rigid forklift-type attachment lends weight, I think, to the idea that the problem is due to physics (friction?) and not the ROS controller or something.

==========

I've tried using all four physics engines and modifying physics tags in the world file, as well as collision surface tags in both the object sdf and the gripper urdf. It's apparent that changing these parameters has some effect (though mu1 and mu2 don't make any difference) but the problem persists. The files are pasted below.

It also seems to me that this could be a problem to do with Gazebo 9, which is what I moved to because the previous project had a mobile base that could not move due to this bug with Gazebo 7 and ros_control. Since this simulation does not have a mobile base I will try reverting to Gazebo 7 to see if that fixes the gripping problem.

update: The behavior is identical with Gazebo 7. I've seen the same thing on two computers running Gazebo 9 and now one computer running Gazebo 7.

An additional tidbit: if the mass of the object is too high (though still less than 1) it will fall during the upward motion. So that's fun :-/

World file:

<sdf version='1.5'>
  <world name='default'>
    <!-- A global light source -->
    <include>
      <uri>model://sun</uri>
    </include>

    <!-- A ground plane -->
    <include>
      <uri>model://ground_plane</uri>
    </include>

    <!-- Set physics parameters to hopefully improve contact behavior -->
    <!-- Default max_step_size is 0.001 -->
    <!-- Product of r_t_u_r and m_s_s gives target realTimeFactor, I think.  Default is 1000. -->
    <!-- Default iters is 50 -->
    <physics type="ode">
      <max_step_size>0.0005</max_step_size>  
      <real_time_update_rate>2000</real_time_update_rate>  
      <ode>
    <solver>
      <iters>100</iters>  
    </solver>
      </ode>
    </physics>
  </world>
</sdf>

Object sdf:

<sdf version='1.6'>
  <model name='object'>
    <link name='object ...