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

[damerell]

One addendum. Maximum braking torque should probably need to be around the maximum drive torque at double gear reduction (the 22kN for the worked example above) but will need to be tweakable freely in flight - because KSP's brakes are either full-on or full-off.

[Azimech]

8 hours ago, Shadowmage said:

INot quite sure what you are referring to with adjustable bump?  (As in bump-stop?  Not much that can be done to tune it; it uses a collider to ensure overcompression does not occur)

Guessing that damper rebound is referring to using a different damper rate for compression vs. decompression... which I've been thinking myself is a bit of a needed thing.  Could benefit the handling for many off road type setups, especially at higher speeds when traversing smaller rough details.

(Disclaimer: I am not a vehicle physics expert, merely a programmer with a decent grasp of maths; many of the specific terms are unfamiliar to me by name, but I can probably tell you how they function...)

 

You're right, that's exactly what I'm pointing at. Bump is the damping ratio while the strut is being compressed, rebound the ratio of return. The advantage of a stiffer rebound is it prevents a wheel from losing contact with the surface. The problem with the current KSP dampers is that a high damper setting puts too much strain on the part, in other words it's easy to break the wheels. In real life you get an uncomfortable ride and everything wears down quicker, especially bearings and joints. Oh and yes, easier to damage your tire as well.

While we're at it, there's something else missing in the stock game: anti-roll bars. If I were a programmer I would use a method of clicking two parts to create a symbolic link. Anti-roll bars are very important. If for example you have a four wheel drive vehicle with the CoM in the center, same tires front & back, same spring rate and damper settings etc, you can actually control the vehicle behaviour when driving at its limits: if you want understeer you'll choose a stiffer anti-roll bar on the front than the rear. If you want oversteer, the opposite. The reason is that while the primary function of an anti-roll bar is to prevent rolling of the vehicle in corners thereby reducing a shift in CoM and preventing a change in camber,  the anti-roll bar also pulls a wheel up because it's connected to the wheel on the other side of the axle. Now if the other bar is less stiff, it won't pull as hard and because both bars are connected to the chassis or monocoque, it will create a difference: less road contact for the wheel with the stiffer bar -> less grip.

Oh and they also help when you have two big guys sitting on one side of the car. Without anti-roll bars, the car would list to one side all the time. And I've already seen it with some overweight kerbals sitting in my cars.

One more thing ... Mentioned this before to Squad but no reply. Isn't it odd those heavy & powerful electric motors don't generate any heat at all?

That's it, I'm done, have a picture.

 

18 minutes ago, damerell said:

One addendum. Maximum braking torque should probably need to be around the maximum drive torque at double gear reduction (the 22kN for the worked example above) but will need to be tweakable freely in flight - because KSP's brakes are either full-on or full-off.

Not exactly, I've noticed the brakes are progressive ... it just involves learning the right way of using PWM. The fact the brakes have a delay doesn't help though.

Edited December 3, 2016 by Azimech

[damerell]

I think it would be best to try, as far as possible, free the player from the need to play a little tattoo on the brake button. :-)

Addendum the second; this is all a bit more complicated when it comes to treads, and I'm not sure I know enough about the current internal model. Assuming they are still so-many actually independent wheels in line and the tread is purely cosmetic, I think the thing to do is perform the calculations as above then divide the total torque between the wheels. Force their speeds to be identical then dynamically change the division of torque to remove it from wheels which are trying to go faster than average and add it to slower ones. I don't know how feasible that is and it's definitely pretty vague.

[Azimech]

9 minutes ago, damerell said:

I think it would be best to try, as far as possible, free the player from the need to play a little tattoo on the brake button. :-)

Addendum the second; this is all a bit more complicated when it comes to treads, and I'm not sure I know enough about the current internal model. Assuming they are still so-many actually independent wheels in line and the tread is purely cosmetic, I think the thing to do is perform the calculations as above then divide the total torque between the wheels. Force their speeds to be identical then dynamically change the division of torque to remove it from wheels which are trying to go faster than average and add it to slower ones. I don't know how feasible that is and it's definitely pretty vague.

