ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | Q&A answers.ros.org

# Simple box grasping fails

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?

===== additional info Here's a link to my gazebosim question on the same topic with a slightly different grasping scenario. http://answers.gazebosim.org/question... =====

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

edit retag close merge delete

( 2018-05-15 16:55:02 -0600 )edit

Is there a reason why the surface properties of the box are commented out?

( 2018-05-15 17:06:49 -0600 )edit

@jayess, the animation is now attached.

@PeteBlackerThe3rd, the surface properties of the box are commented out because changing them made no difference so I just reverted to the default values.

( 2018-05-15 19:40:55 -0600 )edit
1

Tbh I believe this is more a Gazebo issue for now. Seeing as you're using SDF exclusively here and we're talking about interaction with objects in the dynamic simulation, perhaps posting this to answers.gazebosim.org would result in better/faster/more answers.

( 2018-05-16 01:15:55 -0600 )edit

@gvdhoorn, Tbh I had intended to post it on the gazebosim forum but it was the end of the day and I was hurrying and ended up using this one instead :) Thanks for the advice, I'll go post it there now. One thing, though, the gripper sdf was generated from a urdf xacro file.

( 2018-05-16 08:14:04 -0600 )edit

re: xacro/sdf: I don't believe that really matters -- for now. This seems to be something to do with interaction of various objects in the Gazebo world, and as such will probably have something to do with either the static model of your sim, or the sim (object) properties. Gazebo ppl will ..

( 2018-05-16 08:17:17 -0600 )edit

If you do end up posting there, please post a link here so we can keep things connected.

And if possible -- and you remember -- if you solve it, please post here as well.

If it does turn out to be on the ROS side, you can continue here.

( 2018-05-16 08:18:06 -0600 )edit

Thanks @gvdhoorn. Would you check out the update I made to this question and see if the gazebo_ros_control elements are working as you'd expect?

( 2018-05-16 11:42:02 -0600 )edit

Sort by » oldest newest most voted

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!

more