Landing legs in 1.1

[Bonus Eventus]

I've been trying out different settings, but I can't seem to get ModuleLight working with the landing legs even though the landing gear use the same modules. Really wanted to get this working, didn't have my hopes up. Still relying on animateGeneric in the meantime.

On the spring/dampening issue, I did some test with the stock legs. I attached 6 of the t2 struts to a s3 large tank and on physics load they exploded. It makes me think that some of this "voodoo" is caused because of the way physx 3.0 handles transferring forces through joints. 

[nli2work]

@Bonus Eventus have you checked the slave module index setting in ModuleWheelDeployment? slaveModules = should match the index # of ModuleLight.

made some very coarse data points for suspension vs damper ratios
Using Stayputnik probe core and Medium S3 fuel tank, 4x demo wheels I made before. This puts roughly 10t of load on each wheel. I recorded each run with different spring and damper settings. Each run starts with few switches between space center and the vessel on launch pad to see how the vessel unpacks. Then turning gravity on/off to drop the vessel from roughly the same height to see how the suspension behaved. 

total of 16 recordings with springRatios of 2, 16, 32, 128; and damper ratios of 1, 4, 16, 64; all other wheel settings remains the same through out.

152mb; full test settings in the archive file.
https://www.dropbox.com/s/dlycxpg65iqrgfa/SpringvsDamperRatios.zip?dl=0

[TiktaalikDreaming]

6 hours ago, nli2work said:

made some very coarse data points for suspension vs damper ratios
Using Stayputnik probe core and Medium S3 fuel tank, 4x demo wheels I made before. This puts roughly 10t of load on each wheel. I recorded each run with different spring and damper settings. Each run starts with few switches between space center and the vessel on launch pad to see how the vessel unpacks. Then turning gravity on/off to drop the vessel from roughly the same height to see how the suspension behaved. 

total of 16 recordings with springRatios of 2, 16, 32, 128; and damper ratios of 1, 4, 16, 64; all other wheel settings remains the same through out.

152mb; full test settings in the archive file.
https://www.dropbox.com/s/dlycxpg65iqrgfa/SpringvsDamperRatios.zip?dl=0

Sounds like pretty good testing.  I'll see if I can take a look after work.

.

.

.

and looked at;

Pretty solid science! there.  I like 16G or 2C as closest to perfect damping (slight overshoot but then returns without passing the equilibrium again).  2E & G look overdamped to me, and the rest seem underdamped.  All my stuff then seem dramatically underdamped, as my settings are wildly lower on damping.

As to spring constant, to me, it doesn't look linear, but I suspect that's just how it looks.  And looks are deceiving.  But it's definitely not standard SI units for spring rates, because that would put equilibrium for 10t per wheel at about .8m on the stiffest setting.  Which is closer to what the 16 looks to get to.  Maybe it's N/cm instead of N/mm.  Or, adjusted in some mysterious way as suggested in devnotes.  Maybe the stiffness is multiplied by tonnage.  But that would mean you should always get the same deflection for the same legs regardless of craft size, which seems optimistic.

 

Edited April 11, 2016 by TiktaalikDreaming
looked at testing

[Bonus Eventus]

@nli2work thanks man you were totally right, and in fact I was able to understand another error I kept getting because of it. The error was the result of baseModuleIndex=0 but ModuleWheelBase positioned at index 1. As a result I now believe that ModuleWheelBase wasn't loading at all before but still played the animation. It was if All wheel modules just became a ModuleAnimateGeneric, and since I have other colliders in the model, the legs still worked. 

On another note I discovered that groundHeightOffset = (whatever height is added to the part its attached to once extended), so if your legs keep spawning partially in the ground, setting this correctly will most likely solve that, otherwise you'll get launched 100 meters into the air from the collision of the ground against the feet of your landing leg, haha

Edited April 11, 2016 by Bonus Eventus

[NecroBones]

7 hours ago, nli2work said:

total of 16 recordings with springRatios of 2, 16, 32, 128; and damper ratios of 1, 4, 16, 64; all other wheel settings remains the same through out.

152mb; full test settings in the archive file.
https://www.dropbox.com/s/dlycxpg65iqrgfa/SpringvsDamperRatios.zip?dl=0

 

