What can be made to work, vs what’s safe and practical is two different things. There’s a reason some people can get 500 hrs on their piston engine, and others only get 50 hours before it seizes up. In cold weather I run at high idle, clutch engaged and rotors turning for 2-3 minutes sometimes for warmup. In hot weather I’ll run it for the same time at the same speed for cooldown so when I shut it down the temperature doesn’t spike and stick piston rings. Which will score a cylinder and seize it up.
Turbines are even more important for proper warmup and cooldown if you don’t want a $2,000 engine overhaul to due to cracked combustors, or letting an autopilot over-temp it by pushing the ITT over 1000C on spoolup.
Lack of autonomy is not holding helicopters back. Aviation authorities are. Those authorities that do the certification of the aircraft are not impressed with full autonomous features. They are impressed by a Pilot in Command retaining 100% control of the helicopter in all phases of the flight. That’s why drones are so tightly regulated commercially. They don’t trust them because they’re too automatic. That’s why a drone can’t be hired out to DOT for a survey of a U.S. or State highway, but a manned aircraft can be.
A) Your usage of a gas heli, should not preclude somebody else who is flying, say a 249g helicopter in full auto mode.
B) You’ve presented no problems with a programmable system could not be made to handle. Those sorts of situations are, frankly, trivial to solve in software. And in fact, would be more reliable than an operator being left to handle it manually. You even said it yourself, you do it right, and others don’t. I would have loved to have sold a gas powered helicopter, but I won’t go there until all of it can be automated. Right down to oil and fuel injection.
There might be people doing that, but as long as EKF lane changes are a thing, I would not call it safe.
So maybe keep focusing on features that make ardupilot safe, rather than features for toys.
Well, no it’s not. Especially with turbines and there is now a few users flying turbines both commercially and hobby with ArduPilot. For one, you have to be able to initiate the start sequence, which is manual control. The reason it is manual is because even with the most advanced FADEC the engine can experience a hot start with lots of fire, or a hung start where Ng fails to accelerate. Either condition will cause severe damage to the engine. In both full-size aircraft and RC the pilot very carefully guards the fuel cutoff and monitors ITT and Ng rotation until the engine goes self-sustaining and you have a verified good start. Something as simple as wind blowing up the tailpipes during a start can cause a bad start with a turbine. And these engines are VERY expensive to fix if you over-temp one. You’re looking at $150,000 for a hot section on a PT6 if it has a bad start and over-temps. And RC turbines aren’t any cheaper on a scale basis - entry price to most turboshaft RC engines is in the $5,000 range. The larger JetCat engines with dry sump lubrication system and oil cooler are $18,000 and up.
Since the fuel cutoff is a necessary pilot-controlled item for in-flight engine fires, and is used for starting and stopping the engine, it cannot be an autonomous thing. No pilot (that has any experience) is going to fly an aircraft with an autonomous fuel control that falsely detects an engine fire and shuts down in flight without the pilot commanding it.
While not all have it, my piston helicopters have a fuel control as well for the same reasons. If the throttle servo fails or throttle sticks, or in-flight engine fire, the fuel control is used to shut it down and stop the flow of fuel to the fire or kill the engine. Verifying the fuel control works properly is a required pre-flight check during runup.
That has nothing to do whatsoever with the code. Oil injection on two-strokes is mechanical. Fuel injection is electronic, controlled by an engine ECU, pretty much the same as turbines with a FADEC.
It doesn’t preclude such a thing at all. I believe a 249g helicopter is flyable with ArduPilot as is. The code is open source so if somebody wanted to hack a cell-phone controlled helicopter and make a custom build for it that is entirely possible to do (and not even that difficult).
This is a consideration for things like fully automated flight with no RC. It could only be supported for some helicopters, primarily electrics.
For instance, Bill and I discussed adding support in the RSC for starting turbine engines. But we decided against it because they’re not all the same. The basic arming/throttle hold used with the throttle curve works with all of them for engine control. But the start sequence is programmed into the RC.
The only timer used is for max starter time if the starting battery is low or weak and fails to accelerate Ng to self-sustaining before the timer expires. But some require a full throttle signal to initiate the FADEC, then return to ground idle within 2 seconds. Others require:
ignition on - also starts the timer
starter on and hold
monitor Ng - 13-15% turn on the fuel control first stage
monitor for ITT rise and Ng acceleration
first ITT peak (do not exceed 850C), on ITT drop and continued Ng acceleration second stage fuel on
second ITT peak, we have more cooling air flowing thru the engine now so don’t exceed 850C for more than 5 seconds, 1000C for 2 seconds
monitor for ITT drop and continued Ng acceleration, check starter timer
50% Ng release the starter, the engine is now self-sustaining, unplug the DT
release throttle hold (advance to low idle), Ng 63%, temperatures within limits, we have a good start with a stable engine
If during the start sequence any one of these steps or checks fails the start must be aborted and continue to motor the engine to cool it down.
Trying to code this all up to make it “automatic” would be a nightmare. ArduPilot understands nothing coming out of the Data Terminal from the engine’s sensors and thermocouples. There would have to be a new library to support that. Decisions have to be made at every step to continue the start or abort - lots of code logic (assuming ArduPilot would read the output of the DT). It is an inherently dangerous process - since we don’t have onboard fire suppression for engine fires, ground crew must available with a fire extinguisher.
So when you add anything “automatic” and it can’t be supported by all frames and prime movers, it’s not worth putting it in the code. So then the argument can be turbine power is not common, don’t have to support those because can turn the feature off so other users can relax in their lawn chair and watch their helicopter blissfully lift off and fly away into the sunset all by itself. But turbines are popular with high-altitude operators and the fact that they produce tremendous amounts of power with an engine that’s only 16" long and weighs only slightly more than a Zenoah G290. Both are a low user-percentage use-case.
That’s where a custom build applies. Being an open-source system a custom build for non common-use scenarios where only partial support is possible in the code for all types, is the best way to handle it.
I recently had one of the problems that Chris described, the turbine was hanging on start and not accelerating the Ng which causes Excessive EGT temps. It will melt the engine down if you don’t get it shut down quickly. We were using the recommended battery and it was new with just a few cycles. Replaced it with a rather expensive battery with twice the ma rating and now it’s all good. We have two telemetry links that we moitor on startup, one is FADEC telemetry coming through the Jeti telemetry system and the second is Blue Tooth coming directly from the FADEC to a tablet that a second person is monitoring. The pilot is watching the Heli and the second person is watching engine start on the tablet. Either person can call a shutdown with no questions asked. It would be great if we were able to get FADEC telemetry to the Autopilot. But, I would always want a way to quickly override the automation and be able to bailout especially on engine start. Also, on our FADEC if the engine fails to accelerate to run and we shut is down it doesn’t automatically enter the cool down cycle, we have to cycle the starter on and off manually to cool it down. We do fly at high altitudes.
Any time you get the N2 spool glowing red you got serious engine damage and you’re looking at a hot section. I see lots of pilots over-fueling them to get faster Ng acceleration with flames on the tailpipes. Not good. Turbines are coaxed into life, ham-fisted pilots will ruin one in short order.
I like it on the RC where the Pilot in Command has control of it. You can get a hung start if you let go of the starter too early before it goes self-sustaining. Or if you have a low starter battery and exceed the max motoring time you can burn the starter/generator up. Or if you shut the engine down and don’t wait for the min ITT before attempting a restart. Advance the fuel too fast on Ng acceleration and exceed the ITT limits, Or if you got wind blowing up the tailpipes during a start. Or in flight or during spool-up if you over-torque it.
There’s any number of ways to ruin a turboshaft engine.
The upside is that the typical RC turbines will fly 250 lb helicopters no problem at all. They have incredible shaft power in a small package. And they are self-altitude compensating, where most piston engines run out of power at 6500 MSL a turbine is just starting to really run. And the higher the altitude you fly them at, the better the fuel burn is. Turbines love cold air and low atmospheric pressure where you can squirt a little fuel in, set it on fire, and get huge expansion ratio.
There’s a surprising number of ArduPilot users that I support personally now flying them for high-altitude and heavy-lift applications commercially. Not too common among hobby users because of the entry cost to turbine power.
Our problem was definitely a weak battery, we weren’t getting flames out the exhaust but the pipes would begin to lightly glow and I would immediately shut it down. Put the new battery in and it started better and cleaner than it ever has. Lesson learned !! I even had a local guy (So Called Expert) look at it and he didn’t even catch what the real problem was, It took a friend I have in California that builds 3 meter autonomous turbine Heli’s for NASA, he uses the JAKADOFSKY PRO-X Turboshafts, he got me pointed in the right direction. I’m going to look at the start timer and reduce that and maybe reduce max EGT a bit, this could also have been caught with a low voltage alarm, so now I have a second PM on the turbine battery feeding data to the autopilot. One of the reasons for having the autopilot log FADEC data would be to have a one stop location to view logs instead of having to graph stuff from three different places and then try and match everything up. That’s my wish, but I realize turbines aren’t that widely used. I know a little about coding and at some point may see if I can do it…
Well, it illustrates the issues trying to make one autonomous start. Heck, at AMA-sanctioned RC clubs pilots aren’t even allowed to fly one without a turbine endorsement from an instructor. There’s a reason for that.
Other folks have made requests for this type of thing in the past as well, with other data sources. Again, the best thing for something like that is a custom build.
Curious if your temp probe is downstream of the N2 (EGT) or downstream of Ng (ITT). There is a large temperature and pressure gradient between those two stages of the engine. If the FADEC is using EGT with ITT specs it is very easy to over-temp the N2 spool. Like a PT6 idling at 470C ITT, you can lay your hand on the tailpipes without getting burned. A good portion of the heat is extracted in the N2 power turbine and converted to shaft power.
This would be another issue with trying to autonomous start one. Some use EGT, some use ITT, some use TIT downstream of the combustors/upstream of the Ng turbine, and the temperature and pressures drop at each stage of any turbine engine. The flame from the combustors never actually touches any part of the engine internally, including the combustor liners. If it does, that’s what causes the damage.
Well Chris, I have no idea without looking it up, that’s a great question This is a test platform using a Wren 44, and were at 6000’, on a hot day density altitude easily reaches 10000’, it has a 3 blade main and 3 blade tail rotor. The tail has 130mm blades so it has plenty of authority.
Trad Heli Users,
AC 4.0 rc 3 was released yesterday. here is the post. There was significant change that I wanted to pass along. I put the IM_STAB_COL parameters in percent rather than percent * 10. when you upgrade to AC 4.0, the parameter will be converted automatically
Other changes were strictly to the parameter display names and descriptions. @ChrisOlson has been working on QGC to make the heli page compatible with AC 4.0. I will be working with @Michael_Oborne to make the heli page in mission planner usable again. I don’t expect that will be ready right away. I am working with Michael to update the page layout.
Lastly the SITL version of autonomous autorotation was merged with AC 4.0. For now it only works on SITL with Realflight and @IAMMATT has it performing the entry and glide. He is currently working on the flare algorithm and control logic.
I have QGC’s heli setup mostly done, and that is in the Daily Builds at present for 4.0 rc’s. I had to put a version control in QGC because 4.0 is not compatible with 3.6. So for helicopters running 4.0 or newer the heli setup will display in the next-gen QGC ground station, but it won’t display if the firmware version is 3.6.x or earlier. For helicopters running ver 3.6.x you will have to use the current QGC stable build.
I will also prepare a couple short video presentations for the ArduPilot channel and wiki explaining the new swashplate and throttle/governor setups. I think the PR is in for the latest param description improvements, so should be able to get to that when the XML is updated in QGC.
I asked this in another traditional heli forum but I tried version 4 and had to roll back because of missing RSC channel 8 throttle control missing in ver4. In the latest version of firmware (arducopter trad heli), with the latest QGC there is no longer an option to set channel 8 to throttle output so I can tie it to a knob. I rolled back to QGC 3.5.6 and it returned, but I had to re-flash the older firmware (arducopter-heli-stable-3.6.12) manually (which I dont like doing, I like QGC to find the fmuv2 version on its own as its safer than manual updates).
Is there any reason for this change and I missed the note somewhere? I cannot use arducopter without this ability and I tried to map it through the full param list but it didnt work. I left it on the older QGC and older firmware but ideally I would like to use the latest version.
Hi Josh,
We changed the name in 4.0 because it is no longer tied to channel 8. It is now called RC passthrough. The user now has the option on setting the RC channel for the motor interlock and the RSC passthrough mode follows that assignment where as in 3.6 it remained tied to rc channel 8.
