CarSuspensionDemo and tank movement

[sergiusz308]

Hi Norbo, I'm experimenting a little with CarSuspensionDemo trying to make it turn like a tank - stop rotating left wheels and keep rotation on the right side to turn left etc.

I modified demo so when I want to turn left, I set "Settings.VelocityMotor.GoalVelocity" to the left drivingmotor to zero or negative driveSpeed and keep driveSpeed for the right drivingMotor to make it happen but this doesn't work. What's hapenning basicaly is car slowly stops but doesn't turn. I looked at TankInput code and you basicaly do the same thing there. So, why it's not working in CarSuspensionDemo setup?

Thanks,
S.

[Norbo]

Tread-like behavior in the TankInput is created by a careful balance of forces. If the coefficients of friction are modified ever so slightly, or if the motors are weakened/strengthened too much, the tank can easily become impossible to rotate or so agile that it spins madly. It's made more difficult by the fact that a bunch of Vehicle class wheels are not exactly suitable for the simulation of treads.

In a constraint/entity tread system, similar issues occur. There are even fewer dimensions of friction tuning available to entities: a vehicle's wheels have separate horizontal sliding/driving coefficients, entities have isotropic friction.

However, a constraint-based tank has a significant advantage over a Vehicle. You can link all the separate wheel entities in a tread together with NoRotationJoints. This has the effect of bundling the entities into a tread- either they all rotate, or none do. This means that a wheel that currently has weak contact with the ground won't spin pointlessly. Instead, a motor controlling that wheel will also be driving the other wheels.

I suspect that bundling would go a long way in creating a tanky tank. Friction and motor strength should be easier to tune once it is in place.

[Norbo]

I went ahead and added a constraint-based TankDemo to the latest demos.

It appears that bundling the wheels does indeed make things quite a bit easier to tune.

[sergiusz308]

This one is great, that's exactly what I was thinking of. I like the idea building this using constraints - it looks more lightweight then vehicle class, for this particular purpose. Thanks!

Another question: what's the difference using DistanceLimit and LinearAxisLimit with approriate settings for min and max travel? Is DistanceLimit not restricted to particular axis?

[Norbo]

Another question: what's the difference using DistanceLimit and LinearAxisLimit with approriate settings for min and max travel? Is DistanceLimit not restricted to particular axis?

Correct. The LinearAxisLimit can be thought of as constraining a point on an object between two parallel planes defined by another object, while a DistanceLimit can be thought of as constraining a point on an object within a volume between the shells of spheres originating at a point on another object.

The LinearAxisLimit is also a little bit faster.

[sergiusz308]

Great.

In the tankdemo suspension and wheels entities creation is based off tankbody position. How to move / teleport tank in desired position without messing it up? Setting tank's body position to arbitrary value displaces wheels and basicaly screws up whole setup (tank body is to high or wheels located inside body). I tried setting tankbody position BEFORE tread creation and AFTER with pretty much same result.

What I'm basicaly want to have is after tank initialization is done teleport it to some arbitrary location on the map.

[Norbo]

The reason why changing the tank's position before adding treads failed was a little bug- in the CreateTreadSegment, the Cylinder constructor included the body.Position despite the fact that it was already taken into account by the CreateTread parent call.

Any method which preserves the relative positioning of the entities will work. You can also move it after creation, so long as you move the wheels along with it.

[sergiusz308]

OK, now it works fine.

I'm trying to understand various settings here and we have this initialization code:

Code: Select all

var body = new Box(new Vector3(0, 0, 0), 4, .5f, 5);
body.CollisionInformation.LocalPosition = new Vector3(0, .8f, 0);

so, as I understand this, it creates box at 0,0,0 with height of .5f.
Next line of code moves box pivot point (or center of mass) .8f units UP.

Without this line, center-of-mass would be at vertical position of .25f but that line moves it up to 1.05f, right?

Why you move center of mass up? If I comment that second line out wheels are created inside the body, but then I check "nextSegmentPosition", anchor point for treads and suspenion here:

Code: Select all

Vector3 nextSegmentPosition = tankBody.Position + offsetToFrontOfTread

it has the same value with or without center of mass moved up.

[Norbo]

The EntityCollidable.LocalPosition is the offset of the collision shape from the center of mass. So, rather than moving the center of mass up, the shape has been moved up relative to the center of mass. Equivalently, the center of mass is now lower relative to the shape.

In other words:
ShapePosition = Entity.Position + Matrix3x3.Transform(Entity.CollisionInformation.LocalPosition, Entity.OrientationMatrix)

So, despite modifying the local position, the Entity.Position is unaffected. That's why the wheels don't move.

Without this line, center-of-mass would be at vertical position of .25f

The position passed into the constructor specifies the Entity.Position which refers to the center of mass/pivot, so a box created at (0,0,0) will have a center of mass vertical position of 0.

[sergiusz308]

Yeah,I think I finaly got it

When I position my tank on the slope and no buttons are pressed no impulses are applied to the tank but still it slowly goes down the slope, in a slightly jerky fashion. It looks like some of the wheels are unable to withstand gravity force and loosing traction or wheel motors giving impulses on their own. How can I prevent such a situation, so that tank remains still? Slope is roughly about 15-20 degrees.

[Norbo]

I don't see that behavior under normal circumstances, since the tank just goes inactive. If deactivation is permitted, it should quickly go to sleep and become completely still.

If the tank is forced active continuously, however, I can see something like you describe. I suspect it is caused by the velocity-only friction constraints gradually losing to the tiny impulses of gravity.

The jerky behavior is probably from two sources. First, when a contact drifts far enough from its original position that it gets recreated somewhere else, it changes the constraint structure. The problem is compounded by the difficulty of solving the whole tank structure. Second, damping and pre-deactivation stabilization are trying to sap energy out of the system in a way which isn't consistent between all the involved objects.

The first source of jerking isn't really addressable. For the second one, you could set their AllowStabilization to false, but this will stop the entities from deactivating as quickly. It will just be easier for the tank to slowly slide.

There are a couple of additional changes which could be made within BEPUphysics that might help this situation. However, these are very low-level fundamental changes to the nature of collision response. It would require quite a bit of testing to verify that they help and don't hurt performance or some other behavior. So, while I might get around to it eventually, I've got other things to focus on at the moment.

[Norbo]

Turns out the slidey-jerkiness was, in large part, caused by a old and nasty bug. Should be fixed now.

[sergiusz308]

Great, and I started to worry already because my spring voodoo didn't do the magic and tanky were sliding no matter what

I'm working on gun and turret right now and I'd like to know what type of constraints would do the job in a such a scenario:

tank.jpg (13.32 KiB) Viewed 8549 times

I thought about BallsocketJoint with some limit on gun rotation up and down. Or maybe PointOnTheLine + something else?

Green line indicates a origin around which rotation should happen and where joint anchors should be located.

[Norbo]

A RevoluteJoint would do the trick. It is actually a group of constraints: a BallSocketJoint, a RevoluteAngularJoint, a RevoluteLimit, and a RevoluteMotor. The BallSocketJoint keeps the turret from falling off (handles the linear degrees of freedom), the RevoluteAngularJoint only allows one free axis of motion, the RevoluteLimit bounds the minimum and maximum angle, and the RevoluteMotor motorizes the free axis. The limit and motor have their IsActive property set to false by default; if you want to use them, set it to true. You may find that having the motor actively controlling the turret eliminates the need for the limit.

[sergiusz308]

Thanks for suggestion.

I'd appreciate if you could explain in similar fashion chain of constraints you used in this car suspension demo.