Thanks for doing the science on this! I'll take a look, it may help quite a bit.

 

3 hours ago, Bonus Eventus said:

On another note I discovered that groundHeightOffset = (whatever height is added to the part its attached to once extended), so if your legs keep spawning partially in the ground, setting this correctly will most likely solve that, otherwise you'll get launched 100 meters into the air from the collision of the ground against the feet of your landing leg, haha

 

That makes a lot of sense, actually-- helping determine spawn and unpack heights. I'll have to go back and set these values to something realistic for my legs, since most of them right no just have a "1.0" or something as a placeholder.

 

I wonder if it's height added to the parent, or rather height added to the leg by the suspension? It didn't seem to match the suspension heights in the stock legs though. So it could be overall.

 

[nli2work]

I'm thinkin of doing a see through lander leg too... with more visible marker for the suspension to better see the effects of different loads. There's also a "boostRatio" setting in ModuleSuspension, default value is 0.75, it seems to be a simple multiplier to Spring ratio. Setting it low, 0.1~0.5, appears to reduce spring rate; setting it higher, 1+, increases spring rate and on the test vessel consistently launched it into the air on unpack

[Bonus Eventus]

3 hours ago, NecroBones said:

 

Thanks for doing the science on this! I'll take a look, it may help quite a bit.

 

 

That makes a lot of sense, actually-- helping determine spawn and unpack heights. I'll have to go back and set these values to something realistic for my legs, since most of them right no just have a "1.0" or something as a placeholder.

 

I wonder if it's height added to the parent, or rather height added to the leg by the suspension? It didn't seem to match the suspension heights in the stock legs though. So it could be overall.

 

My experience pointed to it being the height from ground to attach node when extended, but this could be do to orientation. For instance, in my case 5m seemed to work and the height from ground to attach node is 4.685 m. But, my leg is oriented such that the attach node lines up to the origin so it could be the measurement from the ground to attach node (likely) or ground to origin.

2 hours ago, nli2work said:

I'm thinkin of doing a see through lander leg too... with more visible marker for the suspension to better see the effects of different loads. There's also a "boostRatio" setting in ModuleSuspension, default value is 0.75, it seems to be a simple multiplier to Spring ratio. Setting it low, 0.1~0.5, appears to reduce spring rate; setting it higher, 1+, increases spring rate and on the test vessel consistently launched it into the air on unpack

I agree, I set this very low after many km distance launches, haha. After seeing your transparent rover wheels and module linked mesh test rig, I was thinking of doing the same thing here, but you beat me to  thanks for the test logs I love Sarbian's tool!

Edited April 11, 2016 by Bonus Eventus

[lo-fi]

15 hours ago, TiktaalikDreaming said:

Or, adjusted in some mysterious way as suggested in devnotes

Looking over Eddy's sales pitch, I'm inclined to think it's mostly a wrapper which simplifies the settings somewhat (or certainly the bit Squad are using). The spring rates and damper rates, if you take them as arbitrary units, are very different between U4 and U5 to get the same result, so take from that what you will. I've been testing in U5 directly, though. Tempted to pay the £60 for VP just to see the source... I know it won't be exactly what's gone into KSP, but it might well bring some insight. Lot of wonga just to satisfy curiosity, though.

 

12 hours ago, Bonus Eventus said:

On another note I discovered that groundHeightOffset = (whatever height is added to the part its attached to once extended), so if your legs keep spawning partially in the ground, setting this correctly will most likely solve that, otherwise you'll get launched 100 meters into the air from the collision of the ground against the feet of your landing leg, haha

Interesting information. Seems they've abandoned the "bounds" helper object you used to see in wheels and legs.

[Shadowmage]

18 hours ago, lo-fi said:

Looking over Eddy's sales pitch, I'm inclined to think it's mostly a wrapper which simplifies the settings somewhat (or certainly the bit Squad are using). The spring rates and damper rates, if you take them as arbitrary units, are very different between U4 and U5 to get the same result, so take from that what you will. I've been testing in U5 directly, though. Tempted to pay the £60 for VP just to see the source... I know it won't be exactly what's gone into KSP, but it might well bring some insight. Lot of wonga just to satisfy curiosity, though.

 

