Servers by jDrones

New UAV Helicopter with gas power

(Chris Olson) #1

After my experiments with electric power this past season I’m going to back to pistons. The electrics, while they do work, are too inefficient and expensive to fly with relatively limited performance because of too much of the helicopter’s payload capacity being used in battery weight.

Not a lot of people flying combustion engine helicopters it seems. Electric gets most of the focus, I suppose because of its simplicity. And even the heli setup wiki says, for some reason

The system has not yet been proven to work on fuel powered helis, but it should be possible assuming adequate vibration damping is provided for the APM/Pixhawk.

A Trex 700 nitro was the first helicopter I ever flew with the ArduPilot system and it works fine. So that wiki really needs some updating.

For my newest UAV helicopter, rather than buy a hand-me-down piston conversion like the last two were, I decided to start with a fresh sheet of paper and build one the way I wanted it from the ground up

It is based on a Synergy 766 with the gas engine conversion kit supplied by Carey Shurley of Gas Powered Helicopters. I selected a TRM VX310SX engine for power. The engine has stock port timing so it has excellent low rpm range torque and fuel burn. The engine runs on 91 octane non-ethanol blended pump gas, or 80/87 avgas. It is a two-stroke based on the proven Zenoah G290RC format short block with a 2mm stroker crank. It uses the heavy-duty Zenoah metallic-shoe industrial clutch instead of the cheaper lined clutch bells common with nitro/PUH format drives. The transmission is a belt primary with geared secondary

My original design called for installation of a Jewel generator. But in the end I instead went with a larger flight systems power battery - a 5000mAh 2S Pulse. The battery easily powers the flight electronics and servos for a 2 hour flight without a generator. And I would’ve lost my electric top-start system with a generator drive. So the generator idea was scrapped.

The flight electronics is a Pixhawk 2.1 with a Here GPS/compass. Standard MavLink and 5.8GHz FPV system. This is a big heli with lots of room inside so all the flight electronics, short of the GPS module, can be hidden inside and weather-proofed.

I designed the payload system for front-mounted gimbals and cameras. And while can’t be seen in the photo, belly mounted tethered or solid-mounted payloads. The belly payload bar wraps around the engine’s recoil starter, which I retained instead of putting the fan intake screen on it, in the event the electric starter would fail in the field. The belly payload bar also carries two saddle tanks that give it two hour flight time with 15 minutes reserve fuel.

The heli can easily lift and fly with 10kg payload. Maximum takeoff weight is 17.7kg. With full 2 1/4 hours fuel onboard useful payload is decreased to 7kg - but still about double what a comparable sized electric can carry for less than half the flight time. The mainshaft is equipped with fully serviceable axial thrust bearings with grease ports to carry heavy continuous loads. Normal headspeed is 1,400 rpm with 1,460 and 1,530 rpm idleups for heavier payloads. Best cruise speed is 38 kts, maximum speed is 85kts.

I am custom building these helicopters for operators that need a high-end UAV for commercial purposes. This is the second one I have built. Entry price is $11,000 USD.

(Ferruccio Vicari) #2

I have done a lot of gassers using Arducopter in the past few years, yeah it works great, though required a little customization of the code (since i did not use stator gator/ external governor at the time).
My Benzin Vario (VRBrain):

A trex 800(pixhawk) i built for a friend :

(Chris Olson) #3

We have recently made some improvements to the throttle handling for piston engine helicopters to support modern governors that use the throttle curve for feedforward, and support multiple idleups. And fallback to the throttle curve in the event of governor speed sensor failure in flight. Those improvements will be coming out in 3.6.

The 766G uses an Aerospire governor with three idleups and headspeed telemetry to the RC radio with low headspeed and overspeed alarm. It also has automatic fuel mixture control with engine cylinder head temperature telemetry to the RC radio with over-temp alarm.

(Ferruccio Vicari) #4

Sounds nice, I assume the engine telem data is flowing through the receiver, not Mavlink, correct? That could possibly represent a limit for missions range.
I used a Teensy to make an external governor with input FF from Throttle Curve on Ch8 output, with in-built failsafe in case of sensor failure, but it was not communicating back with the autopilot side.

(Chris Olson) #5

Correct. The MavLink packets have a lot latency and are not really suitable for real-time headspeed monitor. And the RC range is much greater than the MavLink range anyway. The other issue is that the RC radio is always present, while some flights are flown without using a ground station. So having engine telemetry on the RC side makes more sense in this case. I would like to add a torque meter for percent power and that would be suitable on MavLink. The ground stations already have a widget for “percent throttle” but that is designed for electric multirotors and is only loosely related to percent torque with a helicopter engine, since with heli’s that is really percent collective pitch. So would require some more extensive modifications to the code to incorporate a real torque meter for helicopters.

(Ferruccio Vicari) #6

Well, to be honest, I’m using Crossfire, in PPM over Mavlink mode, works like a charm, and it is times better than the radiomodules I have been playing so far.
There should be anti-overspeed feature in the governor, since I don’t think you can do so much on the gorund if the overspeed alarm starts beeping (this won’t probably affect most RC helis though…being designed for hard 3D and very high HS settings)…unless twisting back the throttle to idle and entering autorotation, but this is not always feasible.
A thing I’m working on is to include airspeed sensor in the code, in order to consider VNE (I know it does not matter for most RC helis), I faced “serious” problems testing a very large heli during windy day.

(Chris Olson) #7

There is practical limitations due to the operator certificate allowing non-VLOS operations, and that is currently only allowed in the US for licensed commercial (full size with appropriate ratings for the aircraft flown) pilots flying UAV’s. It is not allowed in Canada at all. non-VLOS is not allowed for Part 107 operators at all in the US.

The overspeed alarm is not near as critical as under-speed. With the current implementation of the code in auto mode, you only have a couple seconds to react to an under-speed situation to take manual control of the helicopter to autorotate it. Otherwise the autopilot will max out the collective pitch and stall the main rotor. I have successfully autorotated twice on commercial flights - once with a blown clutch and a second time with an electric with a broken motor shaft. There’s a fair amount of guesswork involved with the heli 1-2 km downrange, but the low headspeed alarm was the key to making both successful and saving the helicopter. So it is by far the more important alarm.

The over-speed alarm simply helps with collective management during autorotation since it is very easy to over-speed the head and reach its mechanical limit autorotating a heavy UAV heli.

The Vne I do not consider a serious issue as long as you are running at least 450 fps blade tip speed on high-speed flights. Helicopters, at typical UAV disc loading, are easily capable of 85 kt airspeed at 450 fps before they start to roll and pitch up. The most common mistake is running the head too slow, and that came from the world of electrics where people are trying to get long flight times by running low headspeed. With piston power the penalty for running higher headspeed is minor, only costing a few cc’s of extra fuel which is negligible from a weight standpoint.

The 766G starts to run out of left aileron at 85 kts TAS @ 1,530 rpm. Which is well above normal mission speeds, even in 20kt headwinds.

(Ferruccio Vicari) #8

[quote=“ChrisOlson, post:7, topic:25999”]
There is practical limitations due to the operator certificate allowing non-VLOS operations, and that is currently only allowed in the US for licensed commercial (full size with appropriate ratings for the aircraft flown) pilots flying UAV’s. It is not allowed in Canada at all. non-VLOS is not allowed for Part 107 operators at all in the US.
[/quote] You are assuming Long Range equipment is used only for BVLOS ops. I feel safer using it also within LOS range.

I’m talking about a 3,5m rotor diameter. It matters (structural) as much as low HS alarm (aerodynamic).
The idea of increasing the situational awareness of the autopilot (so main rotor/motor RPM, TAS ) leads to safer flight operations (preventing collective induced stall, just to mention one), long story short.

yeah, on a 700/800 class heli.

(Chris Olson) #9

Overspeed matters on any helicopter, no matter what the rotor diameter. Maximum structural speed for the 766G equipped with 766mm blades is 1,950 rpm or 580 fps blade tip speed. With the 806 blades it is 1,880 rpm.

In theory the engine is capable of 17,500 rpm no-load, but the practical limit is 14,500 rpm, which is 1,930 rpm headspeed. So over-speed alarm will only go off in the event of governor failure in a steep dive. Which is outside the normal operational envelope for UAV operation except in emergency autorotation with the over-running clutch active.

The current limitations of the nav controller in Copter pretty much limits the performance capabilities of helicopters because it tries to fly them like multi-rotors. When we get the L1 nav controller for helicopters so we can make ball-centered 75-80 degree banked turns on survey passes to reduce overrun, etc, then a TAS sensor makes more sense. The current implementation of the code with all the frame angle limiting going on for multi-rotors simply does not work all that well for helicopters. It only kind works. But fixing that is on the bucket list.

(Jakob Schmidt) #10

Those engines are surprisingly affordable. What’s the maintenance schedule like on them?

I was under the impression that vibrasions was a major issue with gas powered helis. Have you taken any additional measures to isolate the Pixhawk?

(Chris Olson) #11

Check the sparkplug and air filter every 25 hours. Overhaul or engine replacement at 500 hours. There is no other maintenance. It is two-stroke.

No special isolation for the Pixhawk. Just some lead bars on it to damp some of the high frequency vibration running lower headspeeds. The engine has a lightened piston and 2mm stroker crank in it, and it is balanced to run at 11,000-12,000 rpm. It is as smooth as any electric at 11,500.

(Chris Olson) #12

Demo of the new mode 3 throttle curve in action…

I’m using a 25-32-38-50-100 throttle curve with 2 second ramp, 20 second runup to ground idle-rotors turning. From there you’re on the throttle curve and the governor becomes active at 32% throttle and 70% governed headspeed.

It makes the transition from throttle curve <-> governor seamlessly with the new code. If the governor fails in flight it falls back on the throttle curve to get the heli home.

The governor is set to re-ramp in 2 seconds after the initial spool for autorotations - fast enough to come back on power, but not so fast that it torque-twists the frame. However, ArduPilot does not understand this. If throttle hold is engaged in flight for autorotation, ArduPilot insists on re-running the 2 second ramp/20 second runup again. When it should actually never re-run the ramp/runup routine unless the flight controller is disarmed and re-armed. It should only use it on initial spool-up. This is something we need to fix yet in ArduPilot.