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

[damerell]

Part of it seems to be that the power is too high. The tiny wheel weighs 50kg but puts out 214 kW? That compares very well to a Tesla's 1.2 kW/kg - let alone the sort of figure one might expect with parts designed for offroad travel. (I suggested 1kW/kg for wheels, 0.75 for tracks). If you're using stats for real-world motors, there may be some confusion there - it's not the power/mass ratio of a motor we need, but the power/mass ratio of a motor+wheel+suspension+brake assembly.

(It's driveshaft torque for the Tesla, BTW - since the wheels don't turn at circa 6000 RPM).

Stock has never had a very clear value of what a unit of EC is worth. At 1EC = 1kJ, a Probodobodyne OKTO2 draws 1800W, as much as an electric bar fire! Between that and the solar values, we might think an EC is about 100J. (That said, solar panels aren't as absurdly good as your figures suggest - solar energy flux is about 1.3 times higher in space and efficiency is higher (because it's worth spending a lot of money to have a smaller and less massive solar panel to launch)).

However, batteries hold 20 EC/kg, which would correspond then to 2 kJ/kg at 1EC=100J, 20 kJ/kg at 1EC=1kW. A Tesla 85kWh (sigh units) battery, conversely, holds 560kJ/kg! (Lithium thionyl chloride batteries, actually used in aerospace, do better, but it's not a rechargable chemistry). Battery masses suggest that an EC might be of the order of 30kJ.

Aerospace fuel cells provide c. 700 W/kg. A KSP fuel cell array (different chemistry, mind) provides 0.075 EC/s/kg, which would make an EC about 9.3 kJ.

(A SNAP-27 RTG as used on the Apollo missions provided about 3.3 W/kg. A PB-NUK provides about 0.1 EC/s/kg, suggesting an EC is about 300J).

(You say "what is 1EC as a stored energy unit, what is 1EC/s as energy flow?" but of course these are the same question).

With a factor of 250 between solar performance and battery performance, it'll never be possible to pick a "correct" value; a vehicle that gets realistic endurance on solar power (needs a lot to drive a very light vehicle) will suck its batteries dry in an eyeblink overnight - and a vehicle with realistic endurance on batteries will get absurdly high benefit from solar power. There's a reason Teslas don't have solar roofs.

I think this has to be a scalable difficulty setting but the default must be sensible. It might scale from values of 1EC=150J (for realistic performance on solar-powered rovers) to 1EC=30kJ (for realistic battery capacities), and suggest values of 1EC=150J, 1kJ (compatibility with KSPI and realistic performance if you run your vehicle on 1EC=1kJ nuclear reactors from other mods), 10kJ (realistic performance with fuel cells), 30kJ.

At 1EC=30kJ, if the overpower is also reduced, a KSP "tiny" wheel draws 50kW, 1.7 EC/s. (This may seem like a lot, but the tiny wheel isn't tiny - it weighs 50kg, over 4 times as much as the entire Sojourner rover). Four of them drawing from a Z-4K battery pack will drain it in ten minutes. (This seems short, but that's going absolutely full power - if a Tesla was running its 85kWh battery pack at a steady 270kW, it would be dry in under twenty minutes.)

At 1EC=150J, four "tiny" wheels need 1,333 EC/s, flatly impossible to do on solar. Good - it's not practical to run a full power motor car on solar. If people pick this setting, they'll be building very small automated solar-powered rovers, where the square-cube law works to their advantage (the power of Tweakscaled-down wheels will diminish with the cube of linear dimension, but the available top-deck area of solar will only diminish with the square).

Personally, I would put the default at the generous end of the scale. People are much less likely to be unpleasantly surprised by parts working too well! (Ideally, I'd like to see it adjustable in-game - sure, people could use it to "cheat" but they can do that anyway with the debug menu - and it lets the properly hardcore drive different vehicles with "correct" settings each vehicle).

Edited February 11, 2017 by damerell
Fix hilarious PB-NUK error

[Shadowmage]

@damerell  Excellent write up, as usual.  Thanks for the input and sanity check on my all-over-the-place math

Yeah, apparently I am going to have to add in some sort of.... fudge factor.... to handle the input powers to convert them to something sane.  Not a huge fan of cheating physics in a physics-central game... but the inconsistencies in stock handling of EC leave no other option.

As far as the current stats on the parts for torque - they were derived from the calculated max-load for the part at default scale and an arbitrarily chosen acceleration at that max load at stall-torque (usually 10m/s/s or ~1g of accel, less on tracks and smaller wheels).  As a result many are grossly overpowered for 'normal' use.  Certainly room for improvement and a bit more realism in the stats/how they are calculated.  I wouldn't mind basing it off of power density for the motors as a portion of part-mass; but that brings us back to the inconsistencies in EC in stock.

 

You point out one of the largest problems I'm going to have trying to get this figured out -- it is impossible to balance the EC use for both battery density and solar-panel power density simultaneously.

Apparently I'm going to have to give this a ton more thought and consideration before I can activate the new motor-power code.... (thank goodness for git branches....)

[damerell]

4 minutes ago, Shadowmage said:

I wouldn't mind basing it off of power density for the motors as a portion of part-mass; but that brings us back to the inconsistencies in EC in stock.

I think these are two different questions. However motors are statted up, the stock EC inconsistencies will remain - but it's still going to be easiest to make a motor's power (whether that's maximum power, power at optimal efficiency, or whatever) a multiplier of the part mass, perhaps using a lower multiplier for tracks, and let the torque be derived from that.

Edited February 9, 2017 by damerell

[Shadowmage]

16 hours ago, damerell said:

I think these are two different questions. However motors are statted up, the stock EC inconsistencies will remain - but it's still going to be easiest to make a motor's power (whether that's maximum power, power at optimal efficiency, or whatever) a multiplier of the part mass, perhaps using a lower multiplier for tracks, and let the torque be derived from that.

Well, I was trying to derive a 'grand unified theory' for both mechanical and electrical energy... which is simply impossible given the inconsistencies in stock EC handling.

However, if I break it up into separate sets of equations (one for mechanical, one for electrical) with a conversion factor in the middle somewhere, that would allow me to use realistic math for both ends with the conversion factor handling the discrepancies for -one set- of stock-balance (for solar, or for battery, or for fuel cell, or rtg; but only one of them at any given time).

Thankfully I'm getting reasonable mechanical power data from the stock wheels -- ~0.403kw / kg for the tr-2l wheel; seems about right if you assume that ~35% of the part mass is the motor and the rest being suspension, tires, etc.  So stock wheels (at least the one I calculated for) have mechanical power that is reasonable for their mass.

However in order to get the stock motor power draw stats to make sense, I have to apply a conversion factor of 65 between mechanical and electrical power (1 mechanical kw = ~0.015 e kw).  Applying that same conversion factor to the KF wheels gives 'reasonable' EC/s requirements at stall.  Kf-tiny wheel gets 1.6kN*m of torque, for 1ec/s; Mole track gets 157kN*m trq, 34ec/s power draw at stall.  Not too far off from what the current stats are power-draw wise, though -all- wheels will have a massive reduction in power output because of it.  (this is using 15% part mass = motor for tracks, and 35% part mass = motor for wheels)

Hmm.... might be getting close to something usable with those numbers.  Will have to do some in-game testing to see how it all pans out.

 

[0111narwhalz]

I wonder if we might want to start a movement for Real Electric Charge, based on a standard factor of perhaps 1kJ = 1ec. We could do that through MM patches to bludgeon stock into cooperating, and the rest would follow.

[damerell]

41 minutes ago, 0111narwhalz said:

I wonder if we might want to start a movement for Real Electric Charge, based on a standard factor of perhaps 1kJ = 1ec. We could do that through MM patches to bludgeon stock into cooperating, and the rest would follow.

I know RO already adjusts solar performance, and I'd be surprised if it doesn't also adjust battery capacity, so you could look at what they do. If KF has an adjustable conversion factor, it would be able to fit with whatever the CAMREC picks later. :-)

1 hour ago, Shadowmage said:

However in order to get the stock motor power draw stats to make sense, I have to apply a conversion factor of 65 between mechanical and electrical power (1 mechanical kw = ~0.015 e kw).

Please, please, don't express it in these terms, a flat physical impossibility. Exactly the same thing can be expressed as a conversion factor between electric charge and joules, something that might be a bit more obvious to the user.

[Akira_R]

5 minutes ago, 0111narwhalz said:

I wonder if we might want to start a movement for Real Electric Charge, based on a standard factor of perhaps 1kJ = 1ec. We could do that through MM patches to bludgeon stock into cooperating, and the rest would follow.

This idea was batted around quite a lot a few years back and I believe the general consensus at the time was that it would create far to many mod inconstancy issues that would necessitate lots of patch complexity due to there being two main camps that are already making assumptions as to what the value of 1 EC should be, those two being KSPI-E and NFT/MKS, and the real issue being that in both cases the value is coded into the .dll's and isn't adjustable via MM.

Now I personally still don't understand why some kind of standard can't be adopted but I do recall it being debated at great length, who knows maybe this time it will actually happen.

[Shadowmage]

7 minutes ago, damerell said:

a flat physical impossibility.

This is my problem with this entire thing....

But that is what the conversion factor is.  No other way to state it.  Its a fudge factor for the differences in handling between mechanical energy and electrical energy in KSP.  What else would it be called?  1 EC is already labeled as 1kJ by other mods (at least, the ones that I use/care about), so I can't relabel that.

Edit:  As far as users will see -- it will just be a 'magic number that makes things right'....

Edited February 9, 2017 by Shadowmage

[Temeter]

21 minutes ago, Shadowmage said:

Edit:  As far as users will see -- it will just be a 'magic number that makes things right'....

Pretty much. It's hard to grasp the connections as long as you don't have a normalized scenario like Realism Overhaul.

I imagine the only way would be to make a stand alone mod (IE 'standardized kerbal electrics') changing all stock values to realistic and normalized formats, and then for all other mods to include optional configs. Of course people would still need to balance two times then, so that's necessary too, and then there is the question what to do with incompatible mods...

But that's really a lot of work. I imagine most people don't care that much (gameplay wise the effect is minimal) or rather go straight to RO.

[damerell]

5 hours ago, Shadowmage said:

But that is what the conversion factor is.  No other way to state it.  Its a fudge factor for the differences in handling between mechanical energy and electrical energy in KSP.  What else would it be called?  1 EC is already labeled as 1kJ by other mods (at least, the ones that I use/care about), so I can't relabel that.

Edit:  As far as users will see -- it will just be a 'magic number that makes things right'....

It'll equally be a "magic number that makes things right" however it is expressed, and it's not "a fudge factor for the differences in handling between mechanical energy and electrical energy in KSP" because stock KSP never says how much a unit of EC is.

It seems better to potentially disagree with some other mods (and after all, the user has the option of setting 1EC=1kJ in my proposal if they most value equivalence with other mods [1]) than to disagree with your own mod about what a kJ is, especially since from what @Akira_R says it is impossible _not_ to disagree with at least one of KSPI and MKS/NFT.

[1] And in your proposal, _a_ value of the magic number has the same effect, but it is much less obvious to the user what that value is.

Edited February 10, 2017 by damerell

[0111narwhalz]

Global config that tells KF the conversion ec->J? Put it in the difficulty menu like the other configurable things and let the user change it from the "best guess approximation" default. Thus, if a player is heavy on the KSPI, they can tweak the value to 1kJ. If they install the Unified ElectricCharge Patchkit, it can detect that and set the default to align with it.

[damerell]

3 minutes ago, 0111narwhalz said:

Global config that tells KF the conversion ec->J? Put it in the difficulty menu like the other configurable things and let the user change it from the "best guess approximation" default. Thus, if a player is heavy on the KSPI, they can tweak the value to 1kJ. If they install the Unified ElectricCharge Patchkit, it can detect that and set the default to align with it.

This is exactly what I proposed.

[Shadowmage]

@damerell Of course you are correct; it will make more sense to label the conversion as an EC->kJ conversion factor.  I'm just massively frustrated with the existing inconsistencies in stock and other mods (most notably, the mods that I use already specify that conversion factor; which will simply not agree with what the default conversion needs to be for motors).  I honestly don't understand how the game got this far with the current all-over-the-place use of EC and power densities; so much about it is just 'impossible'.  (although, I suppose the handling of part-densities in stock isn't any better; half the stock parts are seemingly made of some exotic material with double the density of lead). 

Most of the frustration comes because I spent so much time writing a mathematically 'correct' system, just to have to go and muck it up and make it intentionally 'incorrect' (as far as it is concerned with the values set by other mods).  I could have just as easily not spent the time, and left the power input as an arbitrary config-specified value.

 

I'll do some investigation on to how/where I can set that conversion up to be configurable.  It can't really go in the in-game settings menu as those don't offer enough control or information (unless I offer just a couple 'presets'), and I'm... hesitant... to put it into its own config file as that adds unnecessary complication to the code and general mod setup.  Has to be one of the two though, as those are the only way to get user-configurable options.

[Akira_R]

2 hours ago, Shadowmage said:

@damerell Of course you are correct; it will make more sense to label the conversion as an EC->kJ conversion factor.  I'm just massively frustrated with the existing inconsistencies in stock and other mods (most notably, the mods that I use already specify that conversion factor; which will simply not agree with what the default conversion needs to be for motors).  I honestly don't understand how the game got this far with the current all-over-the-place use of EC and power densities; so much about it is just 'impossible'.  (although, I suppose the handling of part-densities in stock isn't any better; half the stock parts are seemingly made of some exotic material with double the density of lead). 

Most of the frustration comes because I spent so much time writing a mathematically 'correct' system, just to have to go and muck it up and make it intentionally 'incorrect' (as far as it is concerned with the values set by other mods).  I could have just as easily not spent the time, and left the power input as an arbitrary config-specified value.

 

I'll do some investigation on to how/where I can set that conversion up to be configurable.  It can't really go in the in-game settings menu as those don't offer enough control or information (unless I offer just a couple 'presets'), and I'm... hesitant... to put it into its own config file as that adds unnecessary complication to the code and general mod setup.  Has to be one of the two though, as those are the only way to get user-configurable options.

I am always seeing this issue crop up for mod makers. Not to intentionally knock Squad here as we all obviously love this game, but it is as if when they were doing the game balance they either didn't bother doing the math or they were inconsistent with how they were doing the math. The result is when you try to design systems that are based on realistic values they will align with some stock conventions and then be totally out of wack with others, which results in ridiculously frustrating balance issues for mod makers.While this would be totally understandable and reasonable when we were still in alpha they have had numerous opportunities where they could have re-addressed this and they just never did. But now that we are in a full release I feel like that ship has kinda sailed from a professionalism stand point, if they were to do a complete refactor it would break so many things and probably liquid so many people off, and sure it would have done the same in alpha but at least then you have the "well it's an alpha things are going to change" line to fall back on.

[Shadowmage]

Motor efficiency rework code nearly ready for testing.

(Note the motor stats in the part-menu; input/output power, efficiency, torque, ec use)

Have placed the EC conversion factor into a config file.  Not sure any other way to do it.  At least this way it can be easily patched by other mods.

However this still gives the glaring problem of inconsistencies between mods.  A USI/NF reactor capable of outputing '400kW' as listed on the part will actually drive 26MW worth of wheel motors due to the discrepancies in power handling (65:1 conversion).  If I use a 1:1 conversion factor (1ec=1kj), these same motors will drain batteries in a blink of an eye...

 

Will likely put out an updated KSPWheel testing version later today or tomorrow; will be marked as a pre-release so it shouldn't be picked up by CKAN/etc, but should be a drop-in-upgrade.  Should also have some minor updates to dust-effects.  -Might- also include the zero-suspension (zero-friction collider) changes.

[damerell]

17 hours ago, Shadowmage said:

Have placed the EC conversion factor into a config file.  Not sure any other way to do it.  At least this way it can be easily patched by other mods.

Not to be a nuisance, he says, being a nuisance, but I submit it should be adjustable on the fly. A user might (say) go between a solar and a battery powered vehicle and want correct behaviour from both.

I'm wondering if I want to attempt a Campaign for Real Electric Charge mod. :-/

[Shadowmage]

Updated KSPWheel testing version is available; this should be considered an experimental dev version... may contain more bugs than usual, and these changes might not make it back into the master branch depending on how testing/feedback goes.

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

Largest changes are the reworked motor power handling mechanics, but also includes some additional steering functions and some updates to dust-effects.  NOTE:  KF parts have not been rebalanced yet for the updated motor mechanics, so power draw and torque on them will be quite high.  -IF- testing goes well, the KF configs will be updated with the next KF release.

 

[SpannerMonkey(smce)]

Hi just curious as to how you 'll manage wheel and track speed for amphibious type vehicles, as it stands if you drive into the water with a suitable hull etc and engage propulsion, the simple effect of steering using gimbals causes the wheels/tracks to overspeed and fail, even with reduced damage effect. The same thing happens when moving vehicles with vessel mover while neglecting to apply the brakes first. 

Obviously all that concerns us is how it works in the water not how it works while being moved.   Is there a reason that an over speed cap could not be applied? After all there's no way that even an unloaded track could have so little friction that it would  allow a motor over speed, As i discovered to my cost years ago, it takes a lot more oomph to push something on tracks than it does to move the same mass with wheels (don't build overweight small tracked vehicles children) 

But back to the water thing, perhaps a check to see if wheel is immersed and reduce the power or apply an over speed cap.  if i recall most paddle type tyres have an ideal speed rating for water use above which you just start to pump air,  and aerating the water surrounding the wheel instead of providing traction, so maybe the speed cap makes more sense.   I note in KF thread that you already require that a portion of the wheel to  be above the surface, so you've probably nailed all this already

Cheers

[DocMop]

The thing in question is: Should overspeed damage occur when the wheels are not under load? The wheels could as well hang in mid air.

Note: Haven't tested wheels in water / in air yet.

[SpannerMonkey(smce)]

15 minutes ago, DocMop said:

The thing in question is: Should overspeed damage occur when the wheels are not under load? The wheels could as well hang in mid air.

Note: Haven't tested wheels in water / in air yet.

Very true although tracks are unlikely to get airborne on Kerbin unless falling down a mountain so many will never notice   , if used off world it becomes a real possibility,      My experience with the KerbinDakar challenge showed me that high speed on wheels over Kerbin = airtime and recent local tests have borne out the suspicion that the current  KPW over speed situation is less than ideal for rovers especially the sportier types. I don't want to turn off the damage of course as it's usually fine and a bit of a cop out as it skews every result thereafter. 

[Shadowmage]

13 hours ago, SpannerMonkey(smce) said:

Hi just curious as to how you 'll manage wheel and track speed for amphibious type vehicles, as it stands if you drive into the water with a suitable hull etc and engage propulsion, the simple effect of steering using gimbals causes the wheels/tracks to overspeed and fail, even with reduced damage effect. The same thing happens when moving vehicles with vessel mover while neglecting to apply the brakes first. 

Hmm... I might need a bit more information on this.  I thought I had solved all of the motor-induced over-speed problems with the updated motor-acceleration integration.  Additionally, while in water, there is zero speed contribution from friction; the speed of the wheel is set only by the speed of the motor, which should not be able to 'over-speed' the wheel by itself.  I had zero problems with wheel breakage when I was testing the water propulsion; even driving into the water at near max speed with full motor input worked flawlessly.  From your post though, this is caused by external manipulation of the craft?

Gimbals -- is that using IR or something else to physically rotate the wheel in relation to the rest of the craft?

Vessel Mover -- Hmm... I'll have to give that some thought.  Not sure there is anything I can do about it that wouldn't interfere with the proper functioning of the wheels.  About the only thing I could suggest would be to pick the vehicle up off of the ground before moving it.

Lastly -- are you having these problems on rescaled wheels, or with scale=1?  This may be entirely caused by incorrect scaling of the wheel-max-speed compared to motor-max-speed or incorrect scaling of wheel mass vs. motor torque.

 

12 hours ago, DocMop said:

The thing in question is: Should overspeed damage occur when the wheels are not under load? The wheels could as well hang in mid air.

Note: Haven't tested wheels in water / in air yet.

Over-speed damage will occur anytime the linear velocity of the wheel exceeds that specified in the KSPWheelBase config (adjusted by part scale).  So yes, if you manage to spin the tires extremely fast while the vessel is in the air, it will incur damage.  However this should be impossible to accomplish through using the motor; about the only situation in which this would occur would be if you were already moving faster than 'max speed' and became airborne; the wheels would still be beyond their 'max speed' and continue to accumulate damage.

 

Edit:

Also updated the water-propulsion module to allow for config-specification of the 'peak force output submersion level'.  This will allow wheels (and tracks) to still have their force-output peak at 50% submerged (above or below that the force output is reduced), while allowing for screw-drives to continue gaining force output up to completely submerged (force peaks at completely submerged, if only partially submerged, only partial force output will be available, if entirely underwater, 100% force is available).

Edited February 21, 2017 by Shadowmage

[SpannerMonkey(smce)]

18 minutes ago, Shadowmage said:

From your post though, this is caused by external manipulation of the craft?

Let me retest that with this new dev version, as that  was using the  the last proper release.   But not necessarily caused by moving the craft with unapproved methods, simply forgetting to put the brakes on once wet  and unloaded is enough, any steering input caused runaway breakage. I'm a little concerned that this may be noise though until I can recheck fully (next hour) 

27 minutes ago, Shadowmage said:

Gimbals -- is that using IR or something else to physically rotate the wheel in relation to the rest of the craft?

To explain the gimbals it's easier if I show you the craft,  the gimbals referred to are part or the outboard steering

Spoiler

As i said a basic floaty hull with engines and tracks, ( if it had been a different install I'd have had the engines on a boat ,  so the tracks would never have been splashed normally, no ships in this install so it had to be a truck of some sort)  The engines are massively oversize a quick old mod fix for a buddy so hide the size of the hull somewhat, , the hull is nearly 61/2 mtrs long, around 8 tonne wet

 

27 minutes ago, Shadowmage said:

About the only thing I could suggest would be to pick the vehicle up off of the ground before moving it.

Just have to remember to put on the brakes , but this is the same as the water issue and needs the same recheck with the dev version

 

29 minutes ago, Shadowmage said:

rescaled wheels, or with scale=1? 

The wheels that do it are stock size, never really found scaling wheels to work awesomely well, and I was just about to say the tracks are stock but they aren't as they're all  tweaked size clones to suit half a dozen different vehicle types and hulls , and yes I could see scaling being an issue, but the tracks aren't wildly scaled up as all my stuff is Kerb sized , but again I may just be making noise until I've rechecked  today, either way I'll report back shortly 

 

[rasta013]

1 hour ago, Shadowmage said:

*snip*  I might need a bit more information on this. *snip*

Just as a follow up.  Using the latest dev version:

Non-scaled version I couldn't break no matter what I did or how hard I hit the water including at Gear Ratio x:1 (max speed 43.12 m/s).

Re-scaled was another matter.  I broke them rather easily and have other things that I'm reporting on Git.

Also as a side note, I used to use Vessel Mover regularly and would frequently break my wheels/gear or other parts when I transferred vessels to water but just never tracked it all the way down to figure out why...(maybe frequently is overstating but was common enough) 

EDIT: As a side note, the new acceleration code is not allowing breakage to occur from runaway wheels like it was in the release version.  I was regularly getting air in testing sessions this morning, often significant and they wouldn't break from mid-air acceleration.

Edited February 21, 2017 by rasta013

[SpannerMonkey(smce)]

Hi, as above retested all the issue items  in a new  stock dev version  and had no problems with over speed breakage ,   when scaled the issue returns to some extent,  and you could intentionally break a track ,    but what is there I feel is allowable and  it's nowhere near  as instantaneous  as in the full release, which makes it manageable,  a tap on the brakes will bring it all back to something sensible.

If you're driving your scaled tracks at 30ms expect some trouble, but below that it seems to be good    SO you've already dealt with it pretty much.

I will have to rethink my power policy though as larger tracks have a very large appetite for EC 

[rasta013]

1 minute ago, SpannerMonkey(smce) said:

I will have to rethink my power policy though as larger tracks have a very large appetite for EC 

The EC appetite on those tracks made me have to redesign my stock rover testing vehicle.  My original I've used for years for testing just couldn't cope and died on my first run down the runway.