CleanFlight Ervaringen

Horizon mode werkt niet op PC1 :).
PC1 is een acro geoptimaliseerde pid controller :)

Autotune kun je gewoon op acro doen of nog beter zelf tunen
 
BorisB zei:
Horizon mode werkt niet op PC1 :).
PC1 is een acro geoptimaliseerde pid controller :)

Autotune kun je gewoon op acro doen of nog beter zelf tunen
Klik om te vergroten...
Hmm.. Dev documentatie suggereert dat je horizon of angle aan moet zetten. Vandaar dat ik die speciaal onder een knop gezet had.

Eerdaags eens met PC0 of PC3 proberen
 
Iemand die de PID controllers geanalyseerd heeft:

I've been reading the feedback from various folks to the set of
PID filters that are currently included in cleanflight, and I've
been wondering what accounts for the differences in performance and
ease of tuning.

I decided to do an analysis and comparison of all 6 PID filters, but
in order to begin I will strip each filter down to the code that
provides core stability in ACRO mode. You might think this would lead
to useless oversimplification, but I found that there are significant
differences in how this core functionality is implemented, and I think
it does explain a good deal of what people are experiencing.

The file "stripped_pids.txt" contain my reduction of each of the PID
filters. I eliminated anything that would get in the way of appreciating
the structure of the code, so comments, casts, and other bits that I
thought were unneccessary were removed. I also combined multiple code
lines and adjusted the placement of code where it would help clarity and
not affect the way the code operates.

I use as my baseline the pseudo-code example for a PID filter found in the
Wikipedia entry under "PID Controller". I consider this the canonical
form note differences between this and the PID filter collection found in
cleanflight.

previous_error = 0
integral = 0
start:
error = setpoint - measured_value
integral = integral + error*dT
derivative = (error - previous_error)/dT
output = Kp*error + Ki*integral + Kd*derivative;
previous_error = error;
wait(dT)
goto start

In the canonical form, error is the difference between the set point and
the measured value. Since in ACRO mode we are controlling for gyro rate,
the canonical error term would be the difference between the control stick
input and the gyro rate.

In all the filters discussed, the need for anti-windup limiting on the
integral term discussed in the Wikipedia article is heeded and we see
a wind-up constraint applied after the integral is summed.


Here is my commentary, for what it's worth:


Filter 0 - pidMultiWii:

We're all familiar with this filter, and in it's simplified form we can
see how it differs from the canonical form. The first thing we notice is
that the Pterm calculation applies the dynamic Pterm gain to the gyro value,
but not to the actual error value. This unusual approach is maintained in
pidMultiWii23, pidMutiWiiHybrid, and pidHarikiri

The integral term is accumulated from an error calculation that applies
the Pterm gain to the control stick value, which is unusual and has been
noted by many people. Apart from that the Iterm calculation is fairly
standard. Note that the integral accumulators are cleared if the gyro rate
exceeds a certain threshold. This is not present in all the PID filters.

The canonical form for Dterm caluclation is based on changes to the
control input, however, commentary in the Wikipedia article suggests that
basing the Dterm on the changes in the measured value (gyro rate, in our
situation) is equally valid and may result in fewer issues with sudden large
changes in value. This PID filter follows that advice and averages the
recent changes in gyro rate to produce the Dterm.

The canonical form relies on dT to calculate both the Iterm and Dterm - this
filter does not take dT into account, making it sensitive to loop time, as
has been observed.


Filter 1 - pidRewrite:

This filter essentially matches the canonical form: loop time is included in
the Iterm and Dterm calculations, the gain values are only applied to the
terms they are associated with, and the Dterm is calculated from the canonical
error term, rather than the changes in gyro rate. Note that this is the reason
for the difference in sign where the Dterm is summed into the final PID output.


Filter 2 - pidLuxFloat:

This filter also matches the canonical form, with the difference being that the
Dterm is calculated from the changes in gyro rate rather than the canonical
error term.


Filters 3-5 are all similar in structure in that they break out the yaw
calculation from the calculations for pitch and roll. This probably accounts
for some of the very different yaw behavior seen with these filters.


Filter 3 - pidMultiWii23:

There is no accounting for cycle time in this filter.

Pitch and Roll:

Caculation of the Pterm is closer to the canonical form, except that the static
P gain is applied to the stick conrol input and the dynamic P gain is applied to
the gyro rate. The Iterm is calculated in the canonical form, and here we also
see the integral accumulators being cleared if the gyro rate exceeds a threshold
value. The Dterm is calculated using the change in gyro rate, just as it found
in PID filters 0 and 1.

Yaw:

