## Beginning the PID Control

Now we have access to the input from the RC receiver, and the current orientation from the gyro and accelerometer, the next big hurdle is to actually process these into motor outputs.

Now the algorithm for the job is called a proportional integral derivative controller, or a PID loop. There is plenty of stuff out there on this, but basically it takes the desired value (setpoint), and the actual value (input), calculates the error value and then puts this through 3 different terms to calculate an output.

Here’s a diagram explaining this:

(continued)

Right, with the sensors (nearly) sorted out, I hope, I’m moving on to the next bit of the programming: the input from the RC receiver – the little board that receives the radio signal from the transmitter.

Here’s mine, a cheap one from HobbyKing, where most of my other stuff comes from too:

There are 6 channels of information: Throttle, Yaw (Rudder), Pitch (Elevator), Roll (Aileron), and 2 knobs that act as auxiliary channels. The receiver gets these from 2.4Ghz radio waves sent by the transmitter, and converts them into digital PWM signals to send on the flight controller via wires.
(continued)

## Starting to Implement the RTIMULib Library

I’ve continued to work on the example sketch provided for RTIMULib (as referenced in my previous post). As stands, the sketch is quite cryptic and roundabout, so I’ve made an effort to clean it up and split the code up more.

The sketch used to just print off the fused pose data over serial, but now I’ve actually made a function that, when called, will return the current Euler angles, pressure and temperature recorded by (and fused from) the IMU.

Firstly, I had to find a way of setting all 5 of these values from inside a callable function. Now I could just use global variables – and may still do, if this seems easier – but that doesn’t seem like a very clean or efficient way to do it to me.
(continued)

## IMU Readings and Sensor Fusion

I’ve been having a look at ways to read the raw sensor data from the IMU and translate it into an absolute orientation estimate.

Here’s the problem.

Accelerometers measure forces of acceleration, so that when the board accelerates, it knows. Gravity is a force of acceleration (9.8ms-2, or 1g, towards the earth), so by combining the X,Y and Z vectors of the reading of a stationary accelerometer we can work out the direction of gravity, and hence the orientation of the board.

But as soon as you start moving the accelerometer – as will, of course, happen a lot in a flying quadcopter – it picks up these lateral forces of acceleration as well as the force of gravity (and vibrations affect it too, which are just very fast lateral movements).
(continued)