Replies to This Discussion

ModeratorPermalink Reply by Graham Dyer on March 17, 2012 at 7:13am

I am not an expert by any imagination in reading logs but have just learnt a little while trying to decipher some of my own.

It's hard to say with your log as I can't see if and what went wrong although the Nav lat & long seem to build up tremendously just before the crash.

At about point 975 it appears that you switched to loiter as there are no further stick inputs from there on in, the quad then starts a slow swing back and forth as described which seems to get worse and worse until the crash, I've never let it get that far and switch out of loiter when things start to go pear-shaped like that.

What is your Loiter_P and _I set to?

• ▶ Reply

Permalink Reply by Lloyd Breckenridge on March 17, 2012 at 2:50pm

Hi Graham

Loiter_P is 0.700

Loiter_I is 0

Loiter_IMAX is 30.0

Thanks for taking a look.

This is the first time I have tried loiter and thought things were definitely going pear shaped but was not sure what would happen if I switched out seeing so much speed had built up.

Lloyd

• ▶ Reply

Permalink Reply by Jonathan M on March 17, 2012 at 4:41pm

Looks like Jason updated the GIT loiter gains again and halved the Loiter P to .35.  Since, it's not released, the devs are still working the baseline config.  It's still pretty alpha

• ▶ Reply

DeveloperPermalink Reply by jasonshort on March 17, 2012 at 5:04pm

Here's why:

There are two layers for Loiter: A position controller(Loiter_P) and a rate controller(Loiter_Rate_P). The position error feeds into the rate controller to get the final output. 

Loiter_P value commands a rate based on position error. When Loiter_P is higher and Loiter_Rate_P is lower you get a less noisy signal to the roll and pitch output.You could balance them for a more position based error or more rate based error. This works really well for Altitude hold because the Iterm is broken out in a special way.

Loiter however does not break out the Iterm in the same way as Alt hold for other reasons. What happens is the I term in the rate loop, which is downstream of the position loop, essentially gets scaled with Loiter_P. This is not a bug, but just how tuning Loiter works. More rate error means more compensation. It's also not something I had noticed before, but the Loiter_Rate_I was fairly high to begin with and the .7 it made it double. This leads to massive overshoot that can build over time.

In the wiki we recommend not fussing or at least raising Loiter_P. I should have stuck to my own advice! 

Jason

• ▶ Reply

Permalink Reply by Lloyd Breckenridge on March 19, 2012 at 2:17pm

Hi jason not sure where to raise this.

I was looking through the git diffs trying to track down the bug that caused my problem.

I found this fix

http://code.google.com/p/ardupilot-mega/source/detail?r=f55afc0bcac...

if ( last_longitude == 0 && last_latitude == 0 ) {
last_longitude = g_gps->longitude;
last_latitude = g_gps->latitude;
}

If these values are truly uninitialized then you cannot guarantee they are both zero.

If they are somewhere set to 0 then the code is fine.

Not sure how I can get the email address of the committer to question him.

Thanks

Lloyd

Lloyd

• ▶ Reply

Permalink Reply by Lloyd Breckenridge on March 17, 2012 at 5:52pm

Thanks for the answers.

Guess I should have been more patient.

Not too much damage just a couple of broken props.

How many people are using prop savers?

I would have been through a lot of props by now without them.

Lloyd

• ▶ Reply