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.
yes，understood，thks！
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.
Edit:
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.
Bill,
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?
Protection was put into switches.cpp for 3.6 to protect against out-of-bounds values on all aux switches.
4.0 is different because the aux switch code was moved to the RC_Channel object.
Users going from 3.6 to 4.0, be sure to check the scaling on all your settings, especially throttle, before flying - most of these are in the Heli Setup in QGroundControl.
The Heli Setup for 4.0 mostly works except for a couple items. I have a working version of the Heli Setup for QGC on my Development master HEAD. I have been discussing some changes with Bill that he would like made to the Heli Setup for 4.0. I am helping with that. As soon as I get those done and tested I will PR them to the mavlink/qgroundcontrol project so @DonLakeFlyer can get them into the Daily Builds for 4.0 beta testers.
1 Like
The changes to QGroundControl have been merged to mavlink master. So users that are testing the 4.0 beta’s now have a working heli setup, and convenient page to make heli settings
This is available in the QGroundControl Daily Builds -> for Windows, Mac, Linux and Android for beta testers. Note that the QGC version for 4.0 will refuse to display the heli setup unless you are running Copter 4.0 or newer. For Copter 3.6 continue to use QGC version 3.5.5.
All pilots should be aware that the heli setup in Mission Planner does not work and could make unwanted settings to your helicopter that could crash it. Only QGC heli setup has officially been supported since Copter 3.6.
Edit Tue Nov 19:
Bill indicated to me that he may be able to get something done with the heli setup in Mission Planner so it is compatible with Copter 4.0. I do not have a working installation of Mission Planner to test, but Bill indicated that at least on SITL the current page does not appear to work at all with 4.0. So there is likely little danger in a user trying to make settings with it at the present time until it gets fixed.