[1.8.x] KSPWheel - Physics Based Alternate Wheel Collider [API Only]

[Beetlecat]

This is all so amazing and astonishing and exciting! Thank you all for the great read in this thread!

I also didn't expect the KF stuff to work out of the box with this -- but, wow. This is an auspicious beginning.

Edited December 5, 2016 by Beetlecat

[damerell]

4 hours ago, Shadowmage said:

This is false; a vehicles motor does not apply torque or any other forces directly to the vehicle or road.  A vehicles motor applies torque to drive-train through to the axles, and thus eventually to the wheels, which causes the wheels to spin faster (or slower).  It is the friction caused by the difference in velocity of the wheels against the road surface that propels the vehicle.  (In real life, the 'spin faster' of the wheel is mostly absorbed by rubber stretch and deformation, so except in extreme cases of slip, the wheel visually appears to adhere to the road, even though there is some stretching and deforming going on at the contact patch)

You've misunderstood me. Obviously, I know that the axle turns the wheel and the wheel pushes against the surface. What I mean by "The job of the torque isn't to rotate the wheel, it's to move the vehicle" is that the torque has no reason to vary merely because the moment of inertia of the wheel does, because the _purpose_ of applying the torque isn't to spin the wheel. If the dimensions of the wheel didn't change, once the vehicle reaches a steady speed on the flat, exactly the same amount of torque will be required to maintain that speed.

4 hours ago, Shadowmage said:

Moment of inertia of a wheel -- It does rise with the square of the radius -- http://hyperphysics.phy-astr.gsu.edu/hbase/icyl.html ( MOI of a cylinder = 0.5 * mass * radius ^2 ).

It does, if the mass doesn't change, but of course the mass does change. I'm not sure what I can add here. If you suppose the new wheel is n times as large in all dimensions as the old one but of like density, you will find it weighs n^3 as much and so the moment of inertia is n^5 times as much.

4 hours ago, Shadowmage said:

