# Physics problem with simple movement of grasped object

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 ...
edit retag close merge delete