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

[SpannerMonkey(smce)]

Looking fwd to the update, don't forget the tweakscale if the model's suitable,

And as an infobite to those less curious or much younger than I, way back before RL marine propellers were in existence and paddle wheels were the new big thing the commercial first trial between a paddle wheeler and a prop driven vessel featured a design very similar to the helical drive unit, although it was shorter the function was identical. and by historical record the screw won hands down, spelling the end of large paddle wheelers and of course changing the world.

AS marine stuff is my thing, would you mind if I attacked your trial version to see if an actual propeller is doable.

edit dont know if its relevant or even useful the FS (yes again) prop rotator module has a facility to swap the model for a translucent disc which replaces the prop and simulates motion blur very successfully, could this be adapted perhaps to achieve a similar result ?

Edited August 30, 2014 by SpannerMonkey(smce)

[lo-fi]

Mate, you're always welcome. Feel free.

If you want to play with dedicated propellers, it might be best if I just make a dedicated module, though. Actually, gives me an idea to make it all more modular. I'll be in touch, and thanks for the tip on the blurred model.

[Vrana]

Sharing a little something i made with your wheels.

Javascript is disabled. View full album

Ive built quite a few similar rover-bases but this one takes the cake due to the wheels. Capable of moving unattended and at x4 physical warp at 20ish m/s or up to 40m/s attended and no physical warp on the moon... Mind you there is plenty of stuff to break on the bottom side and it never touches the ground(unattended drive). This makes it the fastest mobile base i made so far.

[lo-fi]

Lovely work, thanks for sharing :)Thats a hell of a pace you managed to get up on Mun with wheels. Where are the body parts from?

Anybody tested in higher gravity? I admit, I've totally neglected that thus far.

[Vrana]

Hmm... The rover itself is a mish mash of parts from many mods.

Front to back main axis:

LLL command pod,

STX fuel tank,

Stock Lab,

STX crew pod,

another STX crew pod,

KW fuel tank,

Karbonite conversion thingy,

Stock large docking.

Wheels are mounted on LLL structural parts, there are also radial Karbonite drills and LLL RTGs.

Upper deck is B9 plates, solar panels are mounted on Infernal robotics Rework Extendatrons, and the radar on top of it is LLL.

There is a bunch of other stuff scattered all over.

Edited August 30, 2014 by Vrana

[Wosser1]

Related to the disappearing wheels:

When putting 6 large wheels around the center, it seems the code to check steering directions or similar is putting out the following:

[Error]: Invalid parameter because it was infinity or nan.

Causing the wheels not to be loaded. After some stuttering the code stops running and the suspension gets initialised.

The wheels still aren't visible.

[lo-fi]

Thanks, some cool stuff in there.

Wosser1, would you mind trying an updated plugin version for me and passing some logs back? Shouldn't happen with 1.6d, as I put some code in to check for infinity in the steering loop and default to zero, so interested to find what's going on there. Thanks for the info.

Also, could you post a screen grab of your design please?

[ratchet freak]

For the ackerman correction would it be possible to model the center of turn directly and then just point the axles of the wheels to it?

Seems to be more straightforward than trying to derive angles.

[lo-fi]

An entirely sensible question! I think possibly yes. Zodius and I have discussed at length but I've been so busy with other things I've not really put to much time into it. I came to the conclusion that however you look at it, getting a rock solid handle on where the wheels are in relation to each other is vital to be able to run any kind of calculation, and that does seem to have been the challenging bit! It sounds like you've got a decent understanding, so I'd welcome some input if you've got some.

I'm currently completely overhauling my code to make it more flexible and completing the bits I need to to finally ditch the stock modules from the wheels. The tracks run nothing stock and the steering is actually harder to do anything with when you're pulling transforms that have been rotated by stock modules. It's about time I simplified and took complete control of everything - it should make the more advanced features far easier to handle. I've Learned a lot since I started!

[ratchet freak]

The key with my idea is that you need to have a single point all wheels orient themselves with and you have the attachment of the wheel and that point in the same frame of reference. This will mean each wheel can be looked at separately.

Then using a LookAt transform you can grab a very good rotation matrix by having the "towards" vector in the direction of the steering axis (around which the wheel rotates to steer) and the "up" vector towards (or away from) the steering point, the new up will become the axle of the wheel.

No need for a single trig function

[ZodiusInfuser]

The key with my idea is that you need to have a single point all wheels orient themselves with and you have the attachment of the wheel and that point in the same frame of reference. This will mean each wheel can be looked at separately.

I too came to this conclusion. The rotation centroid can be calculated based on the user inputs, be it forward/backward and turn, or full 2D motion inputs. I wrote a whole document with figures and sent it to lo-fi some time ago . Was actually derived from my more complex Hexapod walking system I did for a personal project.

Having all wheels calculate together does allow for some extra abilities though, mainly normalising the vehicles speed based on the furthest wheel, or limiting how close the rotation centroid is allowed to be based on wheel turn limits. Normalisation can be avoided by assuming wheels on the arc that intersects the CoM run at 100% speed, those inside run slower and those outside run faster. It is certainly a needed feature for vehicles such as this to work correctly (which is my goal and the reason I've been in contact with lo-fi).

And don't get me started on how this can be applied to omni/mecanum wheels

Edited August 30, 2014 by ZodiusInfuser

[Wosser1]

Wosser1, would you mind trying an updated plugin version for me and passing some logs back? Shouldn't happen with 1.6d, as I put some code in to check for infinity in the steering loop and default to zero, so interested to find what's going on there. Thanks for the info.

Also, could you post a screen grab of your design please?

Never mind, I thought I already updated but apparently not. It's solved in 1.6d.

[lo-fi]

Ah, got ya. I did consider that, though I'm planning to use the steerangle property of the wheelcollider rather than rotating it in a transform like the stock module does. May have to be some trig used after all.

[lo-fi]

Never mind, I thought I already updated but apparently not. It's solved in 1.6d.

http://i.imgur.com/ebE9v6z.png?1

Ah, I did wonder. Thanks, that's good to know. Next release will print the version number to the log when a part is placed, it should help identify.

[lo-fi]

Never mind, I thought I already updated but apparently not. It's solved in 1.6d.

http://i.imgur.com/ebE9v6z.png?1

I too came to this conclusion. The rotation centroid can be calculated based on the user inputs, be it forward/backward and turn, or full 2D motion inputs. I wrote a whole document with figures and sent it to lo-fi some time ago . Was actually derived from my more complex Hexapod walking system I did for a personal project.

Having all wheels calculate together does allow for some extra abilities though, mainly normalising the vehicles speed based on the furthest wheel, or limiting how close the rotation centroid is allowed to be based on wheel turn limits. Normalisation can be avoided by assuming wheels on the arc that intersects the CoM run at 100% speed, those inside run slower and those outside run faster. It is certainly a needed feature for vehicles such as this to work correctly (which is my goal and the reason I've been in contact with lo-fi).

http://www.pecktiongchoon.com/wp/wp-content/uploads/ptc-modular-trailer-05.jpg

And don't get me started on how this can be applied to omni/mecanum wheels

Yes, another good reason to ditch the stock module: Complete control over motor torque. I'll be in touch again after my re-write, I should have everything in place to get this working correctly after that.

[ratchet freak]

I too came to this conclusion. The rotation centroid can be calculated based on the user inputs, be it forward/backward and turn, or full 2D motion inputs. I wrote a whole document with figures and sent it to lo-fi some time ago . Was actually derived from my more complex Hexapod walking system I did for a personal project.

Having all wheels calculate together does allow for some extra abilities though, mainly normalising the vehicles speed based on the furthest wheel, or limiting how close the rotation centroid is allowed to be based on wheel turn limits. Normalisation can be avoided by assuming wheels on the arc that intersects the CoM run at 100% speed, those inside run slower and those outside run faster. It is certainly a needed feature for vehicles such as this to work correctly (which is my goal and the reason I've been in contact with lo-fi).

http://www.pecktiongchoon.com/wp/wp-content/uploads/ptc-modular-trailer-05.jpg

And don't get me started on how this can be applied to omni/mecanum wheels

You can set cones, to limit where the centroid will be allowed to be,

And the speed difference is the same factor of distance to the centroid; if the inside wheel is D1 from the centroid and the outside is D2 then the speed of the inside wheel is D1/D2 times the speed of the outside wheel

[lo-fi]

I think we'll be able to figure this out between us

Did someone tweet/feature/redit or otherwise post something about the mod, btw? Downloads have jumped up sharply over the last few days!

[ZodiusInfuser]

Yes, another good reason to ditch the stock module: Complete control over motor torque. I'll be in touch again after my re-write, I should have everything in place to get this working correctly after that.

Yea, I thought about making my wheels use the stock module, just to get them out there but I can't do it, knowing a much better system is possible.

You can set cones, to limit where the centroid will be allowed to be,

My understanding of the problem is that the centroid is always along a line out from the center of the craft that is perpendicular to the direction of travel, with it's distance being related to the amount of turning wanted. With that you'd limit the distance between center and centroid to that determined by the cone intersection. The issue is, one wheel may be at an odd angle or have limited range, so you need to find the maximum distance each of these independent cone calculations return before you can actually place the final centroid. Time to dig out my images (lo-fi's seen it before )

In the above you can see that the wheels to the right cannot turn to face the centroid, so it needs to be positioned to align with their cones. This means you need to know the worst case cone, by iterating through all the wheels. I'd love it if there was a solution that avoided that, but I can't think of one at the moment.

And the speed difference is the same factor of distance to the centroid; if the inside wheel is D1 from the centroid and the outside is D2 then the speed of the inside wheel is D1/D2 times the speed of the outside wheel

Doesn't that mean the inside wheel needs to know D2, which is a parameter of the outer wheel? Yes it could iterate though and find it, but I fear the performance impact if every wheel did that independent of each other. Also bare in mind that the centroid position would be dynamic, so you can't cache the value of D2 in case the user inputs change. Also I'm coming at this from the perspective of Infernal Robotics, which would allow for the wheel positions to dynamically change too.

Edit:

I think we'll be able to figure this out between us

I'm sure we will . It would be great if there was just one module for wheels that combined all this functionality. Not sure how tracks fit into the mix though, maybe treated like omni wheels.

Edited August 30, 2014 by ZodiusInfuser

[Wosser1]

• Other wheels you could make could be similar to the MAKO from Mass Effect (like your large wheels, but with higher suspension - still very similar though).
  

Wayland Corp also had some wheels, capable of going into VTOL mode (acting like repulsors) but those were quite experimental.

• Another idea: surface attachable wheels with another attachment point on the other side to allow them to be in-line with other stuff, like this:
  

Also the Anti-grav repulsors remind me of the M-44 Hammerhead also from Mass Effect, maybe the inspiration?

• As for tracks, I noticed the similarities with Caterpillar Tracks, after looking in to it, it's not a coincidence (you had to start somewhere).
  

• When you fine-tune the repulsors to go over water, you could make an undercarriage of repulsors with a surrounding skirt (without a colliding mesh) to resemble a hovercraft.
  

• Another track idea: with the attachment point on the axis, so the suspension would turn the whole track with the axis as center (if you know what I mean).
  

(larger image)

[lo-fi]

The tracks don't really do anything vastly different to wheels tbh. I coded my plugin to be as broad as possible, which is why it took me only a few hours to get the screw drive working using it. I realised yesterday I could further modularise, which is what I'm in the middle of now. I have a master module that deals with placement and direction calculation, then you can bolt other modules to it as you wish for specific functions. The tracks now use that master module, plus another to deal with user input and communication to the wheelcolliders, then a small module for the wheels rotation and suspension movement and finally a tiny module for the track texture rotation. The screw drive you can ignore the texture rotation as it's not needed, and treat the helical part as a single track wheel, the mesh of which is simply mounted longitudinally rather than transverse.

You really don't want to have a master calculation, just let each wheel figure out its own rotational data based on user input and its location fed into the algorithm. You'll drive yourself completely insane if you try to have some kind of controller module that tracks all that kind of stuff and communicates down the the wheels! Simple arithmetic happens so fast on modern computers you might as well not worry about it. I almost have it working with a bit of trig after half an hour in Excel, though I stopped because I couldn't control the torque or the wheel rotation exactly how I wanted alongside the stock module. This is all about to change

To elaborate on my 'here be dragons' comment earlier: IMO the centroid method starts to look a bit flaky as soon as you start talking KSP and its sandbox nature. It's fine on a vehicle where you've got control of how all the wheels are placed, but what happens when you've got a couple of wheels mounted higher or lower than the others? Mixed wheel types? At a funny angle? The bloody root part mounted fifteen degrees off to the right and upside down? It's an absolute minefield, I have discovered! That's not to say it won't work, but there are enough considerations that make me think twice about whether I can make it robust enough.

[lo-fi]

• Other wheels you could make could be similar to the MAKO from Mass Effect (like your large wheels, but with higher suspension - still very similar though).
  

Wayland Corp also had some wheels, capable of going into VTOL mode (acting like repulsors) but those were quite experimental.

• Another idea: surface attachable wheels with another attachment point on the other side to allow them to be in-line with other stuff, like this:
  

http://i.imgur.com/7gxlAUl.jpg?1

Also the Anti-grav repulsors remind me of the M-44 Hammerhead also from Mass Effect, maybe the inspiration?

http://img1.wikia.nocookie.net/__cb20100413010019/masseffect/images/f/f0/M44Hammerhead.jpg

• As for tracks, I noticed the similarities with Caterpillar Tracks, after looking in to it, it's not a coincidence (you had to start somewhere).
  

• When you fine-tune the repulsors to go over water, you could make an undercarriage of repulsors with a surrounding skirt (without a colliding mesh) to resemble a hovercraft.
  

• Another track idea: with the attachment point on the axis, so the suspension would turn the whole track with the axis as center (if you know what I mean).
  

http://i.imgur.com/dWDH0nw.jpg?1

(larger image)

Great minds think alike, and all that! Zodius sent me pictures of a robot he made with almost exactly that track arrangement. I have something in the works Yeah, I've kind of unofficially taken on the RBI stuff where they left off. I re-wrote the plugin from the ground up, and it seems to have been largely well received. The thought had occurred about the hovercraft skirt, it will actually be very simple to do. I believe Spanner may beat me to that one, hovercraft are a bit of a passion of his.

The repulsors: quite probably, though unconsciously. I loved that series of games!

Stackable wheels with a static centre.... That's a nice idea. Would be well suited to those track units above too.

Keep the ideas coming Every time I get hold of something new it helps me improve what I've done before.

Edit: apologies for all the edits, I'm tired, still a little ill and a bit drunk on medicinal whisky!

Edited August 30, 2014 by lo-fi

[ratchet freak]

Yea, I thought about making my wheels use the stock module, just to get them out there but I can't do it, knowing a much better system is possible.

My understanding of the problem is that the centroid is always along a line out from the center of the craft that is perpendicular to the direction of travel, with it's distance being related to the amount of turning wanted. With that you'd limit the distance between center and centroid to that determined by the cone intersection. The issue is, one wheel may be at an odd angle or have limited range, so you need to find the maximum distance each of these independent cone calculations return before you can actually place the final centroid. Time to dig out my images (lo-fi's seen it before )

https://www.cubbyusercontent.com/pl/SteeringLimits.png/_070255e2bc524d77b2debbc72c410c0f

In the above you can see that the wheels to the right cannot turn to face the centroid, so it needs to be positioned to align with their cones. This means you need to know the worst case cone, by iterating through all the wheels. I'd love it if there was a solution that avoided that, but I can't think of one at the moment.

the centroid can be anywhere, in a RL car it's in line with the non steering back wheels (behind CoM), and you can put it behind the craft so in high speeds going left is like changing lanes on the freeway. like active 4 wheel steering:

On the car on the right the centroid is behind it.

For straight ahead the centroid is off to the side at infinity, for crabbing it's to the front or back, for turning in place it's under the craft itself.

Doesn't that mean the inside wheel needs to know D2, which is a parameter of the outer wheel? Yes it could iterate though and find it, but I fear the performance impact if every wheel did that independent of each other. Also bare in mind that the centroid position would be dynamic, so you can't cache the value of D2 in case the user inputs change. Also I'm coming at this from the perspective of Infernal Robotics, which would allow for the wheel positions to dynamically change too.

no it only means that each wheel needs to know the distance of the centroid to CoM and the speed CoM wants. Using a max speed on the outer does require a iteration over the wheels to find the wheel furthest but it only needs to happen once and once you have the max speed of the CoM you can pass that to each wheel.

[ZodiusInfuser]

the centroid can be anywhere, in a RL car it's in line with the non steering back wheels (behind CoM), and you can put it behind the craft so in high speeds going left is like changing lanes on the freeway. like active 4 wheel steering:

http://upload.wikimedia.org/wikipedia/commons/thumb/8/8d/4WSselect.svg/800px-4WSselect.svg.png

On the car on the right the centroid is behind it.

For straight ahead the centroid is off to the side at infinity, for crabbing it's to the front or back, for turning in place it's under the craft itself.

That is true about the centroid being anywhere. I was saying its on a line perpendicular to the direction vector because that simplifies the calculations involved in deriving its position based on velocity and turn rate:

Of course, the vector can be in any direction to enable combinations of forward motion and crabbing. If the turn rate is at zero degrees then the calculations naturally go off to infinity as you noted. Inversely, with no velocity the centroid would be at the CoM or a user defined location, with wheel speed being directly related to turn rate. Here's what I posted to lo-fi at the time.

- Translation Only: The centroid is off to infinity on a line perpendicular to the XZ vector. As such it can effectively be ignored

- Rotation Only: The centroid is at the origin of the craft (so centre of mass or otherwise).

- Both: The centroid position is on a line perpendicular to the XZ vector. Its distance from the craft origin (e.g CoM) can be calculated using r = s/theta, where s is the magnitude of XZ, and theta is the magnitude of Y. Centroid = R.rotate(theta) + Origin, where R is the vector[r,0].

no it only means that each wheel needs to know the distance of the centroid to CoM and the speed CoM wants. Using a max speed on the outer does require a iteration over the wheels to find the wheel furthest but it only needs to happen once and once you have the max speed of the CoM you can pass that to each wheel.

Ah, I misunderstood your use of D1 and D2 then. I still thing you would need to recalculate the values though, whenever the user input (and therefore the centroid) changes, or if the wheels are moved due to some robotic assembly. Depending on the specific use case the calculations can be done once or every frame. It seems the best way to avoid this is just to allow wheels further away from the centroid than the CoM (or other designated point) to run faster than the normally would. That being said, if you're having to iterate for the steering limit stuff you might as well do this at the same time.

Anyway, that's enough about it from me for tonight. Lo-fi has heard this all from me before in various forms

[Wosser1]

Since tracks are receiving the highest requests:

Related to RBI, you could bring back these as well:

And maybe add a medium sized flatter version of the large tracks like this:

Another one:

Like this or similar, maybe with an overlapping chain structure.

(Found on Pedal Dozer)

Some others:

Of course there is also this new wheel design:

where the tires themselves act as dampers/suspension

[Gaalidas]

I take a break from this thread for a few days and come back to find you all speaking martian swahili. I have absolutely no idea what you all are talking about... but it sounds cool either way.