(Rolling resistance and drag chart, from: http://www.asawicki.info/Mirror/Car Physics for Games/Car Physics for Games.html , shows linear increase in RR with speed)

That graph is obviously bogus since it shows traction force constant with speed. That is extremely unlikely since it implies power output is increasing linearly with speed with no limit. The author is simply wrong about rolling resistance being proportional to speed (and it is because they are wrong about this that the RR vs drag curves are the wrong relative shape. Aerodynamic drag dominates much more at higher speeds because it is proportional to the square of speed [1] and rolling resistance is not.)

The Wikipedia page mentions speed but does not discuss it in detail; most of the page discusses the usual approximation, where rolling resistance is proportional to the normal force. This is a perfectly good approximation for most purposes and it is a much better one than supposing it is proportional to speed. (For example, see http://www.analyticcycling.com who are happy to use this approximation throughout...)

I increase RR in my proposed model above the part design speed not because that is realistic but because it's an easy way to reflect the part's supposed design speed in its performance, especially given that we don't have tools like increased maintenance, risk of throwing a tread, losses internal to the drivetrain, or whatever.

[1] Someone's going to say, no, cube of speed. Power lost to aero drag follows the cube of speed because the amount of work done against the force is itself proportional to speed.

Edited December 5, 2016 by damerell

[Shadowmage]

2 hours ago, damerell said:

You've misunderstood me. Obviously, I know that the axle turns the wheel and the wheel pushes against the surface. What I mean by "The job of the torque isn't to rotate the wheel, it's to move the vehicle" is that the torque has no reason to vary merely because the moment of inertia of the wheel does, because the _purpose_ of applying the torque isn't to spin the wheel. If the dimensions of the wheel didn't change, once the vehicle reaches a steady speed on the flat, exactly the same amount of torque will be required to maintain that speed.

Yes, apparently I did misunderstand you, my apologies; I was interpreting it in technical terms.  You are correct, changing of the wheel mass doesn't change the output power at the wheel for any given torque input; the same amount of power should be available at the road as was input as torque to the wheel. 

For a given torque input across a range of wheels of varying moment-of-inertia, each should have the same resultant angular momentum, however they will have differing angular velocities, which is important to the simulation (or rather, the integration method).  If a wheel is too light, the angular velocity increase for a given torque across the integration period results in a much higher final velocity, and a higher resulting slip ratio, which causes a greater tendency for the wheel to slip in general and lose traction more easily when downforce is decreased momentarily.  If a wheel is too heavy it could limit potential vehicle acceleration at extreme wheel mass values (though at this point, the wheel would weigh a significant portion of the vehicle, so should probably not be encountered with most reasonable configurations).  (Okay, so something about that last one is striking me funny, but I'm unable to find where I'm missing something...)

This is more a failure of the integration method I'm using than anything else (only standard Euler is available, as I don't have access to the RigidBody integration), but it is a point that needs to be taken into consideration when dealing with the balancing of wheel parts and setting up their scaling mechanics.  I'm investigating alternate integration methods that should hopefully make this less of a concern, but lack of access to the Rigidbody back end means I'm going to have to get creative.

 

2 hours ago, damerell said:

That graph is obviously bogus since it shows traction force constant with speed. That is extremely unlikely since it implies power output is increasing linearly with speed with no limit. The author is simply wrong about rolling resistance being proportional to speed (and it is because they are wrong about this that the RR vs drag curves are the wrong relative shape. Aerodynamic drag dominates much more at higher speeds because it is proportional to the square of speed [1] and rolling resistance is not.)

I suppose this is probably a difference in terminology.  I use rolling resistance as a general term to include friction losses caused by bearings, gearing and axles (all speed dependent, some also load dependent) and losses from tire deformation (which I thought was also speed and load dependent).  However I believe the latter (tire deformation) is the proper/technical definition of rolling resistance, and the former (bearing friction) is more often called drivetrain loss or drivetrain efficiency. 

Reading up more on that, nearly every source agrees that it is independent of speed (on a smooth surface), and is a constant term multiplied by wheel load; you are correct in that tire deformation rolling resistance is a constant force, and I learned something new today .  I'll try to differentiate the two better in the future to avoid any further confusion.  The two aren't really related and probably shouldn't be lumped together -- a tire devoid of any bearings, axles, or other rigging (so, just a tire) will still experience rolling resistance based on deformation, but obviously would not experience any sort of drivetrain related losses; a free hanging axle without any form of tire (or with...) will still experience friction losses, but would not experience any rolling resistance.

I would like to model both, as I think that drivetrain resistance could be a large contributor at higher speeds, especially with tracked vehicles.  Using a linear speed-based approach greatly simplifies the integration end of things, but I'll also look into adding in a flat term to represent the loss due to tire deformation.  No reason that both can't be present and configurable.

(That graph probably wasn't the best example, as the author was demonstrating more the concept of 'max attainable speed' where traction forces and resistance forces balance out, rather than graphing any realistic example of rolling resistance.  The article did note that author was also factoring in drive-train and friction losses for his 'rolling resistance values', but apparently his choice of terminology was poor.)

 

3 hours ago, damerell said:

It does, if the mass doesn't change, but of course the mass does change. I'm not sure what I can add here. If you suppose the new wheel is n times as large in all dimensions as the old one but of like density, you will find it weighs n^3 as much and so the moment of inertia is n^5 times as much.

Yeah, which is where things get a bit complicated trying to figure out the proper scaling mechanisms for everything. 

Engines torque should probably increase linearly with part mass (an electric engine with constant kw/kg) (so should be ^3 with increase in scale, not sure how TweakScale actually scales it), same with the 'wheel mass'.
Wheel radius increases linearly, which as you pointed out results in a ^5 scaling to the MoI of the wheel when combined with the mass scaling.
Spring force should probably increase on the square or cube; probably the latter to maintain equivalence with the increase in part mass.
Damper is a derived value, calculated from spring force and damper ratio (which is dimensionless and doesn't need scaling).
MaxRPM / max-speed -- hard to say...

...Going to take me a bit to work through all the TweakScale support, and I'm going to have to nail down the motor setup that I want to use first.

 

 

[riocrokite]

hey @Shadowmage

Did a bit more testing with sample rover on Kerbin and Mun ( 3 x fl-t800 tanks with mk1 pod, 3 inline batteries and 4 tr-2l wheels slapped on sides).

I simply couldn't get a stable setup for heavy duty wheels for variable weight rovers (i.e. refueler or dumper type). If I got them 'stable' under a given weight, vehicle became ticky and bouncy when empty and vice versa, tried different values from spring / damper and ride height to no effect. I also noticed weird shaking of springs when coming out of a turn so the when a vehicle's body turns from angled to straight:

note 50% here means neutral compression point for the vehicle given its weight and spring(load capacity).

Only stable option for me would be to optimize wheels for light weight and then accept that springs are max compressed and basically not working under heavier load, but that comes around with other problems since max compressed springs are often cause of excessive springiness and erratic behaviour. Then there's excessive springiness when approaching slight terrain angle change on low-g bodies so yeah. In short it's hard for me to build heavy mining rover for hauling cargo one way and coming back empty. It seems that you can design rover that works well according to its weight on a given body. But then change the g force or rover's weight and it's glitch-happy. But yah I guess those are limitations of physx mentioned by you earlier so just mentioning the stuff here for reference.

One more thing, would it be possible to expose drag induced by weight value to it could be changed in the wheel cfg? Right now with a big weight it's pretty hard to get rover to move.

[Akira_R]

4 hours ago, riocrokite said:

hey @Shadowmage

Did a bit more testing with sample rover on Kerbin and Mun ( 3 x fl-t800 tanks with mk1 pod, 3 inline batteries and 4 tr-2l wheels slapped on sides).

I simply couldn't get a stable setup for heavy duty wheels for variable weight rovers (i.e. refueler or dumper type). If I got them 'stable' under a given weight, vehicle became ticky and bouncy when empty and vice versa, tried different values from spring / damper and ride height to no effect. I also noticed weird shaking of springs when coming out of a turn so the when a vehicle's body turns from angled to straight:

*snip*

note 50% here means neutral compression point for the vehicle given its weight and spring(load capacity).

Only stable option for me would be to optimize wheels for light weight and then accept that springs are max compressed and basically not working under heavier load, but that comes around with other problems since max compressed springs are often cause of excessive springiness and erratic behaviour. Then there's excessive springiness when approaching slight terrain angle change on low-g bodies so yeah. In short it's hard for me to build heavy mining rover for hauling cargo one way and coming back empty. It seems that you can design rover that works well according to its weight on a given body. But then change the g force or rover's weight and it's glitch-happy. But yah I guess those are limitations of physx mentioned by you earlier so just mentioning the stuff here for reference.

*snip*

This is actually very realistic, one of the limitations of setting up real life heavy duty vehicles with standard suspensions (standard metal springs) is that you can't optimize them for both loaded and unloaded states, when optimized for heavy loads then when unloaded the vehicle experiences a very harsh rough and jittery ride as the springs are far to stiff for the low weight. This is why most modern semi's utilize pneumatic springs (air bags) instead of standard metal springs because as the spring gets more compressed they get progressively stiffer allowing for reasonable ride and control when unloaded but still able to support a heavy load.

So basically the only solution to this would be Shadowmage implementing some progressive spring curves which sounds like a pain in the a** to code, or have the ability to adjust the spring stiffness while in flight.

Edited December 6, 2016 by Akira_R

[Shadowmage]

4 hours ago, riocrokite said:

One more thing, would it be possible to expose drag induced by weight value to it could be changed in the wheel cfg? Right now with a big weight it's pretty hard to get rover to move.

None is currently modeled, so adjusting it would not be a cure to whatever problem you are experiencing (there is zero rolling resistance or drive-train friction losses).  Could I see a screenshot of the rover with the wheel config menu open while it is experiencing this problem?
(If wheels are at max compression, you are riding on the bump-stop collider, which pretty much drags on the ground, in addition to loss of traction)
(Could also be that the wheel doesn't have enough torque for the chosen use; especially if it is tweakscaled, as the tweakscale support is... well, simply not finished, and is not going to give the correctly scaled stats for torque/wheel-mass, etc)

Edit:  This would also change depending on what body you are testing on.  On Kerbin max acceleration should be ~1g (9.8m/s) for a 4wd vehicle, with some margin for the tires friction coefficient (you might see 1.2g on really sticky tires) (more torque would not help, only make the tires spin out).  On Minmus your max acceleration will be -much- lower; pretty much linear with the gravity -- so max acceleration on minmus would be ~0.05g, or ~0.5m/s.  That is friction at work for you (output at the wheel depends on down-force on the suspension; lower gravity = lower downforce = less traction = lower acceleration).  Same on other lower-gravity worlds, you can expect lower maximum acceleration.

 

4 hours ago, riocrokite said:

I also noticed weird shaking of springs when coming out of a turn so the when a vehicle's body turns from angled to straight:

Were they actually hitting 100% compression in the turn?  If so, the bump-stop colliders were probably dragging against the surface;  I've set them to zero friction, but I also had to set them to zero bounce -- so anytime they impact, all energy from the impact is absorbed (having non-zero bounce results in... well.. lots of bouncing anytime bump-stop is hit).

Otherwise I would have to see the right-click menu throughout the turn in order to be able to diagnose the problem, as I've not seen anything like that in any of my testing -- properly setup suspension at max turn rate is always smooth and even (though the amount of understeer/oversteer varies with speed and throttle).  Could be any number of things, including the other tires going through break-loose-then-grip oscillations.

Was there a specific vehicle arrangement needed to trigger this?  (screenshots with wheel right-click menu open when going around the thrun would be beneficial)

 

4 hours ago, riocrokite said:

I simply couldn't get a stable setup for heavy duty wheels for variable weight rovers (i.e. refueler or dumper type). If I got them 'stable' under a given weight, vehicle became ticky and bouncy when empty and vice versa, tried different values from spring / damper and ride height to no effect.

Normally semi-trucks and other vehicles intended to support widely varying loads have their suspension setup to support the maximum of those loads.  When unloaded they ride near the top of their suspension travel, and have an extremely stiff and rough ride when not loaded down.  Some have variable suspension, or non-linear gas-based suspension, either of which can allow for a better range of load handling and improved unloaded ride quality.

The problem with this approach in-game is that the simulation breaks down with such large spring forces and such small compression distances; you end up with something that wants to bounce and jitter at the top of its suspension, but works fine when load is added.  One of those bits of 'simulation cannot match real world behaviour to extreme precision due to integration limitations'.  Really wish I didn't have to put out that excuse? reason?  but it exists, and there is -nothing- I can do about it (unless Unity opens up their PhysX integration code to modification; and even then it may need to come even lower-level at the PhsX end of things, which is all run from C++ compiled libraries).

^^^ This is probably why all wheels in stock use auto-spring tuning.  Every time the vessel mass changes, the suspension re-adjusts itself to maintain the same nominal travel range, and keep the suspension within the valid simulation range.  I still really hate the concept, but I suppose I can see why it was used (so that these kind of problems don't pop up all the time).  Will see what I can do about implementing something similar.  It really is the only way that these will work as a publicly available / generically usable asset, as general expectations do not line up very well with the simulation limitations...

Another problem regarding suspension use like this -- you would want to use wheels with a very large overall suspension travel (~1m), and set them to ride near the top of their suspension when unloaded.  Sadly most of the wheels in KSP have 0.25m of travel or less (terrible, I have scale RC cars with >10cm of suspension travel); for a use-case like you have posted above, you are going to want at least 0.5m of travel (none of the stock wheels come anywhere near that).  Notably the 'ruggedized' wheels are terrible (0.125m), as are the stock extra-large tank-steering wheels for their intended load range (0.25m, should be at least 0.5m, and closer to 1m); neither should be used with any real load on them, the models and designs are quite poor.  The stock dougnut wheel is not too bad for most uses (0.25m travel), and the stock micro wheel is very good for its intended load range (~0.2m travel)  (yes, the micro wheel has almost as much travel as the largest wheel;  if that doesn't point out a problem with the models, nothing will...). 

The longer the suspension travel, the more stable the simulation in general, and it can allow for a wider range of loads on a given wheel without changing its settings while maintaining a stable simulation.  This occurs because spring force is linear with spring compression;  if you can support load X at compression 0.2 (empty vehicle), you can support load X*2 at compression 0.4, and load X*4 at compression 0.8.

 

4 hours ago, riocrokite said:

Then there's excessive springiness when approaching slight terrain angle change on low-g bodies so yeah

I'm investigating potential workaround solutions to the 'stiff spring' syndrome.  It is another problem with the limits of integration.  Basically it sees compression X before hitting the slope, which gives spring force Xk.  After hitting the slope, the compression is then Y, which gives spring force Yk.  The problem comes when the difference in Xk and Yk is greater than that needed to bring the vehicle back to ride height  -- because of the length of each simulation 'tick', the vehicle is actually in an erroneous position that incorrectly compresses the springs more than it should have;  if the simulation frequency were increased/time-step reduced, the vehicle would have responded properly -as- the compression was occurring, rather than having to respond -after- all of the compression has already occurred (which is where the bounce comes from).

The same thing can cause the vehicle to bounce / jump when rolling over smaller obstacles at high velocities; basically the spring had to go from not-compressed, to very compressed, without any time inbetween to allow for intermediate forces (which would have started to lift the vehicle chassis over the obstacle, reducing compression on subsequent ticks, and avoiding the bouncing/launching forces).

I think about the only thing I can do here is to add a secondary type of damper, that only kicks in on compression, and actually works as a negative damper -- allow brief moments of vastly increased compression with only minor increases in suspension spring output force, and allowing the suspension force to catch up to the new compression state over X ticks (probably based on compression delta, max compression, and.. damper ratio?  idk...).  Another option is some sort of basic suspension-force-lerping; limiting the maximum increase in spring force between ticks to a fraction of its total potential force, and only increasing actual output force by up-to that amount (will also require some...careful handling... of the damper as well, as damp force is normally linear with compression velocity -- some of the problem could also be caused by the damper now that I think on it).

 

Anyhow, thanks for the additional testing and feedback.  I'll see what I can do to clean up some of the problems you are experiencing, I'm afraid many will not be truly solvable (as in proper, concrete, fully stable solution), but for some I may be able to implement acceptable workarounds and compromises.

 

Edit:  After re-reading part of your post, I'm pretty sure I know where most of your problems stem from:

4 hours ago, riocrokite said:

and 4 tr-2l wheels slapped on sides

^^ as pointed out in the post above; those wheels are absolutely terrible for any sort of 'dynamic' use due to their extremely limited suspension travel range.  With those wheels you are lucky if you can get them working at all (they were the wheel that gave me the most problems when trying to set them up for any sort of non-simplistic use, entirely due to their lack of suspension travel range).

 

Edited December 6, 2016 by Shadowmage

[Ryusho]

Question in part related to this, HAve you decided or gotten permission to basically include/add the KF wheels to whatever mod your making with this to work with it? considering the fact if you get permission, it wo uld help keep such nice wheels around, and also would mean we would only have the working ones, and not the 'broken' ones like the current 'test' configuration caused by downloading Kerbal Foundrie- ..Oh ..derp, I just saw you have it on your end-bit with the other mods you work with and/or develop X_X

[Shadowmage]

Just now, Ryusho said:

Question in part related to this, HAve you decided or gotten permission to basically include/add the KF wheels to whatever mod your making with this to work with it? considering the fact if you get permission, it wo uld help keep such nice wheels around, and also would mean we would only have the working ones, and not the 'broken' ones like the current 'test' configuration caused by downloading Kerbal Foundrie- ..Oh ..derp, I just saw you have it on your end-bit with the other mods you work with and/or develop X_X

Yes, I have gotten permission from Lo-fi to continue working on (or at least working with) KF in his absence.  I have not yet 'assumed control' as it were, as I'm waiting for the dust to settle a bit, and still working on making sure that the physics of the wheels aren't going to break down.  (Licensing on the plugin and assets are open source, so technically anyone could pick up future development as long as they followed the licensing requirements).

I'm also trying to decide if I have time to maintain KF as well as my existing mods (I really don't, but as nobody else is stepping up, I'll see what I can do).  My original intent of involvement in all of this was to make the wheel collider and to step down after the wheel collider was working, to let the existing teams take care of their own mods (as I already have my own mod(s) to work on, that already take up more time than I have available; adding more work to the queue will only make everything progress slower).

I'll likely open up a 'Kerbal Foundries -- continued' form thread in the next few weeks.  I'm also not sure that I will be able to get the existing KF plugin code working with the new wheel colliders in a timely manner (mostly due to being unfamiliar with the KF code), so have not yet decided what route to take as far as 'official' updates to the parts.  Seems likely that I'll work on cleaning up/finishing the existing KSPWheel PartModules.  They were originally not intended to be a long term solution, and had intended them to exist only until the KF plugin was fixed; sadly as the KF plugin will not be getting fixed, I have no other options but to maintain them in the long term.  The KF-configs included in KSPWheel are, obviously, intended merely for testing of the physics -- hence the duplication of parts.  If/when I pick up development on the mod in earnest, the duplicate parts and broken plugin will be fixed up properly.

At this point I pretty much have to ask -- is there anyone interested in working on the PartModules end of things?  Feature development, bugfixing, maintenance, updates, etc. 
The ideal candidate would be familiar with Unity and PhysX, competent with C# and the KSP-API, and have a good understanding of vehicle physics and dynamics as they relate to integrated simulations.  (I know, highly improbable; even I only meet the first two of those criteria)

 

[Araym]

19 hours ago, Akira_R said:

This is actually very realistic, one of the limitations of setting up real life heavy duty vehicles with standard suspensions (standard metal springs) is that you can't optimize them for both loaded and unloaded states, when optimized for heavy loads then when unloaded the vehicle experiences a very harsh rough and jittery ride as the springs are far to stiff for the low weight. This is why most modern semi's utilize pneumatic springs (air bags) instead of standard metal springs because as the spring gets more compressed they get progressively stiffer allowing for reasonable ride and control when unloaded but still able to support a heavy load.

So basically the only solution to this would be Shadowmage implementing some progressive spring curves which sounds like a pain in the a** to code, or have the ability to adjust the spring stiffness while in flight.

Basically, "heavy duty vehicles" HAVE adjustable springs "on the fly".

The most used one is the "compressed air filled suspension", where a spring is incapsulated in a "rubber casing" (maybe actually no more rubber ) and filled with compressed air to vary stiffness and height, to change the response .

Give to the end user the possibility to change "stiffness" and "running height" as loads vary could improve:

- heavy duty vehicles, that have a lot of weight differences from empty to loaded
- "All-terrain" vehicles, that could improve their behaviour on "smooth" terrain (a bit more stiffness, less height) to rough, bumpy one (less stiff, more height)
- rovers that need special settings on low and high G bodies (both for small planets/moons than Kerbin, but also for a rover ending its lfe in a planet like Eve)
- racing vehicles (!!!): someone colud like to build up racing cars, both for some "flat use only" (like F1/Indy/NASCAR/GT etc etc race vehicles) or for "dirty tracks" (some creations meant to travel fast like "rally car" on bumpy terrains)

[riocrokite]

@Shadowmage

thx for your lengthy response, I'll surely take it into consideration tweaking my custom wheels so they work properly (making sure there's enough spring range ;))

for now I'm lacking time so just a pic of the test vehicle I used mostly for the tests, I also used hyperedit to empty/refill fuel tanks on the go simulating heavier / lighter vehicle:

during tests I used locked camera mode and highlight the wheel so it's easier to observe behaviour of it:

initial values; I played with 3 top values pretty much through the whole range and then drove with empty and full tanks

 

edit:

1. " I also noticed weird shaking of springs when coming out of a turn so the when a vehicle's body turns from angled to straight: " this behaviour also exists when compression is less than 100% (i.e. 75%).

2. from what i test there's some sort of friction the scales with the mass on the wheel; example setup:

the large tank above is for testing purposes, I start with empty and then fill it gradually with fuel using hyperedit and check mass using KER, from about 44 tons vehicle can't move, with less than that vehicle stops abruptly when not pressing 'forward'. If it's possible to have access to this friction value and modify it in cfg (i.e. for larger wheels) it would be great:)

 

Once again thank you for your dedication working on this

Edited December 7, 2016 by riocrokite

[Shadowmage]

1 hour ago, riocrokite said:

@Shadowmage

thx for your lengthy response, I'll surely take it into consideration tweaking my custom wheels so they work properly (making sure there's enough spring range ;))

for now I'm lacking time so just a pic of the test vehicle I used mostly for the tests, I also used hyperedit to empty/refill fuel tanks on the go simulating heavier / lighter vehicle:

 

edit:

1. " I also noticed weird shaking of springs when coming out of a turn so the when a vehicle's body turns from angled to straight: " this behaviour also exists when compression is less than 100% (i.e. 75%).

2. from what i test there's some sort of friction the scales with the mass on the wheel; example setup:

 

the large tank above is for testing purposes, I start with empty and then fill it gradually with fuel using hyperedit and check mass using KER, from about 44 tons vehicle can't move, with less than that vehicle stops abruptly when not pressing 'forward'. If it's possible to have access to this friction value and modify it in cfg (i.e. for larger wheels) it would be great:)

 

