[1.8.x] Kerbal Foundries -- Continued - Tracks, Wheels, and Gear

[Haifi]

Well, at least its not exploding anymore 

That's what I got with 0.9.2.10:

Spoiler

 

Edit: @0111narwhalzYea you're right, both springs and dampeners add up on that bounciness. Must be Kangaroo-fuel in that tank.

 

Edited February 6, 2017 by Haifi

[Shadowmage]

3 hours ago, Haifi said:

You're the boss, boss!

That's what I get with a stock craft, stock settings on the tracks and no mods besides KF :

  Reveal hidden contents

 

Craft file is here: https://www.dropbox.com/s/o33v01eeyuzmeny/testcraft.craft?dl=0

Log is here: https://www.dropbox.com/s/gd9cmygoxevf6k1/output_log.txt?dl=0

I activated the debugging, but there's no additional data to be seen !?!

Regards Haifi

Thanks much for the updated information and test-craft, will take a look over this tomorrow and let you know what I find out.  Increases the chance of me being able to duplicate and fix the problem by at least 100x

Debugging -- when enabled there should be a little 'truck' icon in the stock app-launcher bar in the flight scene; you can click on that button to open/close the debug-gui for the current vessel.  It displays pretty much every stat for each wheel collider on the entire vessel (actual spring+damper values, spring/lat/long forces, slip ratios, motor+brake torques, collider-hit, compression, and a few other misc stats).  I guess I never really advertised this feature as I put it in mostly for my own debugging use, but it can certainly be useful for others to do a bit of diagnostics.

 

As far as spring/damper settings in general -- yes, setting the damper higher than ~1 can often cause instability, especially when combined with higher spring values (mostly it manifests when the compression is less than ~20%).  There are a (very) few use-cases for it which is why I left the range where it is at though I am considering lowering the max damping ratio to 1 or 1.2, and allowing a config to push it further if needed for special uses. 

Most craft should not need the spring or damper adjusted at all for general use; those sliders are (originally) intended for solving instability problems with the default settings on particular craft designs or for carefully fine-tuning the ride characteristics (which currently requires using the debug-menu to monitor compression values/etc to make sure everything is still in the 'stable' range).

[Haifi]

@Shadowmage Okay, I've made another video. This time with the debug window open .

I've set springs and dampening to the lowest possible setting on all 4 tracks.

Lets see what happens:

Spoiler

 

Hope this helps figuring out whats going on!

[Shadowmage]

50 minutes ago, Haifi said:

@Shadowmage Okay, I've made another video. This time with the debug window open .

I've set springs and dampening to the lowest possible setting on all 4 tracks.

Lets see what happens:

Hope this helps figuring out whats going on!

LoL, setting them to the lowest is just as likely to cause problems as setting them to the highest.  You want them -in the middle-.

Well, actually, what you want is whatever spring value keeps the comp% around ~0.5 (50% compression).  The stable range is between ~25% compression and ~75% compression.  If the craft is trying to sit outside of that range due to user changing the spring.... well.. you are -telling- it to be in the unstable range.

 

As was stated last night -- if it works fine, don't touch the spring slider.  If it is -not- working, then you should play with the spring (and possibly damper) until it is.  Most of what is 'going on' is user error... (or lack of proper instructions?)

(I should probably just remove the spring slider completely, as apparently it is just going to cause problems...)

Edited February 6, 2017 by Shadowmage

[Haifi]

Its unstable for me in every setting, it just escalates when going in one direction or the other... Even with standard settings the comp values can't even be read because they fluctuate too fast...

[Shadowmage]

6 minutes ago, Haifi said:

Its unstable for me in every setting, it just escalates when going in one direction or the other... Even with standard settings the comp values can't even be read because they fluctuate too fast...

As I already said last night, I'll take a look at the craft to see if there is anything I can do, or if it just takes specific spring/damper settings to get it to be stable.  Sadly nothing I can do about it for another ~12 hours or so (back at work...).

 

