AltHold Algorithm Bug

[buckker]

Hello Friends
I posted my problems in connection with overshooting in the AltHold mode a few months ago on DIYDrones. But nobody really listen...
Today I did some aerial footage for a commercial. It was windy but I saw no reason to don't start. I waited in the the Loiter Mode until I get the order to fly forward. Suddenly my X8 coax copter nearly did a backflip... I switch immediately to the Stabilize Mode and the multicopter leveled horizontally. After that I landed and finished the drone shots.
I went home and did a comparison test between the AltHold Mode and the Stabilize Mode. The goal was to fly forward and to slow down the flight speed by push the transmitter stick to the neutral position. So, no aggressive brake maneuver.
Here it is in the AltHold Mode, you can clearly see that the multicopter overshoots. :
https://www.youtube.com/watch?v=cNSFbXruIBE
And the same maneuver in Stabilze:
https://www.youtube.com/watch?v=KqRJz9XztYU&feature=youtu.be
You can clearly see a difference between the flight modes. I got this problem also during shoots early this year. We said, it must be the weather conditions, maybe to windy.. But no, in my opinion it's a problem with the AltHold mode and all other modes who relate to them.
I hope you guys find a solution for this. It's only a matter of time til a multicopter crashes and hopefully nobody get injured...

Here is my setup:

V 3.3.3 / 3DR Pixhawk
X8 Coax

BTW, I have the same problem with other X8 coax multicopter...

Thanks a lot
Michael$
276.zip

[R-Lefebvre]

I don't believe there is a bug here, as Alt Hold uses the same Attitude control algorithm as Stabilize.

I think the problem you are having is that your Attitude control PIDs (RATE_xxx_P, I and D, and STAB_xxx_P) are not tuned adequately. And/or, your copter control bandwidth is not high. Then, the Altitude controller running in Alt_Hold mode is using up too much of the control bandwidth, so the Attitude controller can't function properly.

What size are the props on this thing?

Do you have logs?

[buckker]

Thanks Rob

Your explanation sounds plausible. What do you mean with the bandwith? Or which are the parameters to tune?

Here is the setup of my X8 Coax:
Motors: Dualsky XM5015MR 6 TURN (390KV)
ESC: Maytech OPTO 50A BlHeli
Props: Tiger 16x5.4"
Battery: 6S16000mAh
Takeoff weight: 8.5kg

the log file is attached on my first post, I hope you can see it ;-)

[buckker]

I have done some other test flights with 2 other X8 multicocpters. Exactly the same problem... During a auto mission one copter nearly did a flip.... The strange thing is that the copter follows the desired pitch (see the attached log). In this case I would say it's no overshooting. I have noticed that the Des Pitch and the Des Roll target values varies very fast. So the lines in the graph are sometimes nearly vertical...This means the copter has to move very fast from one angle to another. Why is this so rough? Is it not possible to make it smoother?

11.zip

[R-Lefebvre]

Ok, I had a look at the logs. I'm not seeing what the problem or even bug is. When it pitches back, it's because you commanded it to pitch back. And the angle tracking is really not bad.

Your ATC_ACCEL_P_MAX and R are a little high for a copter that size. I would try changing them to maybe 72000.

[buckker]

I think you didn't see the problem. I didn't pitch back. I only push the stick in his neutral position. As you probably have seen, in AltHold the multicopter go horizontal and then tilt back (without a command from me.)

Take a look at those graphs.

Stabilize:

AltHold:

You can clearly see that I command to go horizontal, not to pitch back.

But I will test if it helps to adjust the TC_ACCEL_P_MAX and R parameters.

Thanks for your help :-)

[rmackay9]

I agree with Rob's advice on lowering the maximum acceleration.

I've had a quick look at the logs and it looks like it's handling pretty well and then it suddenly goes wrong. To me that means an external disturbance or a mechanical issue. Two of the motors (2 - upper front left, and 6 - lower front right) are hitting their lower limit.

The center-of-gravity (COG) of the vehicle also looks quite low. Ideally it should be level with the motors. That's probably impossible but moving it up somehow will help.

Technically we shouldn't use GitHub issues for support so I'll close this if that's ok.

[olliw42]

why would that explain that it repeatedly happens in AltHold but never in Stabilize ?

[rmackay9]

