Jump to content

Propellers changing vectors at different speeds?


Recommended Posts

Can anyone explain what is happening as the speed of the aircraft changes? I have a contra-rotating prop plane and its behaving weirdly.

tbhzn9M.png
During takeoff, both propellers produce forward thrust.

qMPdKVs.png
However, at the top speed of around 117 m/s the rear propeller produces backwards thrust


NTyp1BK.png
On independent testing of the rear propeller, a similar effect happens. It produces forward thrust(and maxes out at the lower top speed of around 104 m/s as opposed to the 117m/s of the whole setup), when I force it to go beyond 104 m/s by diving the rear propeller loses all thrust. On the same test on the front propeller, the same thing happens but at a different max speed.

Am I right to presume that the thrust vector flips when you exceed the "top speed" of the propeller? Is there any way to counteract this effect?

Link to comment
Share on other sites

A propeller produces thrust by having greater than neutral pitch relative to the airflow over it, which is a combination of radial velocity and the aircraft's forward velocity. This means that a fixed-pitch propeller has a thrust curve: it produces maximum thrust at a certain airspeed, which falls the farther you go from the peak, and indeed reverses once you go so fast that the effective blade pitch is negative, e.g. in a dive.

The solution is a variable-pitch propeller: set a coarser pitch when going faster and a finer pitch when going slower. You can do this by binding the blade pitch to an axis group, so e.g. forward/back or up/down controls the pitch. 

Link to comment
Share on other sites

10 hours ago, Brikoleur said:

A propeller produces thrust by having greater than neutral pitch relative to the airflow over it, which is a combination of radial velocity and the aircraft's forward velocity. This means that a fixed-pitch propeller has a thrust curve: it produces maximum thrust at a certain airspeed, which falls the farther you go from the peak, and indeed reverses once you go so fast that the effective blade pitch is negative, e.g. in a dive.

The most interesting thing about the thrust reversal of the rear prop is that it implies KSP is now modelling airflow caused by props. Both props are attached to the same plane going at the same forward speed, and both are presumably turning at the same RPM with the same number of blades at the same pitch.  Thus, on the surface, you'd think they'd behave identically.  But in real life, the rear prop experiences a higher relative airspeed because the front prop is accelerating air back over the rear prop.  KSP seems to be taking this into account.

So, as in real life, the rear prop needs to have more pitch than the front prop.  Here's a post with some info on this subject:

https://aviation.stackexchange.com/questions/43405/what-do-i-need-to-know-to-design-contra-rotating-propellers-for-a-powered-paragl

According to this, you want both props to have the same number and size of blades, and the same RPM, but the rear prop needs a little more pitch than the front.

 

Edited by Geschosskopf
Link to comment
Share on other sites

  • 2 weeks later...
On 7/13/2019 at 7:27 AM, Geschosskopf said:

The most interesting thing about the thrust reversal of the rear prop is that it implies KSP is now modelling airflow caused by props.

Actually, I'm pretty sure it doesn't model that.

My guess as to what's going on is that  @Mignear has built the plane in some way such that there's something about the rear prop that's different from the front prop. The fix would be to find the difference and address that.

On 7/13/2019 at 7:27 AM, Geschosskopf said:

According to this, you want both props to have the same number and size of blades, and the same RPM, but the rear prop needs a little more pitch than the front.

In real life, yes. Not in KSP, though. Both props should have exactly the same pitch, assuming that they're otherwise constructed identically.

1 hour ago, jpinard said:

How/where do I do that at?

Via the action groups UI in the editor.

First you go to the action groups UI, then you click on a prop blade to select it, then you pick one of the axis groups that show up in the left hand column. When you do that, you'll see that the control authority for the prop blade shows up in the right hand column. Click on that to bind the control authority to the axis group you've chosen.

Leave the axis group menu, then toggle the prop's deploy status to "on".

Now you're all set, and can use that axis group to control your blade pitch in flight.

Link to comment
Share on other sites

1 hour ago, Snark said:

Actually, I'm pretty sure it doesn't model that.