Calculations for the yaw axis start out to be canonical in approach, with the
twist that the yaw integral accumulator is cleared if the yaw stick input exceeds
a threshold value. The final calculation of the yaw axis PID filter has some
unique features. First, the D gain term is used to derive a limit taht is applied
to the Pterm, and second, the yaw axis integral accumlator has a second limit
applied to it (in addtion to the anti-windup limit applied earlier) before being
summed in the the PID filter output.


Filter 4 - pidMultiWiiHybrid:

There is no accounting for cyle time in this filter.

Pitch and Roll:

This filter uses the same approach for these axes as is found in pidMultiWii - the
only difference is found in the calculation of the yaw axis filter.

Yaw:

The yaw axis filter is the same as found in the pidMultiWii23 filter.

So, the hybrid filter combines elements of the original pidMultiWiil filter and
the newer pidMultiWii23 filter.


Filter 5 - pidHarakiri:

This filter accounts for cycle time in the Iterm and Dterm calculations for the
pitch and roll axes. It accounts for cycle time in the Iterm calculation for
the yaw axis.

Pitch and Roll:

The Pterm calculation looks like it was adapted from the original pidMultiWii
code - the dynamic P gain is applied only to the gyro rate term, not to the
difference between stick input and gyro rate.

The Iterm calculation looks like it was adapted from the original pidMultiWii
code - the calculation involves botht the P gain and Igain, while adding the
compensation for cycle time.

The Dterm calculation also is the same as that found in the original
pidMultiWii code, with the addition of the cycle time compensation.

Yaw:

The code has two variants of the yaw filter, but it appears that option is
hardwired ("if (OLD_YAW)") to use only the first variant.

The Pterm calculation quite complicated in that the

is structured the same as that for pitch and roll, in that the P gain is scaled
by a factor dependent on the stick command (larger stick input results in smaller
P gain), and then is applied to the gyro rate, but not the difference between
the stick input and gyro rate.

As in the original pidMultiWii code, the error term accumulated by the integral
calculation includes the P gain applied to the stick input. The integral
accumlator is cleared if either the stick input or the gyro rate exceed certain
thresholds. Also, as is found in the yaw filter portion of the pidMultiWii23 code,
constraints are applied twice to the Iterm value.

Also as found in the pidMultiWii23 and the pidMultiWiiHybrid codes, the D gain is
used to determine a limit applied to the Pterm value.


Summary:

I would expect that pidRewrite and pidLuxFloat are tunable in the most
straightforward fashion because they are closes to the canonical PID structure.

Including both the P gain and I gain in the Iterm calculation, as found in
pidMultiWii, pidMultiWiiHybrid, and pidHarikiri probably add to some difficulty
in tuning for pitch and roll, but I think also make it harder to predict how
the craft will respond in various flight situations.

pidMultiWii23, pidMultiWiiHybrid, and pidHarikiri all have similar and complex
yaw filter structures, which might explain the improved yaw performance seen
by pilots who have tried these codes.
Klik om te vergroten...
 
Interessant Boris die analyse.
Sowieso superbedankt voor al je info hier!

Herken jij dit uit de tests die je gedraaid hebt?

Die opmerking over Yaw bij de summary heb ik hier wel een paar keer langs zien komen volgens mij, maar ik weet niet meer bij welke PID controllers.
 
fieliep zei:
Interessant Boris die analyse.
Sowieso superbedankt voor al je info hier!

Herken jij dit uit de tests die je gedraaid hebt?

Die opmerking over Yaw bij de summary heb ik hier wel een paar keer langs zien komen volgens mij, maar ik weet niet meer bij welke PID controllers.
Klik om te vergroten...
ja heel toevallig was ik nu ook fan van 1 en 3 voor acro mode[emoji1]
 
Hi Boris, thanx voor de insights. Dat is best wel hogere wiskunde en dat moet ik denk ik 10x lezen en dan begrijp ik het nog maar een beetje. Ik wist niet dat er nog zoveel verschil zat in de verschillende multiwii PC's. Rewrite betekent dus iets anders dan refactor, bad assumption on my side. Ik ga er eens mee spelen. pid1 en 3 dus voor acro? luxfloat toch niet goed?

hopen dat het weer dit weekend beetje ok is....
 
THCM13 zei:
Hi Boris, thanx voor de insights. Dat is best wel hogere wiskunde en dat moet ik denk ik 10x lezen en dan begrijp ik het nog maar een beetje. Ik wist niet dat er nog zoveel verschil zat in de verschillende multiwii PC's. Rewrite betekent dus iets anders dan refactor, bad assumption on my side. Ik ga er eens mee spelen. pid1 en 3 dus voor acro? luxfloat toch niet goed?

hopen dat het weer dit weekend beetje ok is....
Klik om te vergroten...
oh sorry....ik bedoelde 1 en 2 boven.

maar 1,2,3 en 5 zijn de beste.

2(luxfloat) heeft wel een kleine drift issue eat bijna niet voelbaar is, maar zal opgelost worden hopelijk.

1 is gewoon strak en goed.

3 is erg snappy en zeker de yaw. Bij deze val je stijl achterovef als je de yaw probeert. Ik wist niet dat multirotors zo konden yawen toen ik deze probeerde

5 Deze is vergelijkbaar met default, maar heeft veel betere yaw en level en horizon mode.

Het is een beetje persoonlijk nu dus wat je het meest aanspreekt.
 
BorisB zei:
ja heel toevallig was ik nu ook fan van 1 en 3 voor acro mode[emoji1]
Klik om te vergroten...

Thx Boris,

Krijg een dezer dagen een Mullet (Naze clone) binnen.
Dan zal ik eens beginnen met 1 en daarna 3.

Stap over van een KK2.1.5 en wil gelijk naar Cleanflight gaan.
Dus dat wordt flink uitzoeken en veel leren.
Ga een eind komen met de info uit dit draadje!
 
BorisB zei:
oh sorry....ik bedoelde 1 en 2 boven.

maar 1,2,3 en 5 zijn de beste.

2(luxfloat) heeft wel een kleine drift issue eat bijna niet voelbaar is, maar zal opgelost worden hopelijk.

1 is gewoon strak en goed.

3 is erg snappy en zeker de yaw. Bij deze val je stijl achterovef als je de yaw probeert. Ik wist niet dat multirotors zo konden yawen toen ik deze probeerde

5 Deze is vergelijkbaar met default, maar heeft veel betere yaw en level en horizon mode.

Het is een beetje persoonlijk nu dus wat je het meest aanspreekt.
Klik om te vergroten...

no problem, just checking, thanx! Ik denk dat ik nog niet toe ben aan waardeoordelen, maar zal mijn mening geven. :oops:
 
Laatste 23 Feb Harakiri Fix en er komen steeds meer aan. Er komt een nieuwe autotune hiervoor (gtune)
De PID algorythmes werken nu wel super :D
 
Laatst bewerkt door een moderator:
ok, dat ziet er echt heeeel strak en snel uit :D kan er uren naar kijken

*harakiri aan lijstje te testen PID's toegevoegd*
 
THCM13 zei:
ok, dat ziet er echt heeeel strak en snel uit :D kan er uren naar kijken

*harakiri aan lijstje te testen PID's toegevoegd*
Klik om te vergroten...
[emoji1] thanks. garage is altijd fun. Het is moeilijk maar leuk als het allemaal goed gaat.
fieliep zei:
Harakiri nu ook bij de favorieten Boris?
Super strak gevlogen, lijkt elk filmpje weer sneller te gaan!
Klik om te vergroten...
Yup de laatste fixes zijn toch een success
Let wel op de rates moeten wat lager op deze. Flips en rolls gaan wat sneller dan met de andere pid controllers.
 
ik volg dit topic al een tijd, net als velen denk ik,
nu lees ik dat pid controller 1 beter is dan de default 0.
als ik de controller van 0 naar 1 zet in de cli, kan ik dan de pid waardes aanhouden van controller 0?
of is het wijs om weer vanaf standaard pids te gaan tunen (of autotune) ?

groet van ed
 
denof zei:
ik volg dit topic al een tijd, net als velen denk ik,
nu lees ik dat pid controller 1 beter is dan de default 0.
als ik de controller van 0 naar 1 zet in de cli, kan ik dan de pid waardes aanhouden van controller 0?
of is het wijs om weer vanaf standaard pids te gaan tunen (of autotune) ?

groet van ed
Klik om te vergroten...
toevallig heeft pid1 wat hogere pids dus in jou geval zal het goed komen.
Ga je andere gebruiken kan het weer lager uitvallen.
Beste is opnieuw afstellen.
 
hey boys,

ik ben hier terecht gekomen omdat ik sinds heden een naze32 om mn flip260 heb gemonteerd.
daarna Cleanflight erop gezet. kan iemand mij een lijst met waardes voor in de naze32 of tips tonen om dit allemaal goed te krijgen.
vlieg met 4S 1300 en 4S 1600mah en 4x5 props
full


alle tips zijn welkom
 
Laatst bewerkt door een moderator:
Bedankt boris, ik twijfel nog, daar ik nogal graag in horizon vlieg ben ik benieuwd welke pid controller jullie zouden gebruiken. Ik vlieg nog maar kort fpv, dus vind de stabie functie nogal fijn momenteel.
Welke raden jullie mij aan? Pid 5 of 1?

Groet van ed
 
Weet iemand hoe ik dit kan oplossen met quad wilt nog wel eens sterk een kant optrekken bij vol gas.

Gebruik oneshot+pidcontroller 2 en cleanflight
 
You must log in or register to reply here.
Back
Top