Sounds you're talking about ESC or ESP. Also ... very complex :-)
It would need to know the fact you're steering, because the inner wheels turn slower than the outer wheels, but it also needs the speed data from the wheels before cornering starts and know the steering angle, power requested by the user, use an accelerometer to measure the difference between initial acceleration and current (in any direction), compare the values in a pre-defined lookup table ... ugh.

Edited December 3, 2016 by Azimech

[colmo]

Everything a train mod needs:

- More advanced wheel colliders (this mod)

- Appropriate rail statics and a working Kerbal Konstructs (AlphaAsh talked about using statics joined by nodes and drawn by splines, @Ger_space fyi)

- A means of controlling ground vehicles without physics, like Bon Voyage.

We now have all mod raw ingredients for a Kerbal Rail System...

Edited December 3, 2016 by colmo

[damerell]

12 hours ago, Azimech said:

Sounds you're talking about ESC or ESP. Also ... very complex :-)
It would need to know the fact you're steering, because the inner wheels turn slower than the outer wheels, but it also needs the speed data from the wheels before cornering starts and know the steering angle, power requested by the user, use an accelerometer to measure the difference between initial acceleration and current (in any direction), compare the values in a pre-defined lookup table ... ugh.

I think you have misunderstood. There are no "inner wheels" and "outer wheels" on a track; I'm talking about the line-astern wheels on one track unit, which all turn at the same speed.

Addendum (again): One advantage (I hope) of the approach I outline is that the part data file need only specify the wheel diameter, power output (or perhaps power/mass ratio), and nominal maximum speed, unless it is desired to override some of the computed values like maximum efficient motor RPM or default gear ratio. Everything else can be computed. The advantage is that the potential for error - putting some value in the data file that's off by an order of magnitude, or something - should be reduced.

Edited December 3, 2016 by damerell

[DirkLarien]

To be honest.

At this point i would be willing to pay for mod like Adjustable landing gear.

I think it is one of the mods i am unwilling to play the game without.

Ok ok i am addicted i know.....but i dont care :-) i need my fix XD

Edited December 3, 2016 by DirkLarien

[Shadowmage]

Updated testing release is available:

https://github.com/shadowmage45/KSPWheel/releases/tag/0.9.0.3

Lots of fixes, improvements, enhancements.  Adds much better friction combination code, and adds an 'auto-tune suspension' function to help setup suspension properly (set the load share for the wheel, press the auto-tune button, done).  Also a few config tweaks, but nothing too substantial (sorry, no steering curves yet).  Adds deploy/retract sounds to stock legs and gear.  Full details and more info is in the change log.

Development will be continuing for the next few weeks, focusing on bugfixing, cleanup, and polish.  Still a few more physics problems and edge-cases that need to be sorted out, and certainly the amount of auto-configuration for basic suspension parameters could be improved on the PartModule end of things.

[gomker]

@Shadowmage Great work - I wanted to ask, I was testing the tracks a bit and noticed that they all seem to be working somewhat , but lacking any power to move anything with speed. Before I went through a full report, are tracks still a WIP? 

[mechanicH]

@gomker are you using the tracks that say KSPWheals in front of the title. There should be a set of 2 of the track. Use the ones titled KSPWheals. 

[Shadowmage]

14 hours ago, gomker said:

@Shadowmage Great work - I wanted to ask, I was testing the tracks a bit and noticed that they all seem to be working somewhat , but lacking any power to move anything with speed. Before I went through a full report, are tracks still a WIP? 

Could you show a screenshot of the vessel with the tracks right-click menus open?  A few different things could cause lack of traction, most of them wheel/craft setup related.

Could also be the torque outputs are not setup completely, and if tweakscale is in use, it could also be an incorrect torque-scaling multiplier.

 

[gomker]

1 hour ago, Shadowmage said:

Could also be the torque outputs are not setup completely, and if tweakscale is in use, it could also be an incorrect torque-scaling multiplier.

My first instinct is a tweakscale issue, all tests using the KF Track Long with Auto-tune suspend on. When at a 100% Scaling I can get the craft to move, a bit slow to start but will get moving on runway.

 

