jcg1541

  • **
  • 92
    • Phones, Networks, And The Red Pill
Convert racing controller PIDs to CC3D
« on: January 09, 2022, 10:15:34 pm »

More than 3 different racing flight software in the market have "define" PID_SERVO_MIXER_SCALING 0.7,  PTERM_SCALE 0.032029, etc, vintage scaling in their pid.h .
In the video, the left side is controlled by such a racing controller with those vintage scaling numbers set by a racing champion robot or an anonymous human.
The right side is controlled by a CC3D Atom.
Both sides have identical main blades, RPM, swash mix, servos, tail motor, tail prop, weight, and weight distribution.
With racing controller on the left side, scaled PIDs are 45/118/0 , tail 34/10/28 , seen in configuration dump.
With CC3D on the right side, the true PIDs are 0.002/0.04/0, tail 0.0013/0.003/2.1e-5, seen in Stabilization/Advanced tab.

For gyro-only-control, straight-line flying (the b and c terms in pid2 of Matlab are canceled by zero steering), the conversion is to undo the vintage scaling as so,
Pracing * 0.032029 * 0.7 / 1000 * 2 = Pcc3d   , e.g.   45*0.032029*0.7/1000*2 =  0.002
Iracing   * 0.244381 * 0.7 / 1000 * 2 = Icc3d    , e.g. 118*0.244381*0.7/1000*2 = 0.04
Dracing * 0.000529 * 0.7 / 1000 * 2 = Dcc3d   , e.g.   28*0.000529*0.7/1000*2 = 2.1e-5
. The 1/1000 factor is an emulation of PWM 2000-1000 in racing controllers. The factor 2 is the banking/pitching/yawing force fraction toward mixer signed range, -1 to +1, in CC3D.

 The temperature on the left side is -1 degree Celsius. Even lower temperature of -9 degrees Celsius is on the right side of the video.
« Last Edit: January 22, 2022, 04:14:25 pm by jcg1541 »

Re: Convert racing controller PIDs to CC3D
« Reply #1 on: January 10, 2022, 08:50:20 am »
Just some general musings:

OP/LP tries to create settings that are based on measurement units (e.g. degrees per second, seconds, meters, meters per second per second) and use floating point to allow some of it (e.g. very small numbers).  Even within OP/LP there are simplifications to make e.g. tunings into "unitless" numbers 00-99 (Stabilization -> Use Basic Configuration View).

Even within OP/LP there are multiple forms (maths) of PIDs.  For instance, one of these cannot have a P term of zero, but the other can.  One has a Beta (wind-up decay) term and the other an ILimit (wind-up hard limit) term.  I think that only the ILimit form can "perfectly" compensate for constant drift.

There are other reasonable measurement units like feet and radians.  I don't know that all/many firmwares even try to make their settings based on units.  I would guess that some just use 00-99 or 000-999, at least initially.  Some, like the Fahrenheit temperature scale or qwerty keyboards may be based on their version 1.0, and scale later versions to match that.

Changing "loop times" for those firmwares that use a big loop will change require different PIDs if not internally scaled by loop time.  I would make a guess though that all modern loop-based firmwares scale PIDs by loop time.

Unrelated to your testing and generally invisible, there is a factor of 1000 in internal OP/LP PID calculations that is a relic of integer math beginnings.  Multiply by 1000 at the beginning and divide by 1000 at the end.  Still in the latest next.  Now (unless it is optimized out, which I doubt) it is just a lot (at least 500 times a second times RPY=3 times 4 per call plus a lot of others at lower rates) of useless extra floating point multiplies/divides.  Back of envelope calculation says this is not a noticeable percentage of CPU though...  It is one of the things on my list of things to change, or at least to remember needs changing.  :)
« Last Edit: January 10, 2022, 11:40:40 am by TheOtherCliff »