G-Tune implementation and Harakiri pid updates #568
Conversation
| if (!time_skip[axis]) AvgGyro[axis] = 0; | ||
| time_skip[axis]++; | ||
| if (time_skip[axis] > 0) { | ||
| if (axis == FD_YAW) AvgGyro[axis] += 32 * ((int16_t)gyroData[axis] / 32); // Chop some jitter and average |
There was a problem hiding this comment.
Does this really work in practice? What if value is near rounding boundary?
It just looks wrong to me ...
There was a problem hiding this comment.
I did not touch the algorithms. This is a strait port from Harakiri code. At least the result are flyable P values on my copters. Outside with wind I had sometimes wobble but home in the living room the resulting P values are absolut stable and quite different from the starting ones.
|
looking forward to giving this a test, thanks @MJ666 |
| time_skip[axis] = 0; | ||
| if (axis == FD_YAW) { | ||
| threshP = 20; | ||
| error = -AvgGyro[axis]; |
There was a problem hiding this comment.
Making the value negative has no influence on rest of code.
There was a problem hiding this comment.
I was also wondering. But have not touched it.
|
It would be nice to add blockbox logging for GTune. It can help to explain what it does ... |
|
I have not dived into the BlackBox code yet. What i can see in the Autotune code it looks to be quite complex. May be @thenickdude can help here? |
|
For Blackbox logging you need to decide on exactly which variables need to be logged and when they need to be logged, define a struct to hold that data in blackbox_fielddefs.h, and write the code that'll serialise those bytes in blackboxLogEvent. Then you call blackboxLogEvent with your populated event structure when one of your new events needs to be recorded. And the number one thing to keep in mind is that the available bandwidth for events that will be logged on every control loop iteration is very small. The typical main frame logged on every iteration is about 22 bytes long, so if your event frame is 10 bytes long, you've already increased your logging bandwidth requirement during g-tune by about 50%. And the event frame has a 2 byte header as well! The hardest part is deciding what needs to be logged since this needs a very good handle on how your algorithm works, so that you know exactly what variables capture useful state that you want to inspect. If you don't have a specific debugging goal in mind then logging everything will just be a waste of time. |
|
GTune is calculated every 16th cycle now, so bandwidth requirements are not that high. |
|
1/16th is wonderful, since you can pretty much log whatever values you like
at 1/16th and still meet the bandwidth requirements!
|
|
Will take a look at this. UPDATE: Have added BlackBox recording for G-Tune. Untested since I don't have the related hardware for testing. May be someone can take a look. |
|
@MJ666 are you sure you dont have the hardware to log it? You just need a CC3D or a Full NAZE (with flash) now and you can log to the onboard flash chip. |
|
@hydra you are right I have an WarpQuad with an NAZE rev5. But testing may take a while since I can only go to the flying field at the weekend and the weather is still a limiting factor here. I have posted a Naze HEX in the RCG thread. May be someone can provide feedback more early. I also still have an problem with my WarpQuad which need to be resolved first. |
MJ666
force-pushed
the
Harakiri_PID_update
branch
from
9399350
to
c6baeed
Compare
|
@MJ666, @hydra may I have a suggestion: maybe after G-Tune finally makes it to CF we can remove 'Autotune' alltogether to free up flash for other usefull features, i.e. full-blown navigation with waypoints and RTL? I haven't tested G-Tune yet, however ability to automatically tune PIDs during normal flight looks very promising. |
MJ666
force-pushed
the
Harakiri_PID_update
branch
from
359ea8a
to
4ed378a
Compare
|
Agreed. Bradwii autotune was an interesting experiment that never really worked. The code will remain in the git history should we need it again. However it was never properly debugged either, analysis of autotune flight data logs was next on my list after the serial port cleanup work I'm doing... |
|
IMO GTune won't work either. The assumptions from accompanying posts are questionable and not reflected in code, the algorithm is IMO just magic juggling of external disturbances. It may have some result for quad with right time constants, but that is mostly coincidence (or it works because some principle that is not expected by the algorithm). Adding blackbox logs should help understanding GTune ... |
|
BlackBox logging is added and should work (but not tested yet). |
|
I don't think that working GTune is a mere coincidence. This method it is somewhat similar to Ziegler–Nichols method of tuning a PID controller. Both use random external disturbances as a destabilization factor, both start with zero P value, both increase P to the edge of oscillation and act on that. There are differences, but the similarity of the two can not be ignored. |
|
@digitalentity : Ziegler–Nichols method finds ultimate gain (and frequency) and backs off quite a lot. GTune increases gain if sampled angular rate is increasing fast enough and decreases gain if it is decreasing (with identical but negative threshold). The rate of P decrease is about half. It also decreases gain when rotation direction changes, but only if change occurred at right time in sampling interval(this is probably random) and change is steep enough. If ultimate frequency is low enough, this should result in P going to infinity. But it may work if oscillation frequency is higher than GTune sampling - sampling will reject P-caused oscillation and resulting accumulated value may stay within limits (no change to P). But I may be wrong .. blackbox log will be great tool to analyze this ... |
|
From my testing 25-30 flights mostly with PID5 I always get very flyable results. since I always ended up near 7:0 which is the default limit. I raised to to 10 to see what happens. But I still end op with 6.3 to 6.7 with Roll and pitch and around 7.0 with yaw. most of this flights in a room which will not give much disturbance. My outside flights with changing wind conditions causing some light oscillations in between. But usually the final results where always good flyable P values. The individual results have some variation (up to 1.0) and are different between the PID controllers. I never ended up in something unflyable. With PID2 I onl dis some basic testing since this PID is very aggressive with standard settings and the challenge is the get it stabilized in the air to start tuning. Anyhow looks to be @strips had some good success also with PID2 already here #560: http://www.rcgroups.com/forums/showpost.php?p=30941917&postcount=4078 |
|
It may be interesting to change sampling time (https://github.com/cleanflight/cleanflight/pull/568/files#diff-f948c4e72f6fd563317e98aa58c3e2bcR131). If is is decreased too far, P term will saturate to maximum. Not sure about other extreme, but with high enough value it may tune P to minimum value where quad is controllable (unless crash comes first). My quad (450 frame) seems to oscillate around 8Hz (guessing from log), so if you have something similar or smaller/lighter, P caused oscillation will be rejected by GTune sampling. GTune may actually work (as long as some conditions are met), but if my speculation is correct, same result may be obtained in much cleaner and robust way |
|
During my test with PC2 is even tuned P down and hit the lower limits. may be this is related to the aggressive flight behavior which is already hard to control. |
|
Here is an tuning example for my Nano Hexacopter PC5 all other values are CF defaults: Axis | Start value | G-Tune result The possible range was set from 2.0 to 10.0 |
MJ666
force-pushed
the
Harakiri_PID_update
branch
5 times, most recently
from
f20e539
to
5d6924f
Compare
MJ666
force-pushed
the
Harakiri_PID_update
branch
from
5d6924f
to
697ea48
Compare
Fix code style
- add two new CLI paramaters "gtune_settle_time" and "gtune_average_cycles" - the settle time is not depending on looptime anymore - updated default setting to cover e wider range of copters - remove lower limit for P value for CLI (Zero P is now posible, but schould be used with care) - Documentation updates
Flight tested with PID3 and PID5 (still functional without negative side effects) Additional code style updates of gtune.c
Documentation update
MJ666
force-pushed
the
Harakiri_PID_update
branch
from
0b3caf0
to
f15cedd
Compare
|
Hello, please can you rebase with 1.10 and share a new Naze build ? |
|
I rebased the code recently. Unfortunately the configuration space for the Naze an the AlienWii F1 target is full and the firmware will not build anymore for this two targets. One temporary solution would be to remove one other feature like GPS to get an G-Tune capable firmware build. |
|
Ah ok, do you have a naze build without gps for me ?
|
|
I don't have acces to my development system for the next days. Why not use the latest hex I published here for tuning and use the tuned values with the latest stable afterwards? |
|
The old download links are death. Ok i try my luck to build it on my own. |
|
I'm merging this now. FYI. I'm only enabling this on 256KB targets due to current requirement for configuration storage. On the 256K targets the last 4KB of EEPROM will be reserved for configuration. We can look to address this in a future pull request. |
|
gtune also fits on CJMCU. |
|
merged |
|
what pid controllers does this work for? / will it work on betaflight's luxfloat? |
|
@hydra proudly we can drop autotune now? It doesn't work and takes some
space.
|
|
Sorry, didn't notice that it has been already done, please disregard my previous comment =) |
|
@hydra cool finaly the PR made it. |
|
Changes Unknown when pulling f15cedd on MJ666:Harakiri_PID_update into ** on cleanflight:master**. |
Implement G-Tune (ported from Harakiri). Documentation can be found here:
https://github.com/MJ666/cleanflight/blob/Harakiri_PID_update/docs/Gtune.md
G-Tune is tested in a quite some test flights and is working much more saver and less intrusive than the CF Autotune. It should work on all PID controllers (PID 0, PID 3 and PID 5 are tested). Please see also here #560.
Make two formerly hardcoded parameter for the Harakiri PID configurable. The first one has helped some users with there tuning problem to eliminate some wobble.
Added an yaw constrain if yaw stick commands are given to PID 3, PID 4 and PID 5 controllers. Recommendation by Crashpilot1000.