LY-35 medium landing gears braking either too much or not enough.

[Kerburettor]

Hi,

I'm working on a plane and want to adjust braking strength so it stops before the end of the runway, but not too abruptly since this locks up the rear wheels, tends to cause sideslip which usually ends with a rapid unplanned disassembly. However, I noticed that anything short of 100% braking strength (including 95%) is not sufficient: the plane is stable upon landing but continues to ride along the runway until it just runs out of braking distance. If I suddenly set braking strength to 100% though, the rear wheels lock up instantly and if my speed is roughly south of 80 m/s without any sideslip, all is fine even though the plane and its occupants are a little bit shaken. Otherwise, I end up tumbling and exploding depending on how much the rear landing wheels are separated.

Is this a known bug in KSP or is this expected behavior? Is there a way to modify the config files to mitigate this problem? Also I have to let you know that I'm playing a modded game but the only mod that would potentially act on braking strength is tweakScale since the landing gears have been resized.  I didn't write this thread in the modding section of the forum though because I assume mods are irrelevant: This also happened on an non-modded aircraft, using only stock parts and resources.

Potentially important info:

- I use FAR and Kerbal Joint Reinforcement
- Friction control is set to 5.0 for the rear wheels and 0.2 for the front landing gear.
- braking strength is set to 95% for the rear wheels and 15% for the front wheels (using 55% for the front wheels for instance doesn't seem to improve braking performance).
- I use a plethora of mods but I don't think they influence braking behavior since I also had the same issue with unscaled landing gear installed on a lighter and fully-stock spaceplane. Other quality-of-life mods include visual mods such as EVE and Scatterer, others like Physics Range Extender (which is deactivated right now) and lots of parts mods.

 

TL;DR: LY-35 brakes not enough if Brakes < 100% and too much if Brakes >= 100%

[Caerfinon]

59 minutes ago, Kerburettor said:

TL;DR: LY-35 brakes not enough if Brakes < 100% and too much if Brakes >= 100%

I override the auto friction setting and adjust the rear wheels to a setting between 2.4 and 3.0 with brakes at 80-100%. For front wheels I use 1.5 friction and 60-80% brakes landing speeds 85-100 m/s depending on the aircraft. For larger planes I also use air-braking parts and reverse thrust engines tied into the brake action group. I am not using FAR however.

[fourfa]

You’re definitely right that the landing gear settings are very tweaky, sensitive to small changes, and defaults seem not to work very well. The settings you’re using seem like they should be OK to me, unless perhaps you’ve got a very large craft and the gear are just overloaded. 

My default settings are front friction at 2.0, brakes at 50% - rear friction at 4.0, brakes at 95% - and this works for me 99% of the time.  Also rear brakes very close behind center of mass for easy rotation at launch, and for that matter a center of mass that barely moves as you burn propellant - together this means the main (rear) gear take almost all the load. 

If those settings don’t work, next thing is to disable FAR and see if anything changes. Does it nerf brakes to be more realistic?

[Kerburettor]

@Caerfinon : Will test what you suggest. It makes sense that more friction on the front landing gear will help dissipate more energy. Until now, I was a bit reluctant to do so because my aircraft tend to engage in side to side oscillations during take off.

Edited January 15, 2021 by Kerburettor

[Kerburettor]

@fourfa I tried what was suggested by both of you, to no avail. Well, it does look like the aircraft doesn't decelerate that much as long as it remains stable, but having a high amount of friction on the front gear causes oversteer even when friction is more pronounced on the rear landing gears:

 

[Caerfinon]

@Kerburettor Can you upload a craft file of your aircraft? I'd be happy to test it out in my lab game.

[Kerburettor]

Sure! Here it is: https://kerbalx.com/Kerburettor/test_braking

FAR is listed in the mods required to run this thing but I think you can safely disregard that.

[fourfa]

OK, a few issues to point out.  You're severely lacking in control authority.  No ailerons for roll control, the almost-vertical stabilizers are fine for yaw but very, very limited for the most important pitch control.  Rear landing gear are too far forward and front gear too far back, so there's little passive directional stability on the ground.  Insufficient intake air means the twin engines provide asymmetric thrust at take-off - and there's little way for the plane to counter it (I think this is where the oversteer comes from).  You're carrying oxidizer in the rear-most section, which is just dead mass here.  Main wings are too far back, making it want to nosedive very hard. 

To make it flyable I added wingtip ailerons, changed the tailfin angle to 90° apart from each other and moved them backward a few notches, moved the rear gear back and front gear forward, and added 4 of the same intakes (so 6 total).  Moved the main wing forward (and main gear staying just behind the CoM).     Drained oxidizer.

But still... you're right that the braking power seems minimal.  Partly it's a somewhat heavy craft for the power of the two Panther engines in dry mode - so by the time you get up to speed there's not much runway left to brake to a stop again (as you show in your video).  Usually with Panthers you want to launch in afterburner mode (switching with action groups when you want fuel economy).  That gets you up to speed quickly, leaving more runway left over if you change your mind.  

With those changes It flies nicely, extremely maneuverable, comes to a stop using about a quarter of the runway when touching down at ~70m/s.

PS - I flew it in stock, so the change in main wing position I describe might not work or be needed in FAR.  Same with the intakes.

Edited January 15, 2021 by fourfa

[Kerburettor]

Haha thanks for this very in-depth performance review but I just wanted to test braking distance which is why I never bothered to make the airplane flyable. This serves as a mockup for three other serious (means flyable) aircraft I'm working on at the moment.   

My only priority here was to build this testbench so it reaches a velocity of roughly 100 m/s close to the mid section of the runway so I can verify whether or not it manages to stop before the end of the runway. That's what I'm going for. But you're right, the intakes are too small which is not ideal for speed buildup. I was just too lazy to build a better aircraft

But what you're telling me about your modified version coming to a stop using only 1/4th of the runway is taking my undivided attention. Mind to share a craft file so I can test it this time?

[vv3k70r]

3 hours ago, Kerburettor said:

Is this a known bug in KSP or is this expected behavior?

No bug - corect behaviour.

Problem is not in the wheels. Asign a key to inverted deployment so extended control surfaces press Your plan to the ground during breaking and in such conditions You can apply lot of breaking force at back wheels (do not forget to exclude them from steering).

Wheels on planes are so tiny as they can be to be light. Suspension on plane is as powerful that can be lightweight. Planes do not drive on wheels, they fly. Most powerful breaking part in Your plane are not wheels but aerodynamics.

And You can reverese wheesle if You are using wheesley. Assign a key.

 

27 minutes ago, Kerburettor said:

My only priority here was to build this testbench so it reaches a velocity of roughly 100 m/s close to the mid section of the runway so I can verify whether or not it manages to stop before the end of the runway.

Wheels handle around 80m/s load. No more. If they are not breaking on 100m/s You are airborne.

28 minutes ago, Kerburettor said:

I was just too lazy to build a better aircraft

So You know who is to blame!

28 minutes ago, Kerburettor said:

But what you're telling me about your modified version coming to a stop using only 1/4th of the runway is taking my undivided attention. Mind to share a craft file so I can test it this time?

This one can stop just after touchdown:

https://steamcommunity.com/sharedfiles/filedetails/?id=2265508294

And start on very short runaway.

Normaly we dont do with real airplanes because stress on frame would be horrible (experience for crew with such negative G too) but in KSP there are no such issues.

[Caerfinon]

So I modified some things;

• Not enough air intakes so engines flamed out on launch causing issues
• replaced you wheels with versions that didn't have the spring and damper settings
• added control surfaces and canards and modifies the pitch roll and yaw settings of them
• moved your front wheel forward a little

Flew it round my test system and landed at KSC on the brakes settings you see in the pic. was a little rough. needs more tweaking, but it didn't crash.

 

 

[Kerburettor]

@vv3k70r

That's a very insightful answer!

I have been using flaps until recently to provide more lift during descent but I've never tested them as a braking apparatus on the runway (after touchdown). What's really been bugging me these past few weeks is that I can't make my aircraft nose up after touching down on the rear landing gears so as to generate more drag in an attempt to significantly dissipate kinetic energy before the front wheels can touch the ground. You know, that's how landing is usually performed in real life.

Modelling aerodynamics with FAR is great for such things but it's also a pain in the rear-end to make everything work as intended since I'm trying to recreate fictional planes and they often don't fly so well and don't behave as smoothly as they do with stock aerodynamics. Successfully . Anyway, I thought I would've gotten more braking power from the wheels but apparently I shouldn't expect to. This is great to know and in the meantime I found a few other threads that mention the same issue, such as this one for instance:

So yeah, the main takeaway is that I shouldn't rely on landing gears to absorb most of the aircraft velocity.

[Kerburettor]

I did two other tests. I used the same aircraft as the one I shared on KerbalX for reproductibility reasons (even though one engine flames out which causes the aircraft to veer at the start) but this time tested it using a fully-stock game: I deleted all mods and dependencies in another instance of the game using Ckan.

The aircraft wobbles a little bit during the braking phase but manages to travel the entire distance without tumbling sideways. Again, braking is not very powerful when rear landing gears are set to 95% strength and it takes quite a long distance for the plane to come to a stop.

I ran the test one last time by increasing braking strength to 100%, and got this:

This, to me, shows that there's something wrong about the braking curve for this particular landing gear in KSP. But I can't believe that I'm the first person to notice such a peculiar behavior. There has to be another topic on the exact same problem (i.e. transitioning from 95% to 100% causes wheel lock-up)

 

EDIT:

@Caerfinon

Thanks for testing! I see that both braking strength and friction are fairly close between the rear and front gears. I usually opt to have wayyyy more friction applied to the rear wheels so as to minimize the risk for sideslip-induced yaw instabilities during takeoff. But this only means I've got to modify the aerodynamics, not the landing gear

I also tried setting both spring strength and damping to auto, but this only made the plane bounce a bit more, which is not ideal. I don't really know what to put so whenever I don't want a yaw or roll-unstable craft (or on the verge of instability as I like to put it) to start entering an amplification loop, I increase spring strength and reduce damping a little bit to prevent the springs from bouncing up and down too much, while allowing them to slightly bounce otherwise the mass-spring-damper system becomes too slow and doesn't respond well to sudden accelerations. To me, the holy Grail would be figuring out how to get this to work on nearly any airplane:

https://thumbs.gfycat.com/HatefulLankyAmericantoad-mobile.mp4

and not like this:

or this:

(see landing at the end)

Edited January 16, 2021 by Kerburettor

[vv3k70r]

2 hours ago, Kerburettor said:

I have been using flaps until recently to provide more lift during descent but I've never tested them as a braking apparatus on the runway (after touchdown).

Sport cars use "wing" this to push against ground. Because phy in KSP is as it is I'm using same solution for faster taxi with airplanes.

But because I'm terrible pilot (if I land on airstrip it is just an incident) I'm using planes with big wings that are easy to take off and land, since I added ground effect mod forcing them to land become an issue.

[Kerburettor]

I'm aware of this ground effect mod, but it didn't exist back in the day, or at least not when Paolo Incarnation devised his adjustable landing gears, so I think he managed to get his smooth landing either with stock aerodynamics or with FAR, or simply because the collision model for these new landing gears was much better than Unity's. I find that placing wheels right beneath the CoM should work best to get the same result, because if the CoM and the contact point between the wheels and the ground aren't vertically aligned with each other, the weight of the aircraft creates torque around the contact point. But if it was that easy, I think I would've achieved the same kind of landing already.

One additional difficulty is that my airplanes have a high stall velocity (north of 100 m/s) which means that I'm coming in too fast. This causes quite a lot of stress on the wheels which is not ideal. Also, due to this important stall speed, it is difficult to achieve a vertical velocity close to 1 m/s when approaching the airstrip. And there are many constraints imposed by design such as the position of the CoL which dictates where the CoM has to be for dynamic stability, which in turn dictates where the landing gears should be. Anyway, Imma keep trying until I come close!

Edited January 16, 2021 by Kerburettor

[Kerburettor]

Okay I think I've got something:

It's not perfect but the rear landing gear doesn't bounce off straight off the bat. What worries me is the distance required to stop the aircraft altogether. It takes almost the entire runway for it to come to a still. I have only one option at this point, which is to find a way to decrease stall speed without tinkering too much with the aircraft's design: this is a re-creation so it needs to be esthetically faithful to the original model while keeping sideslip/pitching/yaw stability (which I worked way too much to get).

[Caerfinon]

9 minutes ago, Kerburettor said:

find a way to decrease stall speed without tinkering too much with the aircraft's design

You could "clip" wings in the identical position of existing wings the look of the aircraft would be the same but the lift would be increased.  (not that I've ever done something like "that" ).  Requires some fiddling in the SPH but it can be done.

[Kerburettor]

I doubt clipping would work in this specific case (except if the only goal is to add mass) because I'm using FAR. Basically FAR approximates the shape of the aircraft using voxels, calculating the resulting lift and drag based on the exposed shape of the geometry, its curvature, etc. Stock geometry assumes that each part has its own performance and as far as I know adds them all up. Sometimes, clipping can be used as an exploit to get more or less drag resulting in some weird contraptions. You don't really get that with FAR.

By the way, said voxels seem to be calculated once and for all, regardless of any geometry transformation along the way. This is actually pretty funny because I thought voxels would move with the geometry but it turns out that they stayed where they were, which means that drag should be no different between a retracted vs. a deployed wing setup regarding drag, althought shape shifting moves the CoM forward or backwards, which is rather interesting. I'll show you tomorrow but now is sleeping time.

[steve_v]

12 minutes ago, Kerburettor said:

By the way, said voxels seem to be calculated once and for all, regardless of any geometry transformation along the way.

Voxels are recalculated by geometry changes that FAR is aware of... Which doesn't include the BG robotics, because Squad didn't include an event that FAR can use to detect that something has moved. IIRC the current workaround is to toggle the lights after moving robotic parts.