Search the Community
Showing results for tags 'rotor'.
-
Propellers popped up in Dakota's Top Ten Requests thread a few times and I got to thinking about them. I really enjoyed making propeller and rotorcraft in KSP1 but I thought they were really fiddly and I think they need to be re-thought for KSP2, if they decide to implement them. Here's how I'd go about it! We should still have torque It's an important design consideration and getting rid of it would make propellers too similar to jet engines! Blades should be parameters Instead of attaching blades to motors and then fiddling with them, the critical things should be parameters on the motor: Number of blades Size of blade Rotation direction (affects both blade variant and motor direction so they always match) Reverse rotation switch (for backward-facing props) These should have a sensible default for each motor size. Blades should have auto-pitch as the default option We've had constant-speed propellers with automatic pitch for ages and ages and I think we should have them in KSP as well. There should be an option to switch to manual pitch as well because sometimes you want to. Default axis binds for torque and pitch Throttle controls engine torque Up/Down controls blade pitch (if not set to automatic/constant-speed) You could reassign these but you shouldn't have to assign them manually every time. Handle helicopter main rotors separately You would have to explicitly choose to make a propeller a helicopter rotor. This would change its axis/keybinds and behavior. These could be entirely different parts, or a switch you can flip on a part. Constant-speed/automatic pitch would be removed The up/down axis would control pitch The roll and pitch axes (QE/WS) would control cyclic Handle helicopter tail rotors separately Like for the main rotor, the tail rotor should be either a designated part or a mode/switch you can flip. It has auto-torque to keep it constant speed The yaw axis (AD) will control pitch SAS will automatically adjust it to keep the craft's orientation stable In sum If they were designed this way, making a functional propeller plane would be almost as easy as making a jet plane, as you'd only have to deal with torque. Making a functional helicopter would be fairly straightforward too: install a main rotor and tail rotor (or two counterrotating main rotors), and off you go. I know that this may sound too much like "easy mode" for some people, but I really think they were too difficult to get into for most people, and even when you knew how they worked, they needed too much manual tweaking to fly. Single main rotor helicopters in particular were really hard to build and even when built right were really squirrelly. I think that with this kind of approach, lots more people would use them, and you'd still be able to set them to "full manual" if you wanted the advanced stuff. What do you think?
- 5 replies
-
- 6
-
- helicopter
- rotor
-
(and 1 more)
Tagged with:
-
So, I got this DLC wanting to make helicopters. I found out pretty fast that metaphorically bought the tool, but not the skill. Yet. The DLC has a few stock "helicopters" which are just ducted-fan VTOLs and flying platforms. However, I'm trying to make a "conventional helicopter" so to say. A helicopter with a main rotor and a smaller tail rotor. So far, my results have been far from desirable. My first rotor-tail rotor helicopter design (image links below) was awful. All it did was break itself. https://prnt.sc/tsxyu0 http://prntscr.com/tsxz61 What's the right way to make a rotor-tail rotor helicopter?
- 9 replies
-
- helicopter
- helicopters
-
(and 2 more)
Tagged with:
-
The primary feature of the DLC is, of course, that you can assign some variables for rotors and servos, such as target angle, target RPM, target torque, etc. as dependent variables in the KAL-1000 controller, where the independent variable is the play position of the controller. It is also possible to slave the play position to any of the game's available axes (main throttle, translatory controls, standard flight controls, etc). I am curious as to whether this relationship can be inverted - that is, whether the play position of a controller can be determined by, chiefly, the current angle of a rotor or servo, though I'm sure the other variables would have some uses. If this is not possible in normal KSP, is there a mod that provides a similar function? I ask this because, if this is possible, it may finally allow some aspects of lift dissymmetry to be solved.
- 3 replies
-
- helicopter
- rotor
-
(and 3 more)
Tagged with:
-
This post is to share some tips at improving the efficiency of turboshaft engines, driving propeller blades (airplanes) or rotor blades (helicopters). The concepts should apply equally to electric rotors driving propellers or heli-blades. I'm using 1.7.3, the electric rotors, turboshaft engines, and propeller/heli blades are new to stock KSP, so in later versions some of this info might become outdated. It's easy to focus on either the Turboshaft Engine, or the Prop/Heli blades when troubleshooting 'why doesn't my vessel work'. The reality is you need to look at both elements to make a functioning prop-airplane or helicopter. The engine produces torque, which spins a shaft. This is important, torque produces zero thrust. Add all the torque you want, it will not produce any thrust- until it is coupled to a lifting device, such as a propeller blade or heli blade. On the other hand, the prop/heli blade also produces no thrust unless it is moving. You can angle the blades any way you want, they will produce no thrust unless they are moving. The movement is provided by the Turboshaft Engine (or electric rotor). As of 1.7.3, the stock engines can rotate at a maximum rate of 460 rpm, which is evidently a Unity limitation. Adding torque will increase rotational speed (rpm) up to that limit of 460 rpm. What happens if you are already at 460 rpm, and increase torque? That's an important question. What happens (in 1.7.3) is you increase the Fuel Flow (or EC draw), but do not get any increase in rpm. Beyond 460 rpm, adding torque is simply wasting fuel. In the following examples, we're going to experiment with turboshaft engines. There are two variables we are going to adjust, and unfortunately they are on two different parts. One is the Torque of the Turboshaft Engine, the other is the Authority Limiter of the prop/heli blades. To make things easy, I like to assign these values to action groups. I assign Engine Torque to the Main Throttle, and the Blade Authority Limiter I assign to Translate Forward/Back (usually 'H' and 'N'). Okay, lets get started. Here's a turboshaft engine we're going to play with. It's in the 'propeller' configuration, but the idea is the same for helicopters. Ok, we have an engine built on a stand, let's play with it to see how Torque, Blade Authority, RPM, Fuel Flow, and Thrust are related. In the next spoiler window, I'll play with Torque and Blade Authority Limit, to see what happens to rpm and Fuel Flow. Keep in mind that Thrust is only dependent on rpm and blade angle. If my rpm and blade angle stay constant, but my Fuel Flow increases, I have not increased my thrust. I'm just wasting fuel at that point. So, one goal is to find the minimum Fuel Flow which will maintain a specific rpm at a specific blade angle. Here goes. In the next spoiler window, I'll demonstrate an actual aircraft, making adjustments to torque (and Prop Authority) to reduce fuel burn. Ideally I'd use a single-engine airplane to keep things simple. However, counter-acting the torque effects of a single-engine are difficult to design for, and fly efficiently. It's easier to just make a plane with two counter-rotating engines and propellers. Then, it flies quite easily just like a jet, with no nasty torque effects. The takeaway here is that to get the most out of the turboshaft engines and propeller or helicopter blades, you need to look at more than just the engine or just the blades. Both elements need to be adjusted for optimum performance. Ideally, you need to be able to adjust both Torque and Blade Authority Limit in flight, to adjust for varying conditions. Regarding efficiency, the big takeaway is that adding Torque beyond what is required to maintain rpm is just wasting fuel, and lots of it. As of 1.7.3, I believe the concept is the same for electric rotors driving propellers or heli blades- adding torque beyond what is required is only wasting EC.
- 1 reply
-
- 2
-
- turboshaft
- propeller
-
(and 3 more)
Tagged with:
-
I'm creating a V-22 Osprey replica with the new robotic parts (incredibly original idea, I know). I am using the largest helicopter blades and the R7000 turboshaft engine. The vehicle lifts off fine, albeit with some help from vernor engines, but the second I enter it into "plane" mode the engines are massively too weak to propel it, capping at about 35m/s. The vehicle weighs 66,5 tonnes. Is there any way of improving the thrust/weight ratio without adding more rotor/jet engines? Why is it that they have enough power to lift the whole thing off the ground, but not to propel it? Since I'm new here and couldn't figure out how to insert images into my post, here's an imgur link: https://imgur.com/a/msRQ73z
-
I haven't used this account in quiet some time, nor do I play much KSP anymore... But this has been an ongoing issue for me for ages. Any engine with a rotor, be it stock (Goliath) or modded (in this case Airplane+), the rotors seem to spin backwards. I feel that this isn't major enough to put in any other forum section and may seem trivial, but it's been bugging me for ages. Redownloading the game isn't something I want to do (due to my very slow internet and limited bandwidth) and I've tried removing all mods, but this minor issue still remains. If anyone has any ideas on what I can try before giving in and reinstalling, it would be greatly appreciated. Here's a gif so you understand what I'm talking about. Edit: I just reinstalled the game, no mods, nothing other than stock parts and settings... Rotors still going backwards. This is an issue with the core game. Although minor, I think it should be fixed. No jet engine I've seen IRL pushes air out the front
-
(Edit: If you want to see the part about needing the bearings, go look at the more recent posts. March 9th or later). The time was in the middle of last summer. @Jon144 had built his beautiful helicopters while I had nothing to show for it (We've competed with designs in the past and I usually lost). I didn't really like the fact that stock KSP helicopters had to detach their rotors to work, requiring switching crafts to adjust throttle, and set about on the quest to see if a claw based bearing could work (tests in previous versions showed it couldn't, but I wanted to see if anything had changed). Forcing the claw to stand upright did not work, but then the entire rotor assembly tipped upside-down and started spinning like a charm. And thus I had my idea. The Clawjet Rotor So why did I call them "clawjets?" Simple. The claw is the most important part of the bearing and it uses tip-jets to spin the rotor. The Clawjet rotor's main advantage is that the power of the jets can be adjusted mid-flight without having to switch craft and lose control of the helicopter for a few moments. With a properly placed fuel tank its possible to fuel the rotor from fuel stores aboard the main craft, and the blades can clip through the main craft if you wish. The main disadvantage to it is that it's complex to set up prior to the flight and likes to break at every opportunity. That's the main reason why I never actually built a proper non-experimental helicopter using one to upload to the forums, and decided to just put the whole project on hold. So how does it work? Glad you asked and I didn't type out the exact response I wanted you to have in big blue text above this statement! The setup is effectively made up of 3 parts: The claw, the rotor, and the lock (which itself is made up of 3 parts). The rotor is placed upside-down directly above the claw. It is then detached, landing center on the claw. The claw is then set to "free pivot," allowing the rotor to tip upside-down (2 upside-downs makes a right-side up, so this is good). The rotor is then locked in place with the lock. Here's a picture: In this example the decoupler is between the fuel tank and the claw; its just that the decouper is actually attached to the structural support on the right side of the image and majorly offset over (more than the stock settings allow). Also notice how the claw is tipped back slightly. This is because the claw can't rotate fully upside-down, it just gets really close to doing so. I think this is the reason why the rotors destroy themselves at every opportunity. So then how does the lock work? Ok, the lock is divided into 3 parts, which I shall call the "rotor lock," the "detached lock," and the "attached lock." Here's the same picture with the lock parts highlighted instead: I've named the 3 lock parts in this format because it's descriptive of where they are. The rotor lock is attached to the rotor. The detached lock gets detached from the craft. The attached lock stays attached to the main craft. The attached lock and the detached lock form your typical bearing setup. The rotor lock winds up in the same place as the attached lock once the rotor has been rotated upside-down by the claw. The detached lock then detaches, locking the rotor lock and attached lock in the same place. Essentially the detached lock holds the rotor lock in place, while the attached lock holds the detached lock in place. The rotor lock is "locked" to the main craft, and thus the rotor shouldn't tip when the helicopter decides to lean. EDIT: Make sure to lock the pivot on the claw once the rotor is rotated into place. Free the pivot again when you detach the detached lock. This will make sure that the rotor lock locks properly with the detached lock. This lock setup will work with many types of bearings, and I have indeed experimented with many types of bearings. If you want to get especially creative you could have the rotor lock and attached lock be in different places; as long as the detached lock is locking the rotor in place and allowing it to spin while the attached lock is locking the detached lock in place you should be fine. Success? Flight was achieved with several prototypes, and at least 1 even landed, although they did all encounter many issues with the rotors breaking off when trying to pull maneuvers, along with the helicopters being practically uncontrollable. Eventually I settled on counter-rotating prop designs as the best option, but even that did not remedy the problem. Eventually I abandoned development because the challenges to overcome were greater than my interest in continuing development. Anyways, have some pictures: The Future? The game has gone through a couple of updates since I experimented with these rotor bearings, though I would think they'd still work in the current version. Autostrutting might do interesting things for the clawjets, and perhaps allow them to actually succeed. However, I'm definitely done with them after all the trouble they gave me and a waning interest in KSP. However, now that I'm no longer working on these things, I thought I should probably at least share my progress to the forums. So I guess that's where you guys come in. Try some things with these clawjet bearings and see if you can get them to work properly, or if the concept is so bad that it's unfeasible. And since it's the spacecraft exchange I better post a download link Below is the download for all of the experimental helicopters and rotor setups I have. All of my research into these rotors is in there, so hopefully you can go from where I left off. https://www.dropbox.com/sh/sjsjqxn4yh5xv9o/AACOVuObf-mRivggylhRmwsTa?dl=0
- 26 replies
-
- 13
-
- rotor
- helicopter
-
(and 1 more)
Tagged with:
-
I decided to stop derailing @_Rade's thread, and start a topic for the development of narrow-band scanner based rotors. It's impossible to fly with these, but they have infinite torque, because they are based on rotating colliders. Specifically, the rotating collider of the narrow-band scanner. The major parts of the narrow-band scanner rotor are the Jacket or Bracket or Holder, which locks the narrow-band scanners in place, and is attached to the gears, clutch, or to the wheels. The Clutch stops the infinite torque of the holder from breaking links in the rest of the machine, and is usually based upon wheels with the brakes active to ease in the torque. The Clutch is not necessary for some simple rotors, but for ones involving Gears they are usually necessary. The gears are used to increase the speed up from the ~1 rad/s of the Scanner. Examples: An example of a simple Clutch: http://imgur.com/dN88Qgm A combination of gears and a Clutch: http://imgur.com/FptZWtO An example of some sideways gears with a readout of rad/s: http://imgur.com/xa0SZyC
- 2 replies
-
- 4
-
- narrow-band scanner
- scanner
-
(and 1 more)
Tagged with:
-
Hello! I was developing some propeller plane, and encountered a problem with stability. When plane goes too fast, rotation speed decreases relative to the forward speed, decreasing the AoA of propeller elevons to negative causing unstable lift. It seems that the only solution is changing pitch of propellers. So, are there a way to have 3 pitch angles? Any way will be great if it is stable and reliable. Perhaps some small rotors could be configured for this? Or, is it possible to let landing struts push parts in the same ship? This doesn't work when I tried... Any ideas will be greatly appreciated!