1.1 wheels:

[Alshain]

Just now, Bedwyr said:

Nose looks like. I could be wrong. The wheelpants fairing is supposed to trail behind.

Is it?  I always thought that would be backward, but I can try it the other way round.

[Bedwyr]

Yeah. The streamlining is suppose to be like a teardrop with the spiky, pointy end facing aft.

[Alshain]

Well, flipping it around made no difference anyway.

[Bedwyr]

Ok, no worries.

[Bedwyr]

Well I hate Photobucket, but it's what I've got at the moment. Two pictures:

Picture of forces and parts used. I mucked with the angles of incidence for horizontal stabilizers and wings to adjust the CL so it's halfway between the center of the CM marker and its edge. I've usually found that to be pretty well behaved on takeoff; I don't have to rotate super hard to get up and flying. The center of thrust is at the same height and through the CM. I might mess with the engines later for looks, but it's fine.

 

So testing the gear placement. What I did was move the gear up and down the fuselage by very small increments and then nudged the nose gear up and down to match. At any reasonable point below halfway (that would be where the word "flammable" is on the fuel tank fuselage), the aircraft becomes unstable on takeoff, exhibiting that roll oscillating moment. I found that the on snap-to locations (pressing C) I could adjust at what speed the oscillations begin. One notch down exhibited unstable oscillations at 40+ m/s, two notches down occurred at 30+ notches. Each time I rotate the gear so that they were properly vertical and met the ground flush. No canting in or out like a low-rider. The only time the plane became stable was with the gear mounted directly to the side, no rotations. That makes it nearly impossible to rotate the plane on takeoff; the tail will drag and crash the plane.

One thought I had was to take the position of the gear where it's unstable at 40+ knots and attach it to the cubic octagonal strut like this:

 

Well guess what? It was reasonably stable through the takeoff roll. Again, in the picture dead sideways is level with that flammable label. So it appears that the instability is purely a function of gear width. The gear need to be located at least at a width normally seen at the sideways attach point. Using the cube strut is an ok fudge for testing, but not for a normal career mode playthrough. If the gear need to be attached at the sides, they also need to keep that fuselage high enough not to have a tail strike on rotation.

Layperson's recommendation: Increase the size and the stiffness of the L01 gear so that it gives better ground clearance when attached to a 1.5m fuselage at the sides and might remain stable at some reasonable location just below the sides. Adjust size and stiffness of the nose gear so that a normally designed airplane at early career mode playthroughs will rest with the fuselage perfectly level.

 

Edit: sorry for the second picture size. Photobucket insists on not replacing the larger image with the scaled smaller image like it's supposed to.

Edited April 30, 2016 by Bedwyr

[Alshain]

4 minutes ago, Bedwyr said:

Well I hate Photobucket

Imgur.  Not only is in generally better but you can embed entire photo albums on the forum using the Imgur button at the end of the toolbar.

[Bedwyr]

1 minute ago, Alshain said:

Imgur.  Not only is in generally better but you can embed entire photo albums on the forum using the Imgur button at the end of the toolbar.

I'll get around to it at some point.

[RocketBlam]

On 4/28/2016 at 1:32 PM, Renegrade said:

Y'know, I experienced something kinda weird like that the other day.  I was landing on Minmus with a tripod craft, and it just refused to stay on it's gear.  I kept on having to correct it.  It wasn't trim or anything either (I cleared trim several times, did not help, SAS was off, etc).  Stupid thing just kept on trying to fall over from an almost level surface.  I fought with it for a while, but then it stopped misbehaving of it's own accord and sat normally, and it did not repeat for any of the other landings.

It looked exactly like that too, like as if a gentle wind was slowly pushing it over.

The craft was built around the micro landing strut.

When this happens to me, it's usually because I still have the craft set to turn retrograde.

[Renegrade]

1 hour ago, RocketBlam said:

When this happens to me, it's usually because I still have the craft set to turn retrograde.

I built the craft around an OCTO core (it probably looks like an OCTO2, but that's only because of some cheaty clipping I did to make it into an octagonal thrust plate heh.  I still don't have OCTO2s in that save anyhow, 20% science is deliciously punishing (but also grindy)), and SAS was off as I said in my original post in any case.   I specifically switched back to the craft and ensured that it was off.

[Violent Jeb]

[redacted, done contributing]

Edited August 16, 2016 by Violent Jeb

[Kryten 2X4B 523P]

A couple of observations from my own limited testing. Made a replica of Alshain's plane.

Replacing the fixed landing gear (LY-01) with the steerable landing gear (LY-05, steering turned off) in the same position as the screenshot posted - no rolling or oscillation at all, and veering only starting exhibiting at 100 m/s plus.