At 200% size on the track - heavier vehicle 24 tons - 12 tons of that is just the tracks

It moves very slowly like stuck in mud.

I will note with either vehicle turning is almost impossible, the tank steering is not doing much at all.

[gomker]

Update: I went the opposite direction, shrunk something to fit, using KF Track RBIMole. This was able to move the tank and climb after a few tweaks of the lat/long slip.

It would appear TweakScale is the root cause to me.

[qromodynmc]

I installed this today and i must say THANK YOU!..  There are some issues but so far so good it feels amazing to see this mod working again.

Here is an example tank i built;

at first tracks felt very underpowered and i had to edit config a bit, other than that it works perfectly, just needs proper adjustments.

[gomker]

7 minutes ago, qromodynmc said:

i had to edit config a bit

Can you share what you changed?

[qromodynmc]

3 minutes ago, gomker said:

Can you share what you changed?

     From this;

        name = KSPWheelMotor
        wheelIndex = 1
        maxMotorTorque = 0.10
        resourceAmount = 0.25
        throttleResponse = 2
        tankSteering = true
        maxRPM = 600

to this;

  name = KSPWheelMotor
        wheelIndex = 1
        maxMotorTorque = 1.0
        resourceAmount = 0.25
        throttleResponse = 2
        tankSteering = true
        maxRPM = 2000

Lines are from KSPWheel patches folder, KF-tracklong.cfg.

[Shadowmage]

@damerell  Thanks for the detailed write-up, excellent work on including the maths and details.  Apologies for not replying sooner, been trying to juggle too many projects, leaving not much time for writing posts.

I'm not sure I want to get as technical as specific gear ratios and changing of gear ratios.  I'm not trying to make a full vehicle simulator, merely trying to make wheel colliders that work with >1 collider in a part and don't have orientation restrictions.  I'm also not aiming for a highly-technical or accurate balancing for the part patches, but more of a gameplay-oriented balance for them.

With that said, I do like some of the ideas and data that you have presented, and will give some further thought to if/how they could be used.  Gearing isn't completely off the table, but I would have to rework how motors are handled in order to be able to make use of such a setup (and add provisions for the user to be able to change gearing while in flight = more keybinds...).  If I were to allow for changing of gearing, I would probably also want to include provisions for changing out the motor itself, which would be even more code-side work, more configs to manage, and more user-end setup that would need to be done.  Might play around with these concepts a bit, but no guarantees that it'll be done anytime soon.

Rolling resistance -- already on the TODO list, likely to be supported at the wheel-collider level.  I intend to setup a basic linear rpm-based rolling resistance friction value; probably using a spring-force multiplier as a secondary term to adjust rolling resistance as load changes, with both values being configurable.  RR would be applied to the wheel alongside brake and motor torques.  Nothing too complex.

Anyhow, I've copied your post out to the github repo so the information doesn't get lost; it is written well enough that I feel I should keep it around for future reference for if/when I start working on those features  

@Azimech

Roll/anti-sway bars -- Requires that there be some sort of 'vehicle' level controller to adjust forces/settings across multiple parts, or some other cross-part linking.  Would love to be able to have both roll-bars and some sort of differential / axle setup across parts, but will take some thought on the UI and VesselModule/cross-part setup end of things.

Motor-heat output -- seems logical, and probably not too hard to add in.  If I rework the motor data a bit, using the motor input KW and efficiency data it should be not too hard to figure out how much heat is being generated.  As a bonus, could add heat output for brakes, rolling resistance, and possibly slip forces (though all of those are probably minor in comparison to the motor).  Might be an interesting mechanic to have to deal with managing motor heat

Damper differential -- investigating methods to be able to include this feature, and its implications for performance and handling.  May see it included eventually (alongside non-linear springs), but will likely take me a bit to figure it out.

 

 

 

1 hour ago, gomker said:

Update: I went the opposite direction, shrunk something to fit, using KF Track RBIMole. This was able to move the tank and climb after a few tweaks of the lat/long slip.

It would appear TweakScale is the root cause to me.

