Compound Helicopter Design

What I found is the “trick” to tuning a DDFP on a 500 so it works really nice is to start with a prop that’s slightly too big. Hover it and look at the log. Trim the prop a bit at a time until you you get the throttle at ~ 1550-1600 pwm in hover.

What happens is that as soon as the heli goes into translational lift the throttle to the tail ESC drops to ~1350-1370 pwm because the tail rotor becomes more efficient in forward flight. That is about the minimum throttle were it can respond properly.

But using DDFP drives on a compound is different. In hover one runs one way, one the other. They both have to switch to forward for forward flight and provide asymmetric thrust for yaw control until the tail takes over. Which means the throttle might be able to be kept in the more ideal range of 1500+ pwm for best response time. I wish I knew how much “throttle” was being used on Bill’s machine vs flight speed to make it go. And what the signal output to the thruster servo’s looked like. That would tell me a lot about how to design a DDFP drive system that might work. I assume servo trim setting was 1500 pwm for zero pitch on the thruster props. It would be really cool to see what it was in hover, and what it was in forward flight, and what the pitch range was on the props, and pwm range was on the thruster servos.

I could get you my last log when I took the perf data but it would be a little more difficult to get the thruster blade angle data as I pulled the pixhawk from that aircraft.

A general idea would be close enough. Evidently one prop was running out of thrust in hover. So that tells me whatever the limit was, it was at it in hover. With a clockwise rotor the port thruster would have to be running in forward, the starboard in rearward thrust. Once we transition into forward flight that starboard thruster has to go to forward thrust at some point. What I’m curious about, is the point where a DDFP drive would have to reverse directions, how much of a “lag” would be acceptable when it has to reverse thrust and how much “hunting” back and forth from reverse to forward thrust there would be at that point if you chose to fly the heli at that speed. That would be the downfall of a DDFP drive.

Yep. That is just about exactly the real world numbers that it achieves. It’s fight time
is 25 minutes @ 15 m/s with 6600 12S and 39 minutes @ 15 m/s with 10,000 12S. I can flight

Can you describe your 12S power system components, please? We’re looking
at using 12S on CUAV’s TVBS.

I’m using Spyder 12S 30C stick packs for the 3300’s with one in the frame, one in a belly rack:

I parallel the two 6S strings in the stick packs and one is connected to one side of the ESC, the other pack is connected to the other side of the ESC, with a series jumper to make 12S at the ESC.

The ESC is a Castle ICE2 HV160. The BEC that supplies 8V power to the servo rail and 5.2V power to the flight electronics is a Castle CC BEC Pro with dual outputs, the one output to the flight electronics with a 5.1V step-down regulator. The engine is a Scorpion HKIII-4035-530, 3.4kW continuous power, 4.4 kW for 5 seconds.

The 10,000 battery configuration is the same as the 6,600, except with Pulse 25C 5000 stick packs. With the series/parallel battery configuration, 20 or 30C batteries can be used no problem (saving some weight), as the amp draw is only half of what it would be with one 12S pack. With a single 12S pack you would likely need 55C or better to deliver the full power without serious voltage drop. The series/parallel configuration can deliver the full 3.4kW continuous (if required) with only about 1.2V “sag”.

Ok well I opened my excel file with the log data and got some numbers. So to start off with the set up, it looks like I had as much forward pitch as I did reverse pitch on my thrusters. Remember that I extended the shaft of the tailrotor to increase my reverse pitch throw. So both the left and right thruster servos were set up with 1100 pwm to 1900 pwm as the full throw of the blade pitch with 1500 pwm being flat pitch. So here are the PWM values for the symmetric thrust and the delta PWM of one thruster from the symmetric PWM. So if the left was 1600 and the right was 1500, the symmetric PWM would be 1550 with the delta PWM of 50.
speed(m/s) : symmetric : delta
hover : 1500 : 98
8.5 : 1602 : 60
10.6 : 1640 : 45
14.1 : 1691 : 45-50
So I haven’t really looked at the data like this before. I really hadn’t used even half of my available pitch throw at 14 m/s. I’m not sure by the look of the delta that my vertical stab was helping that much cause as my power increased at faster speed, the delta doesn’t continue to decrease. I’d say the vertical tail is helping because at the same power required (hover and 14 m/s), the same delta is not required as hover.
Hopefully this helps.

Edit: sorry the table didn’t come out that well. It is read in 3 columns, I added colons to help separate data

It helps a lot! The hover delta is not as large as I expected. And it tells me it’s going to be very hard to get a DDFP system to work. At right around 9-10 m/s where both props go to rearward thrust the starboard prop would have to switch directions. And the throttling on DDFP drives is not that precise when we’re spinning 10-11" props and must make a gradual transition to both with rearward thrust.

A DDFP MIGHT work if the helicopter had a very effective tail that was adjusted to totally handle the yaw torque at that speed. But if it gets hit by a crosswind during the transition in rotation direction, I think the yaw control would be less than desirable. Where a DDVP can react within milliseconds. Same reason helicopters are so super-stable in the wind vs multi-rotors that are limited in stability by how fast they can throttle motors.

