Multicopter Control Architecture - design choices

There was some questions about control architecture over on the discord, it was suggested that we move the conversation over here for better visibility.

From user: RajKumar

Hi all, I have few doubts regarding the multicopter control architecture(attached image):

  1. Why angle and its rate controller are implemented at different frequency(i.e. 250 & 1000Hz respectively)? But, We can find position and its rate controller are implemented at same frequency(i.e. 50 Hz)

  2. Why angle and its rate controller are implemented as P-PID controller? Why not PI-PID or PID-PID?

Further to the original post, I would be interested to understand the real world benefits of the high speed rate loops. I would like to move towards a similar scheme in AP, but its hard to quantify the benefit for what would be quite a extensive re-work. I would like to think it would make tuning quite a bit easier but is that true even for big vehicles using “slow” PWM control? How does is the change in rates between the loops handled? Do slower loops have to be at a multiple of the fast loop? Is the rate demand constant until the angle controller gets round to its update or is there some filtering?

In a cascaded control architecture like we have here, each loop has the responsibility to stabilize some vehicle dynamics. The most inner loop (angular rate) stabilizes the angular rate of the drone, which is a “fast” system (the dominant time constant depends on the inertia of the drone and the motor response time but is usually < 0.05s). In order to obtain a tight tracking, the controller needs to run fast, otherwise the control delay will quickly limit the loop gain and the stability of the rate loop.

As you go into outer loops, the dynamics you’re trying to control are slower and slower. This means that even if you could just run all the loops at 1kHz, it would be a waste of CPU. Also, the attitude, velocity and position “measurements” are coming from an estimator, so setting the estimator to output 1kHz data is also not reasonable.

In summary, there is a minimum update frequency due to the vehicle dynamics, but we also want to avoid to run them too fast to save some CPU time (and you probably don’t see any difference if you run the position loop at 50 or 1000Hz).

The integrator in the PID is only needed when it needs to fight against external disturbances. Those disturbances are mainly due to air drag and wind: torques and forces (in physics, every action is generated by a torque or a force). This means that if the angular rate controller has an integrator (no steady-state offset), there will never be an attitude offset, because any attitude error will generate a non-zero rate command and the resulting angular rate will remove the attitude offset (there is already “naturally” an integrator in the vehicle dynamics between “angular rates” ant “attitude”(type 1 system)).

The only reason one would require an additional integrator in the attitude or position control is to remove the tracking error when following a ramp.

(image from Steady-State error – Control Systems – dademuchconnection)