Kerbal Space Program 1.7.3 is live!

[Bartybum]

19 minutes ago, XLjedi said:

I see... you're installing them a bit different than I did.  I thought the range of motion was a bit wide on the props, so I just left mine pointing forward, but I like your positioning better I think.  I may have to tinker with that, I was trying to go for easiest possible installation to get people to a workable fixed blade prop.  But the way you point the leading edge is probably more correct, and it's consistent with how I mount the rotor blades.  ...and your forward/reverse thrust has the correct leading edge.  So agreed.  But why do you think that works in reverse?

Well I mean, it works in reverse because under my system, pitching the blades backwards induces a negative angle of attack between the flow and the blade, generating negative lift.

Just now, XLjedi said:

I wouldn't worry too much about it, just invert your values when you assign the pitch to your preferred hotkey.

Don't worry, I saw the edited post I'm all too guilty of doing that myself. But yeah, I'm happy to cop the few extra seconds adjusting stuff, and sit back with the knowledge that what I'm doing is technically the correct way

Another thing that I've noticed is that the helicopter blades are set up under my system by default, but the turboprop blades aren't. Quite interesting

[XLjedi]

@Bartybum To your point yesterday regarding swashplates...  (I think that was you anyway?)  

I was noodling on that today and it seems it would require the blend of two inputs.  It seems you'd need to be able to adjust or blend together the control inputs for both the deployed and undeployed rotor blades.   I have not quite grasped yet how they intended us to control both the roll/pitch/yaw of the undeployed vs. the authority limiter of deployed that is used for lift?  To me it seems we'd need away to control both of these inputs at the same time.  

Not sure there's a mode for doing something like that with the rotor/prop blades?

 

[Raptor9]

It seems to me that the rotor blades have been (either on purpose or inadvertently) programmed exactly like the prop blades, as a means of strictly propulsion.  However the pitch/roll/yaw functions appear to be included in case someone wants to use these devices as fixed control surfaces (for whatever reason, but KSP is a lego-like system where people use parts for all sorts of reasons).  To make matters worse, the spinning rotor blades themselves are adding a gyroscopic stabilization effect, reducing the effectiveness of reaction wheel parts to "cheat" attitude control into the rotorcraft.

Cyclic feathering of helicopter rotor blades in itself doesn't produce pitch/roll effects.  Cyclic feathering induces tilt of the rotor disc, which in turn offsets the total lift vector of the rotor system from the Center-of-Mass to produce the pitch/roll effects.  However, since the KSP rotors are not mounted on articulating hinges, nor can the rotor blades themselves flex to allow rotor disc manipulation (as in the case of rigid-rotor systems), no actual positive attitude control is occurring.  There are some physical changes happening, but I believe they are a side-effect of how the rotors are interacting with the KSP physics engine.

I'm working on a graphic to illustrate possible changes to the KSP rotor parts to make this possible, or at least predictable.  But I need more time to flesh out the behavior before submitting a feedback report on the bugtracker.

Edited July 16, 2019 by Raptor9

[Bartybum]

10 minutes ago, XLjedi said:

@Bartybum To your point yesterday regarding swashplates...  (I think that was you anyway?)  

I was noodling on that today and it seems it would require the blend of two inputs.  It seems you'd need to be able to adjust or blend together the control inputs for both the deployed and undeployed rotor blades.   I have not quite grasped yet how they intended us to control both the roll/pitch/yaw of the undeployed vs. the authority limiter of deployed that is used for lift?  To me it seems we'd need away to control both of these inputs at the same time.  

Not sure there's a mode for doing something like that with the rotor/prop blades?

 

I've been thinking about it too, and I think at the very least you'd require some sort of way to detect the angle the rotor hub is at in order to be able to do that, as well as lump various inputs to a single action.

To be honest I'd really like to see a primitive scripting system ala WireMod from Garry's Mod, that lets you take output values of a part such as thrust, fuel consumption, mass, capacity, status, etc., and then use those as a list of inputs for another object.

[XLjedi]

2 hours ago, shdwlrd said:

Is the craft you made on KerbalX? I would love to see how your are doing the counter rotating blades. The ones I've made so far have been lack luster so far.

It is now...

[Boris-Barboris]

3 hours ago, shdwlrd said:

@Boris-BarborisCreating an automatic control mechanism for the props and blades would be difficult to do without knowing were the stall points for the blades would be. It would need input either from the player or by following the aerodynamic forces. That can be muddied quite a bit depending on the craft you made, or what you are doing at the moment. There were times I was purposefully stalling the blades to slow my craft down with out touching the throttle. How do you teach the program to look for something like that? 

When you program the game, you are in complete control and you are allknowing. You bend the reality of the game to your will, not bounce off with "oh, but how do I control this now?".

If the system you have created is too complex, you simplify it to the point it either needs no control or you clearly see what additional input it needs.

There is nothing to prevent a dev from writing a propeller module that receives desired lift as inpult from the global throttle control and and follows this setpoint with internal logic. Click, select number of blades, select AoA range for blades or fixed. Module has the invertable fomlula that can be used to get desired blade position from airspeed. If you're lazy or overcomplicate formulas, slap a PID on it. Rpm, lift, drag, inertia, stall, visuals, fuel consumption governed by module under complete control of the programmer.

Cyclic control? Easy, I'll just add torque here, with magnitude based on my formula.

Sound? Here it is. I know my rpm and blade count, that's how many samples to overlap and how to modulate them.

Main helicopter rotor torque compensation? I just make a UI where i click on tail rotor, press "compensate torque of..." and then select main rotor. And guess what, i know what the uncompensated toqrue is now, i have it calculated here, in the module class, so I just produce the lift on the tail that creates the desired counter-torque.
 

In no way it is hard to get a functional, controlable helicopter in a lego simulator. You just need to pick the right building blocks.

 

Edited July 16, 2019 by Boris-Barboris

[Goody1981]

@XLjedi thanks for your video - your helicopter looks awesome!

Only 15 min in but had to comment to let you know you should try clicking the hash # symbol in the PAWs... think you’ll be pleasantly surprised. 

Now to watch the rest!

[Starwaster]

@Raptor9

the reason the rotor blades respond to pitch/yaw isn’t as general control surfaces but as helicopter blades. How they respond to pitch or yaw very much depends on their position as the rotor spins. Not sure about roll 

to get them to perform properly they need deploying though. 

[XLjedi]

2 hours ago, Goody1981 said:

@XLjedi thanks for your video - your helicopter looks awesome!

Only 15 min in but had to comment to let you know you should try clicking the hash # symbol in the PAWs... think you’ll be pleasantly surprised. 

Now to watch the rest!

Yeah, someone mentioned to me in the comments that the # was just added in 1.7.3!   Another addition that is long overdue.

[XLjedi]

After building a functional helo, I think my only criticism of the new rotor/prop parts so far is...