I think that kind of answered that question I had. Thanks!

So here is my plan for my new compound heli. My weight without batteries is 7-8 lbs. I would hope I could reduce the drag on the aircraft as well with a full body and wings leading out to the thruster engines. Here are the specs on the main rotor
4 bladed with 550 mm rotor blades
Rotor speed between 1400 - 1700 RPM
Engine: L5055 turnigy 600kv 1500W 8s
Engine to main rotor gear ratio 10:90
ESC: 75 Amp Castle Creations Edge

Specs on thruster:
2 bladed tail rotor hub
Blades will be custom made from 12 inch propellers to make use of twist in blades
Engine: aerodrive sk3 4240 740kv 750W 4s
ESC: 75 Amp Castle Creations edge
Shaft will be replaced with longer shaft to be able to mount rotor hub and pitch slider on shaft.

Powersystem: two 4s 10Ah lipo batteries connected in series to power main rotor engine and then each thruster engine connected to one of the batteries. I will monitor battery voltages for each battery since the load could be different.

I will plan to add a vertical tail and have it adjustable to allow setting it for cruise. The wing will also be adjustable. Both are not planned to be adjustable in flight however it may be desirable initially to make tuning it easier. I also plan to have a retractable landing gear to reduce drag.

As for the flight controller, I plan to use the pixhawk, of course, with the compound Heli frame class and I plan to have an airspeed sensor mounted. Although it’s really not needed because stalling at slow speeds is not a concern like airplanes. Heli’s still could benefit in performance by flying on airspeed. Granted if you are performing a search or mapping grid then performance would not benefit with an airspeed sensor as you would fly one leg into the wind and the next with the wind at constant ground speed. And the performance would average out over the flight. The other benefit would be to at least know when you are getting close to retreating blade stall. Which is definitely something I want to keep an eye on as I need to find a balance between performance (efficient high speed flight) and handling qualities.

Retreating Blade Stall can be an issue. But I don’t think a very big one unless you fly really excessive low headspeed. With any helicopter they develop a roll tendancy to the retreating blade side of the disc as forward speed increases, this due to dissymmetry of lift on the disc. This is normally not noticeable because the cyclic pitch is driving the heli with the maximum pitch in the cycle being on the retreating blade at ~90 degrees to the direction of the relative wind. So due to increased AoA on the blade at that point it keeps the dissymmetry of lift balanced.

What eventually causes the RBS phenomenon is that the AoA of the retreating blade increases to the point where it can’t make as much lift as the advancing blade. So the heli momentarily rolls to the side of the retreating blade and simultaneously noses up. Which automatically decreases its forward flight speed and it recovers just like reducing the AoA of the wing on a fixed wing when it stalls.

With compound design the cyclic pitch is basically not being used for forward drive. So only roll pitch is needed for attitude control in the roll axis. This means the retreating blade is going to be operating at lower AoA all the time and it should be able handle much higher forward flight speed than conventional before the retreating blade reaches critical AoA.

In the US we are limited to 100 mph maximum flight speed for commercially flown UAV’s with the current law. Hobby ones can fly faster than that. But what I’m hoping is that 27 m/s, the magical one statute mile/min for flying Section surveys making one mile passes, is achievable at higher efficiency than conventional. I already fly those surveys at 27 m/s with a conventional 696 heli with the main rotor turning at 1,550 with not even a hint of RBS problems, and only about 7-10 degrees of nose-down pitch, depending on wind. So my compound test design is based on that performance criteria, but it will be much heavier in the 14 lb class with a 1355mm main.

My first tests will not use the compound heli code. I am going to use a Trex 600 flybar with Rail 606’s and a mechanically driven conventional tail. It is already equipped with a vertical tail fin adjusted to provide yaw compensation at speeds higher than 10 m/s. I am going to outfit it with outriggers with DDFP drives and control the throttle for the drives on Channel 10. And make test flights with one mile runs using the Castle Link Live telemetry to measure power consumption differences on the main drive, and how much the thruster drives draw on both upwind and downwind passes. Just to get some benchmark data on efficiency of the compound concept.

Looks like somebody has already built a scale X3 powered by a Jakadofsky 6000 turbine with electric thrusters. I would say this one looks like it handles amazingly well, although the pilot is most certainly not an amateur.

Very cool Chris. Thanks for sharing. Great looking scale replica! It would be interesting to learn about his setup and the flight controller that was used.

Based on what I observed at IRCHA in the large turbine scale models, I would almost place money on it being a HeliCommand (now Bavarian Demon) FC.

http://www.premium-helicopter.de/de/pages/show/premiumhelicopter

Thanks for that link! I love scale models. It confirms what I figured it was probably using. Just about every large turbine model I saw at IRCHA had the HeliCommand system in it. I saw one with a DJI Wookong H.

RC-Anlage: Futaba FX 40, Helicommand, Servos Futaba BLS 152, zwei Kreisel für die Turboprops

I’ve been looking at how to test a modified compound Trex 600. For my first tests the attitude and yaw command, and thruster mixing won’t be a problem. The goal is to test power efficiency in high speed cruise flight as compared to a conventional. I will use the mechanically driven tail for yaw control initially, and simply add DDFP thruster drives. Controlling the thrusters with a separate channel.

