Info about kp_roll_pitch

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:




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... :)





You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –


  • Jason thank for the reply.
    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.
  • Developer


    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






    Make sure you run test :: tune

    That way you can see the output. I can tune a quad in a few seconds this way.




  • 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.



    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.




This reply was deleted.


DIY Robocars via Twitter
RT @knightsautoteam: Hi @diyrobocars, we are Orlando's first Autonomous racing club and would love your support. We are hosting our first K…
21 hours ago
DIY Robocars via Twitter
RT @Heavy02011: #VirtualRaceLeague: @DIYRobocars Race #14 - #ParkingLotNerds join us January 15th for #AutonomousRacing #RoboRace ⁦@DAVGtec…
DIY Robocars via Twitter
RT @chr1sa: And after that came our races, 50 in all. This battle between these two Russians was the best we've ever seen -- incredible fig…
DIY Robocars via Twitter
RT @chr1sa: Before our @DIYRobocars virtual race this weekend, we had a presentation from the team that won the Indy Autonomous Challenge i…
DIY Drones via Twitter
Dec 12, 2021
DIY Robocars via Twitter
Dec 12, 2021
DIY Robocars via Twitter
RT @chr1sa: Just a week to go before our next @DIYRobocars race at @circuitlaunch, complete with famous Brazilian BBQ. It's free, fun for k…
Dec 4, 2021
DIY Robocars via Twitter
How to use the new @donkey_car graphical UI to edit driving data for better training
Nov 28, 2021
DIY Robocars via Twitter
RT @SmallpixelCar: Wrote a program to find the light positions at @circuitlaunch. Here is the hypothesis of the light locations updating ba…
Nov 26, 2021
DIY Robocars via Twitter
RT @SmallpixelCar: Broke my @HokuyoUsa Lidar today. Luckily the non-cone localization, based on @a1k0n LightSLAM idea, works. It will help…
Nov 25, 2021
DIY Robocars via Twitter
@gclue_akira CC @NVIDIAEmbedded
Nov 23, 2021
DIY Robocars via Twitter
RT @luxonis: OAK-D PoE Autonomous Vehicle (Courtesy of zonyl in our Discord:
Nov 23, 2021
DIY Robocars via Twitter
RT @f1tenth: It is getting dark and rainy on the F1TENTH racetrack in the @LGSVLSimulator. Testing out the new flood lights for the racetra…
Nov 23, 2021
DIY Robocars via Twitter
RT @JoeSpeeds: Live Now! Alex of @IndyAChallenge winning @TU_Muenchen team talking about their racing strategy and open source @OpenRobotic…
Nov 20, 2021
DIY Robocars via Twitter
RT @DAVGtech: Live NOW! Alexander Wischnewski of Indy Autonomous Challenge winning TUM team talking racing @diyrobocars @Heavy02011 @Ottawa…
Nov 20, 2021
DIY Robocars via Twitter
Incredible training performance with Donkeycar
Nov 9, 2021