Can I retrieve PID values from the log of an unfinished autotune?

I tried performing an autotune on a hexacopter in a semi-confined area (i.e. my basement) and as such required a high amount of user input, which pauses the autotune process. Because of this the autotune process did not finish in the 18 minutes of flight I had.
My question is, are there PID values I can distill from the log file? If so, where?

No definitely not. The Autotune process tries values that may not normally be flyable and you really wont know what works until Autotune finishes.
If there is a .bin log of some hover and gentle flight around then we can start to take some guesses. In my experience, the closer you can get filters, PIDs and everything else to be correct, the quicker Autotune will work next time.
If you wish then let us know more specifications of your hex.

Adding some more useless words…

Thank you both for your replies.
I will redo the autotune process in a more open setting.

There is a PR that prints out the final PIDs as they get calculated. You might want to ask the devs to put that in.
And you should do one axis at a time. That way you will not run out of battery before it finishes.


On MP, filtering on MSG messages, there is some info.

Last 2 week i have a question about this autotune my copter can’t get autotune after 6 flight each flight 10min overall I’m boaring and see telemetry data on radio and I notice there is 1 more features in there WFL what is a WFL ?
And my mean value always higher ther accepted why ?

WFL= Waiting for level

@Moksh if you are using the latest master version you have this inside

And that should help. But you do need to follow the tuning process instructions first, and have no wind, and do an axis at a time, in order to get a proper autotune.

What level ? ,

5° ? And leveling 10°/s means ? Still out of head

Right from the Auto Tune Wiki:

" but first it is waiting until it gets back to level from the last twitch (WFL= Waiting for level"

IMG_20210216_141812 IMG_20210216_141721 IMG_20210216_141651 IMG_20210216_141606

Now I’m little more curious about , lean and target audience , who this ???

And my WFL is why very high to expected ?

Who this? Don’t you mean Who Dat? It’s Mardi Gras.

It means what is a “lean and target” characters , what’s the function ?

I still dont believe you can get PIDs out of the Autotune messages as they are now. If I understand it correctly, Autotune is trying (potentially) extreme values and during the twitch is putting back a reasonable value in order to recover without losing control. Happy to be corrected on this.
The calculated PIDs are evident in the .bin log after Autotune has finished and saved the new PIDs upon disarming.

You’d have more luck looking at an ordinary flying .bin log and making some guesses at PIDs and following the tuning guidelines.
…or just wait till you can get outside and run one axis at a time.

If you can’t get Autotune to complete even one axis before running out of battery, then open a new thread and include the problem, a .bin log file and details of the aircraft.
It may be that you’ve got something making it difficult for Autotune that someone can identify.

Ok , today I will go to play area and test autotune on my fresh new frame

Do not forget to do Tuning Process Instructions — Copter documentation before doing autotune

I’m sorry for let reply , today’s morning I was go to default pids and looks everything ok but there is 1 problem when I’m move my copter then lost altitude , why ? Also there is little bit harmonics but I will tune it my self also any suggestions must be appreciated :slight_smile:

This is my 2 flight 1 is regular for just see , 2 is lost altitude
This is bin file

Thank you :slightly_smiling_face:

Looking at the “lost altitude” bin file you can see motors 3 and 4 (both clockwise rotation) are often going to minimum

Normally this would indicate a physical yaw bias, such as twisted motor mounts, arms or frame. Potentially even different pitch or construction props on CW and CCW positions.
The odd thing is you normally expect to see motors 1 and 2 have higher outputs to try and counteract the yaw too. So it’s not quite clear-cut to me what’s going in here.

I’d say the main problem with that is MOT_THST_HOVER,0.125 and MOT_SPIN_MIN,0.15 overlap.
MOT_THST_HOVER is dynamically calculated in flight, but it always needs to be higher than MOT_SPIN_MIN. You’ll need to add some weight, or put on smaller props, and set MOT_SPIN_MIN,0.12

Your voltage monitoring is out by some astronomical factor, and current monitoring is not quite right either. See if you can fix them up as soon as possible.

After you fix the voltage and current monitoring, with the quad connected to MissionPlanner, press Alt A on the keyboard. Answer the questions and accept all values it offers and write them to the flight controller, including the INS_GYRO_FILTER value (don’t leave it at 20 as suggested).
The also set these:

All vibrations, X, Y and Z axis, are getting bit towards being high. You might want to check if there’s anything you can do for that. Less vibrations are a big bonus to stability.

After all that, do another test flight with some hover and gentle movements around, let’s see that .bin log.

EDIT: typical voltage and current settings are:
but it will depend on your power brick, you may need to do a manual calibration

1 Like