Heli appeared to disarm when RTL activated

I’m running Ardupilot copter 4.2.1 in a TRex 500. Today I had one successful 7-minute flight, mainly doing gentle circuits in PH mode, followed by a successful RTL, landing, and automatic shutdown.

My second flight was the same until I activated RTL at exactly 5 minutes into the flight. At that point I think I was at or just above the RTL_ALT parameter. The heli turned to face the launch point then, I think, dropped a little, then appeared to shut down (motor sound stopped), and dropped like a stone. I immediately switched to stabilised mode, and attempted to autorotate, but broke the skids and a couple of servo arms on ‘landing’. Post flight the battery showed about 45% charge, with well balanced cells, which is what I would expect at about 5 minutes with that model.

To my inexperienced eyes the log appears to say that landing was detected at about the time RTL was initiated. As usual the file is too big to post directly, but here’s a link to it in Google Drive. I would appreciate it if someone could suggest any parameter I need to change to prevent this happening again.

Hi! Access is denied when trying to access the log.

Thanks for looking. I still haven’t got the hang of this file sharing! OK, this time it says that anyone with this link will be able to access it. I hope it works now.

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 :smiley: 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 :slight_smile: ). 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.

22-06-27 Parameters for H_COL_MIN and _MAX.param (16.4 KB)

I think you meant to say ARMING_CHECKS set to 1 :wink: 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.

No wonder I’m confused sometimes :grinning: