Sliding problem with stack of boxes

Question

I'm trying to pull a stack of boxes, as shown in the gif. A robot (not shown here) is moving the bottom box. Instead of following the bottom box, the top box stays in place.

The values used for the collision geometry of the boxes in this particular test are the following:

I've tried many values (with extended ranges) for the different parameters, but as far as I can tell, nothing had any effect on the shown behavior.

Do you have any ideas about what would make it possible to pull the entire stack of boxes?

Edit:

As I haven't been able to make any progress, I'd like to come back with some more information. I have another example to showcase, assumingly, of the same underlying problem.

In the gif below, there is a box that rests on a rotating shelf link. The box has contact points, and yet the motion of the link is not transferred to the box.

Can you draw any conclusions from the gif? Can you make anything of the way the contacts are behaving?

(allow_auto_disable has been disabled for the box and changing any surface parameters for the box has no noticeable effects)

---

Originally posted by nlamprian on Gazebo Answers with karma: 833 on 2019-07-05

Post score: 0

---

Original comments

Comment by Peter Mitrano on 2019-07-05:
maybe try making fdir1 not zero? like [1, 0, 0]? just a guess...

Comment by nlamprian on 2019-07-05:
Already tried it, but still nothing.

Comment by chapulina on 2019-11-12:
Just updated my answer after seeing your gif with contact points.

Answer 1

If you're using ODE, try turning off allow_auto_disable.

---

Update

The flickering contact points are a problem, ideally you'd want them to be steady. Surface contacts like this have helped me in the past, but you may need to tweak the numbers according to your model's mass and so on. Also note that you should use these settings for both surfaces that are in contact.

    <surface>
      <friction>
        <ode>
          <mu>1</mu>
          <mu2>1</mu2>
          <slip1>0</slip1>
          <slip2>0</slip2>
        </ode>
      </friction>
      <contact>
        <ode>
          <soft_cfm>0</soft_cfm>
          <soft_erp>0.2</soft_erp>
          <kp>1e+13</kp>
          <kd>1</kd>
          <max_vel>0.01</max_vel>
          <min_depth>0</min_depth>
        </ode>
      </contact>
    </surface>

---

Originally posted by chapulina with karma: 7504 on 2019-07-09

This answer was NOT ACCEPTED on the original site

Post score: 2

---

Original comments

Comment by nlamprian on 2019-07-10:
Thank you for the response. Unfortunately, it didn't work. I added the element, verified that the state changed by calling model->GetAutoDisable(), but in the end, nothing changed.

Comment by chapulina on 2019-07-10:
Damn :/ I recommend you make models transparent and turn on contact visualization. Then try tweaking surface params like kp and min depth so that the contact points are persistent.

Comment by kumpakri on 2019-07-11:
@chapulina speaking of the model parameters like kp, fdir etc., is there a good resource that explains what those parameters mean and what values we should put there? What are the ranges, what are the units, specific examples etc.? I don't think I have ever found a clear explanation in any of the official tutorials.

Comment by chapulina on 2019-07-11:
The ODE manual can be quite helpful, especially around page 9: http://ode.org/ode-latest-userguide.pdf

Comment by bhej on 2020-09-25:
I had a similar problem of having a box (with no joints) on a trailer-type surface. The trailer would move while the box would stay in place and slide over it. Turning off allow_auto_disable fixed my problem, thanks!

Answer 2

I finally found the time to look into this problem again. Here are my findings:

• I increased the mass of the boxes and played around with their surface properties. I got stable contacts, but no matter what values I tried, the behavior would be exactly the same: the top box always stays unaffected when I pull the stack.
• Then I thought about trying to move the stack without the robot. I applied a force to the bottom box, and surely enough, the stack moved as expected.
• And then I thought about repeating the experiment with a robot, but this time, a simplified one. Once again, the stack moved as expected C:\fakepath\box-stack-test.gif

So, the conclusion is that this isn't about surface properties, but it has to do with the robot model itself. I pull a stack by attaching a joint between the robot and the bottom box, thus the box becomes an extension of the robot. So, both cases (stack-pull and shelf-rotation) exhibit the same problem: a moving link on the robot doesn't transfer forces to the (top) box. I'm still not sure what's going on, but if I had to guess, I'd say this has to do with inertias.

Edit:

I figured it out. It turns out, this has nothing to do with either contact or model properties. (I even tried to play around with the inertias of the links, but it made no difference)

At some point, I noticed that the velocity of the joints on the robot is always close to zero. That led me to believe that the state of the links is not properly propagated to the boxes, so that's why the boxes don't move. After some digging, I was pointed to the control of the joints. I have been using position controllers. I thought that having the robot hw sim directly call Joint::SetPosition might be the culprit. So I added pid gains for the joints to change the control mode to POSITION_PID (thus doing effort control), and suddenly everything worked as expected (the stack can be manipulated, the box rotates with the shelf link on the robot, and the joint velocities are reported properly).

---

Originally posted by nlamprian with karma: 833 on 2020-03-01

This answer was ACCEPTED on the original site

Post score: 0

---

Original comments

Comment by azeey on 2020-03-11:
I did a quick test on this where I put a prismatic joint between the world and the bottom box. The boxes move together (as expected).

I pull a stack by attaching a joint between the robot and the bottom box, thus the box becomes an extension of the robot.

Are you setting the joint velocity of the joint between the robot and the bottom box or is this a fixed joint?

An sdf file that reproduces the problem would be very helpful if you can create one.

Comment by matteolucchi on 2020-07-01:
"So I added pid gains for the joints to change the control mode to POSITION_PID (thus doing effort control)"

@nlamprian How did you do this ?

Comment by nlamprian on 2020-07-01:
Upload the pid configs under the /gazebo_ros_control/pid_gains/joint_name namespace. See here.

FYI That did not solve all my problems. I now do have to work with the surface parameters, and fix issues like, for example, where the boxes are sliding by themselves, while at the same time, the gripper on the robot is unable to move them (even with high effort and pid gains)