It looks like the suspension calculation comes into effect, then when the suspension is almost fully compressed, the wheel breaks free from it’s orientation and begins rotating around the wrong plane which makes the vehicle judder.
Have you got any idea what could cause this?
Thank you in advance
Hi,
Are you using the local pose of a PxShape representing the wheel to draw the vehicle wheels? If so, then it looks the rolling axis of the wheel is not set up correctly.
The vehicle sdk poses the wheel shape taking into account the accumulated angle around the rolling axis, steer angle, camber angle, and suspension travel. To do this, and compute the tire lateral and longitudinal forces, the vehicle sdk needs to know the vectors that represent forward, right. and up. This is achieved with the function PxVehicleSetBasisVectors.
Thanks,
Gordon
Hello,
Thank you very much for the fast and helpful response. I am now calling that function before every PxVehicleUpdate(); it seems to have stopped the wheels from rotating in the wrong axis but the juddering persists.
Yes, I am using the geometry of the wheel’s representation to create a new physics shape which I append to the chassis shape buffer to create the wheel collision.
When I have a look at the telemetry data, it seems like the engine revs are jumping all over the place, but I am not yet providing any input with regards to acceleration etc.
Thank you once again for the rapid response
Hi,
Unless you wish to change the right/up/forward vectors you only need to set PxVehicleSetBasisVectors once before the very first PxVehicleUpdates. Nothing will go wrong if you set it multiple times and it will never be the bottlneck but it might make your code a bit more manageable if you just do this once in setup code.
The next thing to look is to see if you have called PxInitVehicleSDK. If you don’t call this function once before any calls to PxVehicleUpdates the vehicle sdk will report an error because some important thresholds need to be set up as functions of the length scale in PxTolerancesScale.
After that, please make sure that the PxShape for each wheel is set up so that it does not collide wtih the ground. Any rigid body contact between the shape and the ground will interfere with the suspension forces arising from the vehicle raycasts. The vehicles section in the physx guide discussed how to do this with simulation filters.
One more thing to look is to make sure that the sprung masses of the suspensions add up to the rigid body mass. There is even a function to help you compute the sprung masses from the rigid body mass and center of mass: PxVehicleComputeSprungMasses.
Then take a look at the wheel mass. If this is close to zero the simulation might become unstable. Please try and choose a reasonably sensible value here ie if your vehicle is 1500kg then choosing a wheel mass of 0.0001kg might give you some stability issues.
Thanks,
Gordon
Hello, thanks again for the awesome response. The PxInitVehicleSDK() is definitely being called, and no errors / warnings are being reported at any time during the simulation.
The only flags on the wheel shapes are the eSCENE_QUERY_SHAPE and eVISUALIZATION flags. The eSIMULATION_SHAPE flag is definitely not set on these shapes so collision on the wheels shouldn’t be occurring.
The sprung mass should also not be an issue. My masses are worked out as such:
fChassisMassPercentage * 0.01 * fChassisMass
Where fChassisMassPercentage is 26 for both front wheels, and 24 for both of the rear wheels. Collectively they added up to the mass of the vehicle (with the exception of floating point error). The wheels also have a decent mass (10KG, the chassis is ~1500KG). I can’t use the PxVehicleComputeSpringMasses() function as that was added in 3.2.2 and we’re using 3.2.
I do have telemetry info working, and it seems the engine revs are going crazy. I do not have any input going into it (I do call PxVehicleDrive4WSmoothDigitalRawInputsAndSetAnalogInputs with valid values, but I never set the input values to anything). Is this a byproduct of the wheels going crazy or are the wheels going crazy because the engine is jumping all around?
Thank you once again
Sorry for the double post, but do you think working in CM could be the cause of some of these issues? e.g. my car has a width of 180 instead of 1.8. I’m sure I’ve accounted for this in all the forces, butcould it be making some of the forces extreme and start messing up the calculations?
Thanks in advance
Hi,
Are you working in centimetres? If so, the default values of the vehicle components will need to be re-tuned to make sure they reflect the centimetre length scale rather than the assumed default metre length scale. We do have customers already using the vehicles that adopted the centimetre as their length scale so it does work but there is some work to be done making sure that all the vehicle component values are completely consistent.
Can you also please try to put the car into neutral gear and disable the autobox? This will disconnect the engine from the wheels and allow us to get to the source of the problem.
Thanks,
Gordon
Hi gyeoman, thanks for the response.
I’ve disabled the auto-gear switch and placed the car in neutral as you suggested. This seemed to stop the vehicle jumping all over the place but the wheels still span like crazy on the spot. I’ve also added additional debug information for the wheel graphs.
The suspension force values are quite low. As I’m working in centimeters, I’m using a gravity value of -980. Inputting that into the expected suspension force calculation (1432 * 980 * 0.25 = 350,840 expected suspension force). Checking the values for the 4 wheels over obtained these results:
Wheel 0: 301474.28 (FL)
Wheel 1: 323228.19 (FR)
Wheel 2: 271290.25 (RL)
Wheel 3: 293044.38 (RR)
They only seemed to fluctuate from these values by ± 100 or so (when idling on the floor). This is a mean suspension force of around 297,000, or around 85% of the expected force. Could this have an impact on what I’m doing?
To confuse matters even more, I’m working in the coordinate system of +Z up and +X forward, as well as centimeter units. I believe all the units have been altered from meters to centimeters to confirm to the unit system, but I’m unsure if I’ve missed a few. The only 2 units I could find which needed altering where the suspension compression and droop. I’ve changed those from 0.3 → 30 and 0.15 → 15. I’ve also modified the MOI on both the wheel and chassis by dividing through 10,000 (100 ^ 2), although I’m not sure if I needed to modify the MOI or not; I’ve tried it both modified and non-modified. Every other value is identical to the sample vehicle. Is this sufficient or are there other forces which need modifying too?
Thank you once again for the help
Hi,
I’m fairly sure that this is a problem with some data needing to be expressed in centimetres. Atually, upcoming in 3.3 is documention for using the vehicle sdk with any length units.
The following is a list of geometrical data that need to be expressed in the chosen length scale:
PxVehicleChassisData::mCMOffset
PxVehicleAckermannGeometryData::mFrontWidth
PxVehicleAckermannGeometryData::mRearWidth
PxVehicleAckermannGeometryData::mAxleSeparation
PxVehicleWheelData::mRadius
PxVehicleWheelData::mWidth
PxVehicleSuspensionData::mMaxCompression
PxVehicleSuspensionData::mMaxDroop
PxVehicleWheelsSimData::setSuspForceAppPointOffset
PxVehicleWheelsSimData::setTireForceAppPointOffset
PxVehicleWheelsSimData::setWheelCentreOffset
The following is a list of parameters that are functions of length scale and also need to be modified:
PxVehicleEngineData::mMOI (kg m^2)
PxVehicleEngineData::mPeakTorque (kg m^2 s^-2)
PxVehicleEngineData::mDampingRateFullThrottle (kg m^2 s^-1)
PxVehicleEngineData::mDampingRateZeroThrottleClutchEngaged (kg m^2 s^-1)
PxVehicleEngineData::mDampingRateZeroThrottleClutchDisengaged (kg m^2 s^-1)
PxVehicleClutchData::mStrength (kg m^2 s^-1)
PxVehicleWheelData::mDampingRate (kg m^2 s^-1)
PxVehicleWheelData::mMaxBrakeTorque (kg m^2 s^-2)
PxVehicleWheelData::mMaxHandBrakeTorque (kg m^2 s^-2)
PxVehicleWheelData::mMOI (kg m^2)
PxVehicleChassisData::mMOI (kg m^2)
I’m not sure if all of these are valid for 3.3 but you might need to go through each one in turn to work that out in 3.2.
One small point is that the MOI in centimetres is the value in metres multiplied by 100*100. I might have misunderstood your post but I understood it that you were dividing by 100000.
I am starting to think that a helper function might be in order to translate the default data to a chosen length scale.
Thanks,
Gordon
Okay thank you, that cleared some things up. Firstly, all forces were copied from the const values used in the sample vehicle, so they should still be in the right units.
Sorry for the confusion over the MOI, when I said divide by 10000 was because I copied the formulas used to work out the MOI from the sample vehicle ((mass * radius^2) / 2). This obviously leaves the value in kg cm^2 as opposed to m^2, so when I said divide by 10000 I meant from cm^2 → m^2. I should have the data in the right formula, and thanks for clarifying the MOI issue as that was the force I wasn’t too sure on.
I’ve double checked my MOI with the sample vehicle and they’re almost identical (with the exception the forces are applied on different axes). This is how I work out the Chassis’s MOI
// Approximation of a cube: http://en.wikipedia.org/wiki/List_of_moments_of_inertia
// Width = X, Depth = Y, Height = Z
// x = mass/12(z^2 + y^2)
// y = mass/12(z^2 + x^2)
// z = mass/12(x^2 + y^2)
float fMassOver12(rChassisData.mMass / 12.0f);
float fWSquaredInM((vecChassisDims.x) * (vecChassisDims.x) * 0.0001f);
float fDSquaredInM((vecChassisDims.y) * (vecChassisDims.y) * 0.0001f);
float fHSquaredInM((vecChassisDims.z) * (vecChassisDims.z) * 0.0001f);
rChassisData.mMOI = PxVec3(
fMassOver12 * (fHSquaredInM + fDSquaredInM), // X = width = height^2 + depth^2
fMassOver12 * (fHSquaredInM + fWSquaredInM), // Y = depth = height^2 + width^2
fMassOver12 * (fWSquaredInM + fDSquaredInM)); // Z = height = width^2 + depth^2
You should be able to see the axes from the comments. Comparing sample vehicle to my copy, I can’t really see any cause for concern between the two versions with regards to the data input.
It seems like the car works great until I attempt to put any acceleration into it which is the point it goes crazy. Looking through the visual debugger, there are no contact points so the raycasts are correctly filtering and working. There are no additional collisions going on which should be interfering with the calculations. The suspension is also correctly adjusting on the first bounce. The second the vehicle moves and begins to accelerate is when the wheels turn extremely violently and make the suspension bounce all over the place.
Any more suggestions would be wonderful, I appreciate the help so far
Thank you in advance
Hi,
If your geometry is modelled in centimetres then every parameter needs to be expressed in centimetres. I think the source of your problem is that you have been converting the centimetre dimensions of your car into metres.
Let’s say that your car is a box that is 100cm * 100cm * 100cm. The moi of the vehicle will be
[100100 + 100100, 100100 + 100100, 100100 + 100100]*mass/12
Similarly, if the wheel radius is 50cm then the wheel moi will be
0.55050*wheelMass
The default values of the car assume that the metre will be the adopted length scale. If centimetres are used then many of the pararmeters need adjusted to reflect that they are expressed in inches or centimetres or furlongs or whatever the chosen length scale might be.
Let’s think about what can go wrong when the units end up being mixed. Imagine that the wheel center is offset from the rigid body center of mass by (100cm, 100cm, 100cm) but the rigid body moi is expressed in metres. If a suspension force F is generated at the wheel then a torque of (100,100,100) X F will be generated.
torque = (100,100,100) X (Fx, Fy, Fz).
The angular acceleration will be
angAccel = torque/moi.
If moi is expressed in metres and the torque is expressed in centimetres then angAccel will end up being orders of magnitude larger than is physically correct. However, if they are expressed with the same units of length then the length scale will cancel in the numerator and denominator, thereby generating the correct angular acceleration in radians per second. There are many parameters combinations in the vehicle code that end up with this kind of error if the units are mixed.
To re-express the vehicle in centimetres you need to go through the list of affected parameters and re-compute their values. Remember that vehicle parameters have been assigned default values under the assumption that metres will be the adopted scale. If centimetres are chosen instead then the default values are no longer correct and need re-computed.
Thanks,
Gordon
Thank you so much for putting up with me :)
I’ve changed all the units to their correct scale and as you predicted, everything is now working great. The only units I now question are the damper rates:
PxVehicleSuspensionData::mSpringDamperRate
PxVehicleWheelData::mDampingRate
PxVehicleEngineData::mDampingRateFullThrottle
PxVehicleEngineData::mDampingRateZeroThrottleClutchEngaged
PxVehicleEngineData::mDampingRateZeroThrottleClutchDisengaged
If we look above at your list of values which need changing, all these appear (with the exception of the spring’s damper rate). When I look at the comments for these attributes, it seems the units are s^-1, so I don’t think they are unit dependent. However, above they’re listed as (kg m^2 s^-1) which would mean I would have to multiply my old meter value by 100^2 to obtain the value in kg cm^2 s-1.
For my final question, are these damper rates units in kg m^2 s^-1 or simply s^-1.
Thank you for all you help, truly appreciated.
Hi,
I’m glad that worked out. I think this is a difficult problem and I’m glad you drew my attention to it. There is clearly some work to be done to make the api easier to use when the length scale is anything other than metres.
I’m afraid there is actually a mistake with the 3.2 unit descriptions. This will be corrected in the next release of 3.2 and also in the upcoming release of 3.3. Sorry for the confusion here.
To avoid confusion here are the correct units of the damping rates:
PxVehicleSuspensionData::mSpringDamperRate (kg s^-1)
PxVehicleWheelData::mDampingRate (kg m^2 s^-1)
PxVehicleEngineData::mDampingRateFullThrottle (kg m^2 s^-1)
PxVehicleEngineData::mDampingRateZeroThrottleClutchEngaged (kg m^2 s^-1)
PxVehicleEngineData::mDampingRateZeroThrottleClutchDisengaged (kg m^2 s^-1)
Any damper rate that affects a rotation is the square of the length scale. This makes sense because the angular acceleration is the damping torque divided by the moi, where the moi is also a square of the length scale. This affects the engine and wheel damping rates.
Any damper rate that affects a linear motion is independent of the length scale. Again, this makes sense because the linear acceleration is the force divided by the mass, where the mass is clearly independent of the length scale. This affects the suspension damper rate.
I hope this gets you up and running.
Gordon
Okay thank you for the explanation. I changed all the above and the wheels do not really “grip” or propel forward, it’s almost like they’re on ice. The friction being returned by the tires are 1.0. When I test the wheel rotation speed, the rear-left is about -6.0 whereas the rear-right is about 5.0. I also get an assert in PxVehicleUpdate.cpp, solveDrive4WInternaDynamicsEnginePlusDrivenWheels (PX_ASSERT(isValid(A,b,result)). The gear ratio value (G) is 16, and the clutch strength (K) is 100,000 (10 * 100^2). It seems to fail after a few seconds of accelerating.
The other question is you left suspension spring strength off your list of values , but the comment states the units are N m^-1. Should I change this value to go from N m^-1 → N cm^-1 as well?
The vehicle also never slows down on any surface. If I give the vehicle a rolling start, it correctly calculates the speed and rotation of the wheels so long as I don’t add any acceleration. It continues to travel at that speed and it looks like there is no friction. If the vehicle is trapped on the chassis and the wheels are spinning in the air but are not connected to any surface, they eventually slow down as they should.
Looking at the graphs the friction continuously fluctuates between 1.0 (the correct value) and 0.0. It still looks like it’s jumping up and down slightly and not sticking directly on the surface. I’ve checked all the units and they’re now correct.
Sorry to keep bugging you, I appreciate the help. Thank you in advance
Hi,
I’m afraid that is another documentation error with the spring stiffness units. The actual units are kg s^-2. Sorry about that.
Let’s try and solve the friction problem first. Is the friction instantaneously jumping from 0.0 to 1.0 or does it also have values in-between? If it instantaneously jumps from 0.0 to 1.0 and then back it sounds like the tire is sometimes contacting the ground then not contacting the ground. This sounds like something has gone wrong with the raycast. Can you please render the raycasts using the results of getSuspRaycast ? You should see a line that starts above the top of the tire and ends below the bottom of the tire. If you don’t then the suspension maximum droop and compression are not set up properly or the wheel radius is not set up properly.
If the friction has values in between 0.0 and 1.0 then the friction vs slip graph is probably not helping you. Please take a look at PxVehicleTireData and make sure that mFrictionVsSlipGraph is a flat graph (mFrictionVsSlipGraph[0][1] = mFrictionVsSlipGraph[1][1] = mFrictionVsSlipGraph[2][1] = 1)
The other thing to look is to make sure you set up PxTolerancesScale correctly for the units you are using. This is actually really important because there are thresholds that depends on the scales.
Thanks,
Gordon
Changing the spring strength back to the non-modified value fixed the friction jumping from 0.0 straight to 1.0. I think you were right in thinking the wheel was leaving contact with the floor because the suspension strength was not right. The magnitude of the suspension raycast wasn’t much larger than the diameter of the wheel so I increased the radius a bit and that seemed to make the wheel stick a little better. The PxTolerenceScale is correct (100 for length, 1000 for mass and 1000 for speed).
Again, after a second of accelerating the vehicle, I get the same assertion in solveDrive4WInternaDynamicsEnginePlusDrivenWheels. Whilst rolling without any acceleration, the wheels seem to rotate, but they do not rotate smoothly. The rotation speed of the wheels spike quite rapidly. One frame it might rotate 1/8th of a circle, another it will stand still, and another it will jump to 1/2 a circle etc. Here is the output of the four wheels in the same order (FL FR RL RR)
Rotation Speed: 5.44
Rotation Speed: 38.60
Rotation Speed: 6.95
Rotation Speed: 36.82
Rotation Speed: 45.86
Rotation Speed: 1.21
Rotation Speed: 41.78
Rotation Speed: 1.92
Rotation Speed: 8.05
Rotation Speed: 49.23
Rotation Speed: 10.43
Rotation Speed: 42.27
Rotation Speed: 37.85
Rotation Speed: 14.22
Rotation Speed: 33.18
Rotation Speed: 12.58
Rotation Speed: 11.44
Rotation Speed: 29.07
Rotation Speed: 11.82
Rotation Speed: 30.38
Rotation Speed: 33.47
Rotation Speed: 5.46
Rotation Speed: 32.25
Rotation Speed: 6.25
Rotation Speed: 5.17
Rotation Speed: 43.21
Rotation Speed: 6.94
Rotation Speed: 40.05
As you can see they fluctuate quite a lot. The interesting thing is one frame the wheels on the left are rotating the quickest, then the next the wheels on the right rotate the quickest etc.
Even after the friction was fixed, the vehicle does not correctly slow down and does not correctly accelerate when I apply input.
Thank you in advance