Home | Tutorials | Wiki | Issues
Ask Your Question
0

Grasping unable to lift object

asked 2018-05-16 08:19:40 -0500

raequin gravatar image

updated 2018-05-29 09:16:19 -0500

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

image description

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?

image description

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.

image description

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

image description

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.

image description

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.

image description

image description

Here is an animation and force plot when using PositionJointInterface.

image description

image description

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 ...
(more)
edit retag flag offensive close merge delete

Comments

Hmm, based off all this and your previous post, it might be an issue with the ros_control / gazebo interaction. I've previously been able to grasp simple objects without any major problems, BUT I was using a custom joint motor plugin to apply joint torques.

josephcoombe gravatar imagejosephcoombe ( 2018-05-17 12:44:32 -0500 )edit

Thanks, @josephcoombe. The thing I don't understand about that scenario is that the joint forces seem high enough to lift an object (the box) without issue but the gripper just slides right off.

raequin gravatar imageraequin ( 2018-05-21 09:16:28 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted
0

answered 2018-09-17 14:01:58 -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
Login/Signup to Answer

Question Tools

1 follower

Stats

Asked: 2018-05-16 08:19:40 -0500

Seen: 589 times

Last updated: Sep 17