Jump to content

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


Shadowmage

Recommended Posts

As mentioned in one of my  posts the 8X8 and two part 4x4  which last saw the light of day in 1.0.5 lives again the short video below is the vehicle straight out of unity, No setup , generic cfg,  no adjustments whatsoever. It is 8x8 fully independent every thing which is wonderful but does bring a particular problem, more one that in a bit,.  No errors no problems,  the hardest part was fixing a very broken prefab in an upgraded v3 project. ( I'll be sending you a copy for your inspection, the 8x8 and the two part 4x4 version)

A screeny of it stood still and the problem mentioned, take a look at the context menu,it's a tad long, and although fortunately it seems to list the wheels by number, there is no way of telling which is which.  A small thing that could diminish the fun factor, so   is there any way to have wheel groups for instance? and/or some indication of which wheel is which, though i feel the latter request might not even be doable in the current code or with the intentions you have , 

pTwNeXo.png

And finally , spoilered because I've taken up enough  room here lately, the associated comedy Gif, with 8x8 pulling 3 4x4's

Spoiler

dcvyeiA.gif

 

Link to comment
Share on other sites

13 hours ago, SpannerMonkey(smce) said:

A screeny of it stood still and the problem mentioned, take a look at the context menu,it's a tad long, and although fortunately it seems to list the wheels by number, there is no way of telling which is which.  A small thing that could diminish the fun factor, so   is there any way to have wheel groups for instance? and/or some indication of which wheel is which, though i feel the latter request might not even be doable in the current code or with the intentions you have , 

That is a bit out of the scope of what I'm trying to do with these part-modules in the near-term.  It is pretty early in their development though, so something along those lines might be added in time (it just won't be in the near-future, perhaps a few weeks/months out).  The amount of work it would require is non-trivial as it would need an entirely new GUI system to be developed to handle such features (the stock right-click menu is not sufficient for such a complex feature or for complex part setups).  At this point I'm happy if parts such as those work and are usable at all; if they are a bit complex to use, well, that is the nature of complex parts :)

The -goal- for the finished UI for the wheels is something akin to the IR servo controller; this would be a control panel in the app-launcher that would open the 'wheel controller' UI for an entire vessel.  From there you would be able to group wheels to share specific features/toggles, on a per-feature basis (so you could link the 'steeringInvert' on the front wheels, link the 'motor invert' on the right-side wheels, link the 'motor-lock' of the rear wheels, and link the gear-changing of all wheels).

A temporary UI improvement that I might be able to make in the short term would be to add a 'wheelUIName' to each of the WHEEL definitions and to display this name along side the motor/steering/etc controls so that you know which wheel it is.  This change obviously wouldn't fix the super-long-GUI, but it would at least allow for the user to know which wheels settings are being adjusted.   Hmm... perhaps if I combined this with a per-WHEEL 'hide/show controls' toggle it might be a workable interim solution until I can get the full GUI working....  thoughts?


On the subject of UI's -- I spent a bit of time yesterday cleaning up (read: rewriting) the debug-gui features.  It no longer uses the right-click menu of the part, but instead uses a separate 'pop up' GUI (e.g. mechjeb windows) to display information for all of the wheel colliders on a part simultaneously (previously it only displayed information for a single wheel collider, even when multiple were present).  I've also increased the amount of debug information being displayed to cover pretty much all of the values that are exposed by the wheel collider.  The new debug GUI still functions on a 'per-part' basis (I would prefer a per-vehicle window), but is a pretty big improvement over the old debug display.  Not that the debug features will matter to most users, but to modders who are rigging wheels or debugging problems with wheels it can make a huge difference.


General development is continuing at a good pace, and still on-track for an initial KF release over the weekend.  There are problems to solve and things to clean up, to be sure, but nothing too worrisome.  Even with that work I'm sure the initial release won't be perfect and will have its share of balance changes to be done, but should be quite usable.  Not all features will be in place yet (no dust-fx, no 'advanced' wear model, no wheel or motor sound/particle effects, no wheels working in water, no repulsors floating over water), but I don't anticipate those features causing too many problems or any craft breakage when they are added (except perhaps the rework of repulsors... that might cause some breakage as the modules will be changing).

