Servers by jDrones

Rotor RPM Sensing

(Robert Giordano) #9

Thanks for your reply. I’m actually trying to figure out average RPMs on a quadcopter hovering in Loiter because I want to determine the excitation frequency of the motors/props.

I want to know the excitation frequency in order to best eliminate vibration harmonics between the motors and the natural frequency of the frame I’m designing.

(Bill Geyer) #10

I’m not sure if this is helpful but with helicopters if you take an FFT of the gyro signal, it is very clear what the rotor speed is based on the peak in the FFT. Not only do you get a peak at the rotor speed frequency but also at the frequency of the number of blades * rotor speed. Now with Multlcopters, I don’t think the peak would be as pronounced but I would imagine that you would get some wider frequency range with increased energy/amplitude on the FFT. You would definitely have to keep the aircraft in a stable hover so as to minimize the variation of prop speeds.

The only other way I can think of is buy ESC’s with logging capability and download their logs after the flight. At that point it is just matching ESC log to what you were doing in flight or to the pixhawk log.

Good luck!

(Robert Giordano) #11

Okay so Fast Fourier Transform? And what parameter would be the “gyro”? IMU? something else?


(Bill Geyer) #12

So it could be just about any of them, at least that is the case for helicopters. I would suggest using the batch logging feature described here.

Here is a plot from the sampling that I did with my helicopter. Here is the FFT of the Accels

And here is an FFT of the Gyros

My rotor speed was 30 hz (1800 RPM) and you can see the nice large peaks in the X and Y accelerometer. So maybe those two would be your best bet. I have never done this with a multicopter so you may have to experiment to see what signal works best.

Good Luck!

(Robert Giordano) #13

Ahhh, thanks for the link!

( Doug) #14

I talked to Rob at AUVSI-Denver and he said that Tridge had Rotor RPM sensing input on Aux-5 and governor control working and he thought it was in the Master but I can’t find it anywhere. Maybe its still in a branch somewhere. Maybe someone else could look around and see if it can be found.

( Doug) #15

I did find this in the Library

It talks about setting the input pin and type of sensor and appears to include Hal sensors.
Also, Rob said that Tridge had set up the PID loop code for the governor function and that it would work down to about 10 rpm

(Bill Geyer) #16

Rotor speed control using the rotor RPM would be accomplished in the motors heli RSC library. I am not aware of a closed loop control algorithm that was added to this library. However the RSC controller was originally designed to support a closed loop algorithm if/when the control algorithm was developed. So now that we have rpm sensing it would not be hard to implement this. If anyone wants to code this capability, Chris and I could work with them to get it merged into the code.

(Chris Olson) #17

There is rpm code, but I am not aware of any governor functions in ArduPilot. I have rotor speed sensing with hall-effect sensors on all my heli’s. But I use it on the RC telemetry and not in the ArduPilot code, or for logging.

On my gas heli’s I have two sensors - one for the engine governor and the other for the RC telemetry. I drill a hole in the autorotation gear and put the small magnet in the hole and epoxy it in there. Both sensors use the same magnet.

I found it most useful on the RC telemetry for several reasons:

  1. On my commercial heli’s I never look at the logs unless there’s a problem. I fly them for a full year sometimes without ever pulling any logs out
  2. Some of my flights I don’t use a ground station - but I always use the RC radio and have headspeed (and engine temp) no matter if I’m using a ground station or not.
  3. Most all heli ESC’s have built-in logging and governors these days
  4. The commercially available governors for piston heli’s are not expensive, and have advanced features like being able to turn it on or off with a switch, and set different governed headspeeds with the flick of a switch.
  5. The FADEC controllers for turbine engines have their own governor and speed sensing for N1 and N2.

One useful thing headspeed sensing might be used for is automatic autorotation if the engine stops in flight in auto flight mode. But, as I said, the code already exists to read it - what doesn’t exist is any methods to use it.

(zhangpeng) #18

Very much needed!

Because the current ESCs all have GOV functions, for example, the V4 series ESCs of HOBBYWING have very high quality. At the same time, they have speed signal terminals. It is easy to realize speed monitoring and constant speed control of the ESC in Pix. I recommend incorporating these codes and functions into the firmware!

(Chris Olson) #19

Bill and I will put together a “road map” of things TradHeli needs (or doesn’t need) for the future, and some sort of assisted autorotation is one of the things we have talked about. Which will require rpm sensing for the headspeed. We have many other things on our plate right now with the 3.6 release candidates in testing phase to make sure TradHeli is stable when 3.6 hits the first point release. As Bill mentioned, if someone would want to help by using the existing code to make a logging function (or feed it to a MavLink message to the GS), and test a suitable sensor that works, we would certainly help get it merged to master.

And then this would be in place when we do autorotation code for 3.7. Or it could also be used for a governor function in ArduPilot. However, I’m not sure we can duplicate the quite advanced features of the commercially available governors. We can do governor code, but the problem is that it requires more parameters, and 3.6 is up to 800 parameters. The brakes need to be put on some of these things that keep adding more parameters to the code or ArduPilot will become so compilicated it will be difficult to set up and use for the average user. All those parameters in 3.6 are not for heli, but one of the things on our plate is to make heli more user-friendly for setup.

( Doug) #20

Chris, I have have a Hal sensor for rotor RPM coming back through the RC telemetry link and I manually control turbine RPM. This is a 1.5 meter rotor Heli and once it’s airborne and RPM is set I don"t have to mess with it much but for the transition to flight at lift off I have to be careful not to overspeed the blades. I’ll look around some more when I get a chance but from what Rob said Tridge did this for a special project he was working on and had this fully working with closed loop control with adjustable PID’s. And, yes this would be the predecessor to Auto-rotation.

(Chris Olson) #21

Is this an older engine like a MW54 or a JetCat single stage?

It may be possible tridge has something like this working. If so I’m not aware of it. Rob may be referring to some basic governor code he did in AC3.4 that may or may not have been flown and tested, I’m not sure

( Doug) #22

Chris, its a Jakadofsky Pro X

(Jakob Schmidt) #23

Unless I’m misunderstanding something, this already exists.??
Look at the RPM parameter in this log:

I’m using the hobbywing RPM sensor mentioned earlier.

( Doug) #24

Jakob, The sensor your using pulls RPM from the brushless motor. What we’re talking about is a sensor that pulls actual rotor RPM directly from the main rotor gear and feeds that into the pixhawk and the associated code to take that RPM and control throttle and in the event of engine failure that RPM could also be used in-conjunction with collective pitch in order to preform a auto-rotation

(Jakob Schmidt) #25


However, that should still work with the hall effect sensor? (I keep meaning to buy one of those Align ones)

(Chris Olson) #26

OK, I had to get up-to-date on this. It appears the code reads pulses or PWM. If your hall effect sensor puts out a pulse per revolution, it should read it on pin 54 and set the RPM_TYPE to 2. 50Hz will show 3,000 rpm, so it appears the scaling would be 1.0 with a single magnet on the auto gear. Any hall effect sensor should work the way I read the code.

(Samuel Tabor) #27

Hi Chris,

To combat the growth in number of parameters you might create a new group containing an ENABLE parameter with the AP_PARAM_FLAG_ENABLE flag. This way, the parameters in the group are only displayed to the user when the feature is enabled. is the example I’m most familiar with.


(Chris Olson) #28

Wow, thanks for that tip, Sam. I didn’t realize we could do that. That will certainly be helpful. Heli does not have a lot of params compared to some of the other things. But it is still good to try to keep the number of params that have to be downloaded to the GS at boot time to a minimum.