loiter debug - gains altitude rapidly when engaging loiter/alt hold - ArduCopter User Group

Hi,

When I try to engage loiter or alt hold at about 3-4 meters above ground, the quad shoots up in the air as shown in the barometer altitude logs below. It does not drift too far out but gains about 20m of altitude immediately. There is medium wind in an open field. Please suggest ways to debug this issue and have tighter altitude hold in loiter.

The attached log has afew instances of enabling loiter and the quad shooting straight up. The baro-alt seems about right from what I remember seeing the flight. I would have expected Loiter/Alt hold to be much better at holding altitude and have some spread in X/Y plane due to GPS accuracy. That does not seem to be the case.

What can be done to improve the loiter. Marco has this nice video of Loiter https://www.youtube.com/watch?v=vnJcxMxDfy4 ... how can I tune the quad to get performance like that?

Another thing I notice from these logs is that the GPS reported altitude is totally off compared to the baro-alt. Maybe thats the limits of GPS' precision and from what I understand not necessary for Loiter? I'm using a mediatek GPS.

Thanks for your comments in advance

Regards

Vikrant

PS:

The log file is at: https://www.dropbox.com/s/8qxh2kth9f0f01d/Vikrant%20loiter%20test%202013-05-31%2012-15.log

Please excuse the large size of the log, IMU logging was enabled for this flight.

The compass is well calibrated for this quad and the vibration levels are also well within the limits. Running 3.0rc3.

I wanted to express interest in this, since I have also struggled with getting smooth altitude hold with 2.9.1b (which is the actual problem here, not the position hold part of loiter).

Randy had said in an earlier post that tuning the acceleration control loop was the only thing we should *in theory* have to mess with, and that the throttle rate and position P terms should not need to vary between copter frames. But I think experimental evidence seems to be contrary to that.

The smoothest I have been able to make my copter is still quite jumpy, even after eliminating the sonar, which was having some troubles due to EMI. However, I have gotten rid of most cases of shooting up into the sky.

One piece of advice though: ensure you get a very stable hover before you engage altitude hold. If the copter is still moving, or has just stopped moving (but is at the bottom of an impending upswing) it is not in what I call a stable hover.

Stable hover will allow the software to estimate the hover throttle value, which tends to be more or less constant (although varies with air pressure, temperature and state of battery..., although state of battery is accounted for in other parts of the software).

I don't know if you need to disarm for the stable hover throttle to be saved, but that is probably the case.

The shooting up in the sky part I think might have something to do with how the hover deadzone is centered once alt-hold is engaged. I thought it used to be centered at the current throttle stick position. Is this still the case? it seems as though sometimes it picks up an apparent throttle move that hasn't actually happened, and some throttle stick movement is needed to stop altitude changes. Either that or the target altitude can be changed by the actual altitude exceeding a threshold and that, in my opinion is a control loop with potential for bad feedback (which is exactly what happens when the copter shoots up!)

With respect to Marco's video, notice that he is not running the same version that is public (apparently version 3?), so maybe what you need to do is wait for that version, or risk using pre-release software (not a super high risk, but a real risk to keep in mind)

Finally, After studying the altitude control loop diagram that was published, I couldn't help but guess that the code I added as a short time member of the dev team, about a year or two ago has probably been removed due to there being better options (and my lack of participation) The parameters were not very well documented and probably were terribly sensitive to different frame types, as shown by the latest form of inertial navigation, which while promising super impressive performance, needs to be properly tuned to the given frame.

But I still suspect that a direct damping from dc filtered accelerometer integral (a very high bandwidth and low latency signal proportional to short term velocity, after transforming by the DCM to account for rotation, that is) would still smooth out those bumps, as my experience showed, while allowing the rest of the new control loop to take care of mid and long term stability. The throttle rate is based on what I believe to be the derivative of altitude after inertial mixing, but I don't know how high bandwidth that inertial mixing is, which is needed for smooth damping. Marco will probably have a lot more to say, but my suspicion is that marco has probably already figured this out and that is probably what he is showing off on that video.

-Aurelio

Replies

Vikrant June 2, 2013 at 3:59am

Update: Much better alt-hold today when engaging alt-hold from a stable hover in a relatively wind free environment. The space was quite tight so I could not test Loiter.

I used AC3.0 rc4 which got published on Mission Planner today so that could also have impacted alt-hold stability.

Next will try this in a more open field but much wind there these days. I guess I will have to learn how to get a good hover out in the windy field before going into alt-hold.
Developer

Randy May 31, 2013 at 7:39pm

The problem is almost certainly that you have too much vibration on your copter. You might want to check out this item in the trouble shooting guide.
Aurelio R. Ramos May 31, 2013 at 1:11pm

I wanted to express interest in this, since I have also struggled with getting smooth altitude hold with 2.9.1b (which is the actual problem here, not the position hold part of loiter).

Randy had said in an earlier post that tuning the acceleration control loop was the only thing we should *in theory* have to mess with, and that the throttle rate and position P terms should not need to vary between copter frames. But I think experimental evidence seems to be contrary to that.

The smoothest I have been able to make my copter is still quite jumpy, even after eliminating the sonar, which was having some troubles due to EMI. However, I have gotten rid of most cases of shooting up into the sky.

One piece of advice though: ensure you get a very stable hover before you engage altitude hold. If the copter is still moving, or has just stopped moving (but is at the bottom of an impending upswing) it is not in what I call a stable hover.

Stable hover will allow the software to estimate the hover throttle value, which tends to be more or less constant (although varies with air pressure, temperature and state of battery..., although state of battery is accounted for in other parts of the software).

I don't know if you need to disarm for the stable hover throttle to be saved, but that is probably the case.

The shooting up in the sky part I think might have something to do with how the hover deadzone is centered once alt-hold is engaged. I thought it used to be centered at the current throttle stick position. Is this still the case? it seems as though sometimes it picks up an apparent throttle move that hasn't actually happened, and some throttle stick movement is needed to stop altitude changes. Either that or the target altitude can be changed by the actual altitude exceeding a threshold and that, in my opinion is a control loop with potential for bad feedback (which is exactly what happens when the copter shoots up!)

With respect to Marco's video, notice that he is not running the same version that is public (apparently version 3?), so maybe what you need to do is wait for that version, or risk using pre-release software (not a super high risk, but a real risk to keep in mind)

Finally, After studying the altitude control loop diagram that was published, I couldn't help but guess that the code I added as a short time member of the dev team, about a year or two ago has probably been removed due to there being better options (and my lack of participation) The parameters were not very well documented and probably were terribly sensitive to different frame types, as shown by the latest form of inertial navigation, which while promising super impressive performance, needs to be properly tuned to the given frame.

But I still suspect that a direct damping from dc filtered accelerometer integral (a very high bandwidth and low latency signal proportional to short term velocity, after transforming by the DCM to account for rotation, that is) would still smooth out those bumps, as my experience showed, while allowing the rest of the new control loop to take care of mid and long term stability. The throttle rate is based on what I believe to be the derivative of altitude after inertial mixing, but I don't know how high bandwidth that inertial mixing is, which is needed for smooth damping. Marco will probably have a lot more to say, but my suspicion is that marco has probably already figured this out and that is probably what he is showing off on that video.

-Aurelio
Charles lakins May 31, 2013 at 1:02pm

sounds like its changing altitude sources for calculations to me, bringing the craft to the one that reports the highest reading

This reply was deleted.