Interesting information. Seems they've abandoned the "bounds" helper object you used to see in wheels and legs.

From some brief investigation, yes, the EVP stuff just wraps around the standard U5 WheelCollider component while allowing for a more consistent (and dynamic?) way to setup the collider settings.  If you examine the hierarchy of a wheel/leg part, they still use the standard WheelCollider component (along with all of the EVP-derived KSP components to make them work).

So... one way or another it should be possible to code a custom wheel module that allows for multi-wheel and multi-leg support.

I have one ... semi-working?... custom module with a test part that uses 6 wheel colliders in a dual-track type setup, each with their own independent suspension and steering setups.  Sadly as soon as I attempt to use that -same- model and module in another part, things stop working.  Still working on figuring things out

Yes, it seems the biggest changes are that the spring and damper values are vastly different and that both rigidbody and wheel-collider mass influence how the colliders perform.  One other change is that the wheel colliders have to be completely removed when the wheel is in the 'retracted' or inactive states as there is a bug in Unity 5.2.x where 'disabled' wheel colliders don't actually get disabled or removed from the PhysX end; so I've had to put in some event-handling to remove and re-add the colliders during vessel pack and unpack events.   Haven't made it much past that.... just started working on it all yesterday.

 

Edit:  Hmm.. apparently wheel-collider orientation in the editor/hierarchy matters not; they are oriented according to the rigidbody they are attached to (as per Edy of EVP):
http://forum.unity3d.com/threads/unity-5-wheelcollider-wrong-rotation.349596/#post-2264801

This would explain the majority of the inconsistencies of what I was seeing regarding the (working) wheel model when I was adding it to other parts (as I was rotating the model relative to the rigidbody).

Hmm...going to be inconvenient at the least getting wheel parts working.

Further Edit:  Confirmed that the rotation of the game object that the collider is attached to has zero bearing on the colliders orientation.  Setup a basic Unity5 test vehicle;  add a rigidbody, main box body, and some wheel colliders.  Rotate the wheel collider transform... and watch the rendered wheel collider transform do... nothing.

Great....  How am I supposed to add landing-gear/wheels to a wing now (e.g. a shuttle wing with integrated landing gear)?  Wings need a certain orientation due to the aero calculation setup, which is different than is needed for the rigidbody setup for the wheels.  This likely won't effect most modders / parts... but I have a lot of integrated parts... and this absolutely breaks them.  (Not actually expecting answers.... just expressing my dismay).

And to be clear, this is a UNITY problem, not KSP; there is nothing the KSP devs / SQUAD could do to solve this even if they wanted to.  The more I mess with these things (wheel colliders), the more I agree that the U5 upgrade absolutely broke them for anything but very simplified cases.

Edited April 12, 2016 by Shadowmage

[davidy12]

The (LT-1) legs keep causing my craft to slide, even on the slightest of slopes

[nli2work]

I'm making magical launch legs now... kinda frustrating. Leg either clips through ground, or launch the vessel up several km.

how do you guys have leg's wheelcollider oriented? like LT-1/2 or LT-5? LT1/2 rotated the entire leg to keep the wheelCollider is oriented to world XYZ... LT-5 has rotated wheelCollider to match the piston's orientation when deployed. 

Edited April 12, 2016 by nli2work

[NecroBones]

 

3 minutes ago, nli2work said:

I'm making magical launch legs now... kinda frustrating. Leg either clips through ground, or launch the vessel up several km.

how do you guys have leg's wheelcollider oriented? like LT-1/2 or LT-5? LT1/2 rotated the entire leg to keep the wheelCollider is oriented to world XYZ... LT-5 has rotated wheelCollider to match the piston's orientation when deployed. 

 

When I started making legs, I followed the existing tutorials here on the forum, and still it took me weeks before I had one working. I'd work on it a little, then give up for a while, come back to it, etc. So this sort of frustration I think just goes hand-in-hand with making legs.   (what finally fixed everything for me was to get the hierarchy exactly right in Blender, and not break the prefab status in Unity).

 

I'll give a little more detail than what you asked for, to help make everything make sense for other readers:

 