@olliw42, so the basic attitude control is the same between Stabilize and AltHold. The only difference would be the throttle level. So what's likely happening is that as the vehicle leans back, the altitude hold controller sees the vehicle starting to rise and fights back against that. To "fight back" it reduces the throttle. Doing that causes a conflict between attitude control and throttle level (i.e. it can't do both to the level requested meaning it needs to prioritise and/or sacrifice some control in one or both of the areas). That prioritisation is probably causing a weakening of attitude control which leads to more overshoot in AltHold. In fact, if the pilot were as quick with the throttle as the AltHold controller we'd see the same response in both modes.
So the proposed solution is to make the vehicle not try to lean back so quickly. A little more time will mean less of a shock to the altitude controller and thus lead to less need for sacrifices.
There is actually another solution though as well - the prioritisation of throttle over attitude control can be adjusted with the MOT_THR_MIX_MIN and MOT_THR_MIX_MAX parameters. Adjust one or both up could help as that would lead to increased priorisation of attitude control over throttle in these situations. I'd try reducing the acceleration limits first though.

[olliw42]

this was a very detailed and good explanation, thx a lot :)
the case made me curios since it seemed contradictory but I failed to see that both controller have to act on the same output, thx for the lesson

[buckker]

Thanks for your explanation, Randy

I will test it and give a feedback on this. If I have success, it would be great to share those tuning information on the arducopter documentation page.

[R-Lefebvre]

That's what I meant about "Control Bandwidth". The motors can only do so much. You have to give them a chance. Either slow the responsiveness. Or sacrifice Yaw or Altitude control for Roll/Pitch.

[buckker]

Hi Rob

I have reduced the ATC_ACCEL_P_MAX and ATC_ACCEL_R_MAX according to your recommendation. Unfortunately it doesn't help. The only thing I noticed is that the multicopter fly a little bit smoother. But that's all.

It was strange again, after leveling horizontally, the copter tilt back after probably 1 second and felt not controllable. I have to use the emergency exit and switch to Stabilize.. Immediately the control was back, I could feel the copter with my sticks..

For the second flight I set the EKF_ALT_NOISE Value from 5 to 1. I increased it a few months ago, because the AltHold performance was not good enough. It was not possible the control the altitude smoothly. The copter jumps up and down.. I got this issue after a firmware update. Never had this before.. I think with the adjusted EKF_ALT_NOISE value it was a little bit better, but I have do some more test flights.

@ Randy. The MOT_THR_MIX_MIN and MOT_THR_MIX_MAX parameters are already on their lowest limits. For my problem, I think we must prioritize Throttle over the altitude controller..

[rmackay9]

Hmm.. well, you could try reduce the altitude hold PID gains (maybe halve the lowest level accel gains). That'll reduce the altitude hold performance but might help some.

My feeling is that there's only so far we can go in software. I think you'll find if the camera is removed it flies better. So a physical solution would be to move the center-of-gravity up. I.e. mount the batteries above the arms and bring the camera up too... and shorten the legs.

[buckker]

I did 2 test flights this evening. I reduce the Alt Hold and the Accel gains. But it didn't help... I thought I modify the test method a little bit. I only descend in a angle from maybe 60°. So, no fast maneuvers.. The goal was to reduce the influence of my copter design (low center of gravity) One time it overshot again in AltHold( the copter leans back)... In Stabilize no problem. After this, I studied the full parameter list and found the parameter ATC_ANGLE_BOOST. I set the value to 0 and had no problems during my test descends.

How does this parameter affects the hole control algorithm?

[buckker]

Hi Rob and Randy

It seems that I'm not the only person with this problem (one person also with a Octo X):

http://discuss.ardupilot.org/t/problem-with-altitude-hold-tuning/624/5

You should think about it...

[buckker]

I updated all my multicopters to copter 3.4-rc1 and have no overshoot. I tested it with the same maneuvers and the problems is gone. This is very nice but I still doesn't know what exactly cause this problem in V3.3.3...

[skafel]

Hi Guys ! Sorry for my "google translator english" but this is my last hope. I have similar X8 and the same problem, but update to copter 3.4-rc1 didn't help. Mr. buckker can you share with me your PID's ?

[buckker]

Hi

I can post you the actual values earliest in a few days. But what you can do right now is to download the zip file in this thread (11.zip) It's a logfile. You should be able to get the PID values from the logfile.

BTW, do you have some pictures of your X8?

Cheers Michael

[OXINARF]

@skafel @buckker Please move this discussion to the forum, that's the place for support questions.

[skafel]

ok, sorry for that, @buckker can you send me your email adres?