Getting Road torque, wheel reaction torque from wheelCollider

Hi fellow devs,

I'm trying to model a simple vehicle clutch and need to get the reaction torque from the wheels so I can calculate the resistant from the wheel side and figure out the angular acceleration at the engine. From what I've read in the documentation, there is no such exposed variable from wheelCollider. The variables that I think are related to my problem are wheelHit.force and wheelHit.sideway/forwardSlip.
In my understanding, wheelHit.force is how hard the wheel is being pushed to the contact point. The harder it's being pushed, the higher the force. This is different from stiffness or grip in general as it's not how grippy the current wheel is but just how hard it's being pushed. They are related but not the same.
So I'm thinking maybe I need to use these 2 variables to calculate the reaction torque of the wheel somehow? I've seen nVidia's clutch using the difference between engineRPM and wheelRPM, but that means the clutch will always be slipping which is not how the clutch works. Can someone please help me on this?
Thank you very much.

 

PhysX vehicles don't use the reaction torque concept. There's no single mention to it in the nVidia's PhysX Guide nor in the vehicle API reference.

The reaction torque requires the precise final force that is being applied by wheel to the vehicle at the tire's contact point. This is the force vector enclosed in the ground's plane (suspension force doesn't count). The reaction torque would be the longitudinal part of that final force converted to torque. I doubt it could be extracted from the WheelCollider or even from the PhysX data.

 

Thank you very much for your reply.
It's kind of weird for nvidia to not referencing important factor like reaction torque, as this is important for simulating the engine and the LSD (reaction torque required to lock the diff), and also very important for force feedback on wheel controllers. I guess now I will use what I can get from wheelCollider to implement a simple clutch, maybe using nvidia's clutch formula (clutchTorque = clutchStrength * (wEngine - G*wWheel)). Do you think that nvidia is really using Pacejka for wheelCollider? Because I'm pretty sure reaction torque is a big part of pacejka.

Another question if you don't mind. When looking at your Vehicle Physic Pro asset page, it mentions that the asset support steering wheels such as the logitech g25/g27. I'm testing the input with my logitech g29 using the logitech sdk for unity3d (which is pretty similar to the g25/27) and realized that the pedals are from -1 to 1, not 0 to 1, so I can't use torque*input anymore, and the buttons are confusing. Would you mind sharing the input map for buttons and axis on the logitech g25/g27 and how you implement the -1 to 1 input? The asset looks promising by the way. Do you still use wheelCollider as the base and build off that or implemented something new completely from the ground up?
P/s: your GTA-style Vehicle Physic is awesome by the way, perfect fit for arcade style games, and one can learn a lot from the source code also.

 

In my opinion, nVidia's PhysX Vehicle SDK is a collection of badly applied formulas (i.e Carsim's tire model), cheap tricks (i.e. filters) and patches for specific situations (i.e. look-up tables). It *mostly* works in some situations, but clearly fails in the majority of them. They say that it's targeted for performance and not for realism, but I believe that doing it right would be even more performant that is now as they would get rid of a ton of useless code (such as the mess around their wrong interpretation of the sprung-mass model). Thus, I'm certainly don't surprised that the concept of reaction torque isn't even mentioned.

Pacejka is not a tire model, it's just a y=f(x) formula (see Facts and Myths on the Pacejka formulas). Here you may be referring to the self-alignment torque, which is a different concept than reaction torque, defined by an additional curve in the Pacejka formulas. Anyways, nVidia is not using Pacejka at all. It uses a simple curve defined by three points, origin, extremum and asymptote, which are the friction parameters exposed by the WheelCollider in Unity.

Just map the values to your convenience:

Code (CSharp):

1. normalizedValue = (rawValue + 1.0f) * 0.5f;

I had used the Logitech SDK for Unity3D in the past, but I had to discard it because it was highly unstable and crashed Unity often. Now I use my own native DirectInput wrapper, which allows reading input and providing force feedback to any device, not only Logitech's.

The device's axis and button maps are typically available at the device's manual. Axis can be quickly learned by examining the raw values when moving them.

Thank you! Yes, WheelCollider is used for suspension and contact detection only, but it's just used "internally" by the package (i.e. no need to create WheelColliders, they are instanced in runtime). I plan to improve this part by replacing the WheelCollider with other solutions.

 

I noticed another thing about WheelCollider is that it does NOT account for tire width because it is just a raycast. In closed-wheel cars this can be somewhat overcome by bringing the wheelCollider to the outer ring of the wheel. However, for open-wheel like Indy or Formula cars, it can be problematic when 2 wheels collide, and the fact that there is no cylinder collider makes the problem nearly unsolvable. Does Vehicle Physic Pro have some sort of 3D wheel? I read the new PhyX press release and I think they try to overcome the problem of the wheelCollider not being a wheel but a ray by having filters for different situation (ie: sweep for multiple contact points). Is that the filter that you talked about?
Also do you understand the wheelHit.force from wheelCollider? The scripting preference doesn't do a very good job of telling what kind of force it is.

 

