Hinge Constraint with friction

[Moose]

Hello,

I need a hinge constraint with friction to simulate a certain resistance when a user interacts with an object.
Now in this forum I read I can use an angular motor like this:

hinge_constraint->enableAngularMotor(true, 0.0, 0.02);

I understand this is to create a motor with a target velocity of 0 (like a break) and a small max impulse to slowly push back.

Sadly. this doesn't seem to work. The constraint itself works fine but appears to spin freely upon collision with a kinematic object.
The motor, no matter what values I enter, appears to have no effect whatsoever. I also tried the following:

hinge_constraint->enableAngularMotor(true, 2 , 10.0);
hinge_constraint->setMotorTarget(1, 1.1);
hinge_constraint->setOverrideNumSolverIterations(50);
hinge_constraint->enableMotor(true);

All to no avail. The rigid body attached to the constraint still spins freely. And by that I mean, it rests until something bumps into the object and gives it an impulse. Then it just keeps rotating. Is there anything else I need to do to make it work?

Thanks for any input,

Moose

[Flix]

First of all, I've never tried something like that before, so you're probably more expert than me about this topic. Anyway:

I understand this is to create a motor with a target velocity of 0 (like a break) and a small max impulse to slowly push back.

AFAIK the max motor impulse won't exactly "slowly push back": to my knowledge it's simply the maximum force that the constraint can use to move the constraint towards the target velocity. In your case the target velocity is 0, there's no way it can move your hinge "back" once you move it: it should just add a resistence to external moves (I'm not sure about it: as I told you, I've never tried it).

The constraint itself works fine but appears to spin freely upon collision with a kinematic object.

This is probably because kinematic objects can't stop due to a collision with any dynamic object in general as far as I remember.

The problem is that the constraint does no stop the hinge after the collision... don't know why... maybe a target velocity of zero simply disables the hinge (but it should stop it...). I don't know: I would try with a huge max motor force and with objects set to DISABLE_DEACTIVATION to test this case further...

[Moose]

Flix,

thanks for your response. As it so happens, you were right. I sort of figured that out trying wild combinations at the same time. If I set the max impulse very high, it has the desired effect. Like that:

hinge_constraint->enableAngularMotor(true, 0 , 100000.0);

Thanks for the help.

Moose

[Basroil]

Flix,

thanks for your response. As it so happens, you were right. I sort of figured that out trying wild combinations at the same time. If I set the max impulse very high, it has the desired effect. Like that:
hinge_constraint->enableAngularMotor(true, 0 , 100000.0);

That usually means you need to up the joint iterations. For robots with friction joints, I'm usually above 200 iterations and 5-6x smaller time steps. You could also look into the direct solvers, they tend to work pretty well with motors and faster than ridiculously high iteration counts.

[Moose]

You are saying that my solution is not the preferred (as in right) way?
I have tried to set the iterations to 50 which had no effect. I'm gonna try 200 and see what it does.

About direct solvers, I don't know what that is. Would you care to elaborate please?

Thanks,

Moose

[Moose]

A little update here. I have tried all sorts of iteration limits for this now an I cannot see any effect at all. So I guess it's huge motor impulse for now.

Thanks,
Moose

[Moose]

There's one more thing that puzzles me about that hinge.

It allows for an amazing amount of movement of the hinge axis. Considering a door example, if I have a dynamic object push the door open it will do so, but the actual door will wobble in it's hinge quite a bit. From visual judgement I would say it's about 5% the length of the door. The axis is not as strict as I would hope it would be. It's more like the hinge is made of rubber bands instead of steel.

Can I make that "tougher"?

[Flix]

As far as the number of iteration is concerned, I suggest you start increasing them only if your current simulation is not working as expected, and keep them only if you see some improvement; overwise discard them (they decrease performance a bit).

The axis is not as strict as I would hope it would be. It's more like the hinge is made of rubber bands instead of steel. Can I make that "tougher"?

The Bullet Forum is full of questions like that (you can search the forum for them if you want).

