For my helicopter, I’m using 6.2 hz but it will vary depending on the Heli. I added the notch filter in my version of AC 3.3. I’ve found that the low pass filter already built into the PID controller is not enough
Yes Bil, I read your thread. I was curious if you stuck with that same 6.2Hz or not with further testing on your frame, or if you had revised that later. That is a quite interesting topic that I think holds some promise. I’m sure there’s some room for improvement of the rate controllers in heli. But even the way it is, if you fiddle with it it will fly a heli pretty decent.
Does anybody know what the ATC_RAT_xxx_ILMI params do? They are set to zero by default and I have no clue what they are for, or do.
Chris,
Yes it seems that the frequency of the instability does not change with the feedforward enabled and ACCEL limiting.
The ILMI parameter is the I min value for the integrator leak as opposed to the IMAX parameter which limits the max value of the integrator.
Ah, OK. So, since it is set to zero by default, does that use the default leak-down for the I gain? Or does that mean the integrator leak is disabled? I can’t find that param in the current documentation of the full param list, so was kind of curious as to what values to start with to use it. I think it was, in AC3.3.3 at least, that it bled down the integrator by 20% per second by default.
I tried to track down where the ILMI param came from, and how to set it, what the range is, and what it does. It appears (as far as I can tell) only in the heli version of the firmware. I looked in the param files for my multi’s running 3.4 and it’s not there. In 3.3.3 it was called RATE_xxx_I_L_MIN and moved to ATC_RAT_xxx_ILMI in 3.4.
I found some references to example heli param files posted, and every one I looked at, that param, either in 3.3 or 3.4, was set to zero. So my question is, since this parameter is obviously unique to helicopter, who is flying a heli with that parameter set to anything but the default of zero, and what exactly does it do?
Chris,
Here is what I understand about that parameter. The integrator is allowed to build to the IMAX value if the aircraft is on the ground and not level. This causes the pilot to have to make several inputs on takeoff to keep the aircraft going straight up. A leaky integrator was added to Trad Heli to address this issue users were experiencing with takeoff on uneven terrain. So the value of 0 for the ILMI parameter essentially doesn’t allow the integrator to build while the aircraft is less than 5 m/s. Once it determines the aircraft is moving then the leaky integrator is turned off. Once it gets below 5 m/s then the leaky integrator is turned on again. The idea is to set the ILMI parameter to some smaller value so that the integrator doesn’t grow so large as to cause a huge problem when taking off from uneven terrain. Where at higher speeds the larger value of the integrator may be needed to hold attitude and thus the leaky integrator feature is turned off.
If you want the integrator to work all of the time and bypass the leaky integrator then set the ILMI parameter to the same value as the IMAX parameter.
I hope this makes sense and that it helps.
Sorry for my bad English, wasn’t ment as dogma, just as better default values.
IMHO the default value for ATC_ACCEL_Y_MAX is way too low, anybody(=me 
) used to FBL-units will think something is wrong with the tail which cannot be corrected unless you raise ATC_ACCEL_Y_MAX a lot (no problem in ‘Auto’ just for manual flying).
The default values for ATC_ACCEL_R_MAX and ATC_ACCEL_P_MAX are o.k., but for me there was a slight advantage in setting them to 0. I couldn’t find any benefit compared to disabling them. I wouldn’t be surprised if some high numbers are better suited on some helis or different PID settings.
Just my 2 cents and as usual YMMV.
Markus,
That makes sense. I just want to clarify the impact in the code to setting these parameters to 0. Basically when the ATC_ACCEL_X_MAX parameter is set to 0, the FF_ENABLED feature no longer works because it depends on the accel max parameter. The FF_ENABLED feature is a rate feed forward feature in the attitude controller. Instead of just looking at the error of target and actual attitude and generating the requested rate command from it, the controller generates a rate command regardless of current attitude limited by the accel limiting parameter and this rate is modified by the error between actual and target to generate the requested rate. The requested rate is then sent to the PID controller. This is different than the ATC_RAT_XXX_VFF parameter which passes the requested rate directly to the servos rather than going through the PID controller which looks at error with the current aircraft rate. IMHO, I would say the response should be better with the FF_ENABLED feature and some high value of ATC_ACCEL_X_MAX. I think as a default leaving the ATC_ACCEL_X_MAX parameters the same as the multicopters would be fine for trad heli users. They can always increase the accel max values to achieve a better response.
Thanks Bill. Yes, that does make sense. It is not well documented (at least not that I can find), however.
@ultrafuge I think you are flying a FBL unit with a Pixhawk? So your setup may be different than just using a Pixhawk with no external gyros?
I recently acquired a Trex 500 that had been crashed, rebuilt it and am using it for testing. It is a modified Trex 500 with a DFC head, converted from 6S to 4S with a 10,000mAh battery and running low headspeed, at least for a 500 (1,900 rpm).
I think when going from 3.3.3 to 3.4 you have to be careful because there was scaling changes made in the rate controller. I flew the Trex 500 with both, and I would suggest starting over and doing the complete head setup and tune the rate controller for 3.4. Don’t try to carry over your settings from 3.3.3. I’m not saying it won’t work to carry over your params from 3.3.3 - just be prepared for some surprises.
The pertinent setup I ended up with on the 500 for 3.4.5
ACCEL_Z_D , 0.000000
ACCEL_Z_FILT , 20.000000
ACCEL_Z_I , 1.000000
ACCEL_Z_IMAX , 800.000000
ACCEL_Z_P , 0.320000
ATC_ACCEL_P_MAX , 110000.000000
ATC_ACCEL_R_MAX , 110000.000000
ATC_ACCEL_Y_MAX , 27000.000000
ATC_ANG_PIT_P , 4.000000
ATC_ANG_RLL_P , 3.800000
ATC_ANG_YAW_P , 4.500000
ATC_HOVR_ROL_TRM , 300.000000
ATC_PIRO_COMP , 0.000000
ATC_RATE_FF_ENAB , 1.000000
ATC_RAT_PIT_D , 0.000000
ATC_RAT_PIT_FILT , 20.000000
ATC_RAT_PIT_I , 0.120000
ATC_RAT_PIT_ILMI , 0.000000
ATC_RAT_PIT_IMAX , 0.400000
ATC_RAT_PIT_P , 0.024000
ATC_RAT_PIT_VFF , 0.050000
ATC_RAT_RLL_D , 0.000000
ATC_RAT_RLL_FILT , 20.000000
ATC_RAT_RLL_I , 0.150000
ATC_RAT_RLL_ILMI , 0.000000
ATC_RAT_RLL_IMAX , 0.400000
ATC_RAT_RLL_P , 0.016000
ATC_RAT_RLL_VFF , 0.040000
ATC_RAT_YAW_D , 0.001000
ATC_RAT_YAW_FILT , 20.000000
ATC_RAT_YAW_I , 0.100000
ATC_RAT_YAW_ILMI , 0.000000
ATC_RAT_YAW_IMAX , 0.250000
ATC_RAT_YAW_P , 0.380000
ATC_RAT_YAW_VFF , 0.050000
ATC_SLEW_YAW , 1000.000000
After tuning for AC3.4.5 it flies fine and no real glaring problems that I have found (yet). It flies Loiter and Auto at up to 15 m/s with no real issues. I get some slight bobbing when passing a spline waypoint in Auto, but not serious.
When tuning, you can strike a balance between how much you want to lean on the rate controller vs VFF. But if you set the VFF so you get about 75% of max cyclic and use the same rule of thumb that you fly the rate controller about .01 below where you get roll and pitch oscillation, it should fly stable in Stabilize. I started at .25 on ACCEL_Z_P and turned it up until it started to bounce the collective, then backed it off .05. I don’t have any problems with leaving the ATC_ACCEL_x_MAX params at the multirotor defaults here.
The I gain is not really that critical. I set it much higher (just to try it) than what I ultimately set it at. But seem to be getting good performance on the longer term corrections in moderate wind with the above settings. I tried some D gain, and got instant roll oscillation with it, so turned it off, except on the yaw. If I further backed down the P gains I might be able to get some D gain in there without oscillation, but didn’t try it.
When I get time I’m going to try this same setup in my 600E and 700 nitro and see how they fly “out of the box” with 3.4.5.
Thank you Bill for the explanation, as always very informative. Do I understand this correct, I set ATC_ACCEL_X_MAX parameter > 0 and than I can use FF_ENABLED=0 to switch it off or use ATC_ACCEL_X_MAX=0 to disable it. I guess my English isn’t good enough to understand that.
Yes, unless Bill forces me to try his code 
So your setup may be different than just using a Pixhawk with no external gyros?
Yes, ofcourse, I am only interested in PID=0 settings . Please understand that I refuse to use the standard code anylonger, I fly either Bill’s code or use the external FBL-unit.
…and running low headspeed, at least for a 500 (1,900 rpm).
I use 1900 / disc diameter[m] for the high headspeed setting, which explains why I wouldn’t be happy adapting your settings and ATC_ACCEL_Y_MAX = 27000 is really not what I enjoy.
I always liked this rule, although I varied it depending on size (more FF for bigger helis, less FF for smaller size).
No offenses, but 0.01 as an absolute value doesn’t fit into my understanding.
Based on what I’ve seen in the code it requires both FF_ENABLED =1 and ATC_ACCEL_X_MAX > 0 to use the feed forward feature. Again this is different from the ATC_RAT_XXX_VFF parameter.
Hi Bill,
yes I understand it is not affecting VFF, but I don’t understand (never looked at the code) why there is FF_ENABLED, when I can have the same functionality by using 0 or > 0 with ATC_ACCEL_X_MAX. FF_ENABLED seems to be superfluous to me.
When I’ve been tuning I’ve found that if I get rocking and rolling at, say, .035 on the P, back it off to .025. It stops rocking and rolling, and is stable enough so that if a wind gust hits it, or scrape a skid or something, it recovers and doesn’t go into the shakes. So I kind of use that a rule of thumb, but I’m not using a flybarless unit.
Markus, I think what Bill is saying is that the FF feature NEEDS to have ATC_ACCEL_x_MAX set to some value greater than zero in order to have the rate feed forward feature work in the attitude controller. If you set ATC_ACCEL_x_MAX to zero it effectively disables the rate feed forward because it depends on that setting.
So FF_ENABLED is not really superfluous because if ATC_ACCEL_x_MAX is set to some >0 value, then the rate feed forward works. In your case where you have a FBL unit actually stabilizing the helicopter and the Pixhawk is merely an electronic pilot making requests to the FBL unit, it probably doesn’t make a lot of difference because you’re not using the rate controller. When the Pixhawk is doing the stabilizing, it probably makes more sense to use at least the defaults there.
Markus,
I agree it does seem to be redundant. There may be other places in the code that FF_ENABLED alone affects that I haven’t seen.
I flew my Trex 500 today, which doesn’t have a governor in the ESC, with H_RSC_MODE set to 3. I wanted to test this and it actually seems to work quite well. It provides a linear 3-point throttle curve, and works as well for an electric as it does for a gas engine.
My Trex 500 test heli is a heavy (2,750g) modified helicopter with a 1800kV motor running on 4S with a 10A battery, and headspeed 1,900 rpm. I took the DFC head off today and put a flybar head on it. I got better stabilization with the flybar and can run more aggressive PID’s with it. My revised settings are as follows with the flybar:
ATC_ACCEL_P_MAX , 110000.000000
ATC_ACCEL_R_MAX , 110000.000000
ATC_ACCEL_Y_MAX , 27000.000000
ATC_ANGLE_BOOST , 1.000000
ATC_ANG_LIM_TC , 1.000000
ATC_ANG_PIT_P , 4.500000
ATC_ANG_RLL_P , 4.500000
ATC_ANG_YAW_P , 4.500000
ATC_HOVR_ROL_TRM , 300.000000
ATC_PIRO_COMP , 0.000000
ATC_RATE_FF_ENAB , 1.000000
ATC_RAT_PIT_D , 0.000000
ATC_RAT_PIT_FILT , 20.000000
ATC_RAT_PIT_I , 0.120000
ATC_RAT_PIT_ILMI , 0.000000
ATC_RAT_PIT_IMAX , 0.400000
ATC_RAT_PIT_P , 0.065000
ATC_RAT_PIT_VFF , 0.060000
ATC_RAT_RLL_D , 0.000000
ATC_RAT_RLL_FILT , 20.000000
ATC_RAT_RLL_I , 0.150000
ATC_RAT_RLL_ILMI , 0.000000
ATC_RAT_RLL_IMAX , 0.400000
ATC_RAT_RLL_P , 0.055000
ATC_RAT_RLL_VFF , 0.050000
ATC_RAT_YAW_D , 0.001000
ATC_RAT_YAW_FILT , 20.000000
ATC_RAT_YAW_I , 0.100000
ATC_RAT_YAW_ILMI , 0.000000
ATC_RAT_YAW_IMAX , 0.250000
ATC_RAT_YAW_P , 0.380000
ATC_RAT_YAW_VFF , 0.050000
ATC_SLEW_YAW , 1000.000000
I run more aggressive PID’s than the above with my Trex 700 nitro flybar without any oscillation problems. But those settings locked the little 500 in pretty good. I’m not exactly sure what setting H_FLYBAR_MODE to 1 does. Don’t know if it changes the scaling in the rate controller, or what. I tried it with param set to 0 and to 1 and couldn’t tell any difference. Although I only flew it in Stabilize today. I think that might do something for Acro, but I didn’t try that yet.
This is a photo of my new test heli. She’s a heavy beast at 2,750g takeoff weight with that 10A battery slung under there. But it flies for 30 minutes in hover, and is inherently more stable because of the weight. So it’s kind of nice for testing with a heli that’s stable, and trying different things without running out of power in 7-8 minutes.
When H_FLYBAR_MODE is set to one then acro is basically RC helicopter and PID is applied only to Yaw to keep the heading. It is assumed that flybar will do the needed balancing. Obvioulsly this should not be set for Fly Bar Less systems. I do not think that there is any other difference.
Hi Chris,
Can you please post some pictures of the vibration isolation system you use on your Nitro heli.
what is the logic behind keeping it at 75%. While tuning P do we need to keep VFF = 0? Then after tuning set it to 75% of P term?
First of all 75% is not cast in stone, it is just a rule of thumb or a matter of taste.
The VFF is your direct input, it bypasses the PID controller. Please read this pdf
Some pilots fly 700 class and bigger without FB and without FBL-unit etc. , these pilots don’t need/want PID controllers of any kind, this translates into PID=0 and FF=100%. AFAIK nobody is flying a 450 size without FB or FBL-unit. You can fly every helicopter with FF=0 if you have PID>0.
NO, I start tuning by setting FF to have about 75% of the needed cyclic, but you can use the default value as well. This gives me the necessary control (I use Dual Rates and Expo as well) and it allows me to start with low(=maybe not enough) PID values to avoid oscillation drama.
NO, usually you set the cyclic to have about 6° to 8°, The FF should or could be set to give you 4.5° to 6°.
Use the default values, lower ACCEL_Z_P from 0.5 to 0.3( and tune that later) and start the usual tuning process. I use Acro others prefer Stabilize.