The fixed gear also displays some odd attachment behaviour in the SPH when using the move tool - click move tool, click on it and most of the time it snaps to a point in the centre of the part its attached to - I'm wondering if the two issues are related in some way, and that this may would indicate that the problem lies with the LY-01 fixed gear.

Also - the swept wings with control surfaces seem to be "inverted", and act in the same way a tailfin / AV-R8 would in the same position - pointing downwards (which would force the nose down) when using the S key to climb. Replace the swept wings with Wing Connector E with control surfaces and you get "normal" control surface behaviours (they point upwards when S is used to climb). Turn on the aerodynamic indicators to see - the force indicator arrows act in the opposite direction for each wing type.

Combining the two changes and you get a plane that gets off the runway with no issues.

I think in Alshain's test plane the combination of both the LY-01 and the swept wings is causing the problems. Replace the fixed wheels and the oscillation stops but you still get veering at high speed due to the downward pressure on the nosewheel caused by the inverted forces. Change the wings as well and it flies. Move the rear wheels nearer the COM and it pivots nicely for take off as well.

 

update on swept wings - Im not familiar with how the parts are handled, but looking at the parts config & location - the swpt wings in the the "AirplaneFins" folders, rather than the "Wings" folder - not sure if the location of the part files also acts as a "class" modifier somewhere in the code so it treats the swept wings as fins rather than wings. Config looks the same as a wing connector E though, bar the obvious differences in drag / lift / naming.

Edited April 30, 2016 by Kryten 2X4B 523P
Additional info

[Knaapie]

1.1.2 is out, making wheels more adjustable.

According to the previous patch the dynamic instability while standing still had to do with the fact that the landing gear was stiffer than the parts around them. That means that any damping in the suspension would result in a deformation of the craft, creating a momentum that makes the airplane dip down in the opposite side of the COM. Auto struts were applied in 1.1.1, yet imo that should only partially solve the problem. The fact remains that the resulting momentum was/is stronger than the initial momentum, creating dynamic instability. (I should test more to see what is and what was). This would suggest that there is some phantom force, since the landing gear should not only have a spring to soften the landing, it should also dampen the initial force.

edit: Perhaps this phantom force is created due to the fact that the limit of the suspension is reached at every small bump. making the craft flex further while the limit of the suspension is already reached (creating the opposite dip and then the springforce in the suspension is applied to the craft already dipping over.) This Makes me believe we need more damping in the suspension, more force needed to deflect the suspension (spring force) and more stiffness of the rest of the craft (or damping while deforming the craft).

Imo ppl should test these things taking a few things in mind. Our builds are inherently unstable due to game mechanics:

1. Having steering wheels behind the COM creates dynamic instability while "driving". Disable steering there.
2. Our keyboard can only fully turn a wheel while steering, disable steering in the front wheels when you are above a certain velocity. (or from the start when taking off. Control surfaces do enough)

 

edit 2: Yet the problem is..  some solutions, like violent jeb 2 posts up, suggests to do the opposite to solve the problem :/  and oww...  i noticed improvements with a bit of wing AOA as well.. mostly to take off before you crash ^^

 

Discovered a free energy device, this keeps on spinning ^.

e3: tested the same on the launchpad. it didn't move initially, but when a very small spin is induced, the craft starts to wobble clockwise/counter clockwise. Wheel friction doesn't seem to depend on the turning speed of a wheel. these irregular movements should dampen out by wheel friction alone, but they dont. Giving the outward wheel in a turn more friction, should (very) slightly enhance dynamic stability of the craft.

e4: I'm starting to believe that any force put into deformation of a craft is stored as "spring energy" without any losses.. Creating deformation energy losses might help quite a bit

Edited April 30, 2016 by Knaapie

[Kryten 2X4B 523P]

Been playing about with this a bit more (1.1.2) on the fixed landing gear.

Im pretty sure the veering & oscillation is being caused by "toe in / toe out" (basically the fixed wheels are pointing slightly in  / out as opposed to dead ahead) induced after rotation. By eye it looks like everything in line, but its out slightly in the local plane.

Tested by doing this: 

Attached a pair of fixed gear to the underside of  structural fuselage

Rotated in the local plane so they looked straight

Tested - plane oscillated and veered off the runway.

Switched back to SPH, selected part and switched to absolute rotation rather than local. If you switch between these two modes rapidly you can see the wheel is out of alignment slightly. Rotate it straight ahead in absolute and tested again.

and it trundled down the runway with no veering or oscillation.

[MaxPeck]