Once again thank you for your dedication working on this

1.) Interesting; I cannot say that I've observed this behaviour in any of the testing I've done.  Could you upload the craft file you are using, with the wheels setup the same as are causing problems for you?  (along with instructions on how to make the problem manifest if it takes more than 'accelerate, then turn, then go straight, then watch twitching/shaking')  I'll also see about duplicating it from the pics above, but small differences in construction and placement could give different results.

2.) Nope, there is -zero- rolling friction currently in play in the current testing releases ( https://github.com/shadowmage45/KSPWheel/blob/master/VSProject/KSPWheel/Component/KSPWheelCollider.cs#L800-L890 ).  If your brakes are not on, and you are traveling in a straight line, then the only thing that should slow you down is gravity when going up hills and stock aero drag (and a very tiny bit of slowdown due to floating-point inaccuracies).  Could I get a copy of the craft that is experiencing this problem, in its problematic setup?  (Alternatively, can you show the right-click menu of the wheel when it is experiencing this problem?) 

It is highly probable that the suspension is overloaded, and the bump-stop colliders are dragging on the ground -- this would cause exactly what you are seeing, and is the only time I have seen such phenomena during testing -- if a wheel is overloaded, they will pretty much not want to move as you are fighting full kinetic friction for dragging a collider; the more overloaded it is, the less it will want to move. 

If you are putting 44t on those wheels, I can guarantee that they are overloaded unless you've tweaked config settings.  Their max load rating is set to 3t in the config.  4 of those wheels would get you to 12t.  Max out the suspension ride height (0.2), and you can get the spring up high enough to maybe support 36t total (at or very near max compression, already less-than-ideal).  Anything beyond that, and you have waaaaay overloaded those wheels (technically they are overloaded with anything past 12t on 4 wheels).  (I'm not going to say that the 3t max currently specified in the config is correct.. because, well, it was a guessed at value; nobody has provided information on what the min/max loads for wheels should be, and the stock configs do not use any such mechanics so I cannot derive the intended values from their configs)

