Hi!
I’m using Pixhawk 2.1 with two RPM sensors, both type 2 (connected to the AUX pins). One is reading the RPM of the motor, reported by the ESC, the other one is connected to a hall sensor on the main rotor shaft. Is there a way to setup a warning for low rotor speed / engine failure?
Hi Felix,
Great to hear that you are making use of the RPM feature of Ardupilot. Currently there is no low RPM warning to my knowledge. there is a below critical rotor speed message that is sent to the log. I think that would be something @ChrisOlson and I would look to implement in the future once the spool logic changes are complete (which we are looking to have finished for 3.7). this would also be beneficial for the autorotation work we are planning in the future. I’m sorry there isn’t anything in there at the moment.
Regards,
Bill
Hi Bill,
thanks for the fast reply! I just thought, I might have overlooked something, how to monitor the values, mission planner is receiving. Yes! Autorotation would be a great feature! But I guess it’s going to be a difficult way to get there. Another great possibility I can see in using the data of the RPM sensor, is to implement something like the “optimum speed rotor technology” of the A160 Hummingbird. It would allow significantly longer flight times.
You can monitor RPM in the Mission Planner Hud if you would like. I don’t know if that helps but it can be added as a line in the hud readout.
Yes, I’m using that feature. I meant automatically monitor, so that I’m being informed if the RPM drops below a preprogrammed threshold.
Felix there is no warning system set up for it at present. When we eventually use it for indicating loss of power for autorotation then the code will have values it looks to determine if autorotation is necessary.
At the present, the only way I know of (short of modifying one of the ground stations) to have a warning is to use rpm on your RC telemetry and have a warning announced on the RC. This is actually better because RC telemetry has close to zero latency. Mavlink has quite a bit of latency so if there is a power loss in auto flight, for instance, you would likely not get the warning via the ground station until after the fact when the rotor is already stalled.
I think what we plan on is to monitor this onboard the aircraft in real time. So the autopilot can respond appropriately to a loss of power and prevent stalling the main rotor. In this case the ground station announcing autorotation has commenced due to loss of power is not after the fact as the autopilot has already initially responded to it and the helicopter is losing altitude, but it is still flying. In auto flight mode there is only about two seconds after loss of power where it will be possible to enter successful autorotation at altitudes that most UAV’s fly at. And that is about the normal latency in MavLink. I think the issue should be self-explanatory as to why a low headspeed warning in the ground station wouldn’t really work that well.
Hi Chris,
thank you for your detailed answer. Yes, that explains a lot. So an RPM warning via MavLink wouldn’t be that helpful. I’ve seen in your videos, how you set it up via RC telemetry. By the way: I really like your Synergy 766G! Unfortunately I don’t use RC telemetry, because I’ve got an mc-22 with a Spektrum module that doesn’t support that. The other thing is, that I’m planning to do measurement flights with the helicopter and I like it to have all information recorded. Pixhawk does a pretty good job in logging the data. I wouldn’t have that, if the sensors were connected to RC telemetry. So I guess I just have to live without the warning for the moment and – what you always should do – put enough time in maintenance, so the motor won’t fail in the first place. But I’m really looking forward to the onboard monitoring you’re talking about! Would be a great feature, especially with autorotation capabilities. I guess for the beginning it would be sufficient to just lower the collective to a preset value when a loss of power is detected to give the pilot more time to react.
I think that’s what we’re looking at doing for an initial autorotation system, is to have an autopilot assisted autorotion where the autopilot will set up for it in the initial stage of power loss in flight (can happen with electric too due to dead batteries).
Doing a full-down auto with the autopilot is pretty challenging because the altitude to execute the flare is not all that accurate in ArduPilot. Especially if the terrain is at different altitude than the heli took off from. Would almost require a laser range finder or similar. And if the heli is moving in forward flight like it should be before the flare, laser range finders don’t work all well either at 20-25kts. The heli will be in ~12 degrees nose down in the glide and the range finder has to shine directly downward.
So when we get around to working on this, the autopilot’s job will be to prevent the rotor from stalling. The pilot still has to land it. But RPM monitoring will be required for the autopilot to decide if autorotation flight mode should be engaged. And some sort of failsafe to detect a failure of the rpm sensor so it doesn’t engage autorotation simply due to a failed sensor.
Not an easy project.
That’s true. Definitely not an easy project. I guess a failed sensor could be detected by how fast the spooldown happens. If the signal has just vanished, it’s a failed sensor, if the rotor (or motor) slows down exceeding the normal RPM-range, it’s a power loss and autorotation flight mode should be engaged. But for a full down auto you need something to determine height pretty accurately. I guess that could be either a LIDAR as you said or something like a stereo imaging system. Of course the latter would need a lot of processing power. Or you’re doing it in a separate unit together with the cameras and this unit is only sending something like a terrain profile - or in the easiest case just the height - to the flight controller.
The other thing I mentioned, the “optimum speed rotor” would be relatively easy, once you have a working RPM sensor. The controller would need to identify the flight condition the helicopter is in. Is it cruise flight, takeoff or landing or the pilot having some fun with high power demand? Or something in between… Once that’s clear, the controller can adapt the rotor speed (continuously) to that condition and you’ve got a helicopter with perfect agility when you need it and with perfect efficiency when you don’t even notice agility (e.g. in cruise flight especially in auto mode). And the best thing about auto mode is that you know in advance, what flight condition you’ll be in.
I believe adaptive rotor speed is used in both the EuroCopter/Airbus x3, and the Sikorsky x2/S-97 Raider. I don’t think the EuroCopter concept has flown anymore. But Sikorsky/Lockheed-Martin is actively testing and developing the S-97. They crashed their prototype last year due to ground resonance but resumed flight tests a few months ago again. It will be interesting to see how the adaptive rotor speed technology is applied in the full-size model. Whatever applies to full-size also applies to RC. And Sikorsky/Lockheed-Martin’s R&D resources are infinitely larger than mine.
Hi Chris,
Yes, that’s true. Airbus Helicopters X3 and Sikorsky X2 both use adaptive rotor speed. But in a totally different way. They’re high speed concepts and have to reduce tip speed on the advancing blade, to avoid transsonic problems like shocks and in general high energy consumption. With RC helicopters we don’t have these problems. But we could learn something from the A160 Hummingbird which as far as I know holds the world record for the longest non-stop helicopter flight. The trick was it to adapt the rotor speed to the specific flight condition.
For us, the first step could just be to monitor the power demand (collective position) over the last let’s say 10 or 20 seconds and if it’s constantly low, we can reduce RPM progressively. As soon, as the helicopter starts climbing or entering a less predictable flight condition (more maneuvers, more pilot inputs etc.) we can raise the rotor speed again. I think that’s not very difficult, but could bring us a lot more flight time.
I agree this could probably work very well with electric helicopters that can only carry a limited amount of energy. I played with electrics last year and got them up close to an hour of flight time carrying a moderate battery load.
But then I went back to piston power and 2 hours is really trivial for a gas helicopter. The total fuel weight for two hours of flight is approximately equal to two 6S 5000 batteries. Which on electric power would fly the same helicopter for about 8-9 minutes. The other advantage with combustion power is that I don’t have to run excessively low headspeed to get flight time. I run them at minimum 450 feet/sec blade tip speed which really enhances the stability, performance and handling of the machine. Slow the engine down and fuel burn actually goes up. Flying at 20 m/s at 16-17cc/min @ 450fps blade speed becomes 20cc/min if I slow the rotor to 400fps.
And that’s still much slower than full-size. Most ultralights run 500-550fps. A Cabri G2 runs 650 fps. All larger helicopters with the exception of the Bell UH-1 run 725-750 fps. The UH-1 is 814 fps @ 324 rpm and is part of the reason for its unique sound.
Which interface should the ESC’s speed sensor line be plugged in to display the speed of the electronic governor? I haven’t figured out the connection and setup issues, and I haven’t found any instructions on the wiki.
You need to connect it to one of the AUX pins:
http://ardupilot.org/copter/docs/parameters.html#rpm-parameters
I had it working on my Protos500 with a separate RPM sensor (connected to the ESC output), but have yet to get it working on my Soxos600, with a Hobbywing V3 ESC, with a built in RPM sensor (but have only briefly experimented with it).
You then also need to figure out the scaling values.
I first estimated mine from the gearing, measured with a phone app (Headspeed) and then adjusted the scaling value.
That’s true, I had electrics in mind when I thought about this. I’m using a T-Rex 800E PRO DFC. Mostly because I need accurate information about the power consumption for the measurements I planned. That’s easy with a current sensor in an electric helicopter. But how do you do it with a piston engine? Besides that, flying electrics is easier thinking of flight regulations etc.
Interesting what you’ve noticed regarding the fuel burn in combustion engines. I guess that’s because of the engine not running in the point of highest efficiency any more…?
@zhangsir:
I’m using a Phoenix Edge HV 160, which can generate a pulse every electrical commutation on a separate line. I connected that to the AUX pins of the Pixhawk (Cube). But be sure you don’t have a ground loop in your setup. I isolated both ESC-lines with optocouplers.
Fuel burns by the clock not by the gauge, just like it does in full-size. No need for complicated battery monitoring. When you file a flight plan for full size fuel onboard is not given by lbs or gallons or liters - it is supplied to ATC in hours and minutes. Same applies to RC. Unlike batteries that change capacity with temperature, age and load, none of that applies to combustion engines.
Yes, all aircraft engines have a cruise power setting where they are most efficient. Again, RC is no different. But unlike batteries that go into a death spiral as voltage sags, the fuel burn in combustion engines is a constant from tanks full to empty.
Felix, I’m curious why you would say electric is easier? In my experience fuel is easier and much simpler. It has a generator to keep the flight systems battery charged. It is the least amount of hassle and far more reliable. No big magnetic fields in the aircraft to mess up compasses. Electrical system is way less complex. It’s way cheaper to fly.
I know of no flight regulations that prevent use of combustion engines. They have been used in full-size aircraft exclusively since the beginnings of powered flight. It doesn’t take long to get $700-1,000 tied up in batteries, chargers, balancing boards (and some even carry generators to charge batteries in the field) for a 800-class electric helicopter. That money will buy over 300 gallons of gas at today’s prices. That 300 gallons will fly that same helicopter over 1,100 hours of flight time. You’ll be really lucky to get 100 hours from $700 worth of batteries before they have to be replaced.
For smaller helicopters of 600-class and lower, electric makes more sense. They aren’t big enough for gas engines. In the past there was lots of nitro models in those sizes. But once above 600 class (you can do a 600 gasser) I don’t see where electric makes much sense just because of the battery cost and weight.
I believe that there is been an overcomplicated debate about implementing autorotation.
In 80% of cases when a UAV heli has an engine failure, a safe and successful landing is not achievable.
Therefore most of the high end commercial autopilots, don’t implement a full autorotation function, instead they implement a "collective limiter "
The collective limiter, is a function that is enabled after spool up and reduces the collective every time that the RPM drops out it’s specific range. This will trade off Altitude VS Engine load ( Rotor RPM ), avoiding an engine stall or a dynamic loss of control due to low RPM.
In case of a complete engine failure, this collective limiter will reduce the descend rate therefore reducing the severity of the impact ( assuming you have some forward Airspeed ).
One things that has to be noted. The collective limiter will need to be supported by an other function of Forward speed VS Target Height. If this second function is not present then you can run into some trouble if you are trying to fly with a fast forward airspeed with high engine load.
As for Low-RPM event warning, I believe that is a must have! An indication of a low rpm event on the GCS, will help the UAV operator evaluate if the helicopter is now operating on the borderline of the flight envelope and decide to abort the mission or not. I have been in this situation many times and the RPM warning on the GCS saved the day.
The best option for RPM sensing, is to collect rpm data from two sensors. Sensor 1 located on the engine, Sensor 2 located on the main rotor shaft. The sensor data that will be considered “VALID” is the one closer to the " Target RPM ". In case of a dual sensor failure, the Autopilot will revert to a basic collective curve instead of a governor. ( this applies for heli that have a couch or a one way bearing ).
I would have to disagree if there is forward airspeed. I’ve successfully autorotated two of them from 75 ft AGL @ 20 kts cruise - one due to clutch failure, the other a broken electric motor shaft. Both were about a 1/4 mile away, one I landed in a grass waterway, the other on a irrigation road going to a center pivot in a corn field. Both were done primarily on FPV with some guesswork in executing the flare and pushing the nose down after I lost the FPV signal close to the ground and the helicopter out of visual reference from where I was. Neither had any damage short of the mechanical failure that caused loss of power. Both were announced my RC telemetry (real time, not MavLink latency) with low headspeed warning, plus audio feed from the FPV with strange noises that were not normal. One was a nitro and the engine was still running when I got there to pick it up. The electric one, the motor caught on fire (due to the motor’s rotor hitting the windings with a broken shaft) but it only scorched the paint on the canopy.
From hover, autorotation is very difficult. Initiated from forward flight it is not difficult at all. My large gassers, even though they are heavy, can be flown in autorotation across a 40 (1/4 mile), turned around and flown halfway back across the 40 from 400AGL. Smaller helicopters are more difficult to autorotate because of lack of rotor mass.
Yes, that’s clear. Nevertheless in my case I need precise information about the real time power consumption of the heli. I’m doing research on retreating blade stall and a way to prevent it. So I’ve to compare different modifications on the helicopter. With an electric heli I can measure it, look at it and say: “Oh, this one needs 300 Watts less power.” I think it would be really hard, if not impossible to have information like that in a gasser.
In Germany there are very strict regulations for flying with combustion engines. You have to go to a model airfield. With electrics that’s a lot easier. Besides that you don’t have to do carburetor adjustments, the heli is always clean, you never have startup problems… just plug the battery in and fly. And I guess it’s more reliable, because there aren’t that many moving parts. The motor just runs, whether it’s warm or cold, dry or humid air… But yes, you’re right: Flight time is terribly short 
And yes, I’d also agree that autorotation with some forward speed with a UAV heli is a doable thing. But only if the pilot (or autopilot) reacts fast enough after the engine failure. Therefore an autorotation feature that does this for you would be a pretty desirable thing.