My guess as to what's going on is that  @Mignear has built the plane in some way such that there's something about the rear prop that's different from the front prop. The fix would be to find the difference and address that.

I have tested contra-props in various configurations.  If you have an unpowered rotor as a bearing and a powered rotor on top of it, with sets of blades on both halves of the powered rotor, then the upper/forward blades do indeed affect the lower/rear set of blades, which need more pitch.  If you don't give it more pitch, the lower/rear prop will actually provided negative lift/thrust beyond a certain RPM.  But, if you use 2 rotors at opposite ends of the plane in a push-pull arrangement, then the rear prop is not affected by the front and the same pitch works for both.

Link to comment
Share on other sites

57 minutes ago, Geschosskopf said:

I have tested contra-props in various configurations.  If you have an unpowered rotor as a bearing and a powered rotor on top of it, with sets of blades on both halves of the powered rotor, then the upper/forward blades do indeed affect the lower/rear set of blades, which need more pitch.  If you don't give it more pitch, the lower/rear prop will actually provided negative lift/thrust beyond a certain RPM.  But, if you use 2 rotors at opposite ends of the plane in a push-pull arrangement, then the rear prop is not affected by the front and the same pitch works for both.

Fascinating. I know they said they went to a lot of effort to simulate/abstract realistic prop effects but I didn't know they went that far. I thought it was mostly just compensating for the (game) engine RPM limit.

Link to comment
Share on other sites

4 hours ago, Geschosskopf said:

I have tested contra-props in various configurations.  If you have an unpowered rotor as a bearing and a powered rotor on top of it, with sets of blades on both halves of the powered rotor, then the upper/forward blades do indeed affect the lower/rear set of blades, which need more pitch.  If you don't give it more pitch, the lower/rear prop will actually provided negative lift/thrust beyond a certain RPM.

I suspect the difference is related to drag occlusion, I seriously doubt there's a more general airflow simulation.

4 hours ago, Geschosskopf said:

But, if you use 2 rotors at opposite ends of the plane in a push-pull arrangement, then the rear prop is not affected by the front and the same pitch works for both.

This has not been my experience when testing push-pull configs, I've spent hours trimming and re-trimming the tail prop to keep up with the nose.

Link to comment
Share on other sites

6 hours ago, Geschosskopf said:

I have tested contra-props in various configurations.  If you have an unpowered rotor as a bearing and a powered rotor on top of it, with sets of blades on both halves of the powered rotor, then the upper/forward blades do indeed affect the lower/rear set of blades, which need more pitch.  If you don't give it more pitch, the lower/rear prop will actually provided negative lift/thrust beyond a certain RPM.  But, if you use 2 rotors at opposite ends of the plane in a push-pull arrangement, then the rear prop is not affected by the front and the same pitch works for both.

That's interesting to hear, would love to know more!

However... I still find myself strongly doubting that they've modeled anything of the sort.  (If I'm wrong, would love to find that out, of course, which is why I'd love to hear more.  And I should go do some more experiments of my own.)

I base that presumption on what I know of the way KSP models lift and drag (and what it doesn't do), with some idea of what would be likely be involved in an attempt to do so (i.e. my programmer's and physics-major's gut saying "seriously big fat hairy deal"):  an unattractive prospect to a software developer, with a very large cost to develop (lots of programmer time, even more tester time, extremely fertile ground for potential bugs) and a very minor benefit (subtle effect that most players won't notice).

In my own contra-rotating prop designs, I haven't noticed anything of the sort.  They "just work" and I don't see any discernable difference from the fact that one propeller's behind the other.  (Some speculation on why you're observing it and I'm not, below.  Further testing is indicated, I should go and tinker with this.)

2 hours ago, The_Rocketeer said:

I suspect the difference is related to drag occlusion, I seriously doubt there's a more general airflow simulation.

Except that I'm pretty sure that KSP doesn't model drag occlusion at all, except for stack-mounted objects that are connected at nodes.