I think the only 'large' task remaining that absolutely has to be done prior to a release is setting up the initial part-balancing in the configs (max wheel speed, max load, motor torque, max motor speed, gear ratios) and configuring the scale-factors (powers) used when scaling the stats for the modules.

Currently working on adding support for max wheel speed; it will be configurable through config, but if not defined in the config will use a calculated value based on the wheel radius and a default 'safe' rpm value.  This max-speed value will be used by both the wheel-damage code and by the steering curve (speed/maxSpeed (percent of max speed, clamped to 0-1) = steering curve input value).

Link to comment
Share on other sites

8 hours ago, Jz03 said:

Hey btw shadow mags can you help me test out your API with KF by helping me with which plugin to delete because there are two plugins and what to do with the API 

Download the KSP-1.0.x release of kerbal foundries.  Install it.  Delete the KerbalFoundries/plugins folder entirely.

Download and install KSPWheel.  Launch game....

Link to comment
Share on other sites

20 hours ago, Shadowmage said:

A temporary UI improvement that I might be able to make in the short term would be to add a 'wheelUIName' to each of the WHEEL definitions and to display this name along side the motor/steering/etc controls so that you know which wheel it is.  This change obviously wouldn't fix the super-long-GUI, but it would at least allow for the user to know which wheels settings are being adjusted.   Hmm... perhaps if I combined this with a per-WHEEL 'hide/show controls' toggle it might be a workable interim solution until I can get the full GUI working....  thoughts?

After spending another day with multiwheel combinations I've found the gui size not a real problem for me, I was thinking ahead to potential non mod making customers, as you know we modders will put up with and are used to lots of things that would drive users to distraction. And there's always mods like part commander which solve that over long context menu problem. Show hide wheel would seem to be a nice option to have, as once they're set you don't really need to mess with it again, unless of course you load or unload the vehicle. and even then not so much.

Having created a second much larger 8 wheel chassis I find the the wheel positions in the gui is different for each vehicle, why this should be I have no clue as the cfg's are to all intents and purpose, less half a page of constraints, the same.  The wheel name would be ideal , though just a number would do, perhaps based off the wheel index?? This does though require that the user understands the part and what is indicated by the gui. Actually is that how the gui slots are decided? by the wheel index? if so I could arrange that so it gave a consistent results.

I doubt very much if any of these creations will make it out into general circulation, due to the complexity of setup etc etc, but as an engineering exercise and a demo of the potential it's been well worth doing, and I'll be converting all the other wheels I've done lately to the KSPW method.

Cheers

 

Link to comment
Share on other sites

4 minutes ago, Fireheart318 said:

Not sure if this's breaking rule 2(?) or not but when will KF be out properly? We have the wheels and API and you said it could be manually compiled but what about a proper release?

or you could read the thread, just a bit , :sticktongue:

22 hours ago, Shadowmage said:

General development is continuing at a good pace, and still on-track for an initial KF release over the weekend. 

 

Link to comment
Share on other sites

5 minutes ago, Fireheart318 said:

Not sure if this's breaking rule 2(?) or not but when will KF be out properly? We have the wheels and API and you said it could be manually compiled but what about a proper release?

22 hours ago, Shadowmage said:

General development is continuing at a good pace, and still on-track for an initial KF release over the weekend.  There are problems to solve and things to clean up, to be sure, but nothing too worrisome.  Even with that work I'm sure the initial release won't be perfect and will have its share of balance changes to be done, but should be quite usable.  Not all features will be in place yet (no dust-fx, no 'advanced' wear model, no wheel or motor sound/particle effects, no wheels working in water, no repulsors floating over water), but I don't anticipate those features causing too many problems or any craft breakage when they are added (except perhaps the rework of repulsors... that might cause some breakage as the modules will be changing).

Be advised that "weekend release" for developers is "next month" for the rest of us. :P