The tutorials basically said to orient the wheelCollder "vertically", as a child of the "piston holder", parallel in the hierarchy to the actual piston that moves up and down, and oriented through the piston such that the suspension-line just barely protrudes out of the bottom of the foot. Now that the system has changed, this is where we put the "DeployTarget" transform instead. I've been pre-positioning the wheelCollider so that it already is in this position pre-deployment, just for my own sanity.

 

In practice, the coordinate space of the parent object (the piston holder) in my legs ends up being oriented whichever way it wants, sometimes with the "X" going vertically, based on how I animated the deployment. But the wheel collider's transform is oriented so that Y+ goes upward through the piston holder, and Y- down toward the foot.

 

 

[nli2work]

I'm also seeing the wheelCollider is not destroyed on retraction like I see with the deployable wheel I made... maybe that's just side effect of me setting up the leg wrong. 

[TiktaalikDreaming]

1 hour ago, NecroBones said:

 

 

When I started making legs, I followed the existing tutorials here on the forum, and still it took me weeks before I had one working. I'd work on it a little, then give up for a while, come back to it, etc. So this sort of frustration I think just goes hand-in-hand with making legs.   (what finally fixed everything for me was to get the hierarchy exactly right in Blender, and not break the prefab status in Unity).

 

I'll give a little more detail than what you asked for, to help make everything make sense for other readers:

 

The tutorials basically said to orient the wheelCollder "vertically", as a child of the "piston holder", parallel in the hierarchy to the actual piston that moves up and down, and oriented through the piston such that the suspension-line just barely protrudes out of the bottom of the foot. Now that the system has changed, this is where we put the "DeployTarget" transform instead. I've been pre-positioning the wheelCollider so that it already is in this position pre-deployment, just for my own sanity.

 

In practice, the coordinate space of the parent object (the piston holder) in my legs ends up being oriented whichever way it wants, sometimes with the "X" going vertically, based on how I animated the deployment. But the wheel collider's transform is oriented so that Y+ goes upward through the piston holder, and Y- down toward the foot.

 

 

Totally concur that legs have always been crazy complex to get right.  I think I burnt a good few weeks (at my usual 30-60 min per day) trying to get my first leg working, and it still makes the launch pad explode.

I haven't reoriented my legs, but my end position for the piston/suspension is close to vertical, so maybe it's acting vertically, and I haven't noticed (esp as I'm having trouble getting more than a cm of travel in the suspension).  My wheelCollider is +Y for compressed, -Y towards ground.  And now that I check in Unity, it's not just approximately up-down, it's exactly in line with the global axis.

[nli2work]

LOL... been replying in the wrong thread... 
apparently suspensionRatio and damperRatio are multipliers to the wheelCollider settings exported from Unity. hm.... explains why my legs were throwing me up several km. and apparently only for LEG and not for MOTORIZED? cna't reproduce it on the wheels.

WheelCollider doesn't get turned off... so leg works even when retracted. LOL 

I been trying to get something that works like Squad's landing struts. They're all at an angle to the ground once deployed. 

*FACEPALM*... forgot to change the wheelCollider name in the config. I'm such a noob

alright... things are falling into place now more or less. just have to figure out what's making everything float up in the air.

Edited April 13, 2016 by nli2work

[NecroBones]

1 hour ago, TiktaalikDreaming said:

My wheelCollider is +Y for compressed, -Y towards ground.  And now that I check in Unity, it's not just approximately up-down, it's exactly in line with the global axis.

 

Is the arrangement in the screenshot working? One thing the tutorials explained, and I replicated in my legs, was to put the wheel collider up into the "piston holder", and set its radius so that the circular portion only can touch the ground if the suspension is completely compressed, if ever. The suspension "line" is what gives you the springiness, and actually touches the ground normally. Take a look at the MRS leg (the one that works great):

 

 

The circle is positioned to catch the foot if it comes all the way up, and the suspension line just barely sticks out of the center of the foot.

 

1 hour ago, nli2work said:

apparently suspensionRatio and damperRatio are multipliers to the wheelCollider settings exported from Unity. hm.... explains why my legs were throwing me up several km.

 

