# Unbalanced motors, Rate PID & Bandwidth

For a multirotor to fly, the thrust of each motor has to be equal, within certain tolerances. These tolerances depend on the bandwidth of the multirotor which are usually reflected in (well tuned) rate PIDs.

Let me explain:

The rate PIDs are usually tuned to reach the best impulse response which depends on the moment of inertia (radius, mass and mass distribution) and thrust inertia (prop weight, motor power, ESC, etc etc).
Unbalanced motors result in a steady-state error for the rate PID which it has to compensate for using the P and the I terms. Going too high with either term – higher than the multirotor bandwidth can allow – will cause oscillations and instability.

It might seem obvious that unbalanced motors are bad. In the end all motors – even high end ones – tend to have slight Kv differences which results in different thrust for the same PWM input. It happened to me when I last tested my quad – it kept flipping over at launch and I didn’t understand why the PIDs cannot compensate for this. All other quads work and surely they have their own unbalanced motors.

So when I got home I measured the Kv of each motor and I found that one of them is lazier – around 90% thrust compared to the others.

So I fired up the simulator and added some randomness to each motor thrust (between 80% and 120%) and yes – the quad wouldn’t fly. The rate PID was unable to compensate for the difference in thrust. Increasing a lot the P term or a bit the I term stabilized the quad.

So Success!!

But what if I couldn’t increase the P or I because of oscillations? What if my PID was at its limit, stability wise? Then the quad would not be able to fly with this particular combination of motors and moment of inertia.

Seems like a silly conclusion – if the motors are bad the quad will not fly – but I felt like I had some sort of epiphany that the thing responsible to compensate for bad motors is the same thing responsible for fully using the quad bandwidth – so unbalanced motors need some bandwidth margin to allow the PID to compensate for them.

# Multirotor diagram

The new GS node editor is progressing nicely and everything seems to fit. I have data visualization for most types of streams with scopes and FFTs and yesterday I added a map widget to visualize the GPS ECEF location.

On the silkopter brain side I kept having a weird feeling that something is not right, that I cannot model everything with nodes and streams. Since I tend to obsess about finding the correct paradigm to modeling a certain process, I started drawing multirotor diagrams to see if/where I hit a road block. After 6 tries I got this:

(excuse the quality, I got tired of drawing on my galaxy note 4 after the 3rd diagram and went back to paper)

I’ll start from the end – the PIGPIO sink. This takes a PWM stream from the Throttle To PWM node which does exactly what the name says – converts a throttle stream into a PWM stream.

The Throttle stream comes from the motor mixer which uses data from the Multirotor Model Data node (top cloud) to convert a Torque stream and a Force stream into throttle values for each motor. This conversion can be done easily for a certain combination of motors + propellers. It doesn’t have to be very accurate as there are some PIDs before this to compensate.

The Torque stream is calculated by the AV Model node (renamed now to Rate Model) that basically combines a rate PID + a feed forward model using again the top cloudy model data. It takes as inputs an angular velocity stream from the gyro and another angular velocity target stream from the Stability Model and tries to match them. The corrections represent the Torque stream.

The Stability Model node is responsible for matching a given Reference Frame (from the AHRS node) with a target ref frame from the Pilot or Assisted Model Node. The output of the Stability Model Node goes into the Rate Model Node.

The Assisted Model Node is responsible for matching a stream of velocities from the GPS with a target velocity from the Pilot. The velocities include both horizontal and vertical (altitude) components. It’s used to model a very intuitive control scheme – move left at 1m/s, or climb at 2m/s. Its outputs are a ref frame stream for the Stability Model (which will try to match it) and an up force stream fed into the Motor Mixer Node.

The Pilot Node interprets RC inputs (not shown in the diagram) and outputs either a ref frame + up force stream when using rate/stab controls, or a velocity stream when using an assisted control scheme.

So going top-down now :

– The Pilot tells reads RC commands and outputs either low-level rotation+vertical force data or high-level velocity data

– The Assisted Model reads velocity data and tries to match those inputs by changing the orientation and altitude of the quad

– The Stability Model reads orientation data and tries to match it by rotating the quad. It uses a stab PID to do this (until I have a good FF model).

– The Rate Model reads rotation speed and tries to match it by outputting torques. It uses the quad geometry and weight + rotational inertia of the motors + props to figure out how much torque to apply to rotate with a certain speed. Small corrections are done with a rate PID

– The Motor Mixer reads torques and figures out what throttle each motor should have based on the geometry of the quad and power train.

So far this looks like it should work.