I meant the socket to PC setup was even less stable than the body -> axle -> wheel etup you use (and I tried). Also I tried using a skeletal mesh with the bones where the wheels and PC’s should be and it was even worse.
Heres the settings of the rear wheels, axles, and wheels and such. I know how a game engine can cause you issues from “checkbox errors”
I see two problems out of the box:
Perhaps my naming convention is misleading, when I’ve added “axle” primitive I wanted to simply add an intermediate block between wheel and chassis - it’s not suppose to work as a real axle which would rotate and rotate wheel, it’s just there so the wheel’s constrain doesn’t have to extend all the way to the chassis root.
Thank you for your help! You’ve definitly played with PC’s more than me. I tried the socket method using the setups for wheels above (changing AxleL/R to socketnameL/R obviously) and it seems much more stable. Things still go wonky when i hit a bump at fast speeds or it goes over it limits (ie I have the z rotataion of the hitch (coupler) limited to 120 degrees so that I cant do crazy 180 turns into it but i get the results seen in the video.
I’m also able to leave it at stock weight with this setup so it isnt as bouncy. I alsdo added the pysmat with a friction value of 1.125 and bounciness value of 0.05 to the wheels.
I think without some serious engine rework or once unreal works on the wheeledvehicle class for Unreal Tourn. I wont be able to get this pet project much beyond this point but it is fun to see something like this working! Just like when I got my submarine simulator pet project to work very realistically. Wheel/vehicle physics are the most complex/difficult thing in Unreal I commend you on what you’ve been able to do being so stable.
I’ll let your thread get back on track ,I dont think I can take this project where I want because I see all sorts of issues (if you’ve played Farming Simulator 09/11/13/15 you’d know why this isnt even close to acceptable for a “pet project” let alone anything serious). For example imagine having a front end loader with a frame that can move up/down and a bucket that can rotate on that frame attached to a hitch (coupler) on the front of a tractor, then a trailer connected to the back coupler which is connected to another 1,2,3,4… and lets say these trailers have steering wheels to 15 degrees and can tip (hence tipper trailer) plus you can see how bouncy the Z translation is in the video at the coupler even though I set it to 1 unit max.
Much thanks though!
Downloaded your new MarkI BTW gonna check it out later.
Can I safely remove the idler and sprocket from the blueprint?
I tested this by just duplicating the ripsaw… deleted the idler and sprocket and removed their reference in the animate wheels function.
Works fine…
I can then just use “roadwheels” to drive the excavator. Will then just make the idler and sprocket a drivewheel also, since they are inline anyway with the smaller roadwheels in the middle.
Probably not the way it is supposed to be done… but works… unless you have another suggestion.
I don’t see them being referenced anywhere except AnimateSprocketOrIdler function and you don’t have to call it if you don’t have them, so it’s fine to remove them.
Replacing it with road wheels won’t really work as first of all they don’t have collision. The other issue is Normal Force necessary for friction, is calculated from Suspension Force, in case when your Sprocket/Drivewheel tries to go over some higher than wheel radius vertical obstacle, suspension will be pushing wheel vertically but collision surface normal would be horizontal - normal of the surface would be orthogonal to suspension so normal force would be zero or just too small to provide any kind of grip.
You could try setting suspension with 45 degrees in pitch, to get some force pushing against the wall, but most likely it will push vehicle away from the wall if force is too strong or don’t provide enough grip if it’s too little.
The real solution to all this is refactoring code to support friction in arbitrary points, effected or not effected by suspension, like it’s done on Mark-I.
Amazing work BoredEngineer
first sorry for my bad english:)
Im writing my own code in blue print for 4 wheeled vehicle. As in know you very good in vehicles so I have some questions:
By shifting gear up the gearbox torque decrease so the force on wheel will descrease. I apply this force to my vehicles wheels and the vehicle speed will decrease. What should I do to increase my vehicle speed in high gears?
Perhaps come back here in a few weeks or a month. I’m planning to re-build most of the tank’s functionality into components (Aerosled is a prototype for such approach). I’ll be adding components for the wheels as well, so something like a half-track could be easily build. I’m still polishing some of the holes in the math and algorithms and figuring out architecture for setups based on physics constraints.
I’ve been testing with an excavator setup.
I removed the idler and sprocket and use only the roadwheels here.
but I noticed some weird collision behaviour.
Whenever any colossion volume comes over another (hope I’m explaining it right)… it stops the excavator from being able to move foreward.
I hope it’s visible in the video… The cabin and all the rest is a child object of the hull.
The bucket and the arm have a collision object.
Whenever one of these inline with the Z axis go “over” something on the floor… it stops the excavator.
When I remove the collision from the bucket and arms… all is fine.
There is no direct collision (the arm is raised high enough to clear everything) , It looks as If everything in the hierarchy upwards of the hull get’s checked in the Z direction down to the ground.
Any thoughts on this?
Perhaps you are not integrating velocity of the axle separately. You need to store velocity of the axle, if you have differential then it would be velocity of the axle before differential. On every frame, take torque from engine, calculate from it angular acceleration of the axle and update velocity using it. This way, when you up-shift, torque will be less but angular acceleration will still be there, even if it’s a smaller value than on a lower gear. This angular acceleration will keep raising angular velocity of the axle and wheels.
The full update cycle looks like this:
-> update throttle -> using current axle velocity calculate engine RPM -> get potential engine torque at current RPM -> multiple potential torque by throttle (0…1) -> clutch passes torque to gearbox -> gearbox multiplies torque and passes to axle -> calculate angular acceleration of axle using torque -> update axle angular velocity using new angular acceleration -> multiple axle angular velocity by wheel differential -> calculate relative velocity of the wheel for friction calculation -> friction exerts torque on wheel -> calculate wheel’s angular acceleration from friction torque -> calculate new wheel’s angular velocity using angular acceleration -> divide wheel angular velocity by differential to get new axle velocity -> update throttle (this is where cycle repeats)…
One very important thing, you need to add “red zone” of the engine. This is a maximum RPM of the engine over which torque rapidly drops. Without red zone you will be accelerating infinitely even in 1-st gear and there won’t be any point to up-shift.
Are you moving arm using physics? Otherwise collision on them might not be updated. Try console command “show Collision” too, maybe you can spot something weird.
It can be related to the fact that most of the “ground clutter” objects in the scene have been scaled non-uniformly and physics doesn’t like it. For example logs don’t work properly with sweeps.
Edit: try dropping some uniformly scaled boxes on the ground and see how it works with them.
I should have asked first what kind of setup you have 
If your wheels are physically simulated and you applying torque to them using AddTorque then most likely gear ratio is just too weak to overcome other forces acting on the wheel - friction, air drag of vehicle and etc. depends on what you simulate.
Some new juicy math with illustration. This is a “half” of the suspension force equation which talks only about calculating Spring part of the force:
This should simplify tweaking of the suspension. The idea is following:
Second part of equation is “dampener” or “shock absorber”. It’s not show in diagram as it’s the same as it was before:
Dampener Force = Damping Coefficient * Suspension Target Velocity * Current Suspension Velocity
where suspension velocity is the velocity of it’s compression. The only new change I’ve added is scaling of the dampening force by 25% or 75% percent depending if suspension is compressing or expanding. We want suspension to react quickly to compression when wheel/track/ski hits surface so Damping Force is only at 0.25 at the same time when suspension expands we don’t want to do it too fast so Damping Force at this point is 0.75
Actual code looks like this:
New version is available at git-hub. Mark-I prototype and new suspension for Aerosled where added:
Visual suspension of aerosled matches 100% with actual calculation of suspension. I’m using newer model for the chassis of aerosled with a different center of mass. From my reasoning, new center of mass is more realistic to real-life vehicle, but if you try to drive it, you’ll see how easy it is to flip it over. Something like anti-roll-bars should help but I don’t thing they were used on this vehicle. Perhaps I need to add non linear spring force, so that vehicle is easier to balance. The other approach is to limit eve further how far, in the up/down arc, ski can travel. Right now it’s set to 45 degrees, but I consider this cheating and rather get proper behavior by figuring out “why?” and how it can be solved.
Fresh compiled version:
https://www.dropbox.com/s/1rtmxzaib33zz7e/TrackedVehicles.zip?dl=0
Thanks for your respond BoredEngineer
Torque unit is (kgm^2)/s^2 i multiply this by 10000 to convert it to unreal unit(cm)
Multiply to gear ratio and final drive?
angular acceleration = Torque/(wheel mass(kg)* r(cm)^2) ?
angular velocity =sqrt( angular acceleration (W^2)) ?
How can i calculate relative velocity? is this true: using unrotate to calculate relative velocity from get actor rotation and get actor velocity ?
for obtaining miuX and miuY as you told in earlier posts ?
Friction torque=miuvehicle weight forcer or friction torque= axle torque*miu ?
I think clamp is good to limit RPM.
I use add force at location not add torque so i think i should convert new axle velocity to force!! do you have any proposal for this?
Depends on engine curve, the one I’ve found were all in N*m, so conversion is just multiply by 100.
If you have some gear connected after gear box but before deferential - then yes. The point is to select some part of transmission as a reference for integrating angular velocity, I choose to do this right before differential and reverse gear (actual mechanical gear) as left and right track can be rotating with different velocities and in different directions. This way axle always rotates in the same direction, regardless which way tracks rotate.
angular_acceleration_of_axle = Torque / Moment_of_Inertia_of_Transmission; wheels are not involved in anything yet, at this point we are rotating clutch-gearbox-axle, so we need their moment of inertia, not wheel’s. I calculated MOI offline using simple primitives and guesstimation.
angular_velocity_of_axle = angular_velocity_of_axle_on_previous_frame + angular_acceleration_of_axle * delta_time; that’s what it means by continuously integrating axle velocity, we keep track of it on every frame and capture any changes that happen to it.
Relative velocity consists of two part: linear velocity from car’s movement and linear velocity from wheel rotation. First one you ether calculate yourself by taking into account linear and angular velocity of the car or just use GetVelocityAtPoint() function.
Linear velocity from wheel’s rotation is simply wheel angular_velocity*radius. Both terms give us a complete linear velocity of the wheel at collision point, but as collision surface can be sloped and wheel might be moving not in parallel to it we need to project everything into the plane defined by collision normal. Final expression will be like this:
Wheel_velocity_at_point = GetVelocityAtPoint() - Car_X_Vector * (wheel_angular_speed * radius);
Relative_wheel_velocity = ProjectVectorOnToPlane(Wheel_velocity_at_point, Collision_Normal);
It’s a bit more complicated as friction might not be aligned with the X axis of the wheel. After you got friction force you project it first to the X axis of the wheel and only then you calculate torque from it.
It’s not about limiting RPM but limiting Torque, without red zone you will be always getting torque at top RPM, so you will be accelerating without need to shift gear.
Velocity doesn’t convert into force, “propulsion” comes from friction force resisting movement of the wheel, you could take into account torque in friction calculation but together with wheel’s velocity.
Hope this helps!
Thanks BoredEngineer. your tips are very good
I will try to use them.
Apparently I did forgot to take wheel torque into account when calculate friction. That’s a fail. Might explain why m113 weren’t able to scale 30 degrees slope!
I forgive you 
But only because it’s christmas eve 
Hehehe
Have you solved that collision issue with excavator?
Happy Christmas, everyone!