The craft below is using those same wheels.  Trailer contains a full orange tank (36t of fuel) + weight of the trailer cargo bay; I think the whole craft came in at ~45t or so.  It is using 10 of those wheels, and still can barely support the load without overloading the wheels (I actually had to max the load rating and ride height, and then turn down the damper to maintain proper damping ratio, and the four wheels at the rear of the tractor are just barely in the usable range).

I think I'm going to add a screen message to the wheels whenever they are past ~90% compression for more than X seconds it will start posting to the screen messages like 'Wheels are overloaded!!!'.  Or perhaps I should go the stock route and make them explode if overloaded for too long (perhaps after a warning period)?  Not entirely unrealistic either; if I were to put 40t onto my car tires with its current suspension, I would expect the tires to explode, probably the strut as well, and would likely bend or deform most of the rigid suspension components; for all intents and purposes, it would be broken and unusable.

 

Hopefully I can help you track down what is going on in these cases; if you can provide craft files for those two setups it would be beneficial.  I'm fairly certain I know what is going on with #2; but for #1 (the turning problem) I would love to take a look at what is going on.

 

 

In general development:

Added in a 'rolling resistance' term to the wheel collider physics integration.  Is intended to represent the rolling resistance coefficient of  a wheel.  The coefficient is multiplied by current spring force (to derive a force in newtons), converted to a torque, and applied to the wheel as a change in angular velocity, capped to the current angular velocity of the wheel (so it won't cause you to roll backward, but it can and bring you to a full stop).  It resists motor input forces, so any input force below a threshold will be negated before it can accelerate the wheel or move the vehicle.  Input forces above that threshold will be reduced by that amount, and the resultant remainder force applied to the wheel (its actually simpler than that; the motor acts on the wheel first, and then rolling resistance is calculated, potentially bringing the wheel back to a stop).

Also added in a 'rotational resistance' term to the wheel collider.  It is intended to represent friction from bearings, gearing, magnetic drag on motors; all of the speed dependent resistance sources.  The config coefficient is multiplied by current wheel angular velocity to derive a force in newtons, converted to a torque, and applied to the wheel as a change in angular velocity; capped at the current angular velocity so that it cannot apply sign changes.  As it is a multiplier to angular velocity it can never bring you to full stop (0 input = 0 output), but has a linear relationship with wheel rpm.  (May need to adjust this a bit to ensure that the 'resistance' for cannot outweigh the momentum force; seems I may have to add in spring-force as an additional input term, or more properly probably use wheel momentum (a force/potential) rather than rpm).

Lastly I added in a form of non-linear spring; using a function of k = xy + axy^2 (where x = spring rating, y= compression, a= configurable curve parameter, output of k = calculated spring force for compression y).  While it does work as intended (giving a non-linear spring response), it greatly complicates the calculation of a proper spring force for a specific ride height at a given load rating -- will need to come up with a new method to calculate the 'auto-tune' suspension settings.  Haven't yet done any in-KSP testing on it to see if it helps with the 'mining rig' problem, but from the response I was seeing in the Unity editor it should be a decent solution when configured properly for the load and use.

Of course this will require adding additional user-configurable settings for suspension type (linear, curve) and for the curve grade (the 'a' in the formula above).

 

[damerell]

On 06/12/2016 at 6:54 AM, Shadowmage said:

I suppose this is probably a difference in terminology.  I use rolling resistance as a general term to include friction losses caused by bearings, gearing and axles (all speed dependent, some also load dependent) and losses from tire deformation (which I thought was also speed and load dependent).  However I believe the latter (tire deformation) is the proper/technical definition of rolling resistance, and the former (bearing friction) is more often called drivetrain loss or drivetrain efficiency.

A difficulty here is that most of the information about drivetrain losses pertains to motor cars, where it's typically expressed as a percentage of input power lost. (That would imply it's a force that does not vary with speed but, like rolling resistance, does more work at higher speeds). This is a perfectly sensible way to look at it in that context, where when the power is shut off most of the drivetrain isn't doing anything. In my proposed model the term proportional to the mass of the part added to the rolling resistance term is intended to cover these losses.

