Wheels cause undesired acceleration

Hello,

I’ve been trying to write a super simple car script, and it’s working perfectly fine for the most part. There is however one absolutely game-breaking problem:
Whenever I give an input to accelerate or decelerate and then release said input, the vehicle just keeps on accelerating in the input direction for a while.It then proceeds to slowly bleeding off speed like it’s supposed to.

I tried to strip my code of anything unrelated to wheel torque and even ended up discarding most of that, but still end up with the same broken behaviour.

Here is the code:

public class VehicleCar : MonoBehaviour
{
    public WheelCollider[] wheels = new WheelCollider[4];

    void FixedUpdate ()
    {
        float driveInput = Input.GetAxis("Vertical");

        foreach(WheelCollider coll in wheels)
        {
            if(coll == null)
                continue;
         
            coll.motorTorque = 8000.0f * driveInput;
        }
    }
}

As I can’t find any bugs in the main code and the bug keeps on appearing even in this stripped down version, I am at a complete loss. Am I missing something very obvious? Or should I dump wheel colliders entirely and just write my own solution?

edit:

  • I have confirmed that MotorTorque is definitely reset to zero if no input is provided.
  • The vehicle’s rigidbody has a drag > 0, the vehicle should come to a halt by itself.

After release is supposed to tell to the motorTorque to return 0 i suppose.
Or motorTorque = 0 and addForce to negative (-1000) to help stop the vehicle (Deceleration) after release the key , then, if key pressed add torque and addForce to zero.

Thank you for you reply, however there lies the problem. The motorTorque is already being reset to 0 since I’m using Input.GetAxis(). Checking the values for motorTorque on the wheels directly via an OnGUI method showed it was indeed 0.

As for the AddForce suggestion: The above bit of code is a vastly reduced version of the real deal, which has braking torque and everything set up. However, the mysterious acceleration is in fact so strong that it negates the effects of setting WheelCollider.brakeTorque to something superior to the maximum motorTorque value.

The frustrating thing about this bug is that I am using wheel colliders with all default settings and code that doesn’t allow undefined states to take place. All the input values are clearly as they should be, but the odd behaviour takes place nonetheless.

Yes , agreed , unfortunately the wheel Collider is poor and bugged and lots of problems , and the problem is not from unity team physics programmers , But from the NVIDIA physx (sdk) company.I believe. It’s a matter of waiting for the solution.

Okay, thanks. I was aware that PhysX 3.x was unreliable. Haven’t been using unity in 5 months so I was hoping those issues were fixed by now.
Guess I’ll just hack my own black magic-ish solution.

Alright.

I seem to have found the source of the weird behaviour: Wheel Colliders are broken beyond repair.

All input transmitted towards a wheel collider will reliably be executed by the wheel collider. However there appears to be a major time delay ( > 0.5 seconds) between input and execution. This became apparent when the vehicle proceeded to perform a set of maneuvers that I had defined a second earlier through code.
Fiddling around with rigidbody or physics settings doesn’t resolve the issue either.

Now I’m not entirely sure if this bug lies with Unity or PhysX, however it means that WheelColliders are unusable right now. I’m thinking of submitting a bug report about this.

This may not be the root cause of your issue, but you should be polling for input in Update not FixedUpdate. It’s possible it may be giving you some iffy numbers so I would certainly change it to rule it out.

Also check if there is any unwanted gravity, sensitivity, dead zone etc on the input in the inspector.

Thanks for the input. I tested most of these before, FixedUpdate and Update behave exactly the same. Input is clearly reset after releasing the keys (axis snap is enabled). I verified all input values using both debug inspector and OnGUI visualisation.
I believe that input can be ruled out as the cause and is has to be related to either the rest of the code or the collider itself. Intersecting colliders weren’t responsible either.

Its likely your wheel rpm giving you issue…

you need to limit it, otherwise the wheel will just spin faster and faster, making it difficult to slowdown.

something like

if(wheelCol.rpm > 500)
wheelCol.motortorque = 0;

theres a fully functional script in my sig.

1 Like

Yes I agree with the JamesLeeNZ i forgot the rpm command.

Thank you for the ideas, I’ll have a look at your wheel controller tomorrow. :slight_smile:

… That still doesn’t really explain the whole delayed reaction thing. Maybe the wheelCollider just turns buggy whenever rpm exceeds realistic values.

well, if the wheels are spinning at high velocity, its going to take a lot more force to slow them down to stop, which is likely why you’re seeing delays.

I use scaling brakes in my script to assist with more powerful braking where needed.

Yeah, that’s what I’d like to believe as well, although you’d expect to see an acceleration/deceleration rather than delayed response. Adding stronger brakes didn’t resolve the issue, and the velocity curves were way to erractic to explain it that way. It’s likely that the underlying code just doesn’t like excessive RPM values.

if(wheelCol.rpm > 500)
wheelCol.motortorque = 0;

I can’t believe it was that simple. The problem has been resolved, and even though the original behaviour remains nonsensical, it can be neutralized with a mere 2 lines of code.

Thanks a lot for the help guys :slight_smile:

2 Likes

I’m late to the party, but I think there are better solutions. Let’s break it down.
Unity’s physics does what’s it supposed to do, if you apply like 5000 Newtons of force at the start, it’s obviously going to slip, think of it in real world terms.

To solve this I tried two ways, both of them are better than limiting rpm of wheel collider.

First is to gradually increase motor torque like in real life scenario, one is having a limit based on gear you are in, or another is to let it increase with ratio, lots of hardcoded values here.

Another idea is to introduce traction control I think this is way better.

If you detect a forward slip, then simply reduce your torque, but you’ve to check slip on all your drive wheels.

How would you detect a slip?

Multiply the rpm (needs to be converted to radians per second) by the wheel radius and you get the velocity that the wheel “wants” to travel at. Check agains the velocity of the parent rigidbody. If there is a mismatch, there is slip.