Yeah, I need to take a look on how torque and wheel mass scale with different tweakscale settings.  Currently it is all linear, which I'm pretty sure is not correct in all cases.  Notably wheel inertia rises with the square of radius, which means that for the same angular velocity increase, motor torque would need to be at least squared as well (but is this appropriate? the same angular velocity at different scales would be different linear velocities depending on wheel radius, thus different linear accelerations).  I'm not really sure how load rating/spring stiffness would increase with scale either -- an abstract mathematical spring is one dimensional, so linear scaling would seem appropriate; but a physical spring derives its values from its coil dimensions, and I haven't dug into those equations too far.

 

In general news I'm investigating how to best auto-calculate valid suspension settings for wheels, so as to remove most of the possibility for invalid configurations.  This is what the stock wheels appear to do, and while I'm not fond of the idea, I can see where it is good from an ease-of-use standpoint.

The current sticking point is on how to account properly for the number of wheels in a vehicle, and all of their positioning and orientations.  I really don't think that is a problem that I'm going to be able to solve, at least not reliably and in an efficient manner.  Instead I think that I'll have to go with a feedback based approach using an initial rough-guess based on vehicle mass, and then have each wheel further adjust itself based on current ride height vs. target ride height, with some sort of delay built in to ensure it doesn't interfere with standard suspension response during cornering.  In the end the two UI controls would be 'stiffness' (damper ratio), and 'ride height', which would allow control of those values within the supposedly valid range.  Adding in some sort of 'wheel groups' or 'axle' settings for wheels would allow for ensuring that left/right wheels use the same settings, and might help with detecting cornering as well.

Another bit I'm investigating is another slight tweak to the friction code.  After looking closer at my friction-combine code I realized it is using a simple diamond/slope based capping rather than a circular capping method (was summing as a maximum value, rather than calculating as a vector magnitude).  The result of this is that both side and fwd friction should be increased by up to ~30% when both are at maximal value (~0.7 vs ~0.5), but will not have noticeable changes when only one or the other is at maximum.

