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

[AdmiralTigerclaw]

6 hours ago, lo-fi said:

I actually have no idea! I suspect probably yes, but it'll need investigating.

 

I tried testing it last night after I asked.  The answer is an annoying 'no'.   The APU does not engage, and does not auto-spool.  Even removing the automatic control module (// comment out in the part file) so I can try and run it on the throttle does nothing.

[lo-fi]

I'd imagine they've changed how the engines work :/

[AdmiralTigerclaw]

I got the turbine working as a normal engine.  It required changing the spool up-down speeds off zero.  It's not dynamic without the APU controller module, but it suffices.

[Shadowmage]

More progress on the wheel-collider component (in the dev branch this time: https://github.com/shadowmage45/KSPWheel/tree/dev ):

Today I got a full implementation of a wheel-physics reference implementation (mostly) working, based on: http://www.asawicki.info/Mirror/Car%20Physics%20for%20Games/Car%20Physics%20for%20Games.html .  This is a simpler implementation than that which PhysX uses (which can be found in appendix H of: http://www.eggert.highpeakpress.com/ME485/Docs/CarSimEd.pdf ), however it has all of the base features that are needed.  The largest difference is simulation of forces from tire camber angle and camber stiffness... in the simplified model they are all rolled into the sideways friction curve parameters rather than handled explicitly.

• Suspension = unchanged; still working just as it was previously.
• Sideways friction = working as-is; could be improved with code to do final limiting based on actual vessel mass rather than fudging it based on down-force (e.g. need to know when there is enough side-friction to stop sideways momentum entirely but not start moving the opposite way).
• Forward friction/traction = working; though force contribution seems lower than it should, likely I'm using an improper unit conversion for one or more of the values.  Should be able to get it cleaned up easily enough though.  Wheels can spin at different rates than the ground underneath them if driven/brakes are applied, and it is purely this rotational speed difference that determines drive/traction force.  Free-rolling wheels will roll at the speed of the ground, and maintain their angular momentum when not in contact with the ground; if a non-moving vehicle has fast-spinning tires and they touch the ground the tires will impart a drive force on the vehicle; wheels themselves have simulated inertia.  Not-yet-implemented is rolling-resistance (which would represent drive-train torque losses/drag, drag due to bearings, as well as tire-to-road rolling resistance).  Air/drag resistance will be left to be handled by Unity/KSP physics code.  Also not-yet-implemented is torque on the vehicle body when drive-torque is applied (e.g. in a free-falling vehicle, applying torques to the drive wheels will also apply a torque to the body and can change vehicle orientation/attitude).
• Sticky friction is still WIP, though I'm closing in on a functional implementation with every pass through the code.  For now I would say it is 'not working'... but is getting much closer (really need most everything else working first).

This will be the -first- physics model that is implemented for the wheels.  After everything else is working (sticky friction, initial part-modules, etc.), I'll work on a more complete/robust implementation based on the reference that PhysX uses.  Likely won't be needed/will be overkill/less performant than the simplified model.... but may be more accurate for some setups.  The physX reference though... gives me headaches trying to read it; they constantly use variables without explaining what they are or how to derive them, so I went with a reference source that I could actually read for the first/initial physics model.  I'll get the PhysX reference figured out eventually.

Hoping to get this first physics model cleaned up and ready for general use sometime over this weekend, which will mean the low-level WheelCollider component should be ready for external use at that point.  After that I'll finish working on the KSPWheelModule stock-replacement-PartModule and integration of the code for use into KSP; hopefully will only take another week or two to get that sorted out and working.

Getting closer

[Vrana]

Love following this thread. 

 

Even though i mostly just stalk it, its really enjoyable to read.

 

Keep up the good work.

[AdmiralTigerclaw]

33 minutes ago, Shadowmage said:

More progress on the wheel-collider component (in the dev branch this time: https://github.com/shadowmage45/KSPWheel/tree/dev ):

Today I got a full implementation of a wheel-physics reference implementation (mostly) working, based on: http://www.asawicki.info/Mirror/Car%20Physics%20for%20Games/Car%20Physics%20for%20Games.html .  This is a simpler implementation than that which PhysX uses (which can be found in appendix H of: http://www.eggert.highpeakpress.com/ME485/Docs/CarSimEd.pdf ), however it has all of the base features that are needed.  The largest difference is simulation of forces from tire camber angle and camber stiffness... in the simplified model they are all rolled into the sideways friction curve parameters rather than handled explicitly.

• Suspension = unchanged; still working just as it was previously.
• Sideways friction = working as-is; could be improved with code to do final limiting based on actual vessel mass rather than fudging it based on down-force (e.g. need to know when there is enough side-friction to stop sideways momentum entirely but not start moving the opposite way).
• Forward friction/traction = working; though force contribution seems lower than it should, likely I'm using an improper unit conversion for one or more of the values.  Should be able to get it cleaned up easily enough though.  Wheels can spin at different rates than the ground underneath them if driven/brakes are applied, and it is purely this rotational speed difference that determines drive/traction force.  Free-rolling wheels will roll at the speed of the ground, and maintain their angular momentum when not in contact with the ground; if a non-moving vehicle has fast-spinning tires and they touch the ground the tires will impart a drive force on the vehicle; wheels themselves have simulated inertia.  Not-yet-implemented is rolling-resistance (which would represent drive-train torque losses/drag, drag due to bearings, as well as tire-to-road rolling resistance).  Air/drag resistance will be left to be handled by Unity/KSP physics code.  Also not-yet-implemented is torque on the vehicle body when drive-torque is applied (e.g. in a free-falling vehicle, applying torques to the drive wheels will also apply a torque to the body and can change vehicle orientation/attitude).
• Sticky friction is still WIP, though I'm closing in on a functional implementation with every pass through the code.  For now I would say it is 'not working'... but is getting much closer (really need most everything else working first).

This will be the -first- physics model that is implemented for the wheels.  After everything else is working (sticky friction, initial part-modules, etc.), I'll work on a more complete/robust implementation based on the reference that PhysX uses.  Likely won't be needed/will be overkill/less performant than the simplified model.... but may be more accurate for some setups.  The physX reference though... gives me headaches trying to read it; they constantly use variables without explaining what they are or how to derive them, so I went with a reference source that I could actually read for the first/initial physics model.  I'll get the PhysX reference figured out eventually.

Hoping to get this first physics model cleaned up and ready for general use sometime over this weekend, which will mean the low-level WheelCollider component should be ready for external use at that point.  After that I'll finish working on the KSPWheelModule stock-replacement-PartModule and integration of the code for use into KSP; hopefully will only take another week or two to get that sorted out and working.

Getting closer

 

So you're effectively writing your own version of general wheel handling code?

 

Nice.

[Rushligh]

1 hour ago, Shadowmage said:

More progress on the wheel-collider component (in the dev branch this time: https://github.com/shadowmage45/KSPWheel/tree/dev ):

Today I got a full implementation of a wheel-physics reference implementation (mostly) working, based on: http://www.asawicki.info/Mirror/Car%20Physics%20for%20Games/Car%20Physics%20for%20Games.html .  This is a simpler implementation than that which PhysX uses (which can be found in appendix H of: http://www.eggert.highpeakpress.com/ME485/Docs/CarSimEd.pdf ), however it has all of the base features that are needed.  The largest difference is simulation of forces from tire camber angle and camber stiffness... in the simplified model they are all rolled into the sideways friction curve parameters rather than handled explicitly.

• Suspension = unchanged; still working just as it was previously.
• Sideways friction = working as-is; could be improved with code to do final limiting based on actual vessel mass rather than fudging it based on down-force (e.g. need to know when there is enough side-friction to stop sideways momentum entirely but not start moving the opposite way).
• Forward friction/traction = working; though force contribution seems lower than it should, likely I'm using an improper unit conversion for one or more of the values.  Should be able to get it cleaned up easily enough though.  Wheels can spin at different rates than the ground underneath them if driven/brakes are applied, and it is purely this rotational speed difference that determines drive/traction force.  Free-rolling wheels will roll at the speed of the ground, and maintain their angular momentum when not in contact with the ground; if a non-moving vehicle has fast-spinning tires and they touch the ground the tires will impart a drive force on the vehicle; wheels themselves have simulated inertia.  Not-yet-implemented is rolling-resistance (which would represent drive-train torque losses/drag, drag due to bearings, as well as tire-to-road rolling resistance).  Air/drag resistance will be left to be handled by Unity/KSP physics code.  Also not-yet-implemented is torque on the vehicle body when drive-torque is applied (e.g. in a free-falling vehicle, applying torques to the drive wheels will also apply a torque to the body and can change vehicle orientation/attitude).
• Sticky friction is still WIP, though I'm closing in on a functional implementation with every pass through the code.  For now I would say it is 'not working'... but is getting much closer (really need most everything else working first).

This will be the -first- physics model that is implemented for the wheels.  After everything else is working (sticky friction, initial part-modules, etc.), I'll work on a more complete/robust implementation based on the reference that PhysX uses.  Likely won't be needed/will be overkill/less performant than the simplified model.... but may be more accurate for some setups.  The physX reference though... gives me headaches trying to read it; they constantly use variables without explaining what they are or how to derive them, so I went with a reference source that I could actually read for the first/initial physics model.  I'll get the PhysX reference figured out eventually.

Hoping to get this first physics model cleaned up and ready for general use sometime over this weekend, which will mean the low-level WheelCollider component should be ready for external use at that point.  After that I'll finish working on the KSPWheelModule stock-replacement-PartModule and integration of the code for use into KSP; hopefully will only take another week or two to get that sorted out and working.

Getting closer

*drools*
I can't wait.
one thing you might want to do is issue your wheels in preset sizes.

there's some severe problems with tweakscale and wheel collides; tweakscale alters the mesh size, but because the collider isn't necessarily attached to the mesh, it doesn't move/change appropriately. the result is wheels sitting half way into the ground, and having their part collides (not wheel ones) get stuck.

this WILL be a severe bug problem for you in the future i can feel it.

[Kenobi McCormick]

That is friggin sweet. Glorious progress!

 

 

It makes me kind of curious whether or not tank road wheels flex significantly when steering like car tires do...well, the rubber part of the ones that have rubber parts anyway. Friction against the track links has to be substantial and you'd expect the relative movement between the hull, ground, track to cause some slippage between wheel and track.

 

 

20 hours ago, Rushligh said:

*drools*
I can't wait.
one thing you might want to do is issue your wheels in preset sizes.

there's some severe problems with tweakscale and wheel collides; tweakscale alters the mesh size, but because the collider isn't necessarily attached to the mesh, it doesn't move/change appropriately. the result is wheels sitting half way into the ground, and having their part collides (not wheel ones) get stuck.

this WILL be a severe bug problem for you in the future i can feel it.

The solution to that is, simply, 'We cannot provide support for bugs created by third party mods at this time. However, we are working with the major mods that would potentially cause them....Tweakscale, being an example...and hope to be able to fix the problems/support such installations in the future. Thank you!'

[Shadowmage]

22 hours ago, AdmiralTigerclaw said:

 

So you're effectively writing your own version of general wheel handling code?

 

Nice.

Yep;

Nice... not really.  What would be nice is if the base Unity wheel-collider component -just worked-, and I didn't have to do any of this .  Well, I suppose it is nice that people can have working wheels after it is done....

 

21 hours ago, Rushligh said:

*drools*
I can't wait.
one thing you might want to do is issue your wheels in preset sizes.

there's some severe problems with tweakscale and wheel collides; tweakscale alters the mesh size, but because the collider isn't necessarily attached to the mesh, it doesn't move/change appropriately. the result is wheels sitting half way into the ground, and having their part collides (not wheel ones) get stuck.

this WILL be a severe bug problem for you in the future i can feel it.

-I- won't be 'issuing' any wheels.  The WheelCollider work I'm doing will not come with a single part, model, texture, config, or anything else directly usable in KSP.  It is a tool for other mods/developers to use (such as lo-fi and Kerbal Foundries).

 

Scaling -- Might be a problem for someone... but not for me

My main part of this is writing the WheelCollider component... which doesn't care what scale the model is at.  All it cares is if you have set the spring/damper/friction values properly, and that the suspension length and suspension target parameters are properly set.  All other 'scale' related functions would be handled at the PartModule level; which are individual mods' responsibilities to handle, not the WheelColliders problem.

I -might- include handling of rescaled models in the stock-replacement PartModule... but that is a big -maybe-.  Someone who actually uses tweakscale/scaling mods is always welcome to submit a PR to add the functionality if needed.  Does tweakscale even work on the current stock-wheels?  (Don't know, haven't used TS since ~0.90)
 

 

1 hour ago, Kenobi McCormick said:

That is friggin sweet. Glorious progress!

 

 

It makes me kind of curious whether or not tank road wheels flex significantly when steering like car tires do...well, the rubber part of the ones that have rubber parts anyway. Friction against the track links has to be substantial and you'd expect the relative movement between the hull, ground, track to cause some slippage between wheel and track.

 

 

The solution to that is, simply, 'We cannot provide support for bugs created by third party mods at this time. However, we are working with the major mods that would potentially cause them....Tweakscale, being an example...and hope to be able to fix the problems/support such installations in the future. Thank you!'

 

Progress indeed

Today I figured out why it appeared that the drive force was being applied incorrectly; it was mostly a visual error related to update sequence (I was applying motor torques after calculating drive torques, resulting in the visual mesh spinning with the full motor-torque, rather than motor-torque - drive-torque).  I also had some incorrect conversions for torque-radians-newtons in there (so many different units to work with....)... so the drive force really was less than it should have been, but the difference was not as great as at seemed (the large visual difference was caused by the above update-sequencing).

Just need to clean up the slip-ratio calculation so that it gives proper bounded/clamped values (-1 ... 0 ... 1) rather than the inconsistent mess that it does now, and integrate that back into the existing code and clamp drive forces to maximum force (based on slip ratio, friction curve, and down-force).  Then lots of testing, playing around with various setups.  Have been using a pretty standard 'car' model so far for testing, but will put together some additional more KSP oriented contraptions (e.g. 2, 3, 5, 6 wheels, tracks... ??).  -Then- comes the in-KSP testing and working on the stock-replacement/example PartModule.

Also somewhere on the TODO list will be investigating sphere-casts for the wheels and figuring out how to ignore any contacts it finds that are outside of the wheel-plane*width.

On the 'would-be-nice' list will be dynamic friction modification based on surface hit;  this would have to be part of the PartModule though, as the WheelCollider has no clue what KSP even is (it is designed as a base Unity component, without any compile-dependencies on the KSP libraries).

 

Tracks -- wish I was more familiar with the physics of them... I'm still trying to wrap my head around basic round wheels' physics.  Simulation of drive-gear-to-track slip and friction is not really something that I'll be worrying about too much initially... though if I need to develop any special handling for track-type setups I'll likely include it.

 

And yep, that'll pretty much be my 'solution' to tweak-scale, etc.  But more along the lines of 'I don't integrate support for mods I don't use... if you would like XXX to have integrated supported, please submit a PR to add/change the necessary functionality.

 

 

But anyhow.... thanks for the support guys.  Really hoping to get some of this code out of the theoretical realm and into the 'usable' realm soon.  Will keep you all informed

[Kenobi McCormick]

4 hours ago, Shadowmage said:

.Tracks -- wish I was more familiar with the physics of them... I'm still trying to wrap my head around basic round wheels' physics.  Simulation of drive-gear-to-track slip and friction is not really something that I'll be worrying about too much initially... though if I need to develop any special handling for track-type setups I'll likely include it.

 

Unless the drive sprocket is stripped out there should be zero slip whatsoever between the sprocket and the track. Generally, if they're slipping, they're seconds from throwing a track completely. Stab a '0' in there and roll with it. The slippage comes from between the track and the surface upon which it rides.

 

 

The slip I was referring to is between the road wheels and the track links, and it's in a lateral direction. When trying to turn the track has to slide against the ground, which the guide horns allow for when they interface with the road wheels, idler wheels, return rollers. However, the gap they run through is significantly wider than the teeth themselves, that plus the natural flex in the track means there's some slippage there. IT was mostly an academic question, no reason to model it for our KSP module as it has zero effect on the function of the track.

Edited May 28, 2016 by Kenobi McCormick

[damerell]

5 hours ago, Shadowmage said:

Tracks -- wish I was more familiar with the physics of them... I'm still trying to wrap my head around basic round wheels' physics.  Simulation ofdrive-gear-to-track slip and friction is not really something that I'll be worrying about too much initially... though if I need to develop any special handling for track-type setups I'll likely include it.

As far as I can tell, tracks could continue to be simulated as a set of (as far as the game knows) independent wheels with the part reporting a RPM figure that's the average of the grounded wheels. The only thing I'd add to that is (as suggested before) that the available torque be calculated per-part and divided between the grounded wheels (if your wheel module can sensibly determine this, to each wheel in proportion to the amount it could handle before slipping).

[TiktaalikDreaming]

12 hours ago, Kenobi McCormick said:

That is friggin sweet. Glorious progress!

It makes me kind of curious whether or not tank road wheels flex significantly when steering like car tires do...well, the rubber part of the ones that have rubber parts anyway. Friction against the track links has to be substantial and you'd expect the relative movement between the hull, ground, track to cause some slippage between wheel and track.

Pretty sure any flex would be a really small effect (although maybe on very gentle turns at speed it could be dominant) compared to slip.  Think about how long a track's surface is in contact with the ground, and usually backed by a fair amount of rigidity.  There'd be intra link flex, and general motion of the links, but the wheels will hold the track to a line.  It means a fair chunk of slip at the front and back during turns.  If they didn't reduce ground pressure dramatically they'd be ripping roads to shreds.  As it is, a heavy tracked vehicle will still rip up a road a fair bit.

EDIT: Dammit, I should read the other posts before posting.
Yep, agreed, interesting issue, and I'm sure tracked vehicle manufacturers would know, but yeah, for KSP, probably doesn't matter.

Edited May 28, 2016 by TiktaalikDreaming

[Rushligh]

22 hours ago, Kenobi McCormick said:

That is friggin sweet. Glorious progress!

 

 

It makes me kind of curious whether or not tank road wheels flex significantly when steering like car tires do...well, the rubber part of the ones that have rubber parts anyway. Friction against the track links has to be substantial and you'd expect the relative movement between the hull, ground, track to cause some slippage between wheel and track.

many tracks use large cogs instead of wheels on their drive wheels; the grooves in the cogs correspond to the structure of the track links so there is 0% slippage, however, it required a massive amount of torque. Excavators have this system. im not to sure about military tanks though.

as for flexing; no. they don't. the tracks can flex slightly, but if you've watched an excavator turn you can see the the pivot point is the center of the vehicle; the front and back of the tracks are actually dragging on the ground at 90 degrees. that's why tank tracks are trapezoid shaped (in cross section); to minimize the effect of that when pivoting. if they gripped the ground too well at the edges, the vehicle would shudder as it rotates, potentially causing damage.

[ComatoseJedi]

4 hours ago, Rushligh said:

many tracks use large cogs instead of wheels on their drive wheels; the grooves in the cogs correspond to the structure of the track links so there is 0% slippage, however, it required a massive amount of torque. Excavators have this system. im not to sure about military tanks though.

Tracks on tanks I know plenty about. I was an M1 Abrams tank crewmember in the Army. That tank and most other tank tracks have a set of drive sprockets on rear top corners of the tracks and suspension wheels that not only are for suspension but also are responsible for steering and makes tanks more agile. The only kind of tracked vehicle that has more than one set of drive sprocket is pretty much heavy construction machinery. Which need more torque to handle heavier loads. 

M1 A1 Abrams: 

 

Bulldozer tracks

Spoiler

I can tell you this. I have driven both. And there's a whole lot of speed difference between the two. The Abrams is like driving pig stuff on a shovel while the other one IS a shovel. 

[Kenobi McCormick]

8 hours ago, Rushligh said:

many tracks use large cogs instead of wheels on their drive wheels; the grooves in the cogs correspond to the structure of the track links so there is 0% slippage, however, it required a massive amount of torque. Excavators have this system. im not to sure about military tanks though.

as for flexing; no. they don't. the tracks can flex slightly, but if you've watched an excavator turn you can see the the pivot point is the center of the vehicle; the front and back of the tracks are actually dragging on the ground at 90 degrees. that's why tank tracks are trapezoid shaped (in cross section); to minimize the effect of that when pivoting. if they gripped the ground too well at the edges, the vehicle would shudder as it rotates, potentially causing damage.

I can't bring to mind a single tank that tried to use a friction drive between its drive wheel and the tracks themselves. Dating all the way back to WW1 when we were still calling them tanks to disguise them as water transport vehicles they used toothed sprockets interfacing with holes in track links for that. T-34, BT-series, T-44 used an inverted version where the drive sprocket accepted the guide horns and pushed them instead of inserting teeth into holes/gaps to drive the track that way, still a zero slippage system unless there's something majorly wrong.

 

They need good torsional rigidity, yes. I've noticed that when turning /35th scale tank models into RCs. I tried to drive my KV-2 on the kit supplied rubber tracks but they just twisted right off when steering it. The metal tracks I replaced it with will form an S-shaped pattern on the ground if the surface upon which it tries to turn is substantially grippy. If you traced the guide horns at each end along where the overall track lies you'd find the exact width of the gap between the inner and outer halves of the road wheels. that is the flex I was pondering.

[lo-fi]

Wow guys!

I treat tracks as the sum of their wheels with the average rpm of the grounded wheels giving the track speed. No special consideration is needed for the wheel colliders, so Shadowmage's version will work perfectly well. Sprockets and idlers are treated as road wheels with no suspension travel.

[Shadowmage]

General progress update:

Got the torque/wheel-rpm/friction stuff all working.  Wheels can spin independently of the surface they are on, and in fact all 'drive forces' are derived from this slip speed, governed by the slip ratio and friction curve.  If the motor has enough torque to break the wheels loose, it will; how much torque is needed depends on the current down-force exerted by the suspension, so it is easier to over-torque the wheels on low-g worlds.  In fact low-g worlds will effect all friction parameters dynamically as they are all driven from the down-force as calculated by the suspension spring system.

Best of all... it all 'just works' in KSP as well   (well.... not 'just'... but... it does work easily without much hackery).

 

As to the tracks; yes; pretty much you would just re-average the individual wheel RPMs on every tick;  I might even add special handling code that could do this for you (e.g. a method such as averageWheelRPM(KSPWheelCollider[] wheels). 

For better turning you might want to slightly reduce sideways friction curves/coefficients for the front- and rear-most 'wheels' in the tracks so they don't drag as much when turning.... could even alter them dynamically if needed (e.g. lower the side friction when turn input is detected or something).

 

In-KSP testing from this-morning.  Note that I've not done much/any suspension tuning for these wheels, its mostly some guessed-at values.  Its still not 100%, but it is working mostly as intended.  Still have some collider things to sort out (like why there is a Kerbin collider hovering above the launchpad?), still need to finish implementing sticky-friction, and need to find out how to allow wheels to work with '0 suspension'.... but pretty sure I can get all of those issues sorted out with a bit more time.

 

[Fireheart318]

Give me a month for the release date. June, July, August, etc. I just made a replica of the Ghost from Halo and can't release it until repulsers work again

[damerell]

24 minutes ago, Fireheart318 said:

Give me a month for the release date. June, July, August, etc. I just made a replica of the Ghost from Halo and can't release it until repulsers work again

Pick one yourself. You'll have the same 1/12 chance of being right as anyone else. Normally I'd suggest you ask nicely rather than making demands, but no matter how nicely you asked you'd still get a wild guess.

[Kenobi McCormick]

27 minutes ago, Fireheart318 said:

Give me a month for the release date. June, July, August, etc. I just made a replica of the Ghost from Halo and can't release it until repulsers work again

 

 

Such a thing isn't really feasible. It's ready when it's ready, be patient. Rushjobs are worse than waiting with nothing.

[Geschosskopf]

On 5/29/2016 at 8:45 PM, Kenobi McCormick said:

I can't bring to mind a single tank that tried to use a friction drive between its drive wheel and the tracks themselves. Dating all the way back to WW1 when we were still calling them tanks to disguise them as water transport vehicles they used toothed sprockets interfacing with holes in track links for that. T-34, BT-series, T-44 used an inverted version where the drive sprocket accepted the guide horns and pushed them instead of inserting teeth into holes/gaps to drive the track that way, still a zero slippage system unless there's something majorly wrong.

Yeah, AFAIK all tanks have used some sort of drive sprocket.  Most common is as shown above with the teeth on the drive sprocket meshing into the gaps between the track plates.  However, there have also been many tanks and lighter AFVs, plus bulldozers, that have put the teeth on the center of the track plates to engage dimples in the drive sprocket.  This isn't amenable to high speed but has the advantage of allowing the track plates to pivot laterally, which is good for very rough terrain.  There are also the "ladder tracks" popularized by the Bombardier company.  With these, the track consists of 2 parallel, continuous rubber bands linked by metal crossbars.  The drive sprocket has lugs that engage the gaps between these crossbars.  Sometimes, the drive sprocket is a pneumatic fire and the lugs one it are in its tread.  This type of track is intended for light vehicles operating in snow and/or mud.

There have been experiments with track systems that used powered roadwheels and relied on the vertical friction, from the vehicles weight, between these wheels and the inner surface of the track.  Such things were intended to allow easy conversion of conventional wheeled vehicles into tracked vehicles.  But these didn't work well AFAIK and aren't used today, although I could be wrong.

[GeoPhizzix]

1 hour ago, Geschosskopf said:

Such things were intended to allow easy conversion of conventional wheeled vehicles into tracked vehicles.  But these didn't work well AFAIK and aren't used today, although I could be wrong.

I have a set of tracks for my Can Am ATV. It will take me on average an hour or 2 to switch out from standard wheels to the tracks, and vise verse. Where it is great to have in deep snow, due to the increased surface area and redistribution of weight, it is an absolute bear to steer on any surface with a higher friction value than ice/snow. I believe this is due to way that Bombardiers independent drive system works vs. that of a "tank". In a tank, when I want to turn left for example, the right side tracks induce positive acceleration, while the left side induces less or a negative acceleration. However, with my Can Am, all wheels (or tracks in this case) want to all continue in the same direction. This makes for some very wide slow turns and tired shoulders after a bit. I feel the other factor in this is the rubber tracks and their friction on different surface.

http://imgur.com/3bsl4gP

Edited May 31, 2016 by GeoPhizzix

[Shadowmage]

General wheel-development progress update:

KSPWheelCollider (low-level component)

Got tons done over the weekend on both the KSPWheelCollider component and the KSPWheelModule stock-replacement module.  The initial friction model is in place and working, and all features of the basic WheelCollider are working aside from sticky friction and anti-punchthrough.  Have those bits to finish up, and then it is all onto polish and API work.  Will likely ask regarding the needed/wanted low-level features when I get to that point... a bit later in the week (note that these are -low-level- features, not anything that could controlled by the PartModule; e.g. the ability to alter the friction curve/coefficients at run-time, alter spring/damper at run-time, etc., are all low-level features).

Spent a bit of time yesterday playing around with sphere-casts as opposed to ray-casts.  Got the basic in-Unity script working with them after a bit of figuring out.  They do make the wheel response much more natural when encountering sharp corners or dealing with the edges of surfaces.  However they do also come with their own sets of ceaveats; notably that they are a sphere and not a cylinder; this means they have more width than they should, and still only contact the ground at a singular point.  Also going to be much more painful to integrate into KSP due to same-vessel colliders interfering (e.g. the current stock 'wheel blocked' issues are caused by this exact problem).

KSPWheelModule (stock replacement module)

As could be seen in the video posted Sat., the wheels are working in KSP as far as a stock-replacement goes.  Not perfectly yet, but still working quite well.  Mostly left to sort out are collider issues; stock models have some colliders in strange places, and whatever the CollisionEnhancer script is loves to explode things that aren't actually colliding.  Also lots of inconsistency in how the stock models are put together and their configs' specified (e.g. the wheel-collider is in seemingly random places in the model; never at either the top or bottom of the suspension; sometimes not even located -on- the suspension); the suspension distance in the config is often -not- the suspension distance as measured in the model; lots of other hackery/strangeness to sort out in the configs (such as why they all list absurd torque, brake, spring, and damper values).  Fairly certain I can get it all working though even if I have to resort to manually measuring things in the models for the patch files.

Vessel colliders though... still have not thought of any good (high-performance) way to implement the 'ignore all colliders on the same vessel'.  lo-fi had suggested doing an initial ray/sphere-cast and ignoring any that were hit;  which would work for a specific vehicle configuration..... the problem with KSP is that a vessel configuration is not static.  Things like joint-flex and docking can alter the positions of parts/colliders relative to the wheel and render doing a single ray/sphere-cast check much less useful (really only useful for a single frame).

 

@lo-fi  I believe that the low-level component should be ready for the start of external use within the week/this weekend, mostly dependent on the API development and cleanup; only a few minor features left to develop/implement, and those shouldn't have any major impact on the overall API or use of the component.  Will likely start working on implementing the API first so that you can start working on the KF integration end of things.  Will do another post here in a bit with the initial API layout (list of exposed fields and methods) to make sure everything you need is present.

[Geschosskopf]

6 minutes ago, GeoPhizzix said:

I have a set of tracks for my Can Am ATV. It will take me on average an hour or 2 to switch out from standard wheels to the tracks, and vise verse. Where it is great to have in deep snow, due to the increased surface area and redistribution of weight, it is an absolute bear to steer on any surface with a higher friction value than ice/snow. I believe this is due to way that Bombardiers independent drive system works vs. that of a "tank". In a tank, when I want to turn left for example, the right side tracks induce positive acceleration, while the left side induces less or a negative acceleration. However, with my Can Am, all wheels (or tracks in this case) want to all continue in the same direction. This makes for some very wide slow turns and tired shoulders after a bit. I feel the other factor in this is the rubber tracks and their friction on different surface.

I've always wondered how well those track modules work.  They've got drive sprockets, however, and don't rely on skin friction.

As to your steering issues, I'm not surprised.  Your vehicle was designed to move and steer on wheels so the tracks have to kluge onto that somehow, without the types of controls normal on tracked vehicles.  Does your system include separate clutch or brake mechanisms for each side of the vehicle?  If not then you've got the same sort of situation as a halftrack, only worse because have to manhandle the manual steering of the front tracks.  Due to their long area of ground contact, you have to fight lateral friction on both ends of the front track when you turn the handlebar.

A brief history of tracked vehicle steering:  In the beginning, tracked vehicles evolved from wheeled vehicles so used the same sort of drivetrain with an automotive-type differential and both tracks always going in the same direction.  To steer, each half of the drive axle had its own clutch and brake system to stop one side while the other side pushed.  This made for jerky turning by short, straight segments at slight angles to each other, and thus a turn radius.  if you tried to turn too far in 1 spot, you'd throw a track. This is still how most tracked construction equipment turns because it's simple and durable.  During WW2, however, the crossdrive transmission came into use.  This allowed the tracks to go in opposite directions so the vehicle could pivot in place and has since then become pretty much universal on AFVs.

Then there were halftracks.  Most of these began as conversions of normal trucks so both tracks always went in the same direction and steering was by the front wheels.  These didn't turn well at all, for the same reason that trucks with multiple rear axles don't turn well.  Later, however, purpose-built halftracks incorporated the clutch-brake system to help with turning.  Pivot steering was never an option due to having the front wheels, and is one reason why halftracks disappeared after WW2.  If your ATV lacks separate clutch-brake systems for each side of the vehicle, then you've got an early-type halftrack except you also have to fight the front tracks with the handlebars.

[Kenobi McCormick]

13 minutes ago, Geschosskopf said:

I've always wondered how well those track modules work.  They've got drive sprockets, however, and don't rely on skin friction.

As to your steering issues, I'm not surprised.  Your vehicle was designed to move and steer on wheels so the tracks have to kluge onto that somehow, without the types of controls normal on tracked vehicles.  Does your system include separate clutch or brake mechanisms for each side of the vehicle?  If not then you've got the same sort of situation as a halftrack, only worse because have to manhandle the manual steering of the front tracks.  Due to their long area of ground contact, you have to fight lateral friction on both ends of the front track when you turn the handlebar.

A brief history of tracked vehicle steering:  In the beginning, tracked vehicles evolved from wheeled vehicles so used the same sort of drivetrain with an automotive-type differential and both tracks always going in the same direction.  To steer, each half of the drive axle had its own clutch and brake system to stop one side while the other side pushed.  This made for jerky turning by short, straight segments at slight angles to each other, and thus a turn radius.  if you tried to turn too far in 1 spot, you'd throw a track. This is still how most tracked construction equipment turns because it's simple and durable.  During WW2, however, the crossdrive transmission came into use.  This allowed the tracks to go in opposite directions so the vehicle could pivot in place and has since then become pretty much universal on AFVs.

Then there were halftracks.  Most of these began as conversions of normal trucks so both tracks always went in the same direction and steering was by the front wheels.  These didn't turn well at all, for the same reason that trucks with multiple rear axles don't turn well.  Later, however, purpose-built halftracks incorporated the clutch-brake system to help with turning.  Pivot steering was never an option due to having the front wheels, and is one reason why halftracks disappeared after WW2.  If your ATV lacks separate clutch-brake systems for each side of the vehicle, then you've got an early-type halftrack except you also have to fight the front tracks with the handlebars.

I raise you the Kettenkrad. Those things are the closest historical analogue to the ATV-with-tracks, they predate power steering, predate epicyclic gearboxes, still had the clutch-brake system integrated into the handlebars. IIRC they would use the front wheel for gentle turns, but after about ten or fifteen degrees of steering input linkages attached to the front fork would begin to actuate the track brakes and steer it via clutch/brake. You could also run them with no front wheel fitted at all, if you so desired.