Long-term Laythe Mission (pic heavy) - ^_^ With Part 45 ^_^

[Brotoro]

5 hours ago, Geschosskopf said:

...I have a car with "automatic traction control".  What this does is decrease the power going to the wheel when it detects wheel slip. I'm thinking that KSP traction control is trying (and failing) to do the same sort of thing.  I don't think the wheels are spinning on the hill, but the traction ccontrol is reducing power to the wheels, as evidenced by the rover's inability to climb hills with it on...

Ah. A fine explanation of what the Traction Control does. But, reducing the Traction Controll setting to zero would only help you climb hills if the program is incorrectly predicting wheel slipping. Otherwise, you're just going to sit there with your wheels slipping uselessly.

i understand why overriding the automatic friction setting and cranking up the friction value helps my rover go up hills, but I'm not sure what wonderful technology the kerbals are using on those wheels that allows then to have their friction values changed on the fly. Do they extend thousands of tiny claws when you crank the friction up from 1 to 5, or what?

[Deddly]

Maybe they are using these

[Geschosskopf]

5 hours ago, Brotoro said:

Ah. A fine explanation of what the Traction Control does. But, reducing the Traction Controll setting to zero would only help you climb hills if the program is incorrectly predicting wheel slipping. Otherwise, you're just going to sit there with your wheels slipping uselessly.

If you have the right-click menu of a wheel open, you'll see there's a non-tweakable slider called "Motor".  If you go around doing donuts and climbing hills with the tweakable Traction Control set > 0, you will see this "Motor" bar going up and down in the same way that "Tire Stress" does.  I'm pretty sure the "Motor" bar is the wheel analog of the Thrust Limiter of engines.  Traction Control > 0 makes the "Motor" bar decrease drastically when going up hills, to the point that it reaches zero on very shallow slopes.  That's why I think Traction Control in KSP does the same thing in KSP as it does in real life.

And I agree, the system is incorrectly predicting wheel slip.  Let.s say you're going full speed on level ground and have the "go forward" key (whatever you've remapped that to) held down.  The system is therefore expecting the rover to be moving at max speed.  But then you start up the hill.  You keep holding the "go forward" key down so the system is still expecting the rover to be going the same speed as before.  However, due to the incline, physics makes it slow down.  Thus, the system sees an expected speed > actual speed, which it interprets to mean the wheels are spinning, so Traction Control cuts power to the wheels, so "Motor" decreases.  But you're still holding down the "go forward" key so the expected speed is still the max, but now because both the slope and the reduced "Motor" are in effect, the system sees even more tire slip so cuts "Motor" even more, and so you quickly grind to a halt.

This is why I think decreasing/disabling Traction Control is more important than increasing friction.

 

5 hours ago, Brotoro said:

i understand why overriding the automatic friction setting and cranking up the friction value helps my rover go up hills, but I'm not sure what wonderful technology the kerbals are using on those wheels that allows then to have their friction values changed on the fly. Do they extend thousands of tiny claws when you crank the friction up from 1 to 5, or what?

There are many vehicles that can vary tire pressure on the fly these days, and also alter the rigidity of their suspensions.  And some, as @Deddly noted, even have retractable cleats

[Tw1]

2 hours ago, Geschosskopf said:

....The system is therefore expecting the rover to be moving at max speed.  But then you start up the hill.  You keep holding the "go forward" key down so the system is still expecting the rover to be going the same speed as before.  However, due to the incline, physics makes it slow down.  Thus, the system sees an expected speed > actual speed, which it interprets to mean the wheels are spinning, so....

Haven't yet read through any documentation on the wheels, but this sounds like a terrible way to measure wheel slip. I was under the impression that the way cars did it used the difference between how much each wheel was spinning. 

As this is a computer game, couldn't they directly compare how fast a wheel's surface is moving compared to the ground, and check if it's touching the ground? Or have it work via SAS?

 

Some of my larger rovers have landings gear bumper wheels, to protect from the troubles of busted tires. It's quite useful. 

 

I so agree about the new mk1. Nice model, but a poor design choice. It's a bit annoying for ladder placement, complicates water landings, and limits craft design more than the old one. Kerbal parts need to maximise the different situations they can be used in. 

There's still the inline for when you want a propper cockpit, but it's not quite the same. 

 

 

[Geschosskopf]

2 hours ago, Tw1 said:

Haven't yet read through any documentation on the wheels, but this sounds like a terrible way to measure wheel slip. I was under the impression that the way cars did it used the difference between how much each wheel was spinning. 

As this is a computer game, couldn't they directly compare how fast a wheel's surface is moving compared to the ground, and check if it's touching the ground? Or have it work via SAS?

As I understand things, under the hood there is really no such thing as a wheel.  "Wheels" are simply lander legs that have the ability to slide over the surface while tarted up with meaningless rotational animations.. There is thus no actual wheel RPM value for the game to use in calculations, which means the game cannot really measure wheel slip.  Instead, it has to infer it somehow from the rest of the situation, plus probably looking up values on pre-ordained curves.

I agree, this sounds like a terrible way to do things, and I think the observed results bear that out.

[Lucky Spacer]

On April 25, 2016 at 7:10 PM, Brotoro said:

...And my new profile picture is in honor of Commander Zoom!

Ok I have searched and failed miserably. How do I make a snazzy Kerbal portrait like this? Also, is there a way to change your kerbals head in the game?

Thanks for any pointers in the right direction.

[Brotoro]

3 hours ago, Lucky Spacer said:

Ok I have searched and failed miserably. How do I make a snazzy Kerbal portrait like this? Also, is there a way to change your kerbals head in the game?

Thanks for any pointers in the right direction.

My kerbal image was just doctored up in Photoshop. (You can tell by some of the pixels, and from me having told you.)

There are mods that change kerbal heads (or just hair, maybe...I never used any of those mods). I don't know if those mods work in 1.1.

 

Edited April 27, 2016 by Brotoro

[Tw1]

On 27/04/2016 at 1:48 PM, Geschosskopf said:

There is thus no actual wheel RPM value for the game to use in calculations, which means the game cannot really measure wheel slip.  

Nah, unity wheel colliders have a radius value, and you can get rpm values, I'm not an expert though, so Idk if there are other technical things getting in the way of something like this being done in KSP.

Edited April 28, 2016 by Tw1

[max_creative]

I designed a plane based on your birddog in 1.1. I have named it the birddog X, because it looks like a T-70 X-wing. It is also completely powered by its 38 RTG's. The only problem is that it flys like a rock and weighs over 18 tons.

[Brotoro]

18 tons? The BirdDog 1.1 only masses 7.5 tons. And 38 RTGs is only 3 tons... so what else did you put on that bird?

I think if you want that much power, you might want to consider fuel cells.

Edited May 3, 2016 by Brotoro

[max_creative]

42 minutes ago, Brotoro said:

18 tons? The BirdDog 1.1 only masses 7.5 tons. And 38 RTGs is only 3 tons... so what else did you put on that bird?

I think if you want that much power, you might want to consider fuel cells.

Well, I have a big rocket engine and a lot of clipped LF+O tanks, two aerospike engines, a bunch of big monopropellant tanks, and a lot of wings. Even with it's 6 J-20's it's a wonder it flys at all.

[Deddly]

4 hours ago, max_creative said:

Well, I have a big rocket engine and a lot of clipped LF+O tanks, two aerospike engines, a bunch of big monopropellant tanks, and a lot of wings. Even with it's 6 J-20's it's a wonder it flys at all.

Hmm, sounds to me like your craft is based on the BirdDog quite loosely, in the way that the The Hammerhead Eagle i-Thrust was based on a TVR.

[max_creative]

14 hours ago, Deddly said:

Hmm, sounds to me like your craft is based on the BirdDog quite loosely, in the way that the The Hammerhead Eagle i-Thrust was based on a TVR.

Oh yeah, and SIX rover wheels. Not the grippy ones, the other ones. 

[Geschosskopf]

On 4/28/2016 at 8:09 AM, Tw1 said:

Nah, unity wheel colliders have a radius value, and you can get rpm values, I'm not an expert though, so Idk if there are other technical things getting in the way of something like this being done in KSP.

But there's nothing actually turning in KSP, so RPM has to be inferred by some algorithm instead of measured directly like we do in real life.  And the algorithm must have some number of built-in assumptions about when and why wheels would slip.  This is unavoidable because, with nothing actually turning, how else can it recognize a wheel-slip situation?  I'm sure they made these assumptions as broad as possible so the algorithm would work in the majority of cases, but that seems to cover no more than gentle slopes.

[Tw1]

On 04/05/2016 at 4:32 AM, Geschosskopf said:

But there's nothing actually turning in KSP, so RPM has to be inferred by some algorithm instead of measured directly like we do in real life.  And the algorithm must have some number of built-in assumptions about when and why wheels would slip.  This is unavoidable because, with nothing actually turning, how else can it recognize a wheel-slip situation?  I'm sure they made these assumptions as broad as possible so the algorithm would work in the majority of cases, but that seems to cover no more than gentle slopes.

Though the wheel colliders don't actually turn, it sort of simulates turning. The force between the wheel and ground is determined by a torque factor and a  friction factor. Wheels have a mass, and radius, and unity presumably calculates rpm based on all these factors. 

Presumably, they're comparing the slip between the ground touching wheels, and reducing torque based on that, leading to the false positive on slopes, as you suggest. 

 I still think linking it to the SAS system would work better.

Edited May 6, 2016 by Tw1

[Brotoro]

What confuses me about how Squad would calculate wheel slippage is that I control my rovers with a binary state control: I'm either pressing the "i" key to go forward, or I'm not; I don't have a continuously-variable throttle. So if the program calculates the translational force the wheels will apply to the ground (assuming a wheel radius and maximum motor torque), and this exceeds the maximum friction force the wheels can provide (based on normal force per wheel and coefficient of friction between the given wheel and given surface), won't I end up spinning my wheels any time I try to move unless there is some sort of automatic traction control (a torque limiter on the wheels)?