Took a look over the Adjustable Landing Gear models and setup yesterday.  While I can get the basic functionality working for them (suspension, brakes, wheels spinning), none of the advanced functionality is working as those models were specially constructed with the BD plugins in mind (and/or the plugins were written for the modules).  Not even the deploy animations work, as no actual animations exist, the transforms were all driven manually by the plugin.  To top it all off, the models are rigged in such a way as to make it very problematic to support the features (such as objects that need to rotate around other objects' origin points, randomly interspersed with normal-rotation setups).  Sad, because they are nice looking models; but I would have to have access to the original modeling files to re-rig them for standard uses / easier coding for support of the intended features, or do some very custom code to support them in their current state.

[gomker]

2 minutes ago, Shadowmage said:

motor torque would need to be at least squared as well (but is this appropriate?

This does get tricky - I have the same issues when figuring out scaling factors for BDA damage code right now. What should be vs. what makes gameplay work?  At the moment the updates @qromodynmc pointed out are working for me, I would vote to up those values for now (maxTorque) and work on the more pressing matters.

[qromodynmc]

I totally had no idea about that. But it worked, or didnt. maybe it just worked because of increased rpm?.

[DirkLarien]

5 hours ago, Shadowmage said:

t I would have to have access to the original modeling files to re-rig them for standard uses / easier coding for support of the intended features, or do some very custom code to support them in their current state.

Not certain if i understand correctly but...

I am almost certain it is modified landing gear originally from B9 aerospace..... old version that is...which can be found on curse....

or.... let me check yup 23.5 version fully modded with b9 and some more on my drive ;-)

i can provide that if needed.

 

Edited December 5, 2016 by DirkLarien

[TiktaalikDreaming]

I drove around a box on wheels using just the reconfiged stock wheels, and it's lovely.  Now to start messin about with MM config to switch out the stock modules for the rover.  And then it'll be time to look at tracks for the box on tracks.

13 hours ago, qromodynmc said:

     From this;

        name = KSPWheelMotor
        wheelIndex = 1
        maxMotorTorque = 0.10
        resourceAmount = 0.25
        throttleResponse = 2
        tankSteering = true
        maxRPM = 600

to this;

  name = KSPWheelMotor
        wheelIndex = 1
        maxMotorTorque = 1.0
        resourceAmount = 0.25
        throttleResponse = 2
        tankSteering = true
        maxRPM = 2000

Lines are from KSPWheel patches folder, KF-tracklong.cfg.

Considering beasts like the M-1 have serious gas turbines with 1000kW or more, you may have wanted to beef up the resourceAmount from 0.25 a wee bit as well.  Not every tracked vehicle speeds along at 20+m/s, but those that do pay for that with power, same as a car does.

[TiktaalikDreaming]

17 hours ago, gomker said:

Update: I went the opposite direction, shrunk something to fit, using KF Track RBIMole. This was able to move the tank and climb after a few tweaks of the lat/long slip.

It would appear TweakScale is the root cause to me.

Wheels, gear, legs etc have never behaved well with scaling in KSP.  Tweakscale tries to compensate (I assume the devs know that wheels etc are an issue), but there's only so much they can do.  And tweakscale vs a completely new module is likely to just not scale.  So, core KSP values, like mass, will increase, but the power to the ground and energy use, and all sorts of wheel/track behaviour won't.  TweakScale isn't actually magic, it's just lots of hard work, hidden away.

[damerell]

20 hours ago, Shadowmage said:

@damerell With that said, I do like some of the ideas and data that you have presented, and will give some further thought to if/how they could be used.  Gearing isn't completely off the table, but I would have to rework how motors are handled in order to be able to make use of such a setup (and add provisions for the user to be able to change gearing while in flight = more keybinds...).  If I were to allow for changing of gearing, I would probably also want to include provisions for changing out the motor itself, which would be even more code-side work, more configs to manage, and more user-end setup that would need to be done.  Might play around with these concepts a bit, but no guarantees that it'll be done anytime soon.

Rolling resistance -- already on the TODO list, likely to be supported at the wheel-collider level.  I intend to setup a basic linear rpm-based rolling resistance friction value; probably using a spring-force multiplier as a secondary term to adjust rolling resistance as load changes, with both values being configurable.  RR would be applied to the wheel alongside brake and motor torques.  Nothing too complex.

 

Well, I appreciate that if I want something implemented I should be prepared to implement it myself, but... one advantage of the system I outline, I hope, is that it's almost entirely hands-off. Given the part's wheel radius, assign a nominal speed and all the other values just fall out deterministically. If you don't like the performance that gives you, assign a non-default power/mass ratio. (It's worth noting, as well, that motor RPM is a purely cosmetic value. It isn't _used_ for anything - the power tailoff is just based on the nominal speed, multiplied by gearing).

I don't see any need for the user to change gearing in flight rather than in the VAB - certainly not with keybinds, and arguably if it can be done in flight, only when the part is not operating. Electric vehicles don't typically make use of gear shifting because of the way electric motors can already provide full torque at very low revolutions in a way that infernal combustion engines can't (which is also partly why diesel locomotives typically generate electricity to run electric traction motors). The proposed gearing feature is part of vehicle design - not just to up the torque if designing a very heavy crawler, but because it will make it easier to mix and match wheels - a wheel designed for a slower speed can be geared up and while it won't provide much torque it will be able to provide some at the vehicle's intended speed. It also is intended to reduce the need for the part designer to get the part "just right".

[damerell]

20 hours ago, Shadowmage said:

 

Yeah, I need to take a look on how torque and wheel mass scale with different tweakscale settings.  Currently it is all linear, which I'm pretty sure is not correct in all cases.  Notably wheel inertia rises with the square of radius, which means that for the same angular velocity increase, motor torque would need to be at least squared as well (but is this appropriate? the same angular velocity at different scales would be different linear velocities depending on wheel radius, thus different linear accelerations).  I'm not really sure how load rating/spring stiffness would increase with scale either -- an abstract mathematical spring is one dimensional, so linear scaling would seem appropriate; but a physical spring derives its values from its coil dimensions, and I haven't dug into those equations too far.

I don't think wheel inertia should rise with the square of radius. It would do so if the mass of the part didn't change. However, the mass probably increases with the cube of linear dimension so the moment of inertia would follow the fifth power of radius.

However, I don't think it has anything to do with torque. The job of the torque isn't to rotate the wheel, it's to move the vehicle!

If one assumes a fairly naive scaling-up, the power output has presumably increased with the cube of linear dimension. However, wheel revolutions for a given speed will have reduced proportionately to the linear dimension. If a wheel n times as big is expected to go no faster, torque should increase with the square of linear dimension; if it's expected to go n times as fast, it should increase with the cube of linear dimension. [1]

Linear scaling for a spring is surely wrong - even if the spring is an exact copy of the spring it replaced, it is fatter as well as longer. I would guess, cube of the linear dimension.

[1] One of these cases looks like something for nothing - but that's because gearing, and the point where the power output can no longer provide maximum torque, aren't reflected in it.

21 hours ago, Shadowmage said:

Rolling resistance -- already on the TODO list, likely to be supported at the wheel-collider level.  I intend to setup a basic linear rpm-based rolling resistance friction value; probably using a spring-force multiplier as a secondary term to adjust rolling resistance as load changes, with both values being configurable.  RR would be applied to the wheel alongside brake and motor torques.  Nothing too complex.

If rolling resistance is to be applied as a torque it should not vary with speed (aside from the reduction at very low speeds I outline). It will already drain more energy at higher speeds because more work is done per second against it.

[Shadowmage]

7 minutes ago, damerell said:

 

However, I don't think it has anything to do with torque. The job of the torque isn't to rotate the wheel, it's to move the vehicle!

 

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)