Unfortunately that doesn't tell us much about tracked vehicles. However, as far as I can tell (see for example http://www.comw.org/pda/0007wheels.html section 2.1.2 (which is discussing total losses, I believe, given the discussion of fuel consumption)) it remains the case that most of these losses vary primarily linearly with vehicle weight and not with speed.

ETA: Incidentally, it's also because of that document that I assess relatively similar rolling resistance penalties for wheels and tracks - while on-road wheels have an enormous advantage, it seems that off-road the two are remarkably similar, perhaps because tracks are much less prone to slipping.

Edited December 8, 2016 by damerell

[Shadowmage]

10 hours ago, riocrokite said:

[...snip...]

Doing a bit of testing on the 'vehicle won't move' problem that you posted.

As close to the same configuration as was in your screenshot that I could put together, here is what the wheel right-click menu shows with a 45t craft:

The 'Compression' field is at 0.999  -- meaning it is riding on the bump-stop colliders and the wheels are very overloaded, and that is with the 'load rating' maxed out at 3t per wheel.  It does perform about like you had described -- very limited traction, very draggy, comes to a stop soon after motor input is stopped.  That is the expected behavior for the current simulation model; not entirely realistic, but the best compromise that I could come up with (the other option is to not have a collider; but then the wheels clip through the ground when overloaded and become even more useless).

