Gazebo | Ignition | Community
Ask Your Question

Physics problem with simple movement of grasped object

asked 2018-08-09 10:49:53 -0500

raequin gravatar image

updated 2018-08-14 09:37:55 -0500

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.)

object and gripper

object and gripper closeup

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.

forks instead of gripper


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 -->

    <!-- A ground plane -->

    <!-- 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">

Object sdf:

<sdf version='1.6'>
  <model name='object'>
    <link name='object ...
edit retag flag offensive close merge delete


Does the result vary at all depending on the speed of movement in the x-axis? What if you move the crane very slowly?

Raskkii gravatar imageRaskkii ( 2018-08-10 04:33:46 -0500 )edit

It would be interesting to advance the simulation by single time steps right before and as it transitions along the x-axis. That might reveal what objects are interpenetrating and what's causing the large impulse.

josephcoombe gravatar imagejosephcoombe ( 2018-08-10 11:38:42 -0500 )edit

For some unknown reason I did not receive email notifications about your comments. Thanks for responding! @Raskkii, as far as I can discern, there is no way to set the translational velocity for a MoveIt! cartesian path. @josephcoombe, here is a video of stepping through the sim. Please read its description on YouTube. What's vexing is that manipulating objects is common in Gazebo and I can't think of anything unusual about this system.

raequin gravatar imageraequin ( 2018-08-14 10:26:30 -0500 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2018-09-17 13:57:51 -0500

raequin gravatar image

The cause behind this unrealistic interaction (that is, this lack of friction) is the use of PositionJointInterface for the UR10 joints. Here's a decent explanation of the phenomenon:

... using 'set position' or 'set velocity' in gazebo forces the physics simulation to try and accomplish this, which results in strange behavior. It's actually preferable, according to the Gazebo team members I'm working with, to always use 'set force' in Gazebo because that allows a more normal interaction when the commanded force of an arm joint puts the arm in contact with the environment.

Following an example, I made local changes to the universal_robot package to use EffortJointInterface instead. Some gain values from ARIAC provide decent performance. Thanks to everyone who contributed suggestions!

edit flag offensive delete link more

answered 2018-10-12 01:42:04 -0500

littleghost gravatar image

updated 2018-10-16 20:59:38 -0500

Maybe the inertia tensors in X direction is too small, remember to check the mass value too.

edit flag offensive delete link more

Question Tools



Asked: 2018-08-09 10:49:53 -0500

Seen: 4,144 times

Last updated: Oct 16 '18