Jump to content

[1.0.x] [V1.9f] Kerbal Foundries wheels, anti-grav repulsors and tracks


lo-fi

What to work on next?  

1,282 members have voted

  1. 1. What to work on next?

    • More wheels
      123
    • More tracks
      453
    • Rover bodies
      241
    • Landing gear
      137
    • Landing legs
      108
    • Something completely different
      193


Recommended Posts

1 minute ago, Shadowmage said:

calculating the mass supported by each whee

There's only really one way to do this: Spring deflection against spring strength. I've given this a lot of thought. Any method that uses "vessel" mass is doomed to failure. Even finding all the "wheels", calculating their positions and orientations, then dividing that all up would be a huge task. OK for a "known" design, but in sandbox form we need a generic mode. Springs are usually measured in kg/mm deflection, so that ought to give you somewhere to work from. It won't be perfect, and there are some edge cases depending on how you've handled maximum deflection (bump stops), but it's the best and only shot you've got of handling this one.

Link to comment
Share on other sites

1 minute ago, lo-fi said:

There's only really one way to do this: Spring deflection against spring strength. I've given this a lot of thought. Any method that uses "vessel" mass is doomed to failure. Even finding all the "wheels", calculating their positions and orientations, then dividing that all up would be a huge task. OK for a "known" design, but in sandbox form we need a generic mode. Springs are usually measured in kg/mm deflection, so that ought to give you somewhere to work from. It won't be perfect, and there are some edge cases depending on how you've handled maximum deflection (bump stops), but it's the best and only shot you've got of handling this one.

Indeed, that is the conclusion I've been coming to from every avenue of research that I've hit up so far.  Spring force data is readily available from the suspension calculation / compression (which yes, is measured in newtons per meter of deflection), and this value is already used for all of the friction calculation.  And it does work, for the most part (and is the -proper- way to do it for friction forces).

Where I'm struggling to make it work properly is in finding the amount of force that is necessary to bring a wheel to zero lateral or longitudinal velocity without overshoot., When using the spring-force value for this purpose it gives incorrect readings whenever the suspension is not in equilibrium (e.g. when initially dropping the vessel from 1m or so, the spring force exerted is far greater than the force necessary to support the mass, because it is also arresting the negative vertical velocity; or when the vehicle first starts traveling downhill/crests a hill the spring force exerted is less than needed to support the mass due to inertia).

I've also tried calculating the sprung mass by examining the previous velocity of the wheel and the previous force exerted, comparing that the the current velocity, and negating the acceleration from gravity.  This gives extremely accurate results, but only in the absence of all other external forces (e.g. if a rocket engine was also pushing the wheel into the ground, the calculation would think that engines force was part of the force from mass).

But... I'm still reading/learning/investigating things.  This may be one of those points where I've been trying to do things 'wrong' and need to rethink the process a bit.  Wouldn't be the first time, won't be the last :)

Link to comment
Share on other sites

11 minutes ago, lo-fi said:

I'll have to have a look at the code. Is it up to date in Git?

'dev' branch is the live mess I've been working on.  Not much has changed on the actual wheel-collider between it and master branch though (I think maybe just some brake-torque/force updates).

So.. either would work, but use the 'dev' branch if you want the latest.

Link to comment
Share on other sites

2 hours ago, riocrokite said:

don't know if this helps but some of destroyed buildings in KSC (specifically administration building) make up for a great trial route for extreme wheels testing :)

kR8Gc24.jpg

Destroying my admin building in my sandpit test game in 3,..2,...1

 

And done

 

Edited by TiktaalikDreaming
evidence
Link to comment
Share on other sites

5 hours ago, riocrokite said:

don't know if this helps but some of destroyed buildings in KSC (specifically administration building) make up for a great trial route for extreme wheels testing :)

kR8Gc24.jpg

In all the time I've been playing ksp..... That never once occurred to me. That's such a great idea!

Link to comment
Share on other sites