I can get it moving decently if I change the 'ride height' to 0.2 with the load rating at 3t and leaving damper at 0.65; I then get about 65% on the compression bar, and it rolls smoothly as expected, responds properly to motor input, and coasts as it should.

On the other problem -- smoothness of returning to level after turning -- I am unable to reproduce any problems with testing using the craft from the screenshot above (minus the extra fuel tank of course), even when using the same settings as in your screenshot (ride height = 0.25, damper = 0.65, load rating = 1.5).

There is a slight over-correction rocking during the leveling-off (rolls a bit the opposite way from momentum), but that is due to the damper ratio being at less-than-critical damping, and is functioning as expected for those settings.  If this is different than what you are experiencing, could you provide the craft file that is producing those problems so that I can do testing with the settings that you have on the wheels?

[Akira_R]

Hey @Shadowmage so I was playing with this and a very much still in-development not intended for public consumption version of FAR that works for 1.2.1 and I just wanted to let you know that currently FAR falls flat on it's face when one of these wheels is used, otherwise everything is fine.

I don't expect any kind of support obviously as like I said, not at all an official FAR release, I just wanted to bring it to your attention as a possible issue in the future and see if you are interested in looking at any of the logs.

[Shadowmage]

7 minutes ago, Akira_R said:

Hey @Shadowmage so I was playing with this and a very much still in-development not intended for public consumption version of FAR that works for 1.2.1 and I just wanted to let you know that currently FAR falls flat on it's face when one of these wheels is used, otherwise everything is fine.

I don't expect any kind of support obviously as like I said, not at all an official FAR release, I just wanted to bring it to your attention as a possible issue in the future and see if you are interested in looking at any of the logs.

Sure, post them up on Github issues page --  https://github.com/shadowmage45/KSPWheel/issues
It should let you upload directly, no need for dropbox/etc.

I'll take a look at it when I'm doing the FAR testing pass with SSTU, which might not be too far off. 

[riocrokite]

16 hours ago, Shadowmage said:

Doing a bit of testing on the 'vehicle won't move' problem that you posted.

[stuff]

Sorry I'm unable to help you further, I'm quite busy nowadays with house renovation etc. You're right about that big weight and oscillation when coming out of a turn. I couldn't reproduce the erratic shaking I've got before. The closest I got was with the empty tanks (light vehicle), low loading ratio and high damp values. But it wasn't exactly what I achieved earlier on so yah, probably not worth pursuing an edge scenario. If it was possible to retain auto-tune feature it would be of a great help for ride smoothness for variable weight rovers. And then I'm really spoiled by unrealistically durable and smooth wheels from unity 4/ksp 1.0.5 with which I was configuring wheels able to support probably close to 25-40t @ 1g on the wheel without problems (100-200t on the mun):

In other words having durable wheels (big ones) that support heavy load was my main interest because of 'mobile multi-vehicle mining bases' theme and reducing number of wheels for optimization purposes. Personal note; I'll probably get back to ksp around Feb-March and try to rig my wheels with your mod:) Keep up good work man!

[riocrokite]

one more thing, if this is any consolation - game devs using unreal engine 4 are stuck with the same physx wheel physics

example threads:

https://forums.unrealengine.com/showthread.php?115680-Vehicles-in-UE4-a-constructive-debate/page2

https://forums.unrealengine.com/showthread.php?48843-Horrible-Car-Physics/page9

in short people were complaining to epic and epic promised to pass that to nvidia... there's a slight hope although not soon

[Shadowmage]

43 minutes ago, riocrokite said:

Sorry I'm unable to help you further, I'm quite busy nowadays with house renovation etc. You're right about that big weight and oscillation when coming out of a turn. I couldn't reproduce the erratic shaking I've got before. The closest I got was with the empty tanks (light vehicle), low loading ratio and high damp values. But it wasn't exactly what I achieved earlier on so yah, probably not worth pursuing an edge scenario. If it was possible to retain auto-tune feature it would be of a great help for ride smoothness for variable weight rovers. And then I'm really spoiled by unrealistically durable and smooth wheels from unity 4/ksp 1.0.5 with which I was configuring wheels able to support probably close to 25-40t @ 1g on the wheel without problems (100-200t on the mun):