Not yet. I plan to develop a competent solution for simulating 3D wheels that account for all the situations.

Currently the best workaround is enclosing the wheel collider within the boundaries of the vehicle's collider, like this:



It's not a perfect solution but it resolves most situations, especially those in which the WheelCollider throws the vehicle to the sky.

This is one of them. It's a trick for the contact points but wouldn't account for the tire width, nor will provide wheel vs. wheel contact (as wheels are still sweeps or raycasts, not "solid" entities).

It's the vertical force at the contact point. The value matches the force the suspension pushes the wheel against the ground.

 

Thank you again for your help.
I would like to go back to the discussion of the clutch. I just found this Mathlab model:
http://www.mathworks.com/help/simulink/examples/building-a-clutch-lock-up-model.html
From what I understand from this model, the clutch would have 2 states:
- Locked-up: wEngine = wTransmission. The condition is when the friction strength is strong enough. This means that even when the clutch is not fully engaged, if the friction is strong enough then wEngine still equals wTransmission.
- Slipping: wEngine =/= wTransmission. The condition is when the friction strength is not strong enough. This can be achieved by having stronger torque on one side which is strong enough to overcome the friction strength (i.e: engine over rev by going down a very low gear when going at high speed), or the friction strength itself is not strong enough (i.e: clutch not fully engaged, clutch wear).
Do you think this model is correct?
Still, I don't have the necessary skill to transfer the formula found in this model into the model in my game. But I think understanding and being able to apply this would be beneficial later on as I need to implement a LSD model too (which I may have to ask for your advice again if you don't mind)

A side question is about engine backfire. From my understanding, backfire is when the fuel in the cylinder doesn't get burned properly or not burned at all, the leftover fuel gets into the hot exhaust and burned, creating the fire. This is due to bad valve timing or intentionally done by the ECU to cut power. However, I doubt that games would model this exactly, since this requires realtime calculation of movement and state of each cylinder and can be CPU hungry. I saw this a lot in even arcade games like need for speed. Do you know this backfire is implemented?

 

I don't see any reason to think otherwise. Indeed, my own formula is very similar to the Equation 5. Mine it's adapted to my drivetrain model (i.e. uses angular momentum instead of angular velocity).

I don't know about this, sorry. Should I implement backfire in the future, most probably I'd start with some simplification that just looks good.

 