It models heat occlusion, but not drag occlusion other than the specific case mentioned above.  That's why, for example, airbrakes work even if you hide them behind a heat shield.  That's why, if you have a Mk1 reentry capsule with a bottom-mounted heat shield, and it's undergoing a few gees of aerobrake deceleration, and you jettison the heat shield (which then immediately gets pinned against the bottom of the capsule by the wind), you get higher deceleration than when the shield was actually attached to the craft:  because now you're getting air resistance from the bottom of the capsule plus the force of the heat shield pinned against it.  The shield doesn't occlude the craft from drag.

2 hours ago, The_Rocketeer said:

I've spent hours trimming and re-trimming the tail prop to keep up with the nose.

Again, I'd love to hear more, with specific examples-- this hasn't been my own experience (and I should do more testing myself).  My own experience has been that no rotor ever affects any other rotor, as long as one's not mounted on the other.

7 hours ago, Geschosskopf said:

If you have an unpowered rotor as a bearing and a powered rotor on top of it, with sets of blades on both halves of the powered rotor, then the upper/forward blades do indeed affect the lower/rear set of blades, which need more pitch.

I suspect (again, need more info and/or observations to be sure) that what you're observing isn't due to some volumetric airflow modeling, but rather due to the fact that you mounted one rotor on top of another.  If you mount one rotating thing on top of another rotating thing, that unavoidably couples their physics together, the way it's implemented.  The rotation of one affects the rotation of the other because they're mounted to each other.

IRL counter-rotating props don't have to have that limitation.  The top one can be mounted to a shaft that passes through the center of the bottom one and doesn't actually couple to it (i.e. the bottom one is on a hollow axle).  There's no reason why Squad couldn't have implemented a rotor part like this (i.e. a thing with a rotating armature, that has non-rotating attachment nodes on top and bottom), and indeed I've seen quite a few players ask for this; wouldn't be surprised to see a modder produce one in due course.  ;)

But since we don't have such a part currently, one has to get creative.

You can mount one rotor to another rotor, on top of it, but then it's unavoidably affected by the lower rotor and I suspect there's going to be some tinkering required to compensate for that, not to mention that there may be potential stiffness problems from "one narrow-diameter thing attached on a tiny attach node atop another narrow-diameter thing."

The other option is to get creative with part offsets, which is what I do in my own designs.  If I want to have two counter-rotating props-- call them A and B, with B above A-- then I don't mount A to the aircraft and then mount B to A.  Instead, I mount them both directly to the aircraft, and then use the offset tool to move B so that it is located directly atop A.  That way, as far as the game is concerned, in the "tree" model of the vessel, both rotors have the same, non-moving part as their direct parent to which they're rigidly attached.  I can then set up the two rotors so that they are perfectly identical in every way (other than being mirror-image reversed), and they work just fine and I don't get any rogue asymmetric torque or other such problem.

That said, though, I haven't gone specifically looking to see if I could find any difference anywhere-- I just built my ships assuming that there's no such problem, and they "just worked", so I've been taking that as evidence that no such problem exists.  I should go take a closer look.

Link to comment
Share on other sites

Well, YMMV.  All I know is, with the original BG rotors, you could make contra-rotating props without any difficulty.  The powered rotor's 2 halves spun at the same speed in opposite directions if mounted on an unpowered rotor used as a bearing, so both sets of blades used the same pitch and torque effects were non-existent.  This is how we made our original batches of helicopters and autogyros.

But then 1.7.3 came out and this changed.  If  you make a system like this now, the rear/lower set of blades on the powered bearing will initially produce less thrust/lift than the front/top set.  And as airflow through the blades increases, this becomes more pronounced  until the rear/lower set is producing negative lift. 

However, you can combat this by increasing the pitch of the rear/lower set of blades compared to the front/upper set.  BUT, if you do this, then the 2 sets of blades no longer spin at the same speed (due to having different drag) so you start getting the torque effects which you were trying to avoid by using contra-rotating blades.  So, the overall outcome is rather like in real life, which is HIGHLY annoying because we can't use the same methods they have in real life to avoid this problem.  But it's ONLY for this stacked powered/unpowered rotor (and thus electric rotor) configuration.  I find that push-pull planes with cockpit and fuel tanks between the rotors doesn't have this issue.

