Helicopter Default Params

ArduCopter Traditional Helicopter
1

I don’t know if this has been asked before. But is there any way to have a different set of default params for helicopters vs multi-rotors? As an example, and one that the Trad Heli documentation doesn’t cover, is ACCEL_Z_P, which is 0.500 by default. That might work for multi’s but it makes the collective bounce up and down like a rubber ball on most helicopters. And can cause a crash as soon as the pilot switches to Alt Hold. Some heli’s, especially higher power to weight ratio ones, can turn into like a possessed demon and start doing vertical tick tocks if that setting is missed. Like 0.200 or 0.250 would be what I would consider a safe starting point for heli’s on that one.

Anyway, just kind of wondered if that’s possible. For somebody more experienced that knows what they’re looking for when something bad happens, maybe not a big deal. But for somebody new, setting up a helicopter for the first time, it can be disasterous if they’re not aware of it.

If it’s not possible in the firmware, at least maybe have a param file available for heli pilots to load that puts in some “safe” values as a starting point for heli tuning for different sized helicopters.

2

(This post will be updated)
I’ve sorta started, as I’m just waiting for a weather window to test my first heli.
I’ve started to collect the various tidbits both from here and the tuning page in the docs. Mostly because I wanted a one page summary of what to do and the docs are a bit confusing to read. (Also parameter names have changed, etc)
I’ll update it as I go along, but here’s what I got sofar:

Initial values:

ATC_STB_RLL_P : 4.5
ATC_STB_PIT_P: 3.5

ATC_RAT_PIT_P : 0
ATC_RAT_RLL_P: 0

ATC_RAT_PIT_D : 0
ATC_RAT_RLL_D: 0

ATC_RAT_RLL_I: 0.1 *
ATC_RAT_PIT_I: 0.05

i. Set a rotary knob on transmitter to ch6
ii. In Mission Planner->Extended Tuning -> Set CH6_RATE_KP to Min: 0.010 Max: 0.075.
iii. hit write. Turn knob, hit refresh and confirm that it changes RATE_PIT_P and RATE_RLL_P.

Spool up heli. Will be hard to control, but should have no oscilliations.
Land, increase RATE_KP on the knob to 0.02. Keep increasing until you get oscilliations and then back off by maybe 0.005-0.010.
Your ATC_RAT_PIT_P value can be a little higher (0.01 or so).

Now start increasing ATC_RAT_PIT_I and ATC_RAT_RLL_I. (Roll I 0.25, Pitch I 0.15).

Now increase
ATC_RAT_RLL_VFF = 0.02
ATC_RAT_PIT_VFF = 0.02

Rudder Tuning:
ATC_RAT_YAW_VFF = 0.04
ATC_RAT_YAW_D = 0.05
ATC_RAT_YAW_I = 0.15
ATC_RAT_YAW_IMAX = 2000
ATC_RAT_YAW_P = 0.38

Also set ACCEL_Z_P = 0.2 (0.25) **

Markus Müller suggests:***
ATC_ACCEL_R_MAX=0
ATC_ACCEL_P_MAX=0
ATC_ACCEL_Y_MAX=0

Refs:

3

The H_ params are OK. Those are only used by helicopter and don’t even show up in multi’s. It’s the PID rate controllers that are an issue. Now, like this one:

“ATC_RAT_YAW_IMAX = 2000”

I think some of the ranges have been revised since the original documentation that you refer to has been written. The range is now 0-1 with .01 increment. But D gains for at least pitch and roll need to be zero. I haven’t been able to get one to fly decent yet unless those are zero.

And with helicopters PID tuning all depends on if you set your ball linkages on the servo arms at 16mm (same effect as more agressive PID’s), or 13mm. I haven’t found a head setup yet that will have enough range at less than 13mm on the cyclic. But I use 10mm on the tail servo, which requires more aggressive PID’s for yaw, and gives more servo range for the limited movement that most tail pitch sliders can accomodate.

I use the hand roll, pitch and yaw test and observe the operation of the swashplate and tail. I can tell just by looking it if I’m going to have a helicopter that’s twitchy as a crook in an electric chair, or so sluggish it won’t even work. So I don’t follow the outdated documentation, or even use channel 6 tuning at all. I prefer to set it up with the hand test and “looks right”, take off in Acro, switch to Stabilize and see what it does. If I don’t like it, switch back to Acro, land, change the PID loops and write it to the controller, and test fly it again.

I guess one of the developers that make the decisions on this stuff will have to say what’s possible to do as defaults in the heli firmware. But it also could be done with a .param file, as well, that could be loaded for heli pilots as a starting point, to change the defaults for mulit’s to something more reasonable for heli’s.

4

Good luck with using ‘Extended Tuning’, it will ‘correct’ your input to multicopter default limits, use Full Parameters List/Tree.
Seldom mentioned, but set ATC_ACCEL_R_MAX=0, ATC_ACCEL_P_MAX=0, ATC_ACCEL_Y_MAX=0
and be VERY careful using RATE…_D parameters.

5

@ultrafuge have you always preached to zero these parameters? Just wondering. I made these non zero in recent tests with good results but this was with the notch filter.

6

@bnsgeyer what frequency are you using on the notch?

7

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

8

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.

9

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.

10

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.

11

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?

12

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.

13

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 :slight_smile:) 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.

14

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.

15

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.

16

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 :grin:

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 :slight_smile:. 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.

17

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.

18

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.

19

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.

20

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.