Autorotation - why you need to know it

Flying a survey late this afternoon experienced sudden loss of engine power. Autorotated it on FPV from a distance of ~3/8 mile, 75 ft AGL, 20kts, over a rise out of sight from the ground station.

Post incident investigation:

  1. I did not touch the controls on the RC after I set it down until I got to the helicopter.
  2. Filmed the result of the autorotation - never lost the RC link from the FrSky sensors or receiver, but did lose telemetry from ArduPilot.
  3. Examine engine throttle position - RC state is armed, throttle hold off - controller state is disarmed, throttle is in fuel-cutoff position, reporting in Stabilize flight mode. At minimum, the throttle position should be at flight idle.

Flipped the switches, armed it, the engine started right up. Ran it up to flight idle and no mechanical problems noted.

Conclusion:
The controller rebooted in flight and shut the engine down.

Not the best autorotation I’ve done. But good enough under the circumstances.

1 Like

Wow…you are very lucky Chris.
Do you practice FPV auto’s?

It will be interesting to find out why the controller rebooted.

Steve, yes I do practice them, actually, on FPV. For some reason I find it easier on FPV than doing it with normal visual reference.

Have not tracked down the cause of the controller rebooting yet. The log contains no useful information - it just ends and everything is normal right up to where it stops. Which is the same thing I observed in the way the heli flew, then suddenly quit. I auto’d it in Acro (or so I thought) but it was reporting being in Stabilize on the telemetry when I got to the helicopter. Stabilize is not even my flight mode selection.

It took me about 10 minutes or so to pack everything up to I drive out to get it. I double checked all the switch positions on the RC. I still had RC link and FPV link so I knew it was sitting safely on the ground. When I turned off the RC I got the complaint about the link still being up, so I force shut the RC off. Then drove out there to get it.

I grabbed the camera and made the little vid. Then began the investigation before I moved it. I connected to it with my tablet and it was in Stabilize, throttle was in fuel-cutoff, etc…

I just verified with a bench test that if I’m in Acro and turn the radio off it stays in Acro.

So the fact that it was in Stabilize, which I don’t even have in my setup, plus the throttle was at fuel-cutoff was a dead giveaway that it had rebooted in flight.

Here’s 15 seconds worth of images from the onboard GoPro.

Systems normal, everything in the green.

G0015776

In autorotation

G0015777

Autorotation complete. Camera is no longer mounted to the heli.

G0015778

About 3:1 glide ratio at 20kts. Ground run was about 6 feet. But this field was rough, camera hit a dirt hump and got tore right off. Still had the FM carrier on the FPV though. :grinning:

Strangely, I never seemed to lose RC control. It normally takes more time to boot the controller than the autorotation took to complete. But it didn’t start a new log when it rebooted, because it was now disarmed. it’s either that or it disarmed in flight, but then that wouldn’t explain why it went to stabilize flight mode.

Still, one of the advantages of flying helicopters. This would’ve been a pick up the pieces in a bag wreck with a multicopter. And is now the third time I’ve successfully autorotated a helicopter on commercial flights. The landing gear is designed to be sacrificial and is a $7 piece of aluminum. Also a good demonstration of why helicopters have skids or wheels, and not moon-lander feet.

Chris, glad to see it ended reasonably well, all considered. That ground is one of the worst to make smooth and safe autos and the bordering trees were not that far either!!
What caused it scares me really A LOT though, can you provide some more details? I just moved into chibiOS (since I have a CubePurple- with vbar 3.6.5 compiled- on my newly built Rex700E FPV machine) and it’s maybe wiser to keep it on the ground, or just switch back to a pixracer with NuttX .
@Steve_Mitchell FPV autos are real fun, here some practicing with Logo600 (2:40 ->):

The trees is why I had to bring it down so hard. I flared early to get rid of glide ratio or it would’ve been in the trees. I didn’t have enough headspeed to make a turn. I should’ve showed on the video how close it was to the trees. Those rows are 30" apart and it was on the 7th row from the trees, or only about 17.5 feet. That was the biggest panic when I saw those coming in the FPV.

Ground run was only about 6 feet but the aluminum gear did a pretty good job of absorbing the impact.