In other words having durable wheels (big ones) that support heavy load was my main interest because of 'mobile multi-vehicle mining bases' theme and reducing number of wheels for optimization purposes. Personal note; I'll probably get back to ksp around Feb-March and try to rig my wheels with your mod:) Keep up good work man!

No worries, I fully understand time constraints (both RL and modding...); the feedback you've given has already helped me fix up a couple things, and given me some ideas on what to look for as far as future developments on user-interface and dynamic functionality.  Your time and effort is much appreciated, thanks

Hopefully by the time you get around to integrating these into your mods I'll have most of the quirks resolved and a more fleshed out feature set.

As far as having wheels that support large loads -- not a problem by itself; simply adjust the config in the wheel to up the 'max load' to what you think is appropriate (and then set the wheel to the proper load in the VAB prior to launch).  The problems start to creep in when you want the ability to support both a 100t load and a 10t load on the same vehicle, without changing suspension settings (or any other large min/max ratio).  But anyhow, I may have some solutions to that as well, see below...

As far as wheel loading and auto-tuning go, I think I'm going to take a split-approach to this, based on some config settings in the parts (or a global game-level config setting; undecided).  There will be two basic modes available.

1.) The first is mostly as is currently seen where the wheels have a hard limit for min and max load, and the user must configure them properly (the engineering approach).  This allows for the user to configure the suspension for very specific scenarios, but the wheels must be configured on a per-vehicle/craft/use basis.  A basic auto-tune would be available, but would still be limited by config-defined min/max load ratings.  Think of this as the 'Realism-Overhaul' mode for the wheels.  Wheels that are overloaded for longer than a specific duration divided by overload factor will explode (or at least break) (how far overloaded will determine how quick they pop; so that hitting the bump-stop when landing from a jump shouldn't explode the wheels due to the momentary contact, but multi-second bottoming out of the suspension will cause damage).  In-flight adjustment may or may not be available, likely depending on a per-part config setting.

2.)  The second mode will be much more user friendly, but far less adjustable.  Think along the lines of the stock controls; there will be a 'damper' slider with very limited range, and a 'spring adjustment' slider with very limited range, neither adjusting in discrete units, but will be used as a term in the dynamic calculations.  Actual spring rate will vary dynamically with vehicle loading with a minor adjustment based on the 'spring' UI setting.  Resultant spring force and damper ratio will be mostly out of the users control; they will only be able to adjust it a very small bit either way to ensure that the simulation stays within the valid stable range.  There may be a config set maximum load before 'wheel stress explosions' are applied, but I might also just leave it uncapped.  If its going to be gamey, might as well let it truly be gamey.

 

 

8 minutes ago, riocrokite said:

one more thing, if this is any consolation - game devs using unreal engine 4 are stuck with the same physx wheel physics

example threads:

https://forums.unrealengine.com/showthread.php?115680-Vehicles-in-UE4-a-constructive-debate/page2

https://forums.unrealengine.com/showthread.php?48843-Horrible-Car-Physics/page9

in short people were complaining to epic and epic promised to pass that to nvidia... there's a slight hope although not soon

