I think I figured out what causes the sudden jerk in Stabiize when the throttle hold (or ArduPilot “motor interlock”) is activated or deactived. I bench tested it on this one and watched the swashplate, then looked at the log
It’s the hover roll trim value being active or inactive, depending on the throttle hold state. I mistakenly thought it was a sudden drop in collective. But it’s not. It’s a sudden left roll that has the same effect when you practice autorotations starting out close to the ground to learn collective management. That’s why you have to make a “hack” to the throttle setup to do practice autorotations with a ArduPilot heli.
IMO, this should be handled fundamentally different. ArduPilot’s “motor interlock” is the equivalent of the throttle hold used in setup in any other system to fly helicopers. For practice autorotations, engaging the throttle hold should allow a piston engine to idle, or return an electric ESC to what is called the “autorotation window” if you have it programmed for auto practice. Re-engaging the throttle should return it to full power immediately, as I demonstrated in the blog post not too long ago on how to set it up for an electric.
There should never be a complete shutdown of power allowed in flight.
ArduPilot’s RSC system returns the throttle to the runup state and has to execute the runup again as set by the H_RSC_RAMP/RUNUP times. The code counts down backwards from the time you turn off the throttle (throttle hold), then upon re-engaging the throttle it counts forward again from the point where it counted backwards. If the throttle was off long enough, it does a complete ramp/runup again.
IMO, the ramp/runup should only be done once and require a disarm/rearm before it executes again. Just because there is no known condition where an in-flight restart of an engine out and going back to full power immediately is anything but desirable. If ArduPilot handled this correctly, then practice autos could be done with either electric or combustion engine by simply setting the H_RSC_IDLE for the combustion engine, and for the “autorotation window” on electric ESC’s without having to do a “hack” to do them. And, of course, the switching of the hover roll trim value would have to be fixed, because that is also undesirable if you engage the throttle hold for a practice auto. Autorotations are something every UAV helicopter pilot should be practicing, but the system makes it very difficult to do.
@Sunit_Pal situation remains a mystery then. But I have seen it in flight in Auto when I had a complete power failure from a broken motor shaft and shut down to prevent further damage to the gear train and there was smoke coming from the motor. There was a sudden surge in the collective pitch that lost almost all headspeed in Auto, and required very aggressive forward cyclic in Stabilize to get the main turning again so I could make a successful autorotation landing. I was able to recover it. At the time I attributed it to the fact that the autopilot simply tries to maintain altitude in the event of power loss. But it could’ve been the same thing that Sunit_Pal experienced here because it was way faster than I thought it should be.
Edit:
Now that I think about the exact sequence of events that day, I shut down before total loss of power. It was in Auto when I shut down because there was smoke trailing behind the heli, and a horrible screeching noise coming from it. I shut down the engine, and went for the flight mode switch about a second later. In that second it just about stalled the main rotor. And I didn’t think it should’ve done that because the heli was cruising at about 12m/s. I don’t know if I could find the log from that flight. But thinking about it, I think it was the same thing that Sunit shows here, except under different flight conditions.
I figured out what the problem was for @Sunit_Pal. It has nothing to do with the descent rate.
The H_LAND_COL_MIN is set to zero, which commands full negative collective pitch before it will consider the Land Complete to be met in an altitude controlled flight mode. When the throttle hold was engaged (“motor interlock” disengaged) it returned the swashplate to the neutral trim position and with a big heli you can actually jump one off the ground with the inertia in the main rotor during spin-down.
I tested this on the bench and the collective pitch is real funky in Alt Hold on the bench and doesn’t respond to the stick except at full input. If you engage throttle hold it will jump to neutral trim, which on this heli appears to be to a rotor lift condition instead of actual zero pitch. It must be a flybar heli. There’s a 150 pwm range from MIN to MID, and a 250 range from MID to MAX. So it’s running probably about -5 to -6 degrees of collective.
What happened is, it loaded the heli into the ground at full negative collective pitch at full power, the power was suddenly shut down, it returned the swash to neutral trim, and it unloaded like a giant spring. With a 800 class heli 50-60 lbs of thrust at full rated rpm and 5-6 degrees of pitch is really nothing. They can easily hit 100 lbs of thrust with a couple more degrees of pitch.
Set the H_LAND_COL_MIN to a more reasonable value that corresponds to a couple degrees negative, and H_COL_MID to true zero pitch with a flybar lock to make sure you got it accurate, and it won’t happen again.
Edit:
Based on some calculations on what I think the negative pitch range is set to, a value of 300 for H_LAND_COL_MIN should correspond to about -2 degrees of negative pitch (assuming H_COL_MID is set right). Which won’t load the heli into the ground near as severe in an altitude controlled flight mode. With a smaller heli you probably won’t notice it. But the blade flex alone will unload pretty hard on a big one if you suddenly release 5 degrees of pitch by returning to swash neutral when the system is shut down.
Have to be careful with those settings in ArduPilot. H_LAND_COL_MIN and H_COL_MID being set wrong can cause an in-air shutdown if you use auto-landing modes.
Hi Chris,
I looked a little further into the code. I agree with you that because his H_LAND_COL_MIN is set to zero (and it equates to a large amount of negative pitch) creates a large change in thrust when motor interlock is disabled. I also agree that in order for the land complete flag to be set, the auto pilot has to command full negative pitch. However in this case, the land complete flag had not been set yet. So the full negative pitch was being commanded because his collective stick, which commands climb rate, was full down and commanding max descent rate. So the auto pilot was commanding full negative stick based on the pilot request. I disagree that when the motor interlock is disabled, the collective pitch is set to a neutral trim position. This position is based on the commanded descent rate and not the H_COL_MID position. Looking in the althold_run function, the target climb rate is handled differently based on the aircraft state. When motor interlock is disabled the state is set to motorstopped and the target climb rate is fixed to a low descent rate.
I disagree, H_COL_MID does not need to be set for zero collective pitch. I have mine set for 4 deg collective pitch, H_COL_MIN equates to -3 deg collective pitch and my H_LAND_COL_MIN is set to 50 which probably equates to roughly -1 or -2 deg collective pitch. I have not seen this issue with ALTHOLD mode. Switching motor interlock to disable causes the autopilot to command smaller descent rate than what was commanded with motors running and collective stick on the bottom stop. So I agree if you have a large amount of negative collective set for H_COL_MIN and your H_LAND_COL_MIN set to zero that you would see a large jump in collective when you switch motor interlock to disable. I agree that @Sunit_Pal should raise his H_LAND_COL_MIN to something equivalent to -2 deg collective pitch. I don’t think he needs to change H_COL_MID.
With the old code in 3.2.1 people used to set H_COL_MID to hover collective all the time because there was not IM_STAB_COL settings to center the stick for Stabilize. With the new code, the collective yaw compensation is base on H_COL_MID being at zero degrees collective pitch. While you don’t have to have it set to that if you don’t want, I think it’s best for your collective yaw compensation to work right.
With a flybar, they can be a bit tricky too, on setting pitch. It’s best to use a flybar lock to make sure the settings are consistent, or you may even end up with blades not tracking properly. A person can do it by sighting the flybar and squaring it by eye when setting the pitch links on the mixing arms. But that usually gets it “close enough”, depending on how good your eye is, so it can fly. And it will require further tuning of the mechanical linkages by flight testing. It looks to me like Sunit’s H_COL_MID might be a bit high, and it’s easy to get it 2 degrees off by just “sighting” the flybar during setup. That’s why I mentioned that.
Certainly if you are using Collective yaw compensation then I agree H_COL_MID should be set to zero. I’m not using that feature. It sounded like you were implying that the autopilot was commanding the collective to that mid position when motor interlock was disabled. Just wanted to be clear that the autopilot is basing the commanded collective on the target descent rate. Thanks for clearing that up.
I looked at this closer again. I see in my analysis it was confused about the landing state because the altitude was negative due to pressure buildup under the main. Then the pressure went away because the heli was driven into the ground at extreme reverse thrust. The autopilot raised a Land Complete Maybe. ~240 ms later the motor interlock was disengaged. The autopilot doesn’t know if we’re landed, going up or down, because of the rapid change in the baro altitude that occurred in the 2 seconds previous, going from negative value to 2m positive under extreme reverse thrust. The increase in collective pitch caused by this confusion caused the thing to unload like a big spring. I think the motor interlock and collective change is coincidental, looking at it closer.
Then it took it another 1.8 seconds to decide we are indeed landed.
When I tested this on the bench it will neutral the collective pitch with the system armed and motor interlock state being changed simply by moving the heli from the shop floor to the bench and turning on the throttle hold with the collective lever all the way down. I’ve seen this behavior before when trying auto land too. It will refuse to shut the engine down sometimes. If you’re flying a piston heli with the engine off the governor, and on the throttle curve, at H_LAND_COL_MIN it will sit there on the ground, rotors turning, and speed the engine up by increasing the collective pitch. Then reduce it to the land min again, and sometimes repeat that cycle 3- 4 times before finally shutting down. In the mean time, in decent wind the heli will get tipped over if it’s a big one.
I guess I still don’t recommend using augmented modes for takeoff and landing with a big heli. I think you can get away with it with smaller ones. The Pixhawk does not have the computing power of a human pilot, cannot even execute an abort on a botched landing, and will continue blindly to the crash site regardless of how bad it messed up. IMO it is not to the state yet were I will trust it to land a $10,000+ 800-class machine.
Hi Bill,
Yes that is what I remember. The sudden jerk was as soon as I switched off the motor. That is why I suspected the barometer to be the culprit for this.
On a calm day I will try to land after fixing H_LAND_COL_MIN. When this is happened I was still flying 3.4.6. I just updated it to 3.5.x which has all the heli fixes. I will report how it goes.
We are building a gasser trex800 that will make autonymous flights with takeoff and landing. We have a lidar installed on it.
Now that i am reading your concerns about auto take off andlanding, i like to get your opinion on few matters;
1 - we are using 3.4.4 at the moment but i have read the baro is fixed on 3.5 version. Would you advise to upgrade to 3.5 with lidar ot stick with current?
2 - the auto flights we will make will be high speed point to point missions and we are adjusting the speed on mission planning already. With this in mind do you think 3.5 is better on such flight plan? The heli will carry a 20 lbs payload. Total take off weight is 35 lbs apprx.
3 - this auto landing and take off is vital so before going out field testing i like to know which version you advise. I have read all points regarxing h col mid and h land col min settings where i will pay attention.
If auto takeoff and landing is vital to the mission, you simply have to accept the fact that a GPS glitch during critical phase of flight close to the ground will result in losing your helicopter.
The UAV industry still needs a lot of education.
In the world of full-size aircraft, airports are carefully designed and extensively tested and surveyed for accuracy of radio navigation systems for precision approaches. And those approaches are regularly flown and tested by the civil aviation authority with specially equipped aircraft designed to test and continually certify the approach and radio gear on a recurring basis. The cost is in the millions to meet the requirements and certify an airport for an instrument approach that will use autonomous (slaved autopilot) or radio navigation gear.
In the world of UAV’s you are using non-certified, non-TSO’d consumer-grade equipment. Instead of using certiifed and tested ground-based transmitters and gear you are relying on GPS, which is notoriously inaccurate close to the ground. So this is what happens:
If you met all the same requirements as for full size for your takeoff and landing zones, used ground-based navigation systems instead of GPS, and ran a recurring certification process on your systems to make sure they work, it could probably be done quite reliably. But that is not normally the case for UAV’s.
Thanks for the info as we are aware of the consequences as you also described and we are adding security measures to prevent this during take offs and landings.
I still need your feedback on the version as it seems 3.5.4 should be the one we should be using for this gasser heli.
We have setup a 450 and 700 electric and experienced the configuration dilemmas as your posts are a great guideline for us and there are few others that i follow.
I have since the arducopter FW3.3. and now 5.5. all my missions finished with RTL with the full auto landing. There was no incidences during all of those Auto landings. My aircraft’s are a quad copter, a RJX 520 Helicopter and a Align 700 E Helicopter. I am using lidar units plus standard of the shelf GPS units. FC are 2 pixhawk and a pixracer in the drone. I feel very comfortable with my RTL’s. But I had other incidences regarding GPS. I tried 2 GPS units on one aircraft which did’t work out very good. But I do no auto take offs. Chris is right with his opinion.
I also would like to finely say that all my mission have been in rural areas without any interference of towers or other objects which could be the reason for that good result.
Just wanted to let you know my experiences.
Security measures might help protect people from personal injury. But it cannot fix the inherent problems with GPS reliability.
In open areas with a clear view of the satellite constellation it can work quite well. But any object that can reflect radio signals can cause degradation of accuracy, or even a complete flyaway. Even trees can scatter microwave signals. The closer the receiver is to the ground, the more chance you have of picking up multi-path signals and so-called “GPS Glitch”.