Link to comment
Share on other sites

 

Just now, Geschosskopf said:

But then 1.7.3 came out and this changed.

Sure, I don't deny that something changed between the updates.  But how do we know it's airflow and not something else?

I've gone and done an experiment to see if I could spot any airflow interactions between different propellers when one is not attached to the other.  Details below, but the executive summary is that I did not see any such interaction.  (This is in 1.7.3.)

I built this craft in the VAB:

0FvNFrk.png

Both rotors are mounted directly to the probe core.  It looks like the top rotor's attached to the bottom one, but it isn't.  I attached them both to the probe core, then used the offset tool to locate the one physically atop the other-- but it's still "attached" to the probe core underneath.  In this way, the rotors' rotation is completely independent, both are equally rigid.

That way, if there is any phenomenon that involves the two rotors somehow interacting with each other, we can deduce that it comes from airflow (such as has been discussed in this thread) and not something involving rotation physics.

I launched it, and here's what I observed as it climbed:

cyNWwAw.png

All I did was hit Z to max the throttle (which I tied to RPM limit of both rotors), and was otherwise hands-off the keyboard, with no control input, and I deliberately did not engage SAS; it's free to tumble or spin as it likes.

Result:  It rose straight up.  The probe core experienced zero torque and didn't roll in either direction, because the torque from the two motors was perfectly balanced.  Aero display shows identical up-arrows for all prop blades.

I enabled the aero stats display for the PAW and pitched both sets of blades (via action group button) more steeply, to accelerate to a 130 m/s vertical climb, which is a respectable airflow.  Here's what I observed:

WPbA1Lz.png

The top PAW is for one of the top propeller blades, and the bottom PAW is for one of the bottom propeller blades.  The craft is rising vertically at 130 m/s in this shot, with both rotors spinning at the max 460 RPM.

As you can see, the lift and drag on both sets of props is essentially identical.  I note that the lift on one is 3.11 kN and the lift on the other is 3.12... but that's just a 0.3% difference and certainly not some big, major factor that anyone would have to adjust prop pitch or do anything else about.  Certainly it was utterly invisible in terms of gameplay; I never would have been able to detect it, if I hadn't carefully been constructing a controlled experiment and peering at the numbers with a magnifying glass.

Whatever's causing that difference, it's so tiny as to be utterly negligible in terms of gameplay-- it certainly doesn't describe a situation such as you or the OP have run into.

So at this point, you and I are observing very different results in-game.  You see a major effect, and I see none whatsoever.  And as far as I can tell from your description, the only difference I'm aware of in our construction techniques is that you mount one rotor to the other, whereas I don't.

So it seems reasonable to me to suppose that there's no airflow modeling going on (because if there were, I'd observe it too), and that what's actually happening is that it's something about the physics interaction of mutually mounted rotors.  Doesn't mean that there couldn't in principle be some other explanation, I suppose, but that's the only one I can think of that fits the available observations.

Link to comment
Share on other sites

2 minutes ago, Snark said:

Both rotors are mounted directly to the probe core.  It looks like the top rotor's attached to the bottom one, but it isn't.  I attached them both to the probe core, then used the offset tool to locate the one physically atop the other-- but it's still "attached" to the probe core underneath.  In this way, the rotors' rotation is completely independent, both are equally rigid.

Oh, that's genius!  Squeezing a twin-engined plane to masquerade as a single contra-prop thing :D.  I wish I'd thought of this.  The way the offset tool has "steps" of  movement is so useful, so you can get both rotors co-axial :).  I used that property with a 2-rotor helicopter with the 2 rotors angled slightly outboard so the blades would intermesh, but never thought to do it on contra-props.

The lack of blade interaction with 2 powered rotors agrees with not seeing any in a push-pull, either.

Link to comment
Share on other sites