The engine mounting for the rotor blades (what's it called, the turboshaft engine?) needs to incorporate a swashplate to allow for roll/pitch/yaw rotor control.  Seems to me the kerbal-ish way, would just have a toggle that allows some omnidirectional tilt control tied to roll/pitch/yaw for that motor where the blades are attached.

As it stands now, all we really have is a cyclic control for hover and then we can fudge it with control wheels and so forth.  ...but even so, I'm just happy that we have what we currently have.  At least I can make a spiffy kerbo-kopter, if not truly a helicopter.

Now the glaring problem here is, the addition of this extra control element would actually further complicate a system that (apparently) is already too complicated for a number of folks.  ...did I mention that I love it as-is?

Edited July 16, 2019 by XLjedi

[Shadowmage]

11 hours ago, Bartybum said:

I position mine such that 0 deployment corresponds to 0 pitch:

Part of my problem with these parts is exactly that ^^.  Those blades in your image do not look like 'zero pitch' to me -- that looks like it is mounted precisely at the angle it should be to produce gobs of thrust in a static test (based on the tip of the prop, looking at the airfoil shape and orientation).  However, you are saying that is the 'zero thrust' configuration for these parts? (*smacks head*)

Perhaps I've just spent too much time playing with RCs (slow-fly in particular), and have too many expectations based on that (where the tip of the prop is nearly edge-wise to the airflow), and with the above information I might be able to get something working.  Just need to remember that 'mounted 'correctly' = 0 thrust', and in order to actually generate thrust I need to mount them at 'chopping lots of cheddar' angles.

 

13 hours ago, Bartybum said:

There's no hologram indicator to say which orientation is forward facing. 

Pretty much this.  Or more precisely, for my purposes, an in-SPH indicator of potential thrust output direction vector at current mounting angle and current engine rotation direction.  So I can adjust angles and deployment while in the editor and get an idea of thrust output.  Bonus points if they can make a 'wind tunnel' widget where you could specify the oncoming simulated airstream speed (and direction?), so you could test the needed pitch for specific airspeeds (and performance at various velocities).

And as you mentioned, symmetry... some method is also needed to not have to adjust individual blades, one at a time.  I haven't been able to get them to work well with symmetry (esp when using the attach nodes), so mostly have to resort to placing them one-at-a-time, which then mandates adjusting deployment/etc one at a time.  Painful for a pair of 2-bladed propellers for an aircraft, and over-the-top-far-too-much-work when trying to create a functional quadcopter.

[Raptor9]

4 hours ago, Starwaster said:

to get them to perform properly they need deploying though. 

Yep, I'm aware of that. But everytime I try a test flight, control in all three axes is either unpredictable or nonexistent.

Do helicopters need a KAL for the rotor blades to be able to perform proper and sufficient attitude control?

Edited July 16, 2019 by Raptor9

[XLjedi]

19 hours ago, Shadowmage said:

And as you mentioned, symmetry... some method is also needed to not have to adjust individual blades, one at a time.  I haven't been able to get them to work well with symmetry (esp when using the attach nodes), so mostly have to resort to placing them one-at-a-time, which then mandates adjusting deployment/etc one at a time.  Painful for a pair of 2-bladed propellers for an aircraft, and over-the-top-far-too-much-work when trying to create a functional quadcopter.

I have a method for building multi-engine prop/rotors that allows for symmetry blade placement (so I don't have to install the blades one-by-one) but then I place the engines with mirror symmetry as a group. 

Basically, I temporarily attach a single engine on the centerline such that it allows me to use radial symmetry to put the blades on.  Then I Alt-Click it to get a copy of the engine with say 3 or 4 blades, and I can then plop those on with mirror symmetry, and the blades stay in proper position and are treated as a singular unit for hotkey assignment.  Now as for the original engine that I temp mounted on the centerline... it just gets deleted.  The other point to mention, if you then want counter-rotating engines... you would turn off the symmetry for each engine and you can then alter the clockwise/counter-clockwise rotational direction AND right-click a blade on that engine to change the variant to the appropriate CW/CCW blade type, and it will apply to ever blade grouped on that motor.

This is a method I developed working in the SPH when I needed to do similar things on other craft where I wanted radial symmetry applied to things I installed on both wings of an aircraft.  ...so I never really saw this as a shortcoming in the editor.  But then again, I already knew the building trick.

19 hours ago, Raptor9 said:

Yep, I'm aware of that. But everytime I try a test flight, control in all three axes is either unpredictable or nonexistent.

Do helicopters need a KAL for the rotor blades to be able to perform proper and sufficient attitude control?

No.  As they are now, I would just completely ignore the roll/pitch/yaw and focus purely on cyclic collective pitch control (deployed like flaps and managed via authority value).  In which case, the KAL is handy for mapping/linking both the engine torque and cyclic to your throttle.

You're gonna have to manage your kerbo-kopter attitude with control wheels.  ...until a proper swashplate is maybe added to the turboshaft engine where the blades are mounted.

For now view the roll/pitch/yaw settings of the rotor blades as if you were using them as ailerons fixed to a wing or fuselage.  ...which doesn't seem terribly useful to me.  Of course, now someone will prove me wrong, LOL! 

Edited July 17, 2019 by XLjedi

[Starwaster]

3 hours ago, Raptor9 said:

Yep, I'm aware of that. But everytime I try a test flight, control in all three axes is either unpredictable or nonexistent.

Do helicopters need a KAL for the rotor blades to be able to perform proper and sufficient attitude control?

I do not think it's strictly necessary but I know that some people have used the KAL to help with control somehow but I don't recall the specifics. Probably by dragging the animation slider to control certain aspects. Authority limiter maybe. 

Actually, yeah... you might want to try adjusting the authority limiter.

15 hours ago, Bartybum said:

Well then, I'm confident in saying the devs got it wrong. Under their system, reverse thrust is done by driving an airfoil backwards into the flow (see below), which is absolutely not how reverse thrust works in real life. Real reverse thrust is done by driving the airfoil forwards but at a negative angle of attack to the flow.
 

No I'm sure that they do not intend for you to do reverse thrust by driving the airfoil backwards.  A little more research went into propellers than that.

[Goody1981]

9 hours ago, XLjedi said:

Yeah, someone mentioned to me in the comments that the # was just added in 1.7.3!   Another addition that is long overdue.

Ah ok no worries, I thought someone may have beaten me to the punch but I looked in the comments of this thread and couldn’t see it.

Thanks again for pointing out how to use the KAL and throttle... made a wonderful little quadcopter with it last night!

[Bartybum]

9 hours ago, XLjedi said:

No.  As they are now, I would just completely ignore the roll/pitch/yaw and focus purely on cyclic pitch control (deployed like flaps and managed via authority value).

You mean collective, not cyclic. Cyclic controls each blade independently, whereas collective controls all at once

[Bartybum]

6 hours ago, Starwaster said:

No I'm sure that they do not intend for you to do reverse thrust by driving the airfoil backwards.  A little more research went into propellers than that.

I mean, that's quite literally what their method does, if you look at it in game. If you apply negative pitch to the blades, the blade airfoil starts moving backwards through the airflow - just take a look below:

(This is a clockwise running motor by the way)

If you're wondering what about when the aircraft is flying forwards, I can tell you that the deployment required to produce negative thrust becomes more positive the faster you go. It's why if you reduce deployment your aircraft is forced to slow down.

Look, I'm sure they put research into variable pitch propellers, but to me it's obvious they missed this. The whole reason I orient my blades the way I do is that by doing so I always driving the airfoil forwards through the flow, because that's how an airfoil is designed to run, with the curved end at the front, and the pointy end at the back.

[XLjedi]

44 minutes ago, Bartybum said:

You mean collective, not cyclic. Cyclic controls each blade independently, whereas collective controls all at once

You are collectively correct!  ...of course. 

[XLjedi]

53 minutes ago, Bartybum said:

Look, I'm sure they put research into variable pitch propellers, but to me it's obvious they missed this. The whole reason I orient my blades the way I do is that by doing so I always driving the airfoil forwards through the flow, because that's how an airfoil is designed to run, with the curved end at the front, and the pointy end at the back.

What you say is all true...  from what I've tinkered with I can see why they may have done it this way for the props.  I can argue the pros and cons to both ways.  It may have been accidental, but I've seen advantages at design time to the way they've done it.  Particularly related to design-time creation of multi-engine layouts with counter-rotating prop designs.  ...and mounting the blades with leading edge pointing directly forward.

I would also note, the way you have them installed is perfectly fine.  Now if you're still twisted up over the +/- value piece...  just change your motor and blade variant to CCW rotation and the values invert.  It may just be a clockwise/counter-clockwise vector math issue where that particular direction (clockwise) is just expressed as negative.

Edited July 17, 2019 by XLjedi

[shdwlrd]

17 hours ago, Boris-Barboris said:

When you program the game, you are in complete control and you are allknowing. You bend the reality of the game to your will, not bounce off with "oh, but how do I control this now?".

If the system you have created is too complex, you simplify it to the point it either needs no control or you clearly see what additional input it needs.

There is nothing to prevent a dev from writing a propeller module that receives desired lift as inpult from the global throttle control and and follows this setpoint with internal logic. Click, select number of blades, select AoA range for blades or fixed. Module has the invertable fomlula that can be used to get desired blade position from airspeed. If you're lazy or overcomplicate formulas, slap a PID on it. Rpm, lift, drag, inertia, stall, visuals, fuel consumption governed by module under complete control of the programmer.

Cyclic control? Easy, I'll just add torque here, with magnitude based on my formula.

Sound? Here it is. I know my rpm and blade count, that's how many samples to overlap and how to modulate them.

Main helicopter rotor torque compensation? I just make a UI where i click on tail rotor, press "compensate torque of..." and then select main rotor. And guess what, i know what the uncompensated toqrue is now, i have it calculated here, in the module class, so I just produce the lift on the tail that creates the desired counter-torque.
 

In no way it is hard to get a functional, controlable helicopter in a lego simulator. You just need to pick the right building blocks.

 

I'm not saying it can't be done, I'm saying would be difficult to do. 

Maybe Squad has something in the pipeline to automatically control the props and blades to be released at a future date. We know they won't confirm or deny anything if they do. Maybe Squad expects some very creative use of the KAL1000. I don't know.

The only thing like that I can compare it to is the autopilots. MJ2 has been around for years and still has spurts of active development. I don't know how long PA and AA was in development before they were released to the public. But I can guaranty it wasn't a couple weeks from start to finish to have a version that was polished, functional, and seeming bug free. 

Basically it's a wait and see if Squad will do anything like that. I suspect someone would program something with Kos before we hear anything from Squad.

XLjedi already proved that you can use the KAL1000 for basic control of a helicopter blade pitch and motor torque. Who knows what someone will do in a couple weeks. KSP players tend to be very creative with how they use the parts.

[Boris-Barboris]

4 hours ago, shdwlrd said:

I'm not saying it can't be done, I'm saying would be difficult to do.

And I am saying that it is difficult only because the thing that was done shouldn't have been done in it's current form in the first place. Other than that, I understand your points.

4 hours ago, shdwlrd said:

The only thing like that I can compare it to is the autopilots.

I think the solar panel that automatically turns towards the sun is a better comparison: it is built with complete user scenario in mind. Blades, judging by the the looks of it, at most received "well, they can tweak authority limiter so they'll be fine".

4 hours ago, shdwlrd said:

XLjedi already proved that you can use the KAL1000 for basic control of a helicopter blade pitch and motor torque. Who knows what someone will do in a couple weeks. KSP players tend to be very creative with how they use the parts.

Yes, no problem with that, I just don't like that such development approach suits the tinker player, not the flyer/pilot. I am afraid it is the reason behind about a third of user screenshots and videos, that involve new rotors, demonstrating significant part of player's screen blocked by ugly tweekable panels and aero debug overlays. Enjoyable flight needs no UI. Not to mention the flight itself, wich I have found in no way enjoyable.

Edited July 17, 2019 by Boris-Barboris

[Bartybum]

5 hours ago, XLjedi said:

It may have been accidental, but I've seen advantages at design time to the way they've done it.  Particularly related to design-time creation of multi-engine layouts with counter-rotating prop designs.  ...and mounting the blades with leading edge pointing directly forward.

Can you elaborate what you mean by design-time creation of multi-engine layouts?

Edited July 17, 2019 by Bartybum

[XLjedi]

4 hours ago, Bartybum said:

Can you elaborate what you mean by design-time creation of multi-engine layouts?

It's kind of a lengthy discussion but sure...  I will post another video related to some of the things I've discovered while converting a jet to a multi-engine prop.  First understand that if you have the engine and blades setup with counter rotation, the values for authority are inverted.  So the positive and negative behave more the way you might like to see it if your engine and blades are rotating CCW.

Secondly, if you mount the blades facing forward...  and you change the orientation of the engine/blades from CW to CCW, the blades are still facing forward.  If you have the blades facing the "correct way" (as you have noted) when you change from CW to CCW you would also have to rotate the blades 180° so they face in the correct direction.  When you are trying to setup multi-engine layouts with counter-rotating props, it's this last step where you'd have to rotate the blades that the editor can get wonky (due to mirror symmetry conflicting with radial symmetry) if you're not careful.

Now, for me...  I think in the future I'll be mounting the blades exactly as you have stated regardless of multi-engine design or not.  I know how to work around the issues in the editor and I'll show folks how to do that in a video so they can mount their props with zero pointing either CW or CCW, and still allow for radial symmetry to apply to the blades (so you don't have to place them one-by-one) and more importantly, be able to assign a single blade authority in your hotkey assignment and have it apply to the whole grouping of blades on a single motor grouping.

I still intend to remap the range of motion for the feathering of the props in my designs, but I also want to maintain the ability to have them feather for reverse thrust with the leading edge facing in the proper direction.  So I prefer your blade orientation, and it's consistent with how I mount rotors, so I like that consistency also!  

But I don't think @SQUAD needs to change anything.  The only minor gripe I'm hearing is the values aren't positive for a CW rotation.  If they inverted it, you'd still see the negative values appear for forward thrust on a CCW motor setup.

 

5 hours ago, Boris-Barboris said:

Yes, no problem with that, I just don't like that such development approach suits the tinker player, not the flyer/pilot. I am afraid it is the reason behind about a third of user screenshots and videos, that involve new rotors, demonstrating significant part of player's screen blocked by ugly tweekable panels and aero debug overlays. Enjoyable flight needs no UI. Not to mention the flight itself, wich I have found in no way enjoyable.

Heeeeeyyyy…  Tinker player?  ...flyer/pilot!!  I'll have you know that I can produce an actual RL pilot's license, my "flyer/pilot" friend.    I'm quite the opposite of the tinker player.  ...at least in my own mind.  I don't fabricate 69' Chevy rover bodies out of 136 parachutes, or use RCS thrusters as bearings for a kerbal steampunk contraption.  Although to my TRUE tinkerer friends...

Your works are most impressive!

When I fly my helicopter, I don't have or need any UI windows displayed (nor do I want them to be).  I set it up so that flying it is fun and it behaves as much like a RL helo as I can possibly manage in the kerbal world.  I setup all of my craft this way, and I'm pretty consistent.  I only display the aero debug overlays and panels in my videos when I'm flight testing and/or explaining my craft designs to people, so they can see specifically how I setup the parts.  ...and how the parts are affecting lift/thrust.

I did a little side mission where I ferried some kerbals to an offshore boat of mine.  ...and landed easily on the helo pad.  It's the first time I've been able to do those sorts of missions reliably because I have not previously had the ability or fine controls to land a VTOL on my HCS-16 Hydrofoil platform.  So I may post a little fun video of that one with me just playing with my new toy, flying around and no pesky UI overlays.

 

Edited July 17, 2019 by XLjedi

[Bartybum]

36 minutes ago, XLjedi said:

It's kind of a lengthy discussion but sure...  I will post another video related to some of the things I've discovered while converting a jet to a multi-engine prop.  First understand that if you have the engine and blades setup with counter rotation, the values for authority are inverted.  So the positive and negative behave more the way you might like to see it if your engine and blades are rotating CCW.

Secondly, if you mount the blades facing forward...  and you change the orientation of the engine/blades from CW to CCW, the blades are still facing forward.  If you have the blades facing the "correct way" (as you have noted) when you change from CW to CCW you would also have to rotate the blades 180° so they face in the correct direction.  When you are trying to setup multi-engine layouts with counter-rotating props, it's this last step where you'd have to rotate the blades that the editor can get wonky (due to mirror symmetry conflicting with radial symmetry) if you're not careful.

Now, for me...  I think in the future I'll be mounting the blades exactly as you have stated regardless of multi-engine design or not.  I know how to work around the issues in the editor and I'll show folks how to do that in a video so they can mount their props with zero pointing either CW or CCW, and still allow for radial symmetry to apply to the blades (so you don't have to place them one-by-one) and more importantly, be able to assign a single blade authority in your hotkey assignment and have it apply to the whole grouping of blades on a single motor grouping.

I still intend to remap the range of motion for the feathering of the props in my designs, but I also want to maintain the ability to have them feather for reverse thrust with the leading edge facing in the proper direction.  So I prefer your blade orientation, and it's consistent with how I mount rotors, so I like that consistency also!  

But I don't think @SQUAD needs to change anything.  The only minor gripe I'm hearing is the values aren't positive for a CW rotation.  If they inverted it, you'd still see the negative values appear for forward thrust on a CCW motor setup.

Sorry, I should probably elaborate that when I say that the devs got it wrong, I mean that the blade variants should have been mirrors of each other around a plane 90 degrees to the current mirror plane. The inverted deployment stuff would be solved by changing that. Under my method it'd be like this:

Clockwise:

Counter-clockwise:

[XLjedi]

1 hour ago, Bartybum said:

Sorry, I should probably elaborate that when I say that the devs got it wrong, I mean that the blade variants should have been mirrors of each other around a plane 90 degrees to the current mirror plane. The inverted deployment stuff would be solved by changing that. Under my method it'd be like this:

Clockwise:

Counter-clockwise:

LOL... well, that's a rather minimal nuance related to the default mirrored variant of the part.  I'm guessing they set it up consistent with the way the other parts are mirrored in their overall part management scheme.  I don't see any problems with it.  ...may even relate to an overall part orientation setup whereby the addition of propellers/rotors were never originally contemplated.

Edited July 17, 2019 by XLjedi