Link to comment
Share on other sites

16 minutes ago, 0111narwhalz said:

Be advised that "weekend release" for developers is "next month" for the rest of us. :P

*Random guy on the internet*: YAY THE NEW VERSION'S COMING OUT THIS WEEK WOHOOOO!!!

*8 weeks later*

"Wohooo... Go... Game..."

Link to comment
Share on other sites

18 minutes ago, DarkOwl57 said:

*Random guy on the internet*: YAY THE NEW VERSION'S COMING OUT THIS WEEK WOHOOOO!!!

*8 weeks later*

"Wohooo... Go... Game..."

The moral of the story is of course, don't get on the hype train if you've anywhere important to be for a week or two.

@Shadowmageforgot to mention that I also had a tinker with the sweep types , what a revelation, more testing required,  Also removed all colliders from the wheels as suggested. You've certainly created the roundest wheels that KSP has ever seen, nice work :)

Can you foresee any snags animating a set of wheels to retract ?

 

Link to comment
Share on other sites

1 hour ago, 0111narwhalz said:

Be advised that "weekend release" for developers is "next month" for the rest of us. :P

Thankfully when I give semi-firm dates for releases I'm pretty good at sticking to them (those that follow the SSTU thread can attest to this);  I won't give dates like that unless I'm very confident I can get things done in time.  Of course, occasionally 'show-stopper' type bugs or issues pop up that require delays, but I've probably hit 90%+ of my first-estimate release dates (and the ones that didn't make it were usually no more than a week behind, being released on the next weekend).

The times where I give the 'few days / weeks' or 'weeks/month' answers... well yeah... those pretty much mean 'it'll get done when its done'.  About as reliable as predicting the weather.

But generally yes, developer estimates of timeframes are just that -- estimates.  Quite often things come up that are out of the control of the developer or take additional unanticipated time to finish/fix.

 

 

Working through figuring out the part-balancing, or rather the system of equations that I'll be using to derive the specific stat balance for the wheels.

Hitting on a bit of a snag -- what measurement should EC be considered in SI?  Joules?  Watts?  (probably kJ or kW).  It seems that quite a few other mods use 1ec/s to be 1kw (see the USI reactors), and 3600ec would consumed/generated for a 1kwh.

The problem I'm running into is putting this back into the power equations for wheels.  I end up with ridiculous power requirements for what would seem like reasonable torque output values.  Take, for example, the Mole track; in order for it to put out 32.5kn/m of torque, I get something silly like 9000ec/s required at stall.  Granted I've probably got some conversions wrong in the math somewhere....  Anyone familiar with electric motors that could help me derive the equations to determine input power if given a motor stall torque, max RPM, and efficiency? (Probably just need to step back and examine the conversions a bit more to find my errors)

Alternatively, does anyone have links to some DC motor graphs that also have specs on the motor (input voltage, current)?  I can use a few of these to double check my work, but I've had a real difficult time finding any plots of motors that -also- have all of the stats for the motor (e.g. the graph will show input current (A), but nowhere is it displayed the input voltage... where both are needed to determine input KW)

Edit: Think I got it figured out; was erroneously outputting watts as out-power rather than kw -- resulting in a 1000x increase in apparent power draw.... and suddenly things start looking reasonable :)
Under the new calculations the MOLE track requires about 9ec/s to output 32kn/m of torque at stall (with a 2500rpm max motor speed).  Graph looks almost exactly the same...
Will be using this data to derive ~85% peak efficiency data for the motors and using that to determine their base stats.  Of course this all relies on first calculating the intended max load for the wheel, its intended max-acceleration at that load, and intended max speed at standard gear ratio -- these stats will determine the base stats of the motor (torque, input power, max rpm, gear ratio).

This is all using the 1EC/s = 1kW/s = 1kJ convention.

(rough graph generated from plotting the motor from the MOLE track)

fNmrKRK.png

green = output power
dk blue = output torque
red = motor rpm
lt blue = input/output efficiency
(input power not graphed, but it goes from 1 on the left to 0.05 on the right)

 