Edit:  Actually that video looks 'about right' for the settings you have on those wheels, or at least for the damper setting.

When you remove the damper (by setting it to 0.00whatever) you then have an undamped spring system, which -will- oscillate forever (in the absence of drag/external friction).  That is 'proper behavior' for a system configured like that.  Just something to think about.....

https://en.wikipedia.org/wiki/Harmonic_oscillator

What happens when you launch that craft with spring at 0.5, and damper at 0.65?

Edited February 6, 2017 by Shadowmage

[V8jester]

@Shadowmage Seeing as I'd like to move past my last comment (forgive me, life has been a rolllercoster, of which you were not the operator)

Is there a way to effectively make the wheels "indestructible" or would this lend problems to the necessity of "getting as close to 50% load" on a given wheel as possible?

[Shadowmage]

Just now, V8jester said:

@Shadowmage Seeing as I'd like to move past my last comment (forgive me, life has been a rolllercoster, of which you were not the operator)

Is there a way to effectively make the wheels "indestructible" or would this lend problems to the necessity of "getting as close to 50% load" on a given wheel as possible?

Yep, go into the in-game settings/difficulty menu, select the KSPWheel tab, and change the 'Damage Model' to 'None'.  That will turn off all custom 'wheel-breaking' damage.

You can also turn up/down/off the individual damage modifiers for loading and speed.  The thresholds will still be the same (it doesn't change the max-load or max-speed), but it will take a longer duration of being passed the 'max' before things will break.

[Haifi]

2 hours ago, Shadowmage said:

What happens when you launch that craft with spring at 0.5, and damper at 0.65?

I posted the vid to that yesterday ( in the You're the boss, boss! post ) 

Stock everything... What I get is very fast small oscillations, like a vibrating grinder. 

[V8jester]

1 hour ago, Shadowmage said:

Yep, go into the in-game settings/difficulty menu, select the KSPWheel tab, and change the 'Damage Model' to 'None'.  That will turn off all custom 'wheel-breaking' damage.

You can also turn up/down/off the individual damage modifiers for loading and speed.  The thresholds will still be the same (it doesn't change the max-load or max-speed), but it will take a longer duration of being passed the 'max' before things will break.

Thank you @Shadowmage

[Shadowmage]

5 minutes ago, Haifi said:

I posted the vid to that yesterday ( in the You're the boss, boss! post ) 

Stock everything... What I get is very fast small oscillations, like a vibrating grinder. 

Hmm... interesting.  Wonder what the differences are between your tests and what @0111narwhalz had shown in testing?  (No need to answer, just thinking out loud here)

About the only thing I could think of would be some changes to the physics timing in KSP.  Any reduction to the frequency (e.g. by increasing the physics-delta-time) can and will wreak havok with the simulation stability.  I wasn't seeing any other physics-altering mods in the logs (though I didn't look too hard for them), but I'm at a loss as to what else could be causing differences between the tests.

Either way I'll be taking a look at it after work; just trying to figure out where the inconsistencies are coming from so I know where to start looking.

[Haifi]

I was thinking in the same direction, my standard setting for physics delta time is 0.04, because I tend to have bigger stations / bases at some point. So I tried higher settings and even lowered it to 0.03, to no avail. The effect is persistent. 

[0111narwhalz]

Results with changing physics delta:

Delta	Stable Range (Spring)	Stable Range (Damp)
.12	.2 - .65	.05 - .675
.03	.2 - .55	.05 - .675

Measurements of stability in one axis were made in out-of-the-box position on the other. "Stable" is defined as "not shaking when at a near-standstill on the runway." 
The results seem to indicate that physics delta has a small, but notable effect on the spring range.  Oddly, it seems slightly more stable at higher values, which is contrary to my intuition. Notably, when the dampers are set very low, they do eventually damp out the bounces, but it might take as much as several seconds.

I would like to advocate the continued existence of the sliders. Perhaps gating them behind Advanced Tweakables will convey that they're not really supposed to be changed, except in specific use-cases. Just like stock's Rigid Attachment and Autostrut.

[BlueDragon1504]

I know I'm a bit late to the party, but there is no way to say how tired I am of the stock wheels. Many thanks!

[Shadowmage]

In the 'good news' department, yesterday I figured out how to model and rig track parts; armatures, skinning, vertex weighting, UV layouts, and how to make it all work in the Unity world.  So there is some possibility of new track parts in the future, if I find any specific cases where new models would be of use.  The KF-TrackSimple that was included with yesterdays release was a completely reworked and re-rigged model (well, two models actually).

Also figured out a method to properly handle left/right sided models.  Is kind of painful to do, as both models have to be built at the same time (blender refuses to duplicate armature rigging for some inane reason)... but at least it is workable now.  Perhaps I'll learn some better methods to handle the duplicate/mirrored model setup in the future, and then it can be both usable and not entirely painful.

 

Additionally I figured out why the dust-effects were becoming over-powering in some cases -- scaling!  (sadly I did not work on this until after the release yesterday)  I was using the scale value of the model to increase the emitter parameters which was causing far more particles to be generated for up-scaled parts (to the point of causing FPS issues even on my higher-end system).  Have reworked those a bit to no longer use the model scale but to instead use the spring-force currently exerted by the wheel -- this gives a much more natural progression from 'not much dust' on light loading/small wheels to 'bigger clouds of dust' on larger loads/large wheels.  Spring force only effects the 'size' and 'energy' of the particles, and not emission rate ('emission'), so should not cause the same choking that the previous scaling method was inducing.  It also means that smaller/lighter craft will by default have 'smaller' dust output, while still allowing billowing clouds for when you want to run a 50t tank across the terrain

Playing with particle emitters is fairly new to me so I'm sure there will be a few more revisions to the code, but the next release of KSPWheel should have much more...natural... dust emission for various craft setups.

 

And finally, I think I have a set of formulas that I can use to clean up the motor input/output/efficiency calculations.  Should allow for specification of a motor by only a few stats (output torque, peak efficiency, no-load/max-rpm current draw ratio of peak input current, and max rpm).  Still working through deriving one last formula, but I've got a good data-set to work from and I'm sure I'll be able to figure out something (even if I just sample from the experimentally derived curve data set).  Hoping to get this implemented sometime this week.  Should not be craft breaking at all, though some may see slight differences in power draw.

 

[lo-fi]

Looking great. Do shout if I can help with track/suspension rigging, and I'll try and remember to get those zips over to you some point soon. 

[DirkLarien]

You have fixed the Adjustable landing gear ?

Is this real ?

You are a hero !

Where is the donate button ?

[Shadowmage]

48 minutes ago, DirkLarien said:

You have fixed the Adjustable landing gear ?

Is this real ?

You are a hero !

Where is the donate button ?

Well, to be fair, the are only 'mostly fixed'.  They work for many craft and setups, but might have stability problems in some cases.

If you do run into any problems with them, please let me know (will likely need logs and a stock/KF craft file to diagnose/debug/fix most problems though).  Otherwise, hope you enjoy them

 

( Added a donate button to the OP/first page; as always, purely optional, and always appreciated )

[Shadowmage]

@Haifi

After some lengthy investigation, I can confirm the instability problems with the provided craft, even at the default spring/damper settings.  Thanks for providing the craft; I would have never designed something like that, so would have never seen the problem.  Would also like to apologize for labeling it as user error, as in this particular case/craft it was not directly caused by anything you were doing.

I can also tell you exactly what the problem is with that craft:  Unity Joints.  More precisely it is harmonic feedback between the wheel forces and the sloppiness in the joints.  Having the wheels at the end of a long arm that has negligible mass itself, connected to or supporting a heavy central mass (really bad setup if you read the Unity documentation on joints).  Unity states that all joined rigidbodies should be within a close range of masses (the fuel tank weighs 9t, so the lightest part on the craft should be -more than- ~4.5t; those i-beams are <1/10 that, and the rover body is ~1/20 of that).

Wheel A goes up, pushing wheel B down, next physics tick it updates for their new positions and finds things -not where they are supposed to be- due to the sloppiness in the joints, suddenly wheel B is way over-compressed and starts moving upward while wheel A has found itself needing to move downward.  Rinse and repeat every physics tick, and you have jitter.

From the unity documentations:  " Avoid large differences in the masses between Rigidbody components connected by Joints. It’s okay to have one Rigidbody with twice as much mass as another, but when one mass is ten times larger than the other, the simulation can become jittery."  ( https://docs.unity3d.com/Manual/RagdollStability.html )

 

In order to minimize the jittering you will need to use auto-struts on craft that are setup like that.  Turn on the auto-struts on the wheels and on the i-beams and the whole thing stops bouncing.  Alternatively, don't attach wheels at the end of long parts that will have joint flex (joint flex can be estimated by the relative mass between the parts;.

Not sure that there is anything I can do to solve Unity joint problems.  Rather I'm fairly certain that there is nothing that I can do.  Even the stock wheels exhibit these problems, but have mostly been 'hidden' behind stuff like auto-struts; and those are the wheels that Unity uses -- if Unity can't solve that problem in their own engine, the chances of me being able to solve it externally are essentially nil.  About the closest I can think of would be to distribute the wheel forces proportionately to every rigidbody in the craft, and even then I don't think that would 'fix' the problem.

 

Pic of craft, with default wheel settings, everything is nice and stable.  Only thing I did was to enable auto-struts on both the wheels and the i-beams.  Note the horizontal and vertical speeds both at less than 1mm/s.

 

Alternatively adding manual struts works nearly as well as the auto-struts -- anything that can be done to eliminate the slop in the joints:

Emptying the fuel tank, bringing the mass ratios closer to what is specified in the Unity docs also eliminates the jittering:

 

Lastly, using heavier parts for the 'arms' also eliminates the jittering (fuel tanks are 4.5t each; note I also parented them to the center fuel tank rather than the rover body as it is too light) -- this is actually the most stable configuration from my testing, with literally zero jitter.  I had to turn off the stress damage for this test as it was just too much load for the wheels at default scale, but they were breaking from actual overloading and not bounce/jitter induced overloading.  After turning off stress based damage it was perfectly stable under the load:  (note the 0.00 mm/s movement for both horiz and vert; doesn't get any more stable than that)

 

 

Seems likely that I'm going to have to put together some instructions or other notes regarding the limitations in the Unity engine and how to best work around them using the tools that have been made available.  I will not be forcing full time auto-struts like the stock wheels do, but users will need to know when they are necessary.

 

In the end... I can work magic (I am a mage after all...).  I can't do miracles (you'll need a divine entity or diety for those).

Edited February 7, 2017 by Shadowmage

[Haifi]

Thank you so much for finding the problem, at times I was thinking I was seeing ghosts...

If its a "stock" problem there's nothing to be done about it. To know a workaround is all that I need.

Again, thank you, and thank you for not writing me off.

[V8jester]

"By the power of Greyskull"

The wheels handle weight even better than I had imagined! I tried disabling the damage as you had mentioned and these wheels perform immaculately under tremendous weight. I am using 16 scale 2 small wheels under a 190t mobile crane. While the steering is still too fast (Very minor complaint ATM. I was finally able to really run the wheels through a good torture test. While I am cheating, the wheels handle weight better than the original KF plugin did. Now that is in no way taking away from Lo-Fi's amazing work. But you have absolutely added some noteworthy improvement to something great. Now all that nonsense aside. I wont come back with nonsense like "I cheated and these wheels are great" again

Now for a more on point question. Do you plan on adding a slider (or equivalent) for steering response / speed at some point down the road? Being that you just released a new version of KF and KSPwheel in the last 12 hours I'm absolutely not asking for anything. Just curious.

[DocMop]

@Shadowmage

Just wanted to say this here: I absolutely love those long explanatory posts of yours. As a fellow programmer it is incredible interesting to read all this "behind the scene" stuff.

[Shadowmage]

11 hours ago, V8jester said:

"By the power of Greyskull"

The wheels handle weight even better than I had imagined! I tried disabling the damage as you had mentioned and these wheels perform immaculately under tremendous weight. I am using 16 scale 2 small wheels under a 190t mobile crane. While the steering is still too fast (Very minor complaint ATM. I was finally able to really run the wheels through a good torture test. While I am cheating, the wheels handle weight better than the original KF plugin did. Now that is in no way taking away from Lo-Fi's amazing work. But you have absolutely added some noteworthy improvement to something great. Now all that nonsense aside. I wont come back with nonsense like "I cheated and these wheels are great" again

Now for a more on point question. Do you plan on adding a slider (or equivalent) for steering response / speed at some point down the road? Being that you just released a new version of KF and KSPwheel in the last 12 hours I'm absolutely not asking for anything. Just curious.

I seem to remember that from some Saturday mornings, many years ago

Indeed, the weight limits are entirely arbitrary and imposed simply for the inclusion of a damage model.  Turn off the damage model and the wheels should be able to support nearly any load (subject to the previously mentioned Unity joint limitations of course).  Originally they were also used for the 'manual suspension' model as well, but that is quickly becoming extinct I think.

Glad they are working out for you though.  If you do run into any craft designs that you would like to suggest for updated balancing on the load-ratings, feel free to post them up.  The current values were based off of the mass of the part, guessing that a wheel part could support 20x its own mass (rough guess from the mass of my own car, estimating the mass of a single wheel+suspension mechanics, and then adjusted upwards a bit for the whole 'space-capable technology' aspect).

 

Steering slider -- should already be present for wheel parts; it is called 'Steering Limit'; there is also a 'Steering Bias' for ackerman(?) steering, but it is kind of tricky to set up, and not very well implemented.  Tracks -- you can decrease motor torque for the same effect.  Track/tank steering not quite finished...will likely be seeing a few changes/improvements to it in the next few releases, including inside/outside differentials and augmenting motor steering with brakes at higher speeds.  (might need to click the 'show wheel controls' button for it all to show up)

Steering in general -- wheel parts currently have... too much steering authority.  Something like 40 degrees on most wheels, was a placeholder value that got built into all the configs.  Certainly could be toned down a bit for particular wheels;  I'm open to suggestions if you have any.

 

15 hours ago, Haifi said:

Thank you so much for finding the problem, at times I was thinking I was seeing ghosts...

If its a "stock" problem there's nothing to be done about it. To know a workaround is all that I need.

Again, thank you, and thank you for not writing me off.

No worries, and you're welcome   Sorry I couldn't provide a more direct solution, but hopefully the information provided and workarounds listed will allow you to make good use of the wheels even with the engine limitations.

As long as someone is willing to provide the information that I need to do proper investigation into a problem in a timely fashion, I will do whatever I can to figure it out.  I'm not a huge fan of mysteries, and even if I can't fix a problem, I still like to know what is going on with it.

[V8jester]

@Shadowmage I may have not explained that very well. The current steering limit slider. Limits the angle of the steering. But when using a keyboard (which is all I have) The wheels will instantly go to max angles when turning. Makes for flippy-floppy issues at any kind of a reasonable speed. The old KF implemented a system of gradually limiting the speed of the steering as well as the available angle of steer the faster you went. Meaning as you speed up, your turning ability is very diminished. But you wouldn't flip your rovers. I would say this is my single "complaint" of the new system is an absence of a steering limiting system such as this. 

[0111narwhalz]

I think there is a steering-curve thing. Look at the patch notes of KSPWheel's latest version:

Quote

• CHANGE - Steering curve uses vessel velocity rather than wheel velocity (slip no longer reduces steering)

I take this to mean that there is a steering curve based on velocity.