Thank you for your reply. I will focus on study this model to implement it in my project.
Another thing I'm still curious about the clutch. When playing driving and sim-cade (forza, gran turismo, project cars), I saw the option of upgrading the clutch to "racing clutch" with the description of "improve clutch response but will hurt uphill climb performance". To my understanding this means that the clutch will be pressed harder thus giving less slippage and more effective power transfer and engine speed matches wheel speed faster, even though having less slippage would make Hill climbing harder as the engine can be stalled easily. This corresponds to formula 2 of the above mentioned model. And this is what nvidia is trying to get with clutchstrength. Is this correct?
From here I am understanding this model into steps and parts like this:
1- engine generates torque Tin
2- Tin is transferred THROUGH clutch. The torque that WILL BE TRANSMITTED through clutch Tcl (or Tf, I'm confused here, will ask below) will be determined by the current state of the clutch, slipping or locking (formula 3 and 5). From clutch state we have another condition: the clutch will remain locked if the torque will be transmitted Tf is less than the capacity (strength) of the clutch (Tfmax, formula 6). So we have 2 conditions: 1- locked if Tf <= Tfmax, in this case Tcl is calculated in formula 5. 2- slip if Tf > Tfmax, this case Tcl is calculated in formula 3. This is summarized neetly in this picture:


Now my question is, I'm confused between Tcl and Tf. I understand that Tcl is the torque will be transfered through the clutch, but in what direction? Is this going to be the Torque from the engine Tin or the reaction torque from the wheel? Because I think sometimes the wheel side would drive the clutch harder, say when downshifting to very low gear and the wheel is spinning faster than the engine. Then there is Tf poping up in formula 5, I don't know where this comes from and how it fits in, and this caused me tp hit a big barrier in understanding this since Tf is the factor that determine the state of the clutch. Would you mind explaining this Tf to me? Formula 5 is giving me hard time understanding.
Also once I have the torque will be transmitted and work backward to find the net torque (Tin - Tcl), how can I use the net torque to workout the engineRPM?

 

It worth mentioning that nVidia seems to be confusing "clutch" with "torque converter". Their interpretation ("By definition, the clutch permanently slips") has some sense in the torque converter but it's completely wrong in disc-friction based clutches.

The main difference between a standard clutch and a racing clutch is that there are no springs in the disc plate. This means that the clutch is almost either fully engaged or fully disengaged, with a very narrow transition in between. Here you can see the clutch of the racing car I'll be driving next year:

​

"Making hill climbing harder" refers to the difficulty of starting the car from being stopped in a hill. In these situations in a standard car you would find an intermediate engagement point in the clutch so the car could smoothly start moving up hill. However, finding that intermediate engagement point in a racing clutch is much more difficult because, as said, it's almost 0 or 1. So you would either stall the car, or start burning some rubber.

About the formulas, I haven't gone through this specific clutch model so I'm afraid I cannot help you here, sorry.

 

Thank you again for your time. I'm sorry that I'm dragging this a little too long but since this is my first time tackling physic simulation in programming I have a lot of questions regarding the model and the implementation.
I can see that the approach will roughly be like this
having 2 if statements corresponding to the 2 states. If Tcl (torque through clutch) <= Tfmax (clutch strength) clutch is locked do calculation from formula 5, else is slipping do calculation from formula 3. Now the confusing part is at initialization, how can I calculate Tcl, because the state is unknown. Again I've bumped into this kind of problem before quite sometimes and still have no idea how to deal with when working with simulation because the variable you need to calculate is needed in the initial calculation, creating a confusing loop. If you don't mind can you please help me sorting this out? And also do you have any reference or material for guiding beginner to simulation programming?

Another thing is when looking at this formula from the matlab model for slipping clutch:

This formula reminds me of nvidia's implementation, which is pretty similar with clutchTorque = clutchStrength*(wEngine - wWheel).

Ps: the personal clutch example you gave me is awesome, I am just getting into vehicle simulation so that helps me visualize. Have fun racing with your car.

 

@Edy
Another small question is about total inertia. In formula 5 for calculating torque out when clutch is locked, I need inertiaEngine + inertiaVehicle. Does inertiaVehicle include things like wheel load, reaction torque or/and vehicle weight? It might sound stupid but I'm thinking that since the clutch is locked, it has to drive not just the transmission but the whole weight of the car, so maybe the vehicle weight must be counted in?

 

Hey, sorry for the delay. The clutch implementation strongly depends on the overall drivetrain design. The matlab model works with those formulas because their framework allows to.

In my implementation the clutch computes the torque that keeps itself locked. If any torque coming from either side is greater than that value, or the torques have opposite sign with a difference larger than it, then the clutch slips. This requires knowing the reaction torque at both sides, with involves knowing the reaction torque at the wheels.

 

Thanks a lot for your time. I think I'm getting confused between wheel alignment force, tire load, reaction torque and rolling resistance. In my understanding right now reaction torque is the torque acting in the opposite direction of the engine torque. This is caused by the force that the tire used to hug the road (friction) and the engine has to overcome this force to drive the wheel.
From that (potentially incorrect) understanding, I'm thinking that there might be a way to calculate road reaction torque based on what's exposed in wheelcollider. Maybe based on the (not very correct) tire friction setting of wheelcollider, the current torque at the engine side that is transferred to the wheel, and the current slip amount (which doesn't make sense also) I can somehow work out how much of the engine torque is effectively transferred to the ground through the wheel. What do you think about this?

 

If there's such way, then I've been unable to figure it out. I couldn't extract any logic out of the WheelCollider friction values when I tested it extensively back in Unity 5 (as for the PhysX 3.3 upgrade).

 

I just took a look back at the first differential equation and noticed that they also use angular momentum


Are those similar to yours since yours also use momentum (inertia * velocity)?
Is the second formula calculate road reaction torque at wheels or the torque that is going to the wheel through the clutch?
And once I got momentum from the formula, how can I use it to calculate back engine speed? The way I'm doing is subtract clutchTorque from engineTorque, then divide engineInertia, times deltaTime. So the engine drives the crankshaft, which is held back by the clutch torque. ClutchTorque = (engineSpeed - wheelspeed*gear)*clutchstrength. Still I don't know if this implementation factors in different gear ratio at the wheel end.
((engineTorque - clutchTorque) * deltaTime) / engineInertia.
This returns the angular acceleration of the engine (torque = inertia * acceleration) , then each time step acceleration is added to engineSpeed.
I don't know what formula I can use to make use of momentum. Can you please help me out, or just give me a wiki or page that has the necessary formula's?

 

Those look like analytical formulas. Mine just compute the derivatives that are consumed by the integration solver, so it's more like "momentum = momentum + derivative (torque or force) * delta time".

Again, I haven't gone through this clutch model nor the Mathworks simulation model, so I can't tell.

This is a good source for learning about integrating the momentum:
https://gafferongames.com/post/physics_in_3d/

 

Hi, may this be helpful, I am doing this code ,base on a model of this paper, with simplify some condition