It's not an easy task to solve. I usually tune the masses of the two bodies or their local inertias (usually increasing them, or trying to avoid too different mass ratios). This has many drawbacks, since the bodies look less "natural" in their movement, but if I'm lucky and that can fix my constraint, it's OK for me.
Most of the time I increase the local inertia (and a lot). However this does not work in every scenario.

Sometimes I've seen that increasing the number of iterations make rough spins look much smoother, but I'm not sure this is your problem...

In short: there's no neat solution to this issue. I suggest you work more on your bodies than on the constraint itself (well.. that's what I usually do: do as you like ).

P.S. On a second thought, maybe now your maxMotorForce is too high. Have you tried decreasing it a bit ?

[Moose]

Well, there's limits as to what I can do here because we actually expose many of these values to the user. The system we are building here is like a physical world building blocks like things. The user can import meshes into the system and then freely set the mass of each object. The local inertia vectors are created like this:

// n_shape is a triangle mesh that comes in
btScalar mass = my_mass;

// initial movement and inertia
btVector3 inertia(0, 0, 0);
n_shape->calculateLocalInertia(mass, inertia);

btRigidBody::btRigidBodyConstructionInfo rigidBodyCI(mass, motionState, n_shape, inertia);

if (user_wants_friction) {
rigidBodyCI.m_friction = *(material().friction());
rigidBodyCI.m_restitution = 0.0f;
}
ret = new btRigidBody(rigidBodyCI);

The objects triangles are treated as mm units and are put into bullet as they are. We observed best precision results that way. Most objects would be between 200 and 2000 mm wide. Considering the mass, we have 1.0 as default and users would often set it to values between 1.0 and 10.0. You are right, it doesn't look very natural if this is increased too much. Also, the friction is just an optional checkbox in the system so we cannot have that influence the simulation too much.
The rubber axis effect seems to occur independently from the friction.

However, this problem is not really a showstopper for us. I guess we can tolerate the rubber band effect for the time being, as the object usually converges to the hinge axis when the collision is over or comes to rest. If this is too complex to solve I'd rather have it rest for now. At least we do have the friction and it does look good now.

Thanks,
Moose

[Basroil]

the object usually converges to the hinge axis when the collision is over or comes to rest. If this is too complex to solve I'd rather have it rest for now.

Most certainly sounds like you have too few iterations and too large a time step. Try something like 500 iterations at 1/500 maximum step size (don't forget to take into account the maxSubStep, should be high enough that frame-rate drops won't mess with physics, unless of course you want the door to "explode" for a bit) and see if it's fixed. If it is, then it's not too complex a fix, though performance hit due to it might be.

You can also try to use one of the MLCP solvers that was added in 2.82 rather than sequential impulse solver, I've been finding btDantzigSolver to be better than high iteration and small step size sequential impulse for robots that happen to have an issue with "weak" joints.

[Moose]

Most certainly sounds like you have too few iterations and too large a time step. Try something like 500 iterations at 1/500 maximum step size (don't forget to take into account the maxSubStep, should be high enough that frame-rate drops won't mess with physics, unless of course you want the door to "explode" for a bit) and see if it's fixed. If it is, then it's not too complex a fix, though performance hit due to it might be.

Well, I'm glad to able to say that performance is not much of an issue for our use cases. There's rather strong hardware and so far I haven't seen the simulation eat more than 10% or one CPU. Even when I have multiple larger meshes and very high iteration steps. I have just tried 500. Unfortunately, again I cannot see any visual effect.

You can also try to use one of the MLCP solvers that was added in 2.82 rather than sequential impulse solver, I've been finding btDantzigSolver to be better than high iteration and small step size sequential impulse for robots that happen to have an issue with "weak" joints.

This is interesting. I just tested both Dantzig and ProjectedGaussSeider and they do have a substantial visual effect. The not so good news is, that my hinge now looks more like a ball socket. It is extremely more wobbly and allows for a lot of movement outside the hinge axis. It looks like my object seems to freely rotate about a single point in the center of the hinge axis. Looks a lot like a ball socket constraint now. Also, the friction motor is no longer effective. It does however, not "rubber band" from this central rotation point Very weird. I can't leave it in as we sort of expect a hinge there but it sure looks interesting.
I couldn't see much difference between the two tested MLCP solvers though.