11 minutes ago, V8jester said:

In all the time I've been playing ksp..... That never once occurred to me. That's such a great idea!

That sounds like an awesome idea for a KK static - Offroad testing grounds.

297.JPG

Link to comment
Share on other sites

11 hours ago, riocrokite said:

don't know if this helps but some of destroyed buildings in KSC (specifically administration building) make up for a great trial route for extreme wheels testing :)

kR8Gc24.jpg

MY favorite is actually the Tier 1 dirt runway we get. If we could put one of those next to the upgraded runways specifically for vehicle testing...

Link to comment
Share on other sites

17 hours ago, Kenobi McCormick said:

MY favorite is actually the Tier 1 dirt runway we get. If we could put one of those next to the upgraded runways specifically for vehicle testing...

Kerbal Konstrucs.
you could also launch from the island dirt runway if you have KK installed.

Link to comment
Share on other sites

On 3/6/2016 at 9:26 AM, TiktaalikDreaming said:

Destroying my admin building in my sandpit test game in 3,..2,...1

 

And done

 

Mind sharing with us what mod did you use for the truck?:wink:

P.S: You can use the destroyed Lv3 VAB and one of the destroyed Lv3 R&D buildings as enterable Off-road tracks.

Link to comment
Share on other sites

On 03/06/2016 at 5:51 PM, martinezfg11 said:

That sounds like an awesome idea for a KK static - Offroad testing grounds.

Hey a bit off topic i feel but here is exactly what you asked for, needs KK, used regularly

Spoiler

5Jd23hY.gif

It's not my terrain mod i didnt make it I've just had it forever it was made by Justin Kerbice many moons ago

https://www.dropbox.com/s/tr3sejhssb8dq4m/RoverProvingGround.zip?dl=0

PS the vehicle above is currently not possible (2 x 4wheel units), GIF from 1.0.5 before wheel collider debacle, Roll on KF

Edited by SpannerMonkey(smce)
Link to comment
Share on other sites

18 hours ago, Kenobi McCormick said:

MY favorite is actually the Tier 1 dirt runway we get. If we could put one of those next to the upgraded runways specifically for vehicle testing...

Lets not go post apocalyptic level, ok?

Link to comment
Share on other sites

7 minutes ago, Temeter said:

Lets not go post apocalyptic level, ok?

You're saying the T1 dirt runway is post-apocalyptic, yet apparently obliterating half of KSC in the name of testing a 4x4 isn't?

 

 

Sense: Your comment makes none.

 

 

Also I'd love some Fallout themed parts for KSP.

Edited by Kenobi McCormick
Link to comment
Share on other sites

3 minutes ago, Kenobi McCormick said:

You're saying the T1 dirt runway is post-apocalyptic, yet apparently obliterating half of KSC in the name of testing a 4x4 isn't?

 

 

Sense: Your comment makes none.

 

 

Also I'd love some Fallout themed parts for KSP.

A destroyed KSP is probably easier to traverse than a post apocalyptic landsacpe; or the runway.

Link to comment
Share on other sites

4 minutes ago, Temeter said:

A destroyed KSP is probably easier to traverse than a post apocalyptic landsacpe; or the runway.

I run sports cars up and down that T1 runway all the time. It's great fun and you need little more than a foot of suspension travel to bomb up and down it at 35-40m/s no prob.

Link to comment
Share on other sites

4 hours ago, Kardel said:

Mind sharing with us what mod did you use for the truck?:wink:

P.S: You can use the destroyed Lv3 VAB and one of the destroyed Lv3 R&D buildings as enterable Off-road tracks.

That's the reason I'm lurking on this thread.  KF seems like the likeliest source of well functioning off-road wheels and tracks to use so my Rover isn't completely incapable of driving over a curb without taking a run up.

It started as a "how oversized are stock rovers?" test, fell into a "can't not make it due to rover pun" and is now taking over my life.  But a set of wheels that weren't large disks with shopping trolley wheels at the bottom would be nice.  So here I lurk.  :-) 

