ArduCopter 4.0 Heli Summary of Changes

Tradheli users,
I wanted to give all a more detailed explanation of the changes that went into ArduCopter 4.0 that will affect you.

Here is a quick summary. I will follow up with more details in future posts.

  • Removed the parameter H_LAND_COL_MIN and functionality now uses H_COL_MID
  • Incorporated a rotor speed governor
  • Moved all RSC parameters to the RSC library
  • Converted throttle curve parameters to %
  • created swashplate library that has presaved swashplate types for use with Heli_Single and Heli_Dual
  • motor interlock with passthrough settable through RC option.
  • Removed collective too high pre-arm check
  • Added virtual flybar for Acro flight mode
  • Fixed H_SV_MAN minimum and maximum settings for Heli_Dual

Here are some changes that are not specifically Tradheli but may interest you

  • Added Systems Identification Mode - this enables the user to use automatic Chirp (frequency sweep) inputs to characterize aircraft in frequency domain.
  • Harmonic Notch Filter - this allows the user to notch out offending frequencies that are harmonics of the base frequency. The base center frequency can be dynamically set by an RPM sensor. Up to 3 harmonics can be notched at once.

I’ll write more with details of each in subsequent posts.


Thanks, look forward to the launch of version 4.0

Removed the parameter H_LAND_COL_MIN and functionality now uses H_COL_MID
Many users are unfamiliar with the H_LAND_COL_MIN parameter and in most cases leave it zero. So it was decided that I better setting would be the collective angle that produces zero thrust which is given by the H_COL_MID parameter. Now H_COL_MID not only is used for the collective to yaw feedforward feature (set by H_COLYAW) but also is used for the minimum collective the autopilot can command when not in dynamic flight (speed less than 5 m/s). This keeps the autopilot from setting the collective too low when on the ground.
If you do not have H_COL_MID set per the guidance above then you need to do so before flying AC 4.0.0rc1!!

Incorporated a rotor speed governor
This was a big step forward for the rotor speed controller. It now has it’s own rotor speed governor. No need to use external rotor governors, you can now use one that is built into the code. It requires that you outfit your helicopter with an RPM sensor and it does require the throttle curve to be setup properly. Here is the discuss thread that describes the setup of the governor.

Converted throttle curve parameters to %
In an effort to make the set up of the rotor speed control more intuitive, the throttle curve parameters were changed to percent. Also the RSC_CRITICAL, RSC_IDLE and RSC_SETPOINT were changed to percent. In addition, the descriptions for each of the parameters were improved to aid in setting the parameter properly. All of these parameters are automatically converted to percent when you upgrade to AC 4.0.0

created swashplate library that has presaved swashplate types for use with Heli_Single and Heli_Dual
This was also a pretty significant improvement for tradheli. By creating a swashplate library, all of the presaved swashplate types can be used for any vehicle and for the Heli_Dual frames, the swashplate types can be set differently if desired. This also offers a 4 servo swashplate and to help with binding issues that are common with 4 servo swashplates, a linear servo feature was developed. The linear servo feature just linearizes the servo throw, thus eliminating coupling that can occur due to the servos being at different points in the servo arm arc.
The description of the setup for 4 servo swashplates and the linear servo can be found here. Soon there will be a wiki describing swashplate setup.

motor interlock with passthrough settable through RC option
In previous versions, the motor interlock has been tied to the input of RC channel 8. In AC 4.0.0, the motor interlock can be set to any RC channel using the RC channel function. If the passthrough mode is set then the input for the passthrough will be read from the channel assigned to the motor interlock. When upgrading, the motor interlock is automatically configured for RC channel 8

Removed collective too high pre-arm check
This is self explanatory but was done due to users flying acro.

Added virtual flybar for Acro flight mode
The trainer feature was modified that if you had non zero ACRO_PIT_BAL and ACRO_RLL_BAL then attitude would be leaked back to the current attitude. The two parameters dictate how quickly the requested attitude leaks back to the current alttiude. Here is a link to the discuss thread that describes this feature

Fixed H_SV_MAN minimum and maximum settings for Heli_Dual
Due to the mixing of the Heli_Dual, the minimum and maximum settings when using the H_SV_MAN feature didn’t work properly. These settings now drive both swashplates to full down and full up


This will still prevent arming if the collective is above 50% of its range. But with all normal setups in either acro or stabilize it does allow setting the collective pitch to neutral during pre-flight and arming with the collective lever in that position. This will not affect most users. I did it for primarily piston and turbine helicopters where neutral (zero) pitch normally corresponds with low idle on the throttle curve for runup and engaging the clutch without excessive slippage, and warming up the engine at neutral thrust.

