Installing RPIO

RPIO is used to provide the hardware PWM signals to drive the ESCs.

Before you can use any of the Python code for your quadcopter, you need to install and build RPIO:

cd ~
sudo apt-get install gcc python-dev python-setuptools
git clone
sudo python install

Once it’s installed, make sure you have the quadcopter python code from 26 January 2014 (or later) – it includes additional function to stop all the debug logging from RPIO which can inhibit performance and smother your screen with debug logs.

Logging stopped the drone headstand

So I think I’ve found and fixed the cause of the drone headstand.

“You think you’ve found it”, I hear you say? Yes, well, this is through simulation as I don’t want to turn on the motors again without understanding what went wrong.

“Who cares, cuts to the chase!”

The problem is (I suspect) that when the drone tilts by a small amount, the z axis accelerometer starts reading less than the 1g down force set as its PID target on the vertical axis. That’s because the vertical axis and the z accelerometer axis are no longer aligned. So the z PID which takes the z accelerometer as it’s input ups the power to all blades to meet the current vertical axis target. That sets the drone scootling across the floor at an angle and the first impact then triggers the flip into a headstand.

The cause is that the target for the z PID is 1.0g absolute vertical, whereas the input to the PID is < 1g but critically that accelerometer is no longer vertical. But if I use the math(s) I’d found earlier, I have now “normalized” the z-accelerometer output to vertical and am using that as the z input. That was the main cause of the problem.

The noise I mentioned previously is probably not caused by the motors as the accelerometers do fluctuate even when the motors aren’t engaged. That’s not really a problem as long as the PID accounts for it. In this cause, the Z axis PID has too much emphasis on its proportional component (the P in PID) in comparison with the integral component (the I in PID). On the vertical axis, it’s the I component which needs to dominate, since it’s that which will power takeoff and vertical stability at a given height. The X and Y PIDs are the ones handling front / back /left / right tilt balancing.

Having realized that, my simulations are showing much more stable performance, and the few niggles I have are due (I hope) down to flawed simulation, rather than flawed PIDs.

I really am running out of excuses to not just set this thing loose!

“Well get on with it then!”

Not until I can have the largest, tallest room of the house emptied to provide a safe take-off site.

“What’s that room used for normally?”

The kids playroom! Think I’m going to have to take another off work while the kids are at school / nursery!

P.S. Processing the simulation results was greatly improved by adding a second handler to my logging. Now each diagnostic log can be written both the file and console. All that’s written to file are diagnostic stats, which then are fed into Excel LibreOffice spreadsheet to churn out some graphs. Compare and contrast the starting, and ending position of these this test. Notice the chaos ending in flat-lining on the before run? (The four lines on each graph represent the power (in PWM ratio units) applied to each motor).

Before PID tweaking

Before PID tweaking

After PID tweaking

After PID tweaking