Sorry to hear about your crash. I will look at this later but I suspect this has something to do with the new parameters for H_COL_ANG_MAX and H_COL_ANG_MIN. Hopefully you set them according to the wiki.
I will take a look and let you know what I find.
Allan,
I do apologize for the in-flight shut down but I had set pre-arm warnings in the code to warn users about having to set these parameters as well as several posts in the forum about the changes in 4.2. You were not warned about this during the pre-arm check because your ARMING_CHECKS parameter did not include checking parameters. Some how that was deselected in your ARMING_CHECKS parameter. I would suggest just setting the ARMING_CHECKS parameter to ALL
Regards,
Bill
Thank you Bill, I’ll set the ARMING_CHECKS parameter to ALL. But, if I’m reading it right, the arming check is not going to tell me why it’s not armed unless I connect MP (or equivalent) using a laptop or smartphone app.
But, what exactly happened in this case? Did it detect a landing at the beginning of the RTL and, if so, why? I was able to fly in stabilise and PosHold modes for a full 5 minutes without any issues.
Correct, you will only be able to see the announcement if you connected with MP or a smartphone app. But it will also not allow you to arm. It will force you to connect to a ground control station to figure out why.
The code uses the collective as one of the checks to determine the aircraft has landed. This is now with 4.2 based on the H_COL_LAND_MIN parameter which is now based on collective blade angle in degrees.
Yes, when you went to RTL, it did determine it was landed because the criteria for land detection was met. Typicallly the only criteria keeping the autopilot from determining it is landed is the collective because the other criteria are based on descent rate and acceleration which are met when the aircraft is hovering or descending slowly.
When you were flying in other modes like stabilize and poshold, I am assuming that some of the other criteria for landing were not met and thus the land complete flag was never declared. You wouldn’t have noticed much if it declared land complete in stabilize as it only affects integrator. But I think you would have noticed for PosHold because you would have lost control of the aircraft. In these modes, the motor would not shutdown. This only happens in autonomous landing modes like RTL or LAND.
Hope this answers your questions.
Thanks Bill. That makes sense. But where do I find the “wiki” which is often referred to in answers to questions? I normally go to subject pages in ardupilot.org, but sometimes they appear to be out of date, or don’t return the parameter I’ve asked for. I’ve now seen your post about this issue in 4.2.X though, so I think that covers it.
If my heli had been well below RTL_ALT when I hit the RTL switch I presume this wouldn’t have happened because the collective pitch would have increased rather than, as I suspect, it decreased at that moment because I was above RTL_ALT.
BTW no need for apologies 
I’m fully aware of the risks I’m taking every time one of my models leaves the ground – especially the helis. And the only real damage (subject to more-exhaustive running checks) is broken skids – no frame or blade damage, which are usually the expensive ones!
Yes you are looking in the right place. More specifically the tradheli pages. I have worked to try and keep these up to date. I’ll admit that the videos that Chris had done are probably quite out of date and I have plans to redo them but it is a matter of my personal time (its limited 
). If you go to the wiki and think somethiing is outdated please don’t hesitate to post in this forum and ask for an update.
Well I only did that because of your accident. I am trying to get the word out so users don’t experience the same problem you did. It is unfortunate that you had your crash but the change had to be made to the code to provide better protection as the previous way of determining landing with collective using the H_COL_MID was not working. I thing overall this will make landing detection more reliable and safer for autonomous flight.
It would have still happened once it started its vertical descent. The new parameters were set to 90 and -90 to force users to change them (if they had the arming checks enabled). And so the collective that indicated the heli was landed was a little below half or hover collective in your case. So any descent would have met the criteria.
This statement makes me sad. You should not feel that your heli is at any more risk than other platforms. The idea is that the firmware should be reliable and trustworthy. At least that is what I’m striving for.
Thank you Bill. I appreciate all the work you’ve done (and others).
What I don’t understand though, is I’ve had a few good RTLs and landings using v4.2.0 and 4.2.1, without this problem, including a 7-minute flight immediately before the one that went wrong.
1 Like
You were just lucky. All of the criteria for landing detection weren’t satisfied for one reason or another. Set the parameters correctly and you shouldn’t have a problem.
A few more queries, I’m afraid …
I have now set ARMING_CHECKS to 0. I previously had it at 5326 because I hadn’t checked the boxes for hardware that I’m not using, such as battery monitor, hardware safety switch, camera, etc. Will the arming check ignore items that are not actually installed or activated?
My max/min collective are +11 and -2.3 degrees without any ‘aileron’ or ‘elevator’ input. But the max/min pitches I can achieve (measured with pitch gauge) by inputting aileron as well as collective, are +18.6 and -10.3 degrees. Am I right in thinking that these two bigger numbers are the ones I should be using for H_COL_ANG_MAX and _MIN? At the moment I’ve set them at the smaller numbers in the attached parameters file.
I think you meant to say ARMING_CHECKS set to 1 
If it isn’t, make sure it is set to 1.
Yes it will not conduct arming checks on items not installed or activated. So leave it ALL in the pop up menu which equates to a value of 1.
Did you follow the swashplate setup in the wiki? please reference the wiki and if you are still confused then let me know. I will help you out and then clarify the wiki as well.
You’re right, I should have input 1 instead of 0. I’ll correct it.
Yes, I followed the wiki, using SV_MAN and H_COL_MAX and H_COL_MIN, achieving a collective range from -2.3 degrees to +11 degrees, which for my purposes was close enough to the suggested typical -3 to +12.
So in my case, H_COL_ANG_MIN and _MAX should be -2.3 and +11 degrees? Just out of curiosity, what would be the effect of having them lower?
Correct. Hopefully that is clear in the wiki?
Having what lower? If you are referring to the H_COL_ANG_MIN and _MAX then that will affect the autopilots estimation of the collective pitch angle. It is using that estimated pitch angle to determine when collective is below COL_LAND_MIN for land complete determination. That is probably the most important effect. I would have to think more about the actual implications of those values being lower or higher but that’s not the point.
Thanks once again Bill. Yes, I was referring to H_COL_ANG_MIN and _MAX. It’s clear that significantly over the actual collective values (i.e. the default -90 and +90) is catastrophic, but I was just wondering about minor discrepancies which might arise if someone doesn’t measure the angles accurately and, thus, inputs inaccurate data for H_COL_ANG_MAX and _MIN.
@abenn1 i think it should be at least accurate to 0.5 deg but if you can get it down to 0.1 deg even better
It seems, it’s incorrect in the wiki. I just looked it up in the full parameter list (online, not in MissionPlanner) and there it says, 0 means all checks enabled.
Its a bitmask, bit 0 is arming checks. Bit 0 of 1 is a value of 1.
Ah ok. Thanks for clarifying that. I was confused, because the description is different in MissionPlanner. But it seems, it’s the value there and in the wiki it refers to the actual bit.
@bnsgeyer
Hello Bill,
what should I take as a value for the degrees for semi symetric blades?
If my measuring instrument shows e.g. +10 degrees as max value, what should I enter as max value in this case?
I use only semi symmetric blades on my scale helicopters.
BR
Heri
@heri always enter the actual values that you read from your pitch gauge. Then modify the values for H_COL_ZERO_THRST and H_COL_LAND_MIN. So now both of these values would be lower because of your blades produce thrust at zero blade pitch angle. You could make them 2 degrees lower initially and see how the vibrations are during ground runs in alt hold. But the right way to do it would be to determine what zero thrust blade pitch angle actually is. You may be able to do it with smoke and watch the smoke as you move the collective up and down during a ground run. Just a thought.
2 Likes