8 minutes ago, Geschosskopf said:

Oh, that's genius!

I agree... though I can't claim credit for it, much though I'd like to.  ;)  Saw someone else doing this somewhere, right at at the start of BG (unfortunately, now can't remember who or where), immediately thought "oh, of course", and have built every single coaxial vehicle like this ever since.  It works fantastic, no asymmetric forces requiring futzing around, and it's super sturdy/rigid so it doesn't cause vibration / flopping problems.

Here's a Duna flyer I built with helicopter blades using the same principle.

Spoiler

 

Link to comment
Share on other sites

Just now, Snark said:

I agree... though I can't claim credit for it, much though I'd like to.  ;)  Saw someone else doing this somewhere, right at at the start of BG (unfortunately, now can't remember who or where), immediately thought "oh, of course", and have built every single coax vehicle like this ever since.

My 1st thing when BG came out was an autogyro so I started with the stacked rotors, only both of them unpowered and both sets of blades on the top rotor.  This worked marvelously when properly adjusted so I also used the same method on powered contra-props.  Then 1.7.3 happened and my autogyro doesn't work so well anymore.....  It still works OK, it's just not quite as good.

Of course, the autogyro was built using control surfaces as blades, which looks clunky.  So as I had to tweak it some anyway due to 1.7.3, I tried putting the actual helicopter blades on it.  This doesn't work as well as the control surfaces.  So, I've kinda had to accept that autogyros are not particularly fun right now.

Link to comment
Share on other sites

10 hours ago, Snark said:

 

My guess as to what's going on is that  @Mignear has built the plane in some way such that there's something about the rear prop that's different from the front prop. The fix would be to find the difference and address that.

 

From what I remember, the only difference was that the rear rotor was facing backwards with a clockwise rotation(functionally the same as a forward facing rotor set to anti-clockwise). The blades were the default angles(100 authority) except I used the anti-clockwise variant of the blades. Both rotors were set to max RPM and torque.
Its unfortunate that the plane in the pictures were an early build that got overwritten with other changes to the rotor blades as I figured things out so we couldn't find out what was going on.

I'm quite certain the default angle of the anti-clockwise variant of the blades is different from the default angle of the clockwise variant of the blades, resulting in different top speeds when independently testing the each rotor. When we exceeded the rear rotor's top speed(due to the front rotor having a higher top speed), it started producing negative thrust which is what we see in the pictures.
 

On 7/13/2019 at 10:27 PM, Geschosskopf said:

According to this, you want both props to have the same number and size of blades, and the same RPM, but the rear prop needs a little more pitch than the front.

 

That is the same conclusion I came to during my testing, though I was doing it for another reason, having 1 rotor performing well at low speed and the other rotor performing well at high speed so that acceleration and top speed can be somewhat tuned on a fixed pitch contra-rotating prop setup.

Edited by Mignear
Link to comment
Share on other sites

Don't have a long time to get into the details today, but the answer you're looking for is no, there's no effect the front propellers pass to the rear propellers.  Something else is different about the two propellers, but without looking at the craft file, I can't say what that might be - it'd have to be a difference of blade angle or a difference of rotor RPM.

Link to comment
Share on other sites

On 7/27/2019 at 1:13 AM, Snark said:

Actually, I'm pretty sure it doesn't model that.

My guess as to what's going on is that  @Mignear has built the plane in some way such that there's something about the rear prop that's different from the front prop. The fix would be to find the difference and address that.

In real life, yes. Not in KSP, though. Both props should have exactly the same pitch, assuming that they're otherwise constructed identically.

Via the action groups UI in the editor.

First you go to the action groups UI, then you click on a prop blade to select it, then you pick one of the axis groups that show up in the left hand column. When you do that, you'll see that the control authority for the prop blade shows up in the right hand column. Click on that to bind the control authority to the axis group you've chosen.

Leave the axis group menu, then toggle the prop's deploy status to "on".

Now you're all set, and can use that axis group to control your blade pitch in flight.

Thank you!

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...