Do not know for certain what caused it to disarm or reboot.

Edit:
@Ferrosan on the topic of landing gears, I’ve seen outfits make UAV helicopters, like the Pulse Vapor 55, and put moon lander feet on 'em. I’d like to see somebody autorotate one of those. You can spot-land a lightweight 3D heli. But bringing in a 25+ lb UAV requires a lot of airspeed and all moon lander feet is going to do in the run-on it tip it over and wad it up. Doesn’t make sense. And it’s not “if” it’s “when” - you fly these things long enough, either RC or full-size, you end up making an emergency autorotation at some point in your career.

Yeah yeah yeah…I’m in the process of changing that landing gear, ok ? :smiley:

I put a NuttX build in the controller (older CUAV V3) in this heli and it fixed a lot of problems. The logging now works properly every time. No more Critical messages about no IO thread heartbeat. It boots and downloads the parameters faster without stalling like it did on ChibiOS.

I reverted my ArduHeli build to get rid of all the watchdog stuff in it that got “hotfixed” into Copter 3.6, as it’s not needed for NuttX. I flew it for 45 minutes with that build just before sundown and no further problems.

My guess is that ChibiOS rebooted, crashed or locked up and caused the issue. This controller does not seem to like ChibiOS.

Chris, I reckon you walk away from that auto with a smile on your dial! :sunglasses:

I haven’t flown in over two years and will try FPV flying and autos soon. This weekend, I should have my old Goblin gasser up flying again with FPV gear. Coming from a full-size helicopter background and having done a few auto’s! I would like to have the throttle on a twist knob instead of collective stick. Would still have throttle hold on a separate switch for auto practice. Do you think this would be fine with your new Gov code?

Your controller rebooting is a real worry. It’s alright if you have a multi-rotor worth $1-2000 bucks but our gas helicopter are too expensive for that nonsense. It’s surprising it rebooted fast enough to give you control to pull off a low-level auto.

I agree, lunar lander legs on helicopters don’t make sense. You need to be able to run it on, pulling off a 0-0 auto every time takes a lot a skill!

Right now the throttle is on the collective with the throttle curve as conventional RC setups are. The throttle hold switch turns it on or off as per conventional RC setup. The governor depends on that. Instead of a switch could put the throttle hold on a knob, but it wouldn’t be like a full size twist grip because the throttle is either on or off on channel 8.

The governor is now merged in master. If you want to fly it on 3.6 you can get it here->

I flew a new Bell 505 about a month ago and they eliminated the throttle twist grip in the 505. The Turbomeca (Safran) engine has a new dual-channel FADEC and they have a two-position switch for idle and flight power. It’s strange if you’re used to a 206. Amazingly, with that new dual-channel FADEC the engine can be started at either idle or flight throttle. And it can be shut down hot and immediately restart it without danger of over-temping it. It was different, that’s for sure. But it’s kinda like RC ones.

This older hardware evidently has something that doesn’t play nice with ChibiOS. I have three other helicopters with CUAV V3x controllers and those have no problems at all. But this one has been problematic with logging. Sometimes had to reboot it a couple or three times to get rid of the Bad Logging. Then take off and 4 or 5 minutes into the flight it suddenly triggers Bad Logging with a CRITICAL: no IO thread heartbeat message. I tried different SD cards in it and thought I had it fixed. But when there’s stuff like that that suddenly fails in flight I should’ve realized other things can probably go wrong too. I flew it enough on the NuttX build to be confident that it’s happy. And the NuttX build for PX4-V3 (will run fine on a Pixhawk Cube) is now available for the ArduHeli build with the governor.

I can manage very few autos without getting some run-on with these heavy helicopters. Only maybe if I got a 10-12 kt wind or something. The ground usually arrives before I get it stopped. If I strip the helicopter down, get rid of the cargo hook bar, belly tank, payload etc then it floats pretty good and don’t want to come home. But its generally safer to just run it on and don’t risk banging the tail rotor in the dirt.