What!?!!? That explains a lot, and probably is the source of ALL of the problems on my other legs. Holy smokes.  I need to change some settings now. Thanks for finding this!

 

[TiktaalikDreaming]

1 minute ago, NecroBones said:

 

Is the arrangement in the screenshot working? One thing the tutorials explained, and I replicated in my legs, was to put the wheel collider up into the "piston holder", and set its radius so that the circular portion only can touch the ground if the suspension is completely compressed, if ever. The suspension "line" is what gives you the springiness, and actually touches the ground normally. Take a look at the MRS leg (the one that works great):

 

Yes, sorry, that's not fully extended.  The lower arm swings further and comes back slightly.  I couldn't remember how many frames my animation was so that's somewhere in the middle of the deploy animation.

More clarity (I added the undeployed as a demonstration of why I needed to not show it.);

And..... I think I'll be setting my Unity values to 1.000000   :-D

[NecroBones]

2 minutes ago, TiktaalikDreaming said:

Yes, sorry, that's not fully extended. 

 

LOL, my bad. Well, maybe it'll help other readers in any case.

 

[TiktaalikDreaming]

1 hour ago, nli2work said:

*FACEPALM*... forgot to change the wheelCollider name in the config. I'm such a noob

When trying to get my first leg working I wasted a couple of weeks because I didn't change the mesh name in the config.  It kinda almost sorta worked real funny.  Drove me mad and had me looking at all the wrong things.  I feel the pain.  :-)

And while being such a noob, you're still rapidly becoming the world expert in KSP wheel colliders outside Squad.  ;-)

[NecroBones]

11 minutes ago, TiktaalikDreaming said:

And..... I think I'll be setting my Unity values to 1.000000   :-D

 

I just set them to 1.0 in Unity, and put some reasonably low numbers in the CFG. And guess what? Feet touching the ground (instead of floating)!

 

[nli2work]

it seems even suspensionDistance is multiplier... but it seems to only apply if you set the type to LEG instead of MOTORIZED

nope... not a multiplier

Edited April 13, 2016 by nli2work

[NecroBones]

1 hour ago, NecroBones said:

 

I just set them to 1.0 in Unity, and put some reasonably low numbers in the CFG. And guess what? Feet touching the ground (instead of floating)!

 

 

OK, so it fixed THAT set of legs. I tried it out on the bigger set, and they still float. Tried setting the springRatio even lower in the CFG, and I crashed KSP. Lovely.

 

[NecroBones]

21 hours ago, NecroBones said:

Now that the system has changed, this is where we put the "DeployTarget" transform instead. I've been pre-positioning the wheelCollider so that it already is in this position pre-deployment, just for my own sanity.

 

 

So it turns out this is part above is a really bad idea. It looks like it contributes to the leg's "retracted" state's bounding box, and makes the leg stick out past heat shields and the like, for purposes of aerodynamic/thermal occlusion. Positioning the wheel collider at the part's origin seems to fix this (obviously relying on the "deploy target" transform for it to be positioned correctly for suspension).

[nli2work]

22 minutes ago, NecroBones said:

 

So it turns out this is part above is a really bad idea. It looks like it contributes to the leg's "retracted" state's bounding box, and makes the leg stick out past heat shields and the like, for purposes of aerodynamic/thermal occlusion. Positioning the wheel collider at the part's origin seems to fix this (obviously relying on the "deploy target" transform for it to be positioned correctly for suspension).

try a parent object that moves both deployTgt and wheelCollider. doesn't seem to be any restriction on moving the wheelCollider, as long as it's not part of the same branch as suspension transform.

[nli2work]

alright... have to do it the hard way. The only value I changed is SuspensionDistance, in 0.25 increments. SuspensionOffset is same value as Distance but negative just to keep things consistent, it doesn't affect the actual suspensionHeight, only moves suspensionTransform up/down the suspensionLine. Yellow disc is center of WheelCollider

The leg arms are all 1m long; each tick on the green ruler is 0.2m. Red line marks bottom of Leg Foot, it's floating quite a lot with higher suspensionDistance. I'm not seeing any kind of pattern here... where, and in what direction, is suspensionDistance measured from??

Edited April 13, 2016 by nli2work