My actual test of 4.0rc1, if you open the “ground effect compensation”, will lead to a serious “TBE” (toilet effect), irrelevant to the compass and feed forward, turn it off, TBE will disappear.

I don’t know if the firmware of the later version will affect the function of some of the previous parameters.

I do not recommend GND_EFFECT_COMP being used with helicopters in the first place. It de-weights the baro and uses the accels. Helicopters, being the dynamic machines they are, the accels are not very accurate during landing and can be easily fooled.

@zhangsir I have not really looked at that portion of the code that handles the ground effect compensation. Do you have a log I could look at. I find it curious that it affects the XY when it sound like it should be a purely Z effect.


It seems that it is mainly to solve the final height of the section before the final landing of the automatic landing. The influence of the turbulence on the barometer data makes the automatic landing more clear…

The ground effect compensation appears to be enabled by default in 4.0. It was one of the things I turned off when I test flew 4.0 briefly last Sunday. I have had problems with that before, mostly on larger helicopters.

It affects not only landing, it also affects the EKF (which ultimately affects the landing). If you do any ground running at all with a piston it can be 16 or more feet off. I don’t recommend using it. I’m not sure what happens with that setting if you upgrade from 3.6 to 4.0 and had it turned off in 3.6. I don’t know if the setting is carried forward or if the new default enables it. Fortunately, I saw that it was enabled when I loaded 4.0 and I disabled it before flying.

The purpose of it is to cause the motors to throttle down quicker on multicopters that have no landing gear and they tend to “bounce” back up into the sky and attempt to land again. If your helicopter isn’t doing that, then don’t use it. Somebody must’ve decided it was a good idea for all multicopters, they never consulted the helicopter people on it and helicopters can pull the pitch to feather on landing (which it does) while still running at full power and there is no pressure buildup.

Here is a graph that shows what happens at landing with the various sensors. You can see the bump in the z axis IMU when the helicopter touched down. The EKF altitude and baro momentarily diverge a bit (about 2 meters). The squiggly line is the baro (with noise). The green line is the EKF (which the system uses). The purple line is the GPS, which is notoriously inaccurate on altitude on the ground.

It was a hot day, the pilot ran the engine for about 40 seconds at flight idle until she saw a temperature drop on the engine temp gauge. Then dropped it to ground idle and idled it for another ~30 seconds until she noted the temp continuing to drop before shutdown. Notice how the z-axis acceleration jumps all over during the ground run. But the blades are feathered and the baro remains constant (as does the EKF).

If you use the ground effect comp it de-weights the baro and uses the accels. Obviously not a good idea.

This is actually nothing new.

You will notice the setup params for 3.6 have it enabled? I did not do that, I’m not sure who did. But I did experiment with it when I saw that in the defaults and had less than acceptable results with 700’s and bigger. I don’t remember who’s 766 it was I was flying, it was probably two years ago. But I had one that flat refused to even land when I tested the auto land to make sure it was working. It stopped like 6" to a foot off the ground and was drifting around so bad I was afraid it was going to hook a skid and tip over. So I’ve had it disabled ever since in my personal settings.

One rotor length is quite a ways from the ground with larger helicopters. And that’s where they start recirculating air thru the rotor, and due to the turbulence the vibration and accels start to build. Combine that with GPS drift close to the ground and you got “toilet bowl”.

With helicopters if it stops due to the baro having excessive high pressure, it will pull the pitch to feather if need be and continue down anyway until it senses the “bump”. Then it has to drop the pitch below feather before it will shut down. Multicopters don’t have that - they have no way to further reduce power without losing stability - so I can see the ground effect thing maybe being useful for those.

Thanks @ChrisOlson for the detailed and timely suggestions, I have turned it off, because I spend most of my time using the stable mode to land, and the previous automatic test when the automatic task was tested, I remember that the ground effect compensation was turned off.

Yes, I don’t think a lot of people are using the auto landing feature with heli. On the right day and conditions it might work fine. Probably works with smaller helicopters ok since they don’t go into ground effect until they are much closer to the ground. Probably doesn’t affect electric helicopters as much on takeoff since they don’t do a long ground run with higher vibes and accelerations to upset the EKF origin. Probably won’t affect most users upgrading because most will save their old params and import them, which will disable it. It will only affect new setups on 4.0 for the most part. And if a problem is noted, then disable it. It is one of the downsides of helicopters sharing code and settings with multicopters, much like the accelz_p and some others. Even the default accelz_p is a little strong for some larger helicopters. It’s very hard to come up with defaults that work perfectly for every size and machine.

All pilots should be aware that auto landing problems are not unique to helicopters too. It bites multicopters every now and then, like this one