I spent the better part of last night and this morning reading about Unity, PhysX and the wheel dilemma.  I'll preface this by saying I'm not a game designer, nor am I a professional programmer.  I know this is a wall of text, but I want to save folks from wasting a lot of time working an unsolvable problems.  Here's what I've learned:

This isn't a KSP problem.  It's not a Unity problem or a PhysX problem.  It's an integration problem.  From what I've been reading, virtually no one who uses wheel-based assets in Unity has had any luck getting them to work in U5.  I read stories of people who write driving simulators who are frustrated to the point of losing the capacity to speak (write) coherent English.  I read a rather lengthy outburst from someone who writes vehicle simulations for car manufacturers - who recently updated from U4 to U5 and is so aggravated that he ported his entire project to Unreal Engine rather than lose one more day trying to make the wheels in U5 work.  That says something that a complete engine change was easier than trying to make a module in the existing engine behave.  The funny thing, as I understand it and as noted by some others, is that Unreal and Unity both use PhysX. The conclusions that I read seems to imply that the problem is in how Unity integrates the wheels.  This is coupled with the fact that U5 doesn't treat wheels as wheels, it treats them as a line pointing straight down from the center of the axle to the ground.  So as long as the bottom of your wheel touches a hard surface, you're fine; but if your wheels become angled, or if you encounter sudden terrain, you're screwed.  Think of it as a rolling donut 1m tall - the only part of the donut that counts is the part that exists in a straight line from the center of the mass to the bottom of the donut.  If the donut encounters a 0.25m tall cube, it doesn't climb the cube, it overlaps it until the line touches it, and rather than a gradual increase as you'd see in a real wheel, what you get instead is a momentary jump from 0 to 0.25m.  The physics engine then creates a force change to compensate, and your wheel blasts off.  This is why we're getting dancing and other phantom forces... Unity doesn't handle modular parts well, because the assumption is that wheels will be a fixed part of an asset, not added at runtime in all manner of helter-skelter configurations.  So if your wheels aren't pointing straight down at the hard surface they're sitting on, the physics engine reads it as a collisions and applies force to compensate.  It also explains why people have issues with the fixed nose wheel - if the three parts of your tricycle gear aren't perfectly perpendicular to the runway, one or more of them will generate phantom forces as Unity detects constant collisions with the uneven surface it sees.  So if your aircraft starts with a slight nose-down or nose up cant to it, and you haven't compensated by leveling the wheels, you're either going to bounce like mad or lose steering ability.  This is also going to be a problem with landing - if you don't make a perfect 3-point landing with the wheel lines perpendicular to the runway, Unity is going to see those offset collisions and apply forces to compensate, probable upward and forward, which explains the bouncy landings people are posting all over youtube.

 So the problem is threefold:

1. PhysX changed how wheels work

2. Unity doesn't implement it well

3. KSP uses Unity

No amount of settings changes or .cfg tweaks are going to fix it, kids. This isn't something you can design around.  Until Unity figures out how to make Physx wheels work, or KSP decides to use a different, less problematic engine, this is what we're stuck with.  KSP will forever be a game that almost works because the engine itself is the problem, not KSP.  KSP is brilliant, but it's just held back by the Unity-PhysX problem.

'Fraid KSP is going on the shelf for me for a while until they get this sorted, I'm not spending my free time being frustrated by a game that continues to be broken at its core.  I get that the devs have done a lot of work to get to this point, and I've had a lot of fun with it until now, but the bottom line is that you spent a lot of time building a project that was doomed to never work right due to the tools you built it in.  It's not their fault, really, that Unity handles wheels so poorly, but unless they're willing to invest more work to port the game to an appropriate engine, it seems this is the best we're going to get.  I understand their reluctance to do so, and I don't blame them, but the only probably outcome is that we bought a game that turned out to be a lemon, and the devs really aren't to blame for it.

There is a petition on the Unity forums to get the Unity developers to enable a legacy compatibility mode so that U5 can use older versions of PhysX... seems to me that's probably the best solution at this point.  So if you want to see this work, that's probably where the community needs to focus its energy right now - getting Unity to make their product work.  In the meantime, KSP devs, thank you for all you've done, and I really hope it works out.

[smjjames]

The devs are trying their best to make the wheels work as best as they can. Also, I really don't see switching to a different engine as a workable solution. A specialized program for vehichle simulations (well, KSP IS a vehichle simulation) is an entirely different thing than something as complex as KSP.

[GoSlash27]

All,

I have posted a MM patch for the 1.1.2 basic landing gear. Check it out here:

http://forum.kerbalspaceprogram.com/index.php?/topic/138567-112-basic-landing-gear-fixer/

Best,
-Slashy

Edited April 30, 2016 by GoSlash27

[MaxPeck]

43 minutes ago, smjjames said:

