Sliding problem with stack of boxes

asked 2019-07-05 09:14:42 -0500

updated 2019-11-12 15:23:38 -0500

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.

sliding-boxes

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

image description

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.

image description

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)

edit retag flag offensive close merge delete

Comments

maybe try making fdir1 not zero? like [1, 0, 0]? just a guess...

Peter Mitrano ( 2019-07-05 12:48:27 -0500 )edit

Already tried it, but still nothing.

nlamprian ( 2019-07-05 13:37:05 -0500 )edit

Just updated my answer after seeing your gif with contact points.

chapulina ( 2019-11-12 16:30:15 -0500 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2020-03-01 20:03:45 -0500

nlamprian

833 ●4 ●5 ●19 https://nlamprian.me/

updated 2020-06-23 17:02:28 -0500

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

edit flag offensive delete link

Comments

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.

azeey ( 2020-03-11 11:01:28 -0500 )edit

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

matteolucchi ( 2020-07-01 04:59:08 -0500 )edit

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)

nlamprian ( 2020-07-01 14:16:50 -0500 )edit

add a comment

answered 2019-07-09 12:58:50 -0500

chapulina
7504 ●2 ●23 ●54 https://louise.world/

updated 2019-11-12 16:29:48 -0500

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>

edit flag offensive delete link

Comments

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.

nlamprian ( 2019-07-10 05:12:49 -0500 )edit

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.

chapulina ( 2019-07-10 07:59:59 -0500 )edit

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

kumpakri ( 2019-07-11 02:45:02 -0500 )edit

The ODE manual can be quite helpful, especially around page 9: http://ode.org/ode-latest-userguide.pdf

chapulina ( 2019-07-11 08:31:10 -0500 )edit

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!

bhej ( 2020-09-25 09:48:04 -0500 )edit

add a comment

Sliding problem with stack of boxes

Comments

2 Answers

Comments

Update

Comments

Question Tools

Stats

Sliding problem with stack of boxes edit

Comments

2 Answers

Comments

Update

Comments

Question Tools

Stats

Sliding problem with stack of boxes