Link to comment
Share on other sites

General progress update:

Think I found/developed a workable and usable method (or workaround rather) for the sphere-cast on skinny-wheels problem.  Rather than using a sphere cast, using two capsule-casts in a V shape (or 4-5+ in a U shape) allows for the 'width' to be set while returning accurate enough results.  More capsules can be used to trade performance for more optimal hit results;  but two in the V shape seems to work well enough.

With that in place there are now three options for suspension-sweeps; ray, sphere, and multi-capsule.  These will be configurable on a per-wheel basis; so parts with multiple wheel colliders may use different methods for each collider; e.g. tracks may use sphere/capsule for the front and rear and use raycast for the middle, or any combination thereof.

Also have a partial/initial/first-pass implementation of 'combinatorial' friction; limiting the maximum friction available per tire between the forward and sideways frictions.  What this allows for is powered-slides/burnouts/drifting; e.g. the more the wheels are slipping in the forwards direction, the less force is available in the sideways direction.  Traction control and/or differential setup is needed for vastly-overpowered wheel setups, else there is a run-away effect where a gripping wheel continues to grip more, and a slipping wheel continues to slip more...resulting in spinout.  Some of this will likely be cleaned up by some better wheel-torque integration methods (sub-step integration for torque/slip forces); the rest will have to be handled through some sort of active traction control.

Still a few more problems that I haven't been able to sort out, but I'm investigating potential solutions for a couple of them (bump-stop/anit-punchthrough, static/sticky/adherent friction).  Found a few more sources that I might be able to derive implementations from, so I'm hopeful I'll be able to find a workable solution for them.

 

The stock-replacement part-module and patch set is also coming along nicely; I've figured out the model setup for most of the stock models (wheels, gear, legs) and have created a patch that will remove the stock modules and insert the stock-replacement module with the config needed for each part.  It is nearly feature-complete; the most notable omissions are damage/breakage, and landing-leg foot alignment.  It will likely be ready for initial testing in a week or two.

 

More progress :)

Link to comment
Share on other sites

14 hours ago, Shadowmage said:

Traction control and/or differential setup is needed for vastly-overpowered wheel setups, else there is a run-away effect where a gripping wheel continues to grip more

Don't worry about this kinda stuff in the wheel collider component - anything application specific should be handled at the PartModule level IMHO. I'll pick that stuff up in the KF plugin :)

Link to comment
Share on other sites

On 03/06/2016 at 1:48 AM, Shadowmage said:

I've also tried calculating the sprung mass by examining the previous velocity of the wheel and the previous force exerted, comparing that the the current velocity, and negating the acceleration from gravity.

I seem to be in charge of asking stupid questions, so: why are we trying to derive the sprung mass? I'm not sure for what purpose it is needed.

(I know that rolling resistance depends on it... but actually rolling resistance can and should be derived from the spring's compression - if, as you suggest, a rocket engine is pushing the vessel down, that should increase rolling resistance.)

Link to comment
Share on other sites

51 minutes ago, damerell said:

I seem to be in charge of asking stupid questions, so: why are we trying to derive the sprung mass? I'm not sure for what purpose it is needed.

(I know that rolling resistance depends on it... but actually rolling resistance can and should be derived from the spring's compression - if, as you suggest, a rocket engine is pushing the vessel down, that should increase rolling resistance.)

At a very low-level, knowing the sprung mass can allow you to more precisely handle velocity changes; specifically knowing the amount of force (newtons) needed to bring a velocity to zero for a wheel (F = M * A); without knowing the M you cannot know the F.

Now, this may not be needed in the end, as I'll likely take use a 'video game' solution rather than a 'physics' solution; in otherwords... cheat.  Likely by merely zeroing out velocity when it is decreasing and hits a certain threshold (like 0.05m/s or something).

4 hours ago, lo-fi said:

Don't worry about this kinda stuff in the wheel collider component - anything application specific should be handled at the PartModule level IMHO. I'll pick that stuff up in the KF plugin :)

Indeed :)  There actually is no clean way (that I can think of) to handle it at the individual wheel level; you would need a PartModule (or VesselController type setup) in order to manage the forces between multiple wheel-collider instances (or wheel parts); decreasing motor or brake torques for wheels with excess slip.