Since it will require long-range steady speed flight, auto would be the best mode to test in. In manual flying at 20+ m/s the helicopter is out of site within seconds, and flying it on a large figure 8 test course is not going to work because the current nav controller has some limitations for helicopters in making turns and maintaining speed in the turn. For instance, if I set the thrusters to provide 20 m/s flight speed, the heli will not only chop off the turns on the waypoints, the system slows it for the turn to meet the WPNAV_ACCEL requirement and the thrusters will be fighting the system trying to flare the heli to slow it. Which will corrupt my data.

This is not going to work with Loiter because that is all based on lean angles.

It is not going to work with Pos Hold because the thrusters will again fight the system trying to keep the heli in one spot without a stick input. And center the cyclic in level cruise, the system will attempt to brake it, even though the thrusters are trying to make it go.

Alt Hold will work for a long range, high speed testing mode at present, flown with FPV, and will help with collective management so I can pay attention to the other systems in the aircraft that I’m testing. So that’s what I’ve decided to use for now.

I’m afraid in the long run the Plane L1 Nav Controller and the FBWA and FBWB modes are going to have to be adapted to TradHeli for compounds. And are actually more applicable to conventional helicopters than the current Copter flight modes are. Except for the basic modes like Stabilize, Alt Hold and Acro, and Loiter for hovering with GPS, once we transition into forward flight Auto and Loiter are not going to work. After looking this over closer, there is no sense to crippling a high-performance system with complicated mixing to fit autonomous flight modes that would need a complete re-design in order to work. Might as well take a good look at fixing the flight modes instead, so the mechanical system can work as it was designed to. And that applies to both compounds and traditional. Looking at the limitations of what we have, there is no reason that helicopters shouldn’t be able to make constant-speed banked turns, nose up climb or climbing turns, autopilot executed ag turns on surveys, etc., like they do in the real world. And this gets even more critical to proper performance of a compound.

How will you be able to test efficiency if you have an additional tail rotor consuming power. When you say you’ll be initially using a tail rotor, I assume you will be doing something with the DDFP thrusters to control yaw at some point?

I think this would be a good opportunity to use the compound code. I left the code in there for DDFP so it should work :thinking: Especially if you have convinced yourself that you’ll be using a manual mode like ALTHOLD. That way you can get rid of the tail rotor that would be consuming power. Just a thought.

No, DDFP thrusters, I am convinced, will maybe work for a smaller size. But not with a 600-class. They will definitely be DDVP once I move to that phase.

The tail rotor is actually a constant. It will draw the same power whether there is thrusters installed or not. And the weight of the mechanical drive is negligable, as it will be replaced by a tail assy with dual vertical stabs anyway.

What I’m really interested in is the efficiency gains in the main rotor with the weight and losses in the thrusters combined (additional takeoff weight), vs a conventional. And where the cruise speed is where the compound may or may not begin to provide an advantage? Any additional losses in the thruster drives related to drag, power consumption, prop tip losses, etc., have to be gained back in the efficiency gains in the main rotor due to less drag and possibity of better aerodynamic qualities. Then remove the tail drive from the equation and the compound becomes more efficient (although there will be some aerodynamic drag losses on a tail assy).

So I figured this configuration gives me a chance to arrive at a baseline of measured efficiency changes, be easily able to try different propeller designs and so on without having to retune each time. Call it practicality testing, if you will. I could find no definitive data on actual efficiency gains or losses in compound designs. The marketing or presentation is all about speed, which is a no-brainer. But what about efficiency? Because that’s actually the bottom line (combined with performance) for UAV designs. And is the primary reason some of us fly helicopters now instead of multi’s. Now that I have Castle Link Live telemetry working I have an excellent tool for testing efficiency of different designs on-the-fly with changes made in-flight to power settings, speed, etc… :wink:

Edit:
I plan to test some different airfoils for stub wing designs with this too.

I’m actually not a huge fan of the FBWx modes and will usually fly in stabilize when flying in ‘manual’ and want the FC to assist. I find that the FBWx modes dumbs down the controls too much.

Yeah, it’s been awhile since I flew those with fixed-wing. Pos Hold would make a pretty good helicopter GPS-assisted flying mode for heli’s if two things could be modified

  1. get rid of the collective “dead zone” as soon as it goes into “dynamic flight”
  2. totally get rid of the braking when it is in “dynamic flight”

But when the heli leaves “dynamic flight” the normal Alt Hold collective and braking is returned, and as long as the sticks aren’t moved it has GPS position holding in hover. That would work very well for both traditional and compound heli’s (I think).

That dynamic flight flag could be used for other things than to just turn on and off the integrator leak in heli’s.

FBWx modes in plane are pretty much the same command strategy in pitch and roll as the stabilize mode in Copter. Stabilize in plane is more like acro with the trainer setting on in Copter. FBWx in plane just like stabilize in Copter makes flying easy that most people can pick it up. But I can definitely see how accomplished pilots may not like the feel.