Think of what happens when a vehicle is airborne and you hit the throttle -- the motor revs up and the wheels spin faster, but there is no change in vehicle velocity.  The same thing happens when you are on the ground, only the friction between the wheels and the surface transforms some of the wheels rotational inertia into forwards momentum.  The job of the motor is to rotate the wheel.  It is the job of friction to move the vehicle.  (its a bit more complex than that, even in the fairly simple model that I use; but I can tell you with certainty that the motor forces act on the wheels, and not on the road or vehicle directly).

Another example is to think of a slick surface, say a patch of ice.  A vehicle on this surface will have very low friction between its tires and the surface.  If you apply too much throttle, the wheels will simply spin out, applying close to no force to the vehicle (even though the same torque is being applied to the wheels themselves as on a higher friction surface).

 

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 is this moment of inertia that determines an individual tires response to torque input from a motor; a higher MOI requires more torque for the same angular acceleration.  Now, that is not saying that my current scaling for the 'wheelMass' is correct (it is not).  Wheel mass should probably use cubic scaling, where it currently uses linear.  (The entirety of TweakScale support currently uses linear scaling where it is actually used; going to take me quite awhile to figure out the proper scaling method for everything)

 

Rolling resistance -- while I'm not fond of quoting Wikipedia, it is an easily available source of information.  From everything I can see, wheel speed / wheel rpm does play a factor in rolling resistance calculations:  "Additional contributing factors include wheel diameter, speed,^[2]load on wheel, surface adhesion, sliding, and relative micro-sliding between the surfaces of contact."   I have no idea if it should rise linearly with speed, or some more complex term, but it is linked with speed.
(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)

However whether it should be applied as a torque or force... really plays nothing into the equation; one is equivalent to the other * the wheel radius, and as rolling resistance will be applied to the wheels/axles, it needs to be applied as a torque (even if calculated as a force originally, it will need to converted to a torque before being integrated to change the wheels angular velocity).

 

Gearing / motor output -- still looking into things.  Good point that gear changing might not be needed in flight; while it could have its benefits, the main reason for transmission-style-gear-changing is indeed for the low-torque output at low-rpms from ICEs, where as most electric motors actually have their highest torque output at zero/low RPM.  Could still be of use for multi-purpose vehicles; a rock crawler that can gear down for rough terrain or high slopes, but gear up for higher max cruise speed.

 

Not intending to argue on these points, merely presenting the information as I know it.  If you believe any of these points or posed information is incorrect, I have no problem with discussing it and finding a proper solution, but please be prepared to back up your information with references so that I can see how/where/why my information is wrong.