hello,
i was trying to understand vdrift clutch implementation and im facing something that i cant understand.
Basically in vdrift the clutch is considered locked when:
Code:
if (friction_torque > max_torque) // slipping clutch
{
friction_torque = max_torque;
locked = false;
}
Since:
Code:
btScalar torque_capacity = sliding_friction * max_pressure * area * radius; // constant
btScalar max_torque = clutch_position * torque_capacity;
btScalar friction_torque = max_torque * new_speed_diff; // highly viscous coupling (locked clutch)
we can write:
Code:
if (clutch_position * torque_capacity * new_speed_diff > clutch_position * torque_capacity) // slipping clutch
{
friction_torque = max_torque;
locked = false;
}
simplifying:
Code:
if (new_speed_diff > 1) // slipping clutch
{
friction_torque = max_torque;
locked = false;
}
So when the engine angular velo and the clutch angular velo differs more than unit, the clutch is considered slipping.
But, if you run vdrift in debug mode, you can see clearly that in almost any situations in which the clutch behaves like locked (normal driving, especially in lower gears) the angular velo delta is more than one unit.
How is this handled?
Hi NewLife.
It is a implementation limitation. There is no way to prevent some minimal slip, the clutch doesn't model static friction anyway. The locked state bool should be removed eventually. It is not used anywhere but for debug output I think.
NaN Wrote:Hi NewLife.
It is a implementation limitation. There is no way to prevent some minimal slip, the clutch doesn't model static friction anyway. The locked state bool should be removed eventually. It is not used anywhere but for debug output I think.
Hi NaN,
so the clutch is considered always "slipping"?
If yes, how the engine torque calculation is handled?
From carengine.cpp:
Code:
btScalar total_torque = combustion_torque + friction_torque + clutch_torque;
in this way clutch_torque should be always added to total_torque, but checking the debug output it seems that clutch_torque is never added to total_torque, even if the clutch is engaging
![[Image: vdriftclutch.jpg]](http://unitypackages.net/vdriftclutch.jpg)
As you can see, the clutch is engaging (the clutch is trying to match the engine speed), but the clutch_torque is not added to total_torque, its just equal to combustion_torque.
How is this handled? I cant understand.
Don't let you irritate by the debug output check the code.
Code:
out << "Total torque: " << GetTorque() << "\n";
....
///return the sum of all torques acting on the engine (except clutch forces)
btScalar GetTorque() const
{
return combustion_torque + friction_torque;
}
Total torque reported by debug output is the torque from the engine side not taking clutch into account for whatever reason.
NaN Wrote:Don't let you irritate by the debug output check the code.
Code:
out << "Total torque: " << GetTorque() << "\n";
....
///return the sum of all torques acting on the engine (except clutch forces)
btScalar GetTorque() const
{
return combustion_torque + friction_torque;
}
yes you are right NaN.
So to sum up:
Code:
btScalar total_torque = combustion_torque + friction_torque + clutch_torque;
shaft.applyMomentum(total_torque * dt);
total_torque is used to accelerate the shaft (that is the engine), (combustion_torque + friction_torque) is just used to apply torque to car body, -clutch_torque is used to accelerate the differential (and the wheels).
Is this right?
Yep. I haven't verified the model formally though. Ideally you would want take the inertia of the powertrain into account, but it seems to work this way too.
NaN Wrote:Yep. I haven't verified the model formally though. Ideally you would want take the inertia of the powertrain into account, but it seems to work this way too.
in my implementation i take into account the drivetrain inertia, but it doesn't change much.
Anyway i noticed that in carengine.cpp the shaft is accelerated in this way:
Code:
shaft.applyMomentum(total_torque * dt);
but it carwheel.h is used the same code to apply the torque to the wheel:
Code:
void SetTorque(btScalar torque, btScalar dt)
{
shaft.applyMomentum(torque * dt);
}
Sorry but i cant understand.. Am I missing something?
Another thing i noticed is that while normal driving clutch_torque value (engine panel) varies greatly (from 640 to -640). How does this not affect wheels angular velocity? is the wheel inertia that cuts out this strong delta?
The SetTorque naming is wrong as it applies/adds torque. As long as it is used only once per step it still ok, but should be fixed nonetheless.
I ran into the oscillation issue when I started contributing to vdrift. The simulation will get worse with lower wheel inertia and higher clutch torque.
There is an alternative implementation which won't have this issues. But it is not ready to go into master yet.
NaN Wrote:The SetTorque naming is wrong as it applies/adds torque. As long as it is used only once per step it still ok, but should be fixed nonetheless.
I ran into the oscillation issue when I started contributing to vdrift. The simulation will get worse with lower wheel inertia and higher clutch torque.
Which values of wheel inertia are you using? im using a value of 1.8 kg*m^2 and a value of 0.3 for the engine.
With a fixed time step of 0.02 (50 steps per sec) im experiencing oscillations (although not with a smaller time step). More, I experience a strange behavior of the clutch torque: while driving, especially in lower gears, with throttle released if I push the full throttle clutch torque raises with a lag respect of the engine torque. The result is that it seems that the clutch is slipping for something like half a second.
Another problem that im facing is that i have to put engine inertia in the driveline too (in this way: engineInertia *Sqr(ratio)). If I omit this, i experience heavy and uncontrollable oscillations. But in this way the inertia of the driveline is huge, so even with a sport car settings I cant make a burnout start.
NaN Wrote:There is an alternative implementation which won't have this issues. But it is not ready to go into master yet.
Would you like to share this implementation with us? im really getting mad in order to make my clutch working like i would.
The code is here:
https://github.com/logzero
Certain things are missing that affect car handling considerably. The simulation is running at the same rate as the rigid body code which will be too slow for the tire model(120Hz). Wheel reaction torque is not applied to chassis. Camber is ignored. ABS, TCS don't work.
You have to use vdrift-data-dev for it.
The loads in the debug output are in kW as the engine power.
NaN Wrote:The code is here: https://github.com/logzero
Certain things are missing that affect car handling considerably. The simulation is running at the same rate as the rigid body code which will be too slow for the tire model(120Hz). Wheel reaction torque is not applied to chassis. Camber is ignored. ABS, TCS don't work.
You have to use vdrift-data-dev for it.
thank you Nan. In these days i tested the alternative implementation.
In order to make it work i had to make some modifications:
Code:
inertiaEff = (engineInertia*drivetrainInertia/(drivetrainInertia + gearRatio * gearRatio * engineInertia))*Mathf.Abs(gearRatio)*10;
//Mathf.Abs(gearRatio)*10 added in order to minimize the clutch torque "lag"
float velocityError = (engine_speed - drive_speed);
float lambda = -velocityError * inertiaEff;
accumulatedImpulseOld = accumulatedImpulse;
accumulatedImpulse += lambda;
impulseLimit=clutch_position * torqueCapacity*Time.deltaTime;
//accumulatedImpulse=Mathf.Clamp(accumulatedImpulse, -impulseLimit, impulseLimit); // i had to comment this line cause it prevent car from moving
lambda = (accumulatedImpulse - accumulatedImpulseOld);
lambda=Mathf.Clamp(lambda, -impulseLimit, impulseLimit); // added in order to avoid impulse to be greater than torquecapacity*dt
return lambda;
engineInertia=0.3
drivetrainInertia=0.01
lambda is used for the engine, -lambda * gearRatios[gear] * finalDriveRatio for the wheels (im not using a differential).
drivetrainInertia*Sqr(finalDriveRatio) is added to wheel inertia.
With this modifications it works somewhat well (it doesnt work well with some settings of engineInertia)
Anyway there is now way to make it work with my target time step (0.02, 50 step per sec). With this time step It has serious oscillations or heavy clutch torque lag.
Do you have any suggestion?
Thanks
Michele
I am not sure I can follow your modifications.
The implementation is a simple iterative solver. You can try to increase the number of iterations, but it doesn't work well with large inertia ratios. The accumulatedImpulse is the total angular impulse applied by the solver. It is clamped to the constraint impulse limit. Usually one will have a lower and upper limit. I haven't noticed any issues with the current version though. Lambda is the correction impulse applied during a solver step.
If you want to use realistic values you have to increase the simulation rate and maybe use a different solver. I am impressed that it runs at 50Hz. I think 120Hz are actually too low.
What tire model are you using? I assume you are feeding realistic torque values? What do you mean by clutch torque lag?
NaN Wrote:I am not sure I can follow your modifications.
The implementation is a simple iterative solver. You can try to increase the number of iterations, but it doesn't work well with large inertia ratios. The accumulatedImpulse is the total angular impulse applied by the solver. It is clamped to the constraint impulse limit. Usually one will have a lower and upper limit. I haven't noticed any issues with the current version though. Lambda is the correction impulse applied during a solver step.
If you want to use realistic values you have to increase the simulation rate and maybe use a different solver. I am impressed that it runs at 50Hz. I think 120Hz are actually too low.
What tire model are you using? I assume you are feeding realistic torque values?
Hi Nan,
Im using the same model you are using in vdrift (pacejka 94 with beckman combining method).
I can use 50Hz cause im using a first order differential equation to calc slip angle and slip ratio. In this way everything should work ok even with just 1 iteration. You just need to avoid wheel inertia to be too little (causes oscillations).
This is the code for slipratio and slipangle:
Code:
float max_dampAbsRoadVelo_absRoadVelo=Mathf.Max(absRoadVelo,dampAbsRoadVelo); // dampAbsRoadVelo usually is 7 - 10
deltaRatio = (wheelTireVelo - wheelRoadVelo) - max_dampAbsRoadVelo_absRoadVelo * differentialSlipRatio;
deltaRatio /= B; // B is longitudinal relaxation length
differentialSlipRatio += deltaRatio * Time.deltaTime;
slipRatio = differentialSlipRatio;
deltaAngle=wheelRoadVeloLat - max_dampAbsRoadVelo_absRoadVelo *tanSlipAngle;
deltaAngle/=b; // b is lateral relaxation length
tanSlipAngle += deltaAngle * Time.deltaTime;
slipAngle=-Atan(tanSlipAngle) * Mathf.Rad2Deg;
absRoadVelo is denom in vdrift.
NaN Wrote:What do you mean by clutch torque lag?
While driving (especially in lower gears) with throttle released, when I push full throttle, clutch torque raises with a lag respect of the engine torque. The result is that it seems that the clutch is slipping for something like half a second. It seems that this happens cause clutchdrag raises in a slower way than engine torque.
If you want, you can test online 1.2 version of my simulation (made with unity3d), with old clutch code that work somewhat well but you can easly notice transition between slipping and locked clutch.
http://unitypackages.net/unitycar/joomla...hp?id=city