Wheeled vehicle with steering, simple suspension?

[lucasw]

Currently I have a cuboid with rounded edges for a collider and apply force to the center to drive it forward and make it off center to turn (https://github.com/lucasw/bevy_viz/blob/main/vehicle_avian/src/bin/vehicle.rs#L127). It doesn't behave well on turns though, it acts like a hovercraft.

Is it possible to set friction to different values for different direction (I think bullet and others allowed this), so it slides forward and backwards easily but is resistant to shifting sideways? I suppose I could calculate forces to resist sideways motion and apply them every update, but it seems like that would be less stable than a lower level lateral friction value and always a timestep late, counteracting the slipping of the last update.

I'm okay with using ray casts for suspension, but a few experiments with this using apply_force_at_point depending on how close a corner of a cuboid is to the ground gets me a lot of pitch and roll oscillations even at a standstill- possibly I just need better damping on the suspension springs.

I'll likely try revolute joints with wheels next, and stick to slower speeds so high wheel rotation rates isn't an issue. (https://github.com/Jondolf/avian/blob/main/src/interpolation.rs#L141 'Very high angular velocities (ex: for car wheels or fan blades) can be especially problematic').

Springy balloon-like tires could be fine instead of a more realistic suspension.

If anyone has a working example to share I'd really like to see it.

[lucasw]

I tried making capsule wheels (exaggerated here to make the capsule orientation clear), but they tend to explode when I attach them, or even if that is avoided they change orientation (in the first picture the initial and desired orientation is shown, with no joints between the bodies, in the second picture I've managed to attach a revolute joint between the chassis and wheel, but the capsule orientation is rotated from where I initialized it- do I supply the orientation somewhere else, it doesn't care where I create it?

[thmxv]

Hi,

I am dabbling in vehicle simulation with avian. I started with a simple raycast vehicle that only handle the surface normal force and apply those to the chassis collider at the contact patch point.

Doing this in a simple system applying ExternalImpulse every fixed time step is quite unstable. Doing it with a very low fixed time step improve stability but still result in weird behavior.

I am not really surprised by this. I assume that this kind of stuff must be integrated with the solver to behave correctly. But the documentation does not describe how to do this for a constraint that is resolved by applying impulse. Looking into the code to see how this is done for ContactConstraint is a bit confusing.

Any advice/link to the math/physics and how this needs to be done (in avian or XPBD sim) would be very welcome.

Regards,

Xavier

[thmxv]

Just to report on my "advancements":

• I moved the system to SubstepSolverSet::SolveUserConstraints
• This made it that inserting an ExternalImpule component does not work on a substep basis. So I applied the impulse manually modifying LinearVelocity and AngularVelocity
• For this I had to not use a RigidBodyQueryReadOnly system parameter, but a RigidBodyQuery
• This new system parameter is not compatible with a SpacialQuery system parameter (used for the raycast)
• So I divided the system in 2 systems, one that does de raycast and another that calculate/apply the impulse. The one that does the raycast is only executed once per step and not one per sub-step. I find this weird, and I will probably test doing the raycast at each sub-step, to see if it is better. I did this because of the PhysicsStepSet::SpatialQuery is obviously done only once per step. But maybe this is only for automatic SpacialQuery (Entities that have the RayCaster component) .
• It is now stable at a default time step (64Hz)
• It looks OK/believable/normal
• Am I on the way to something correct? I do not know.

Edit: Moving the raycast system to SubstepSolverSet::SolveUserConstraints (before the system that calculate/applies the impulses), does change the result and is more stable/realistic. So I will continue with that.