Indeed; the problems we are experiencing on the wheels is not the fault of SQUAD, nor solely at the fault of Unity.  Although, I do blame Unity for ever releasing their engine with the wheels in their current state; they could have very easily shipped with a custom modified PhysX build that had improved/fixed/not-terrible wheel code, or otherwise implemented custom low-level solutions that Unity end-users cannot create (no matter how much I want to, I cannot hook into the low level PhysX code or physics integration data; but Unity's native code can and does so already)

Sad that such a major physics library (PhysX) can have such terrible implementation that practically nobody uses it (or even can use it).
 

[Rushligh]

On 12/7/2016 at 5:19 AM, Araym said:

Basically, "heavy duty vehicles" HAVE adjustable springs "on the fly".

The most used one is the "compressed air filled suspension", where a spring is incapsulated in a "rubber casing" (maybe actually no more rubber ) and filled with compressed air to vary stiffness and height, to change the response .

Give to the end user the possibility to change "stiffness" and "running height" as loads vary could improve:

- heavy duty vehicles, that have a lot of weight differences from empty to loaded
- "All-terrain" vehicles, that could improve their behaviour on "smooth" terrain (a bit more stiffness, less height) to rough, bumpy one (less stiff, more height)
- rovers that need special settings on low and high G bodies (both for small planets/moons than Kerbin, but also for a rover ending its lfe in a planet like Eve)
- racing vehicles (!!!): someone colud like to build up racing cars, both for some "flat use only" (like F1/Indy/NASCAR/GT etc etc race vehicles) or for "dirty tracks" (some creations meant to travel fast like "rally car" on bumpy terrains)

More advanced all terrain and military vehicles now utilize magnetic suspension that can be altered with the vehicles on-board computer.

[qromodynmc]

Hey @Shadowmage, i wanted to ask something; does kerbal foundries cfg files still work when your patch applied? Turn speed is absymal when using neutral steering, i tried adjusting everything and when i get somewhat useful turn, this time friction goes way too low. Should i start messing with KF configs or im missing something?

[Shadowmage]

7 hours ago, qromodynmc said:

Hey @Shadowmage, i wanted to ask something; does kerbal foundries cfg files still work when your patch applied? Turn speed is absymal when using neutral steering, i tried adjusting everything and when i get somewhat useful turn, this time friction goes way too low. Should i start messing with KF configs or im missing something?

They seem to work fine for me?

Pics of the craft with the wheel right-click menu open?  And what kind of turn rate are you expecting?

Mostly the tracks (and large stock wheels) have turn rate that is very dependent on the geometry and positioning of the wheels.  Wide and short craft turn much better than long and skinny craft.  This all comes back to the fact that the existing part modules (and configs) were not intended for long-term use, but were written specifically for testing of the wheel collider physics.  Many things are not handled, or using overly simplified abstractions or quick hacks.  My original intention was to do testing to make sure the wheel colliders worked, and then let other mods' take care of writing the part-modules and their functions, at which point the existing modules and patches would have been removed.

TL:DR  -- all of the existing KSP relevant code was supposed to be temporary, and only intended to test the wheel collider physics.

 

I'll be changing the focus of development soon.  I have not the time, nor desire, to write or support an entire vehicle system.  I had opened this thread up to give a discussion area for testing of the collider while Lo-fi was away on vacation.  But Lo-fi has returned and stepped down, nobody else has come forward who is interested in writing PartModules or helping in any fashion, and I simply don't have the time or desire to do it all.  I tried to develop a generically usable set of PartModules, but it is apparent that I have a different definition of how much setup should be required than most, and different expectations of what should be done automatically.

A big thanks out to everyone was was involved with testing.  Your contributions have helped fix up several bugs with the wheel colliders, and will help make any other mods that make use of it that much better.

If someone else would like to step up to work on the KSP-plugin and PartModules end of things, they are more than welcome to, and I will offer them all of the assistance that I can in regards to the wheel collider component integration.  If interested please get in contact with me through PM to make arrangements for repository access, etc.

The wheel-collider source itself will be moving to an open source license soon.  Anyone who wishes to include it in their mods will be free to do so, including forking, modifying, etc. 

The existing PartModules and configs (both stock and KF) will still be available through the github repository, but will not be included in any future releases.  They will be intended as examples for others and for enabling of testing, but will not be supported beyond that capacity.

 

 

Edit: Rephrased; won't be closing the mod or thread, but will be moving away from PartModule and patch development for the time being.

Edited December 10, 2016 by Shadowmage

[0111narwhalz]

I would like to note that you and lo-fi have brought back the hovertanks and land cruisers in full force. My latest hovertank iteration is the best behaved I've ever built (though a bit lightweight), and my land cruiser drifts to just the right extent to be both gloriously entertaining and useful.

On that note: Multitracked vehicles of the following prototype:

0==0
  ||||
0==0

where every "0" is a track, have abysmal turning speed using out-of-the-box settings. However, if you turn the lateral friction to almost nothing, and the longitudinal friction to max, you can drive at speed and drift like a champ. The disadvantages of tracks do make themselves known at speed, of course; the steering is almost nonexistent on the Mole tracks above 6^m/_s or so. This is expected.

Additionally, how the hell are you supposed to control halftracks when in reverse? At low speeds, the tank steering is dominant. But as that fades out, the wheels take over and steer the opposite direction. Problem is, for a (sometimes wide) interval, the two cancel out and you have absolutely no steering control. Any ideas as to how one might mitigate this? Maybe a special vesselwide flag that tells wheels to invert their steering while rvel to hit is "negative?" That seems like it would cause as many problems as it solves.

Oh, back to the repulsors. Aside from their intended usecase, they are basically shocks, right? I made a dart gun with them, and I'm planning to utilize them in my hideous-abomination-of-joints I call a suspension testbed. The fact that they act on their own craft opens up so many possibilities. Previous iterations of the suspension demon tend to vibrate the rockers, destroying the tires. If I can damp the rockers, I should be able to prevent the vibration.

One last thing: I think you omitted the steering trait on the skids. They slide around, as they should, but I seem to remember them steering. My gunsled* uses battery weakjoints and reaction wheels to achieve control at the moment, and it likes to dive the batteries into the ground when it fires. I'm not adverse to cfg hacking; I just have no idea what to do with the modules.

[Jovzin]

Thank you @Shadowmage for this mod / plugin.  I can finally finish my mod.  Thanks a lot

[Shadowmage]

On Saturday, December 10, 2016 at 8:26 PM, 0111narwhalz said:

However, if you turn the lateral friction to almost nothing, and the longitudinal friction to max, you can drive at speed and drift like a champ.

This comes back to the PartModules currently being a collection of approximations and quick hacks to enable testing.

If I were to fully implement the PartModules, the tracks would use different friction settings for each sub-wheel in the track; the ones in the middle would have full lateral friction, while those towards the front/rear would have reduced lateral friction.  This would enable much faster turn rates as the front/rear-most wheels would not be resisting the turning as much.  Ideally they would only have reduced friction when the turning is actually occuring;  I seem to remember some of the tracked vehicles actually do this during turns, lifting the front/rear road wheels slightly to reduce friction during a turn and not tear up the road so bad (could be mistaken, been a long time since I've researched it).

 

On Saturday, December 10, 2016 at 8:26 PM, 0111narwhalz said:

Additionally, how the hell are you supposed to control halftracks when in reverse?

Good question.  Again this goes back to the partmodules being intended for testing of physics, and not intended for long-term use.  Ideally the tracks would have a user-configurable setting to reverse tank-steering direction when used in combination with traditional wheels.

 

On Saturday, December 10, 2016 at 8:26 PM, 0111narwhalz said:

Oh, back to the repulsors. Aside from their intended usecase, they are basically shocks, right?

Yep, repulsors are simply wheels with extremely long travel range, no visible wheel mesh, and all friction disabled.  They use the same suspension calculation methods as every other wheel.

 

On Saturday, December 10, 2016 at 8:26 PM, 0111narwhalz said:

The fact that they act on their own craft opens up so many possibilities.

This is actually a bit of a bug, but one with no clear/easy solution.  Ideally the wheels would not exert any forces on parts from the same vessel, but due to the dynamic nature of KSP craft this would require an additional layer of collider management (ignoredColliders) that would need to be handled at the WheelCollider level.

Thankfully the wheels do the proper 'equal and opposite forces' bit of physics, so even when they are acting on parts of the same vessel, they shouldn't (in theory) be imparting any actual movement to the vessel.  I say in theory, because Unity joints suck, and are likely bending/flexing/doing harmonic stuff, causing there to be some net force gain.  Honestly, I've never tested it....

 

On Saturday, December 10, 2016 at 8:26 PM, 0111narwhalz said:

One last thing: I think you omitted the steering trait on the skids.

I didn't see anything regarding steering in the existing KF configs.  Will take a look though.  Sadly it might not be possible with the current model rigging; all depends on how the colliders/etc are parented in the model.  Might still be able to 'hack' it by allowing one of the wheel colliders to fake steering input; would have no visible steering component to it, but should effect some level of input.

 

Either way... development of the PartModules and configs has moved to the back-burner until/unless someone else comes forward with the motivation and knowledge necessary to work on them.  I may get back to them personally at some time in the future, but could not say when, or even if, that would happen.

 

 

 

[damerell]

You mentioned that you intended to relicence this under a Free licence. Is that still on the agenda, please?