Are there currently any parameters that can be turned off or disabled that effect the descent rate when landing at relative elevations below zero?
I’m asking about this because I recently flew a road corridor survey and used terrain following, and when the autopilot thinks you’re at negative elevation, it basically does not want you to let you descend below a certain negative elevation, or limits the descent rate, because of this, I had a crash with a $180,000 LiDAR scanner payload with an 800-class helicopter being I had to lower the collective much lower than normal to try to force it to descend, and I had the collective all the way down for too long and this caused the autopilot to disarm when it was still about 50FT above ground level.
@223Wylde I am very sorry to hear that you crashed. I will need more details of the accident in order to determine the issue. Can you post a log either to this discussion or PM me? That would be most helpful in determining the cause.
Based on your post, it sounds like you took over from the auto mode and tried to land in loiter or stabilize? I am not aware of any limitations to landing with negative altitude in one of these modes. What version of arducopter were you flying?
Any info you can provide would be great. I want to figure out what happened.
Thanks,
Bill
Yes, I took over from Auto and always land in POS hold, not Stabilize. I know that Stabilize would have probably prevented this, but its always much easier and safer landing in POS hold. I’ll see if I can get the log uploaded.
Jeff,
I’m am not sure why the vehicle would disarm in POSHOLD even if you did have the collective all the way down. it is using the altitude controller (ALTHOLD) in the vertical axis. This doesn’t make sense. It should have just kept on trying to descend. weird.
regards,
Bill
Yeah, you’re telling me! I know there’s something in the code that causes this though, we had a client flying one of our hexacopters about 2yrs ago in Wyoming, he launched at a much higher point than he landed, and the exact same thing happened.
After my crash or really hard landing, whichever you prefer…LOL, I reviewed the TLOG, and it disarmed at around -25m elevation, I’m not sure how long I had the collective down for, that I’ll need to doublecheck. Anyway, once it disarmed, the servo rail locked, and I think it cut the motor, and it stayed perfectly level and descended rapidly to the ground, amazingly there was no damage to the 800 at all due to the massive carbon fiber struts I use, but the LiDAR scanner broke away from its mount and suffered significant damage.
I do agree that this isn’t something that should happen if you’re using either ALTHOLD or POSHOLD when landing, I think if I had realized it was at negative altitude and refused to descend, switching to STAB mode might have bypassed whatever setting was causing from refusing to descend further.
Hi Jeff, I did a SIM with copter 4.0.5 and I didn’t have any issues in descending in loiter or poshold to relative altitudes of -70 m. So I am very interested in seeing your set up and the data of this accident.
I took a closer look at my tlog, when descending, I never had the collective all the way down, I only lowered it to about 25% (1200) which is quite normal (995 - 1000 is all the way down), you’ll see in the tlog, I always have the rotor head speed and collective added to the hud.
I’m even more unsure of the cause of disarming now, can you think of anything else that could cause an in-flight disarm like this?
Ok, H_COL_LAND_MIN could be the problem then, I wasn’t aware that was a parameter that needed to be set, do you know what version that parameter was added?
Jeff,
I looked at your data and your setup for H_COL_LAND_MIN and H_COL_MID looks good and there were no issues with the flight in that regard. However I am sorry to say that the FS_CRASH_CHECK is what caused your aircraft to disarm. It appears that this was caused by the desired pitch attitude and the actual pitch attitude being more than 30 deg off from each other (shown below)
If the heli is tuned well, the actual and desired attitudes should not be more than 30 deg off. This indicates that you aren’t using ATC_RAT_XXX_ILMI. The ILMI parameter allows I term build up to the specified value for ground speeds less than 5 m/s. It looks like yours are zero. Above 5 m/s the I term is allowed to grow and is limited by ATC_RAT_XXX_IMAX. I know some users are concerned about I term growth when they are on the ground with larger heli’s and set the ILMI gain to zero but values of ILMI of 0.08 should be safe as it should not allow enough control input to tip the helicopter.
Generally we recommend users disable the crash check for heli’s as typically if a helicopter does crash, this crash check is not going to save it from destroying itself.
Again I am sorry that your heli crashed. There is one other thing that concerns me as you said that the helicopter would not descend and that is why you took over in poshold. From looking at the tlog, it appeared that the aircraft had a very difficult time holding position and drifted quite a ways from the waypoint. It seems like you were flying in pretty high winds and I could only surmise that from the significant difference between actual and desired attitudes. What was the next command after command #42 in the tlog? Was it a LAND command? I think it didn’t start its descent because it wasn’t in position over the waypoint to start the descent.
Ok Thanks Bill, I might have missed adjusting the ILMI parameter when I finished tuning. Not sure if you remember, but I had a lot of issues tuning this heli last summer, I finally figured out I could not go above .0015 for the D term, otherwise it would develop a severe oscillation and would basically shake itself apart before I could get it back on the ground.
I will disable the FS_CRASH_CHECK and tune the ILMI parameter.
After it reached the end of the flight line(#42), I had to de-initialize the IMU in the LiDAR scanner, that requires accelerating forward, backward, forward again followed by a U-turn, I had to do that before starting the descent for landing, I typically do all of that while in POSHOLD, is that the manuevering you were concerned about?
Well, yes I was concerned about that but before you took it in POSHOLD, the stopping at the final waypoint resulted in huge pitch oscillations (pitch attitudes +/- 30-45 deg). There is definitely something off in your tune. Part of it could be the attitude controller/rate controller tune but you could also have some issues with the position controller. The oscillations during the stop at waypoint 42 were divergent but somehow calmed down before you took it in POSHOLD.
Looking at your attitude controller settings, I noticed that you also have the Pitch and Roll filters down to 4 hz. I think that may be causing a lot of lag in the aircraft response. You may have set those low in order to reduce the instability with the D gain but I don’t know if it is worth it to squeak out a little more D gain.
Yes, I know there’s definitely still something off with the tune, it definitely overshoots on pitch and takes a while to settle down when sliding to a hover. Yes, I may have lowered the filters a little too far, but that was before I figured out what value not to exceed with the D gain.
It also is very sluggish in changing direction, when I had to push it forward, then stop, then backup, it would take it a while before it would respond to the pitch direction change, not sure if that’s mostly due to running such a low D value or the pitch and roll filters you mentioned.
The other difference I can think of since I tuned it, I’ve added much heavier battery packs that weigh a total of 4lbs more than the packs I had on it while tuning. Also, the LiDAR payload was 7lbs, so I’m wondering if the 11lbs extra mass contributed to the overshoot issue.