56 minutes ago, SpannerMonkey(smce) said:

 

@Shadowmageforgot to mention that I also had a tinker with the sweep types , what a revelation, more testing required,  Also removed all colliders from the wheels as suggested. You've certainly created the roundest wheels that KSP has ever seen, nice work :)

Can you foresee any snags animating a set of wheels to retract ?

 

Indeed, aren't those alternate sweep types a bit of fun to play with?  Still pretty rough/early in their development too; they 'work', but there is room for much improvement, especially on the capsule style.  Contemplating adding a couple more sweep types -- 'compound', and 'tank'  (compound would use multiple other cast types to give a very accurate response compared to the wheel mesh; tank type would be setup special to handle tank-tread style sweeps).


Deployment animation -- should work fine;  check the (disabled) stock patches at ( https://github.com/shadowmage45/KSPWheel/blob/master/GameDataDisabled/Stock/Stock-gear.cfg.disabled ) for examples.  It will use the KSPWheelDeployment module to manage the animation (and disabling of wheel functions when retracted/etc).

Edited by Shadowmage
Link to comment
Share on other sites

I like the edit btw,  and will go on record as not caring if the units are called jelly beans as long as it works :)

On that note, the steering, I don't much like the on or off , full lock or no lock, and would very much to slow things down, i always hated those rc cars that steer by solenoid.  Is there anything i can do in cfg to slow things down a lot, especially for vehicles as below when a lot of steering at the wrong time is bad

Spoiler

The large 8X8 mentioned earlier

Exactly the same cfg as the tiny truck, except for travel and collider diam,  and once again 1 complete part apart from the airbags and the 7tonne launcher on the back , I know these kind of  things are not popular in Ksp but I like them.

 

 

Link to comment
Share on other sites

13 minutes ago, 0111narwhalz said:

Isn't it kinda silly to consider energy in watts? It seems like ec should equate to kilojoules instead.

Not really, they convert fairly well (when time is taken into consideration).  1w for 1s = 1j.  1kw for 1s = 1kj = 1ec-per-second.  1kw in/out for 1h = 1kwh = 3600kj = 3600EC.

The reason I am using KW is because it is one of the standard ways to measure motor power and efficiency.  kw-in / kw-out = efficiency %...  (the other being horsepower, but HP is not a standard SI unit used in KSP).  I've never seen a motor listed using joules for any of its stats; at least the ones that I deal with use watts/kW for output power/power rating (with input given in volts @ amps, which is a watt rating)  (brushless-dc motors for RC use).  Though you could substitute 'j' for 'w' in my equations and it would give the exact same results. 

Pedantry -- more precisely I am measuring power and not work; a joule is a unit of work, a watt is a unit of power.  (At least this is as close to the definition that I could find; I am not a physics expert though, merely pretend at being one on the internet on occasion.... please correct me if I'm wrong on that.)

But anyway, its not me coming up with those units -- I was merely posting data that had been derived from other sources (e.g. see the USI/NF nuclear reactors; they list power output in KW, and output that listed value in EC/s).

 

2 minutes ago, SpannerMonkey(smce) said:

I like the edit btw,  and will go on record as not caring if the units are called jelly beans as long as it works :)

On that note, the steering, I don't much like the on or off , full lock or no lock, and would very much to slow things down, i always hated those rc cars that steer by solenoid.  Is there anything i can do in cfg to slow things down a lot, especially for vehicles as below when a lot of steering at the wrong time is bad

  Reveal hidden contents

The large 8X8 mentioned earlier

Exactly the same cfg as the tiny truck, except for travel and collider diam,  and once again 1 complete part apart from the airbags and the 7tonne launcher on the back , I know these kind of  things are not popular in Ksp but I like them.

 

 

In the current releases -- not really, at least not easily, or that I could remember how to setup (lots of changes in dev code...) --  (there is a steering curve that can be enabled, but it has to be setup on a 'velocity as input' setup, where you need to know the specific velocity for each output point).

In the upcoming release/dev code -- just fixed up the default steering curve last night to work off of the max specified 'safe' speed for the wheel.  Is enabled by default, and default max safe speed (if unspecified in the config) is calculated from largest wheel radius on the part @ 400rpm.  You might try downloading the KSPWheels.dll from the dev branch (UI-Cleanup branch)  ( https://github.com/shadowmage45/KSPWheel/blob/UI-Cleanup/GameData/KSPWheel/Plugin/KSPWheel.dll ).

Link to comment
Share on other sites

4 hours ago, Shadowmage said:

Not really, they convert fairly well (when time is taken into consideration).  1w for 1s = 1j.  1kw for 1s = 1kj = 1ec-per-second.  1kw in/out for 1h = 1kwh = 3600kj = 3600EC.

The reason I am using KW is because it is one of the standard ways to measure motor power and efficiency.  kw-in / kw-out = efficiency %...  (the other being horsepower, but HP is not a standard SI unit used in KSP).  I've never seen a motor listed using joules for any of its stats; at least the ones that I deal with use watts/kW for output power/power rating (with input given in volts @ amps, which is a watt rating)  (brushless-dc motors for RC use).  Though you could substitute 'j' for 'w' in my equations and it would give the exact same results. 

Pedantry -- more precisely I am measuring power and not work; a joule is a unit of work, a watt is a unit of power.  (At least this is as close to the definition that I could find; I am not a physics expert though, merely pretend at being one on the internet on occasion.... please correct me if I'm wrong on that.)

But anyway, its not me coming up with those units -- I was merely posting data that had been derived from other sources (e.g. see the USI/NF nuclear reactors; they list power output in KW, and output that listed value in EC/s).

Watts is just Joules per second, and vice versa.  If you're looking at the rate of work/consumption, then you're looking at Watts.  If you're looking at how much juice you've used over a certain time frame, then Joules.

Brushless DC seems to be basically a flat line from zero speed, max torque, to zero torque, max speed.  Induction AC motors with inverters to run off DC have closer to a fixed KW output, but usually with a torque limit at low revs.  So, flat line at max torque, then an inverse square curve out to effectively zero.  Both have various losses that affect this. 

DC brushless have some significant magnetic/resistance losses at low revs, and they don't scale well as you have to keep beefing up your permanent magnets.  Induction motors have a lower maximum efficiency, but scale better, and as they can adjust magnetic field strength, can compensate for the issues at low revs.

So, the smaller the motor, the more likely it'll be a DC brushless.  The larger (or more powerful, and the two really go hand in hand), the more likely an AC Induction/inverter system is the way to go.  Electric cars are still working that sort of thing out as to when it's best to switch from or the other.  But it is somewhere in the car range of power.  Little commuter vehicles definitely should go DC.  Truck type vehicles or performance cars should definitely go AC.  Jury still out on everything in between.

 

Tesla torque curves;

e98Er.png

and, um, maybe actually a very similar pattern for DC motors in practice, eg: Prius torque (includes blue line for petrol engine)
EngineMotorTorqueFit.jpg

 

Edited by TiktaalikDreaming
added curves
Link to comment
Share on other sites

It's great to finally have KF back but my favorite part, the hoverpads/repulsors really don't work. They act like they're normal wheels being pushed around with the brakes on. In addition to being hard to control, they have friction and faceplant around like a drunk horse

Edited by Fireheart318
Link to comment
Share on other sites

7 hours ago, TiktaalikDreaming said:

Brushless DC seems to be basically a flat line from zero speed, max torque, to zero torque, max speed.  Induction AC motors with inverters to run off DC have closer to a fixed KW output, but usually with a torque limit at low revs.  So, flat line at max torque, then an inverse square curve out to effectively zero.  Both have various losses that affect this.

As discussed upthread, I think that torque limit is in software, not a property of the motor. It's there so that if the driver floors it from a dead stop the effect isn't to yoink the contact patches off the tyres or to slew off into the nearest lamp-post. The mass of a pax-carrying EV doesn't vary much so the maximum acceleration can easily be tuned, but for a KF part which might be fitted to widely varying vehicles there's no sense in a hardcoded torque limit.

Re EC consumption, Power (kW) = Torque (N.m) x Speed (RPM) / 9.5488. Energy consumption is 2 * pi * (Torque in N.m) joules for each revolution. (It's no accident that 60 seconds per minute divided by 2 * pi is 9.5488 :-)

The conversion rate between joules and EC, I don't have an opinion on, but as Tiktallik says, EC can only be measured in joules; EC/second can be measured in watts. (Another possible source of a "far too much" error would be calculating the power consumption in watts (ie joules/second) then subtracting that many joules from the battery once per tick...)

Gosh, this has been edited a few times. I think hence there are two possible implementations. One is using the first formula above - take wheel RPM and calculate power then multiply by tick length to get the EC usage this tick. The second is to use the second formula above, count how many revolutions have happened this tick, and calculate the energy consumption (without reference to the tick length). I don't know which is easiest.

Edited by damerell
Link to comment
Share on other sites

1 hour ago, damerell said:

As discussed upthread, I think that torque limit is in software, not a property of the motor. It's there so that if the driver floors it from a dead stop the effect isn't to yoink the contact patches off the tyres or to slew off into the nearest lamp-post. The mass of a pax-carrying EV doesn't vary much so the maximum acceleration can easily be tuned, but for a KF part which might be fitted to widely varying vehicles there's no sense in a hardcoded torque limit.

It's not there to protect the driver from being an idiot so much as to stop the motor breaking parts of the drivetrain usually.  But yes, it's usually software or equivalent based.  It's not an emergent property of the motor itself.
 

Quote

 

Gosh, this has been edited a few times. I think hence there are two possible implementations. One is using the first formula above - take wheel RPM and calculate power then multiply by tick length to get the EC usage this tick. The second is to use the second formula above, count how many revolutions have happened this tick, and calculate the energy consumption (without reference to the tick length). I don't know which is easiest.

 

I'd be inclined to have a torque curve that's cfg configurable like the ISP to atmo curves.  And just build in some defaults.  Just pick a fairly simple system for best-fit to match the curve points and off you go.

Link to comment
Share on other sites

Hi, tested the latest DLL and sorry to report   I'm having nothing but grief , nothing i've built so far  to use the plugin works straight away as it was left, and when i get it set up ,  it's move two feet break a wheel move 1 meter break everything , even things like a little two wheeler (resto from 0.18!) which is very light, cant move without breaking wheels or suspension.  Sadly as i couldn't get anything to launch with endlessly repairing wheels I can't say anything about the rest of the changes  Fortunately a quick revert to the old version puts everything right.

Am I missing something? The little two wheeler (pseudo motorcycle) has naturally very small wheels, and I just can't get any speed out of it, upping the motor torque has a small effect, upping the wheel rpm has a negligible effect, it's almost as if the brakes were on all the time.  SO what have i missed? as i understand it the collider fitted in unity is removed and any setting applied go with it,  apart from travel and diam which of course translates to the cfg value, so is there an issue with rolling resistance?  There's something odd happening here as at rest the vehicle appears to slip around slightly and slide down gradients, whereas under power it shows rapid reduction in speed when the go button is released indicating some king of drag perhaps.  

Spoiler

 

 

Link to comment
Share on other sites

1 minute ago, SpannerMonkey(smce) said:

As an interesting note  I have the second set of Repulsors ever made and  with a stock (Squad) wheel  cfg and they display no such tendencies

I'll elaborate - Y'know how wheels work when they get pushed around with the brakes on? They work like that, you cannot adjust the friction, suspension, anything. So combine weird twitchy friction with a high rideheight and y'got a drunk horse plane thing

Link to comment
Share on other sites

Just now, Fireheart318 said:

I'll elaborate - Y'know how wheels work when they get pushed around with the brakes on? They work like that, you cannot adjust the friction, suspension, anything. So combine weird twitchy friction with a high rideheight and y'got a drunk horse plane thing

I'll have to investigate

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...