Hi,
I encountered something that I haven’t seen before. While hovering in Loiter mode suddenly the aircraft started to drift away from me. I gave it full cyclic pitch to bring it back, but there wasn’t any control. So I cycled through stabilize back to Loiter and there was stick control again for some time, but then I lost it again. I cycled again and got back the control and finally decided to just land the bird in Stabilize mode.
From the log file I saw that the flyaway started when the Land_Complete_Maybe and Land_Complete flags were set up. As soon as I switched to Stabilize, the flag was taken down, but back in Loiter the flags raised again and control was basically non-existent.
Also, the rangefinder (LW-20/C in I2C bus) froze before for some reason (while airspeed sensor kept on working). I understand that the landing detector needs certain conditions to be met to think that it has landed and my question is that what might have caused the ArduCopter to think that it has landed while it was actually 12 m in the air?
I added a flight log also here so maybe you can give me some suggestions or have seen it before. I tried to google it, but didn’t find anything that might help me.
FW is ArduCopter 4.0.5.
Thanks for your help!
A picture from the log file as well:
Hi Siim,
This is a classic case of setting H_COL_MID too high. This needs to be set to the PWM value that corresponds to zero collective blade pitch or zero thrust if you have non symmetrical blades. The land complete flag is set when your vertical speed is less than 1 m/s, acceleration is less than some value (i can’t remember) and collective is below H_COL_MID. So when you are in loiter and the land complete flag is set then the controller relaxes and you then don’t have control anymore.
So I noticed that you have a flybar setup. In Pitch and Roll, You still want to have some I gain with ILMI set to 0.08. that will help the flight controller hold steady state attitude. What do you have stabilizing the tail? Noticed that your PIDs are zero for the tail as well.
Well that should help fix your issue.
Regards,
Bill
Thanks a lot for the information! I tried to dig into it myself yesterday and I was starting to get to the same conclusion that most probably the H_COL_MID value is too high and zero thrust PWM is actually a lot lower. I’ll set it to correct value and try again.
As for the setup of the heli then we are using external gyro for all the 3 axis and also for governor and that’s why we have the Acro PIDs set to 0.
What does the ILMI setting do when I’m using external gyro? Could it might mess up anything?
Thanks again for your help!
Cheers
Well I don’t have any experience in setting up ardupilot with an external gyro. Using the I term depends on what the external gyro is doing. Is it just a rate command system like acro? The ILMI is an integrator limit where it allows the integrator to build to a certain level and then leaks off the integrator above that ILMI value. So you would only set it if you were using the arducopter I term. The one thing I will warn you about is that arducopter has a crash check. This uses the target attitude and actual attitude. If they are more than 30 deg apart then that will trigger the crash failsafe and disarm your aircraft. I believe the parameter is FS_CRASH_CHECK.
External gyro is only used as rate command system. So when we are flying in Acro mode we are only using the external gyro control system. Do you think it would be wise to use the ILMI .08 in such case?
Thanks for pointing out the crash check thing. I guess increasing the ILMI values should make the desired and actual roll and pitch differences smaller?
I don’t know. If you use ILMI then the I gain has to be non zero.
If you use loiter or auto then it uses stabilize as the underlying mode to achieve requested attitudes from these modes. So it is important that the actual attitude follows the desired attitude.
I am not sure what the best way would be to do that. I’m not a big fan of using external gyros when the flight controller is capable of doing what the external gyro does. That is why I am working on autotune for heli’s.
Regards,
Bill
This method of using external gyro is a technical solution that we used on our earlier helicopters that had only combustion engine and we have been using it so far for many years even though the powertrain has changed.
But it looks your suggestion makes sense as I have also noticed previously that there are discrepancies between the desired and actual roll/pitch. I think just to be on the safe side I would start with a bit smaller values (although .08 also seems to be small already) and work my way up from there to see if that solves this issue and helps to bring the angles closer to each other.
But thank you very much for your help! If you have any more ideas or suggestions then feel free to let me know.
It’s good to know that auto-tune functionality is also coming. What is the progress with that feature? At first glance it looks to be quite tricky as helicopters tend to be quite “interesting”
I don’t know if your external gyro uses any I gain but using some in the arducopter rate loops shouldn’t hurt. Typically I set my I Gain (ATC_RAT_PIT_I and ATC_RAT_RLL_I) small values like 0.1 and the ILMI for each axis to 0.08. That value of ILMI will help correct up to about 5 deg of attitude error. The one thing to remember is that ILMI is the integrator limit for ground speeds less than 5 m/s. For ground speeds greater than 5 m/s, the integrator limit is the IMAX parameter in each axis. So I would suggest changing that parameter as well to a smaller value (around 0.1 or so)
Progress has been slow. I have a early version out for testing just to gather data on the different sizes of heli’s. I was hoping to get something out with 4.1.0 but doubt I will be ready before they release it for beta testing. Yes. Rotor dynamics are quite tricky. 
Again, thanks a lot for your help! I’ll try it out.
I also did a test flight where the COL_MID value was set to the correct zero thrust position and it looks to have helped! It was weird that this issue didn’t occur in AC3.5.7, which we used previously. Thanks again Bill! I appreciate it
We removed LAND_COL_MIN in 4.0 and had H_COL_MID perform the same function. If you don’t monitor this website or the release notes then you wouldn’t have known. There has been a lot of changes and some we can’t make smooth updates and we break setups. Normally this only happens going to a new version (ie 3.6,X to 4.0.X)
Ok, that explains it. Before updating I checked the release notes to see about potential issues and checked the Github issues list that might rise when updating from the old FW to the new one, but this parameter change probably was unnoticed.
Luckily it’s solved now and we can continue using the new FW. Reason for updating was mainly due to better failsafe options and bugs that have been solved, rally points and SmartRTL capability that might help us when operating the helis.
I guess I’ll go over the release notes over again just in case and make sure I didn’t miss out any other similar changes.
Updating the code to make it more efficient makes total sense and these mishaps are coming out with higher probability when updating the code is done seldom. Thanks for explaining!
Here is what I normally post when we have a big release.
Ok, thanks! Will keep a closer eye out for these articles