Still think I can get a big portion of the differential force output cleaned up through better integration, but there is almost no way I'm going to get rid of all of it.  Better integration would likely increase available thrust output, as between each sub-step the slip ratio would be far lower, and thus, more power would go towards the road, and I'll be investigating it mostly for that reason... but I have a feeling it'll help the differential/yaw problems as well.

Link to comment
Share on other sites

hey guys, would be grateful if someone could replicate my observations:

- I think that stock wheel code ModuleWheelSteering doesn't work properly namely it doesn't take speed of the wheel into account. In other words no matter how quickly you go stock wheel turning sensitivity is always the same:

Let's take for example a rover with TR-2L wheel with following config:

        steeringCurve
        {
            key = 0 35
            key = 3 1
            key = 10 1
            key = 30 0.2
            key = 60 0.1
        }

The wheels always maintained 35 degrees steering sensitivity no matter how fast I went :(

edit: created a ticket in ksp bug tracker: http://bugs.kerbalspaceprogram.com/issues/9853

Edited by riocrokite
Link to comment
Share on other sites

4 hours ago, Shadowmage said:

At a very low-level, knowing the sprung mass can allow you to more precisely handle velocity changes; specifically knowing the amount of force (newtons) needed to bring a velocity to zero for a wheel (F = M * A); without knowing the M you cannot know the F. Now, this may not be needed in the end, as I'll likely take use a 'video game' solution rather than a 'physics' solution; in otherwords... cheat.  Likely by merely zeroing out velocity when it is decreasing and hits a certain threshold (like 0.05m/s or something).

Seems reasonable to me.

Indeed, I think I'll have a second silly question, if I may; surely this only comes into play if the wheel isn't touching something? Otherwise its velocity is constrained by where the ground is each tick; its velocity relative to the craft is equally constrained by the wheel ground-hugging and the craft being wherever the forces, suspension included, think it is.

I kind of feel, even having read the code, that I'm missing something fundamental about the implementation.

Oho, a third silly question. Currently it looks to me like the full spring force is applied at the hit, normal to the hit (KSPWheelCollider.cs, line 453). Surely it should always be applied on the suspension axis (with perhaps a small fore-aft shift to account for tyre compression [1]) at the top of the suspension travel? That is the force the rest of the vehicle sees.

The force available for traction is then normal to the hit, but is the suspension force times cos theta, where theta is the angle between the suspension axis (with the aforementioned shift) and the line from the hit to the top of the suspension travel - it's easier to get traction with your suspension pushing the wheel down than by just rubbing a wheel up against something. (To pick an extreme example, suppose we could detect a hit at the _top_ of the wheel. cos theta is then -1 - and sure enough, we'd need a negative suspension force to press the top of the wheel against that surface).

This looks at first glance like conservation of force is violated, but it's not - the lower end of the suspension is pushing just as hard, but little of that force is available for tractive purposes.

Imagine in the current implementation a vehicle has all its wheels leave the ground and shortly after hits a near-vertical wall (wheels first). In either case, the front springs will suddenly squash as it encounters the wall. In the current implementation, it'll rebound backwards (odd, since the suspension springs weren't facing the right way) and continue to fall, staying about level (almost no vertical force from suspension). In mine, the front springs will shove the front of the vehicle upwards (because the impact tick squashed them hard, they'll recoil with more force than one g) but the back will keep falling, risking a backflip.

[1] This isn't needless pedantry; it'll help with contact with near-vertical walls.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...