The devs are trying their best to make the wheels work as best as they can. Also, I really don't see switching to a different engine as a workable solution. A specialized program for vehichle simulations (well, KSP IS a vehichle simulation) is an entirely different thing than something as complex as KSP.

Broke is broke, regardless of the reason.  You can try your best and still not succeed, sometimes for reasons entirely beyond your control.  

I'm not advocating for an engine switch.  That would be a lot of work, I understand that.  This needs to be fixed by Unity/PhysX or there needs to be an engine change.  These are the only solutions.  Tweaks to .cfg files, adjusting settings - these are just bandaid fixes that may mute the problem slightly, but won't solve it.  This is only going to be solved at the game engine level, either through Unity and PhysX working out their problem, or KSP going in a different direction.  Neither is going to happen anytime soon, so like I said, KSP goes on the shelf for the immediate future. 

Good luck though, guys, and I sincerely hope the devs can work this out at some point.  I appreciate all their hard work on this, and I really look forward to the day this is a playable game.

[ndiver]

Can someone explain what are doing the new variable parameters for the wheels?

[msasterisk]

Used the ruggedized wheels in 1.1.

I've never seen such a big explosion.

Why is this happening to me?!

[Bedwyr]

I tried Slashy's cfg file and it appears to have made some improvement in controllability. Please see his thread for my comments regarding the changes.

 

I will repeat what I said there about design choices. Because the Juno engine is now first out of the gate in the research tree, it's natural that people will mount it to the side of the 1.5m fuselage. The downside is that it changes the weight distribution around the longitudinal axis and the L01 gear was never very strong. This means it's still going to result in a difficult-to-control airplane on takeoff and that mounting the gear from a wider position will help stabilize things.

I've tried messing with the damping and spring strength settings, but don't notice a real heap of change. However tuning control systems has always been a test of my patience even in real life. I'm too prone to get tired of messing around with PID gains hours after hour.

[Beryllium Dragon]

20 minutes ago, msasterisk said:

Used the ruggedized wheels in 1.1.

I've never seen such a big explosion.

Why is this happening to me?!

Wheels are totaly broken in 1.1.1, will drift (usually left) and if you have SAS on the controller will overreact destroying the craft.

Edited April 30, 2016 by Beryllium Dragon

[Bedwyr]

19 minutes ago, msasterisk said:

Used the ruggedized wheels in 1.1.

I've never seen such a big explosion.

Why is this happening to me?!

For others to help it would be useful to describe design, control inputs, and actions taken precisely. Otherwise it's just a random comment people will just say "oh... that's nice" to.

[Beryllium Dragon]

14 minutes ago, Bedwyr said:

I tried Slashy's cfg file and it appears to have made some improvement in controllability. Please see his thread for my comments regarding the changes.

 

I will repeat what I said there about design choices. Because the Juno engine is now first out of the gate in the research tree, it's natural that people will mount it to the side of the 1.5m fuselage. The downside is that it changes the weight distribution around the longitudinal axis and the L01 gear was never very strong. This means it's still going to result in a difficult-to-control airplane on takeoff and that mounting the gear from a wider position will help stabilize things.

I've tried messing with the damping and spring strength settings, but don't notice a real heap of change. However tuning control systems has always been a test of my patience even in real life. I'm too prone to get tired of messing around with PID gains hours after hour.

I't not the Juno being attached at the sides of the 1.5m.

There is a degree of instability with the craft direction, even at 10-15 m/s I was noticing slight changes in the Yaw as the SAS tried to compensate.

Something is causing craft to drift (usually to the left), crafts will spin at high speeds if allowed (and not using the tier 1 steerable wheel). Bad things happen at 35m/s with the steering sensitivity causing significant craft instability. The bouncing we see I suspect is due to craft attempting to stabilize their headings.

---------------------------------------------------------------------------------------------------------------------------

The low level of changes in Yaw were noticed while attempting to use a single Juno on the top of the craft.

-----------------------------------------------

That craft spun and crashed out at 22m/s

Edited April 30, 2016 by Beryllium Dragon
update on results.

[RocketBlam]

1.1.2 seems to have fixed some of these problems. On a very small plane I made, the thing won't track straight going down the runway. On a more normal-sized plane, they work fine, although they tend to slide more. That's not a game-breaker though.

They are all more sturdy now though, thankfully.

 

Edited April 30, 2016 by RocketBlam

[regex]

If your plane is veering on the runway try lengthening the wheelbase, it alleviates the issue to some extent.

Also, another thing I've found that helps is to set the friction control to 0 for take-off (obviously you'll want to set it back to normal for landing if you want the brakes to work).

Edited April 30, 2016 by regex