When I replaced the front strut on the one that got bent I shortened it a bit to give the helicopter 3 degrees of rake in a nose-down attitude sitting on the gear. That will allow the rear of the skids to touch down first. Can’t do that with a full-size but with RC you can. This gear slides over rough terrain pretty good and won’t dig in and nose the heli over. Plus gives it 8 1/2" of tail rotor clearance, even with the 12" diameter tail rotor on it. I got three of these, and I’m going to make the same change to the other two.

It was the gear that saved this one from my bad landing. If the gear can’t crush and absorb energy in a hard landing the helicopter will bounce and tip over. The gear stance is 15" and that helps on rough terrain too. In a hard landing the gear will spread and fold back to keep the helicopter upright. Aluminum is easily repairable and has the ability to deform when it’s load limit is reached without springing back and causing it to tip over. I was quite pleased with the performance of the landing gear - it did what I designed it to without damaging the helicopter.

100_0108

Chris, thanks for the throttle/ Gov info. I watched your throttle curve video and now understand why my idea of twist knob throttle isn’t a good idea with standard RC heli setups and new governor.

I’ve installed ArduHeli-3.6-L1Nav-CubeBlack yesterday and did a few ground run’s without main rotor blades before last light. The old girl started up fine, but I have a few small issues to sort out! Mainly to do with Gov RPM sensor/ noise on the main gear and the engine RPM telemetry/ generator system. I tried an old GV1 sensor for the gov pickup but will change it out for a hall effect sensor.

You have defiantly got the auto’s down pat. Good idea to raise the tail to. I will need to increase my ground and tail clearance at some stage as I’d be lucky to have 50mm on each!

Steve, if you have a small ferrite ring try putting it on the rpm sensor wire near the controller. Wrap the signal and ground wire thru the ring 5 times (if you can). Doing so, in effect, forms a choke coil that sometimes removes most of the outliers on the signal that can be caused by common mode.

Chris, I tried a a small ferrite ring and it did drop the spikes but not enough. Will try a hall effect sensor today instead off the GV-1.

Update:
Change to hall effect sensor worked. :+1:

[quote=“ChrisOlson, post:6, topic:43615”]
But bringing in a 25+ lb UAV requires a lot of airspeed and all moon lander feet is going to do in the run-on it tip it over and wad it up. Doesn’t make sense
[/quote] I agree, but what’s on the flight manual of these helos regarding emergency landings? or do the manufacturer provide adequate training for these scenArios? I have seen some advert videos of commercial UAV doing automatic autorotation , at the flying field , perfectly aligned with the runway and at the exact entry altitude at the moment of cutting the throttle. They even put wheels on the skids to make it smoother. What’s the point of it as in most/more practical commercial cases you are away from the perfectly smooth runway, probably operating close to the danger zone of H/V graph without a clear idea of possible obstacles ?! This automatic stuff would probably be the first thing I disabled If I was going to buy one. Awareness, practice and experience is the only gamechanger in real emergencies I guess.

Steve, wow that GV-1 sensor has really dirty output.

I like the autopilot to fly waypoints as it can do it way more accurate than I can at the distances away from me that it does it at. But otherwise, most of the automatic stuff I don’t trust. Auto takeoff and landing - don’t trust either one. All it takes is a GPS glitch to make that go bad. I have used Return to Launch a couple times to test it to see if it works. Otherwise my Return to Launch is Acro and FPV. LOL. I never use Loiter. I only use Pos Hold for 30 seconds or so before starting a mission to make sure the nav system appears to work and it holds position in the sky before switching to Auto.

I flew an Auto flight late this afternoon and the GPS was screwed up. The altitude was way off. The heli was about a 1/2 mile away and heading for this knob and I could see on the FPV it was low on altitude. And it wasn’t climbing - it was going to do ACFID (Autopilot Controlled Flight Into Dirt). So I went to Return To Launch - switch to acro, pull pitch and get out there before it hits the dirt and fly it home. This mission wasn’t working. It was supposed to be at 40 ft AGL but it was flying at ~25 ft AGL for most of it until I aborted it. So can’t even trust using the Absolute Altitude in missions because it uses the GPS altitude for that and it’s not accurate.

All automatic features require PCB (Pilot Controlled Bailout) when they fail to work.

2 Likes

Ah, that’s nothing! This is what it was like raw first go without a ferrite ring.