And that fellow had the ground effect compensation enabled. The downfall of ArduPilot in this regard is that it uses GPS for horizontal guidance. All manned precision approach and landing systems for CAT II and CAT III use ground-based transmitters for vertical AND horizontal guidance. GPS is not trusted where human lives are at stake. Sure, you can fly a GPS RNAV approach but the minimums on that approach do not bring you down to wheels on the runway like a CAT III does.

Basically, ArduPilot is trying to make believe that we can accomplish CAT III results with non-precision RNAV horizontal guidance and it works most of the time. But it will eventually bite.

I finish all my missions with my drones and both of my Helis in RTL mode with auto land.
Only one incident because I had a bad H_RSC_THRCRV_ … setup in H_RSC_MODE 3.
It was a very hard landing what that Heli did but no damage.
I never had a failure so far. I do not use GND_EFFECT_COMP.
Be aware, my Helis are not standard. They have a Tail made up by me as direct drive and variable pitch.
I also use H_RSC_MODE = 1. All other sensors like GPS, Compass are standard.
FLC = Pixhawk 1 and 2.1 and 1 Pixhack v3x and 1 Pixracer.
With my experience up to-date, AUTO LAND is a very safe feature!

1 Like

I agree with @FRED_GOEDDERT. I have well over 100 auto landings with multicopters and a some with helicopters. I haven’t had any issues with auto landing. Or auto takeoff for that matter. However I will say that I am always on the controls ready to take control if and when the autopilot gets it wrong. So I’m not saying it can’t happen but it is always good to be vigilant and ready to take over.

1 Like

Auto land is a not a one-fits-all feature. We do use it for emergency out of visual reference for landing by the pilot, in particular bird strikes. Barn swallows, which are aerobatic daredevils swooping around eating bugs, and they will fly right thru the rotor disc on a helicopter. Hit three of them last summer alone. Then we will use auto land, let the helicopter saw a 6 foot diameter hole in the corn and go get it on foot to inspect it in case it split a blade that would de-lam if we continued flying it.

But otherwise, auto-land is an excellent way to destroy piston and turbine engines. So then you’re flying it one day and it seizes up like the Canberra Team’s GX9 did. It’s got stuck valves or a scored cylinder. Can’t figure out why that happened - well, I can. Unlike airplanes which run at a reduced load during landing approach and cool down during the approach, helicopter engines go to their highest load in hover when setting down. The internal temperatures of the engine goes way up. If you pull the mixture and throw the master switch as soon as the skids touch the ground, guess what you’re going have?

Electrics? Yeah. They are push-button appliances. You’re not going to damage those.

One of the main attractions of helicopters over multi-rotor drones is that helicopters can readily use piston and turbine power without any intermediate conversion stages. And no electric can match a combustion engine for endurance and continuous power. So in the larger sizes engines are quite popular over electric. Now that we have decent controls for piston and turbine engines they have become more popular. These more advanced machines are usually quite expensive. So pilots that fly them probably wouldn’t trust auto land even if it had a proper cool-down feature. I have thought about hacking a feature into the RSC that motors some older turbines like the MW-54’s for cooldown after the fuel is cut. The newer JetCat’s, Jakes, and Turbine Solutions engines have that built into the FADEC. But the older ones don’t. Maybe I’ll work on that this winter when I get time.

Chalk another up to plenty of auto-land usage without any problems. Actually 13 aircraft, some in the hands of end users, no problems with auto-land which tells me it works pretty well.

Now, in a conversation with Tridge a few weeks ago, he did have an idea which would improve the reliability of take-offs. Basically when we know we’re on the ground, explicitly tell the EKF that we are not moving. It will make it reject noise, and lead to a more stable take-off. Might be particularly effective for piston helis?

On another topic Bill, I’m going to have a look if we can fold in any of the changes I had in NovaCopter to Ardupilot Master. First one I checked was the servo test function. But it looks like you got it already… 3 days after I did. Coincidence? Or did I tell you about this?

Now, after I did that, I took it a step further and reworked it even more. I took out all discontinuities and it’s smooth like butter now. I’ll PR this to master and would be great if you can get it into 3.6.

Trying to see if anything like this is in Master. This is to protect against SBUS parsing errors on failsafe returns. But I can’t find this stuff anymore. Where did it get moved to?

This is to protect against momentary rotor shutdowns during the same SBUS failsafe exit error state. Looks like it’s not implemented in Heli.cpp. But did they get it any other way?

And I had this, but there’s significant changes here in 4.0. IIRC, the issue was when the RSC is shut down, the swash would lock to neutral instead of doing basic flight control. Cause two problems. No flight control while maybe doing a mini-auto-rotation landing. And inability to check swash movement on ground before runup.

Any idea what the state is here?