Trying to optimize the performance of my copter, I run into the following two variables used by the DCM to correct Gyro drift.
Unfortunately I have no big knowledge of DCM even though I understand the basics.
I'm just trying to understand the importance and the effects of those two variables for the everyday flight.
First of all I see that these are setted by default in the constructor of the DCM to:
_kp_roll_pitch(0.05967)
_ki_roll_pitch(0.00001278)
Then in the init_ardupilot() function they are set to:
// setup DCM for copters:
dcm.kp_roll_pitch(0.12); // higher for quads
dcm.ki_roll_pitch(0.00000319); // 1/4 of the normal rate
Recent changes in the code from Jason have included a function for fast recovery (to avoid drift issues) that sets the dcm.kp_roll_pitch to 0.15 when there is no stick input and back to 0.05967 otherwise.
Now all these settings are a little confusing: the DCM is initialized with 0.05967, then it is set to 0.12 and then the new code switches between 0.05967 and 0.15. But at the moment excluding Jason's function, the value of 0.05967 is never actually used...
I understand that these values are useful to compensate for gyro drift but what I don't understand is how they affect flying behaviour.
What I'm trying to obtain is a good response from the sticks without loosing stability.
At the moment to have a stable quad I have to lower the P value to at least 0.3 (default from ACM coders is 0.54) and rise my D to 0.17 (default is 0.12) otherwise the quad will oscillate (a costant oscillation at abot 2Hz -rough calculation-) This causes a sloppy control, something I would like to avoid.
In Bill's paper it is stated:
"Selection of the weights and gains is a compromise between accuracy and speed of recovery to disturbances. The practical realities of the wind and gyro saturation favor using weights and gains that are large enough to recover in about 10 seconds. In the feedback loop, the DCM algorithm is a nonlinear integrator. Therefore, you can select the gains for the linearized equivalent dynamic model of the complete loop."
Hehe... how do I in practice calculate them?
If I understand correctly Higher gains recover quickly but are less accurate and prone to instability?
Or is it the opposite?
Thank for anyone clarifying this, and sorry for long writing... :)
Cheers,
Emile
Replies
I wish I had a proportional knob on my radio... :)
I can only set three values (three pos switch) like small med and high and see the difference. THen manual tune. At least I can trim the channel to get a little more options...
ANyway _kp_rollpitch 0.12 is what actually the code uses now.
With no modifications, if you look at the function init_ardupilot() it sets it at 0.12 overriding the DCM ctor.
This is why I arouse the question. You are declaring the DCM with a 0.05967 val and then set a 0.12 in the init function.
What should be a good value then? should I go and try the 0.05967.
I'm not sure of the consequences of playin with those values that's why I'm trying to understand effects on flying.
Thanks for your time and wonderful work.
Cheers,
Emile
Emile,
The check_DCM() function is not used right now. It's a work in progress and frankly with the other changes I don't think I need to finish it.
dcm.kp_roll_pitch(0.12); this could be a tad higher. YMMV.
Can you try tunning in the air with Channel 6? In APM_config.h
#define CHANNEL_6_TUNING CH6_STABLIZE_KD
or
#define CHANNEL_6_TUNING CH6_STABLIZE_KP
Make sure you run test :: tune
That way you can see the output. I can tune a quad in a few seconds this way.
Jason
there is another hot spot as well.
very questionable to what an integrator is.
dcm is in essence an 'integrator'.
for the pid calculation omega is used - which is:
omega = dcm.get_gyro();
further more omega is used in the pid calculations.
Vector3f get_gyro(void) {return _omega_integ_corr; } // We return the raw gyro vector corrected for bias
the declaration is as follows:
Vector3f _omega_integ_corr; // Partially corrected Gyro_Vector data - used for centrepetal correction
and is calculated as:
_omega_integ_corr = _gyro_vector + _omega_I; // Used for _centripetal correction (theoretically better than _omega)
and now the question. _omega_i is changed/corrected in two additional steps:
_omega_I += _error_roll_pitch * (_ki_roll_pitch * accel_weight);
_omega_I += _error_yaw * Ki_YAW; // adding yaw correction to integrator correction vector.
these two correction have only an influence in the very next matrix rotation but not the current.
i had to lower the yaw pid settings - because of low frequent oscilations.
now with slightly higher roll_pitch settings these low frequency oscilations are back.
questions:
Vector3f get_gyro(void) {return _omega_integ_corr; } // We return the raw gyro vector corrected for bias
seems to be wrong - better:
Vector3f get_gyro(void) {return _gyro_vector + _omega_I; } // We return the raw gyro vector corrected for bias
with the later modifications all changes for one matrix rotation are taking into account.
why violating the integration principle?
those low frequent oscilations are no fun.
robert