And with Hall effect sensor. The engine is running pretty rich and without main blades. I’m happy to start test flying now.

That is really bad signal from that GV-1 sensor. I have an old GV-1 here someplace. I used to use it on my 700 nitro but it quit working years ago. It was likely the sensor that went bad. On my gassers I am using two magnets on the auto gear that drives the tail rotor transmission, and set the rpm scaling to 0.5. Getting more samples with two magnets instead of one makes the rpm more accurate. The rpm library has a mode filter that filters out outliers and going to two magnets pretty much eliminates the occasional spike at the rpm’s we are measuring with helicopter headspeed.

1 Like

Thanks Chris, I’ll try with one magnet for the time being as it’s going to be a bugger changing over to two.

I’ll post a summary of what tridge and I think happened that caused my emergency autorotation.

So, analyzing the tlog is very useful and those tlogs contain WAY more information on things than I ever thought they did, once you learn how to decipher the MavLink messages. The information contained in the tlog, based on remnoise and remrssi vs data received from the FMU, and the timing, indicate the controller powered down in flight momentarily. Which caused the IOMCU to close the throttle to fuel cutoff and put all my servos at trim value. Making an almost perfect entry to autorotation, as this part of the system is powered from the servo rail.

So we found a couple problems. The POWER FLAG messages indicate that my backup power to the controller wasn’t working. This is a bitmask that is set based on the system sensing where it has power available. Primary power to the controller is from the power brick, secondary is on the USB port with a little “smart” NiCAD battery pack. The power flag was 1, it should’ve been 5 if there was actually power on the USB port.

So on a bench test with the system powered from the backup battery the power flag is 4, like it should be. This is what I use for pre-flight to power the system up, warm up the IMU’s etc, without powering the servos, to save on flight systems power until the engine is started and the generator starts charging the flight battery. When I flip the master switch and turn on main systems power, the power flag goes to 1 instead of 5. The reason is because the backup “smart battery” senses no load, so it shuts down its output after a period of time. And it will not repower the system without being physically unplugged and plugged in again. It was my fault for not testing this thoroughly enough, as I did not realize that little battery will not put out power after it has shut down by its “smart” circuit.

So there was no backup power to the controller.

The power brick that comes with the CUAV v3 controller says it accepts 2S to 8S input. But these do NOT work on 2S power. It requires minimum 3S to get power out of the voltage regulator to the controller. So I have a Hex Power Brick Mini on it instead, as this one as has always worked on 2S. However, it may not work reliably on 2S. If the flight systems power sags due to servo or payload load on the system, with that power brick operating on the lower end of the voltage regulator’s range, it will cut the power to the controller momentarily.

I just verified this on a bench test. I powered the system up with the voltage at 7.8V. I let the system run long enough to get the battery to sag to 7.5V. With a probe on my DVOM to measure the voltage I armed it and operated all the servos with the RC. The voltage to the controller dropped to 3.91V.

So my conclusion is that in my piston helicopters running a 2S flight systems voltage that I should be using a different style of BEC that is suited to 2S input to power the electronics. Only use the power brick to monitor the system voltage to ensure the generator is working. And, of course, change my backup battery to a “non-smart” one that continuously powers the backup port.

Thought I’d pass along what we learned, as this could happen to other people running HV servos on straight 2S power, and powering their system with the power brick that comes with the controller on the 2S battery. The generator normally maintains 7.85V system voltage. But in this case the tlog indicates the servo rail was down to around 7.7V due to the battery being a bit low from bench running it in the shop prior to the flight. It takes the generator an hour to charge up the battery to normal voltage if it’s low, along with powering the rest of the system load. And I think that sagged voltage was just enough to cause the power brick to momentarily shut 'er down in flight, as it had hit the bottom of what the voltage regulator could do to power the flight system. So she browned out and put my helicopter into autorotation.

I could “patch” this by setting the minimum arming voltage to 7.8V instead of 7.7. But that would not fix the root cause of the problem, especially if the generator failed in flight and I had to bring it home just on what’s left in the battery. There is ~5A load on the system with electronics, servos, radios, high-powered FPV transmitter, payload. If the generator fails it doesn’t take but a few minutes for the flight systems power to sag below 7.5V with everything operating.