This project started in 2010, just as quadrotors were starting to become known. Back then it was already possible to download ArduPilot and run it on an Arduino (albeit with a rather expensive shield containing various sensors) but I chose to build this one from the very beginning myself.
The project started with a Wii Motion+ and a few wires bodging it into the parallel port of a PC. The Wii Motion+ contains a 3-axis rate gyro, and the protocol had been reverse engineered so it was then a cheap way of getting hold of such a sensor. It was later complemented by a Wii Nunchuk, which contains 3-axis accelerometer.
The PC was used for prototyping the communication with the sensor and evaluating the suitability of the Wii Motion+ for this sort of application. After a reasonably successful test it was time to step it up a notch.
See the Wii Motion+ in motion. See also the writeup on hackaday.
It was nice to see that this project benefitted from my efforts.
The quadrotor electronics are based around an LPC2103 microcontroller on the header board from Olimex. This is by modern standards a fairly old microcontroller but it is pretty straightforward to work with. It has an ARM7TDMI core and some pretty flexible I/O.
A flight controller needs inputs from sensors and from the radio. It also needs to output signals to the motor controllers (or ESCs as they’re called in the model aviation world). The sensors communicate with I2C and the LPC2103, like many microcontrollers, has dedicated I2C hardware. The radio input requires accurate timing as the radio receiver outputs either PWM or PPM signals. The first version had one physical input per radio channel, so required many interrupt-capable pins and corresponding timers. Later on this was changed to use a CPPM signal from the radio receiver and measuring the timing of consecutive pulses on the same physical input. The outputs are PWM signals, one per motor. In addition there is a UART for programming the microcontroller and for debugging, and ultimately available for talking to a GPS receiver (not installed). The current version also sports a microSD card, which acts as the aircraft’s flight data recorder, or black box. (The microSD card actually is black, unlike real black boxes which are orange.) There are also pins available for communicating with other sensors such as an ultrasound proximity detector (not installed).
Building a frame for this craft was a good way to learn some basic metalwork skills.
The arms are made of a 1 metre long box section extrusion, 11.5mm square made out of 1.5mm thick aluminium. They have a notch cut in the middle where they cross, and the central body consists of a 200x200mm square aluminium plate (also 1.5mm thick) above and below. Holes are drilled in the plates and the arms, and bolts hold the layers together firmly. The motors are attached near the ends of the arms with smaller bolts. Feet are attached to the ends of the arms and a battery holder is attached to the underside. The electronics live on top.
The first version had a protective battery holder. The second version dispensed with this in favour of battery straps.
The length of the metal extrusions determined the overall size - 1 metre diagonally. However, it is more common nowadays to measure the size of a quadrotor from the centre of rotation of one motor to the centre of rotation of the diagonally opposite motor. By this measurement, this quadrotor measures around 945mm although as people tend to round to the nearest 50 this quadrotor is probably best described as a 950 class quad. This makes it much larger than most quadrotors today. The increasing popularity of the 250 class has left even 450 class quadrotors looking a little on the large side.
This quadrotor sports some T-Motor MT2814 motors with 12x4.5 propellers. That’s 12 inches diameter, and a pitch such that in one complete rotation the air would move 4.5 inches under ideal conditions. This combination is capable of producing considerable thrust. Each motor is controlled by a 30 amp ESC. The power is supplied by a 4 cell Lithium Polymer battery, rated 5000mAh, which weighs 0.5kg.
I don’t have accurate measurements for the power consumption in flight but I did take a measurement with the first quadrotor with all four motors at 100% power and the quadrotor strapped down to the ground. With a nearly full battery, I measured a power consumption of 1.5kW.
Perhaps the biggest challenge in controlling a quadrotor is obtaining an accurate estimate of the aircraft’s attitude. This is where the sensors come in. Nevertheless it’s not trivial to get attitude from the sensor readings.
The biggest problem is that the sensors each have their strengths and weaknesses. No one sensor is good enough to provide attitude data on its own. The gyro measures rate of rotation quite accurately but this data must be integrated in order to get an absolute rotation. This integration allows small errors to accumulate, which we call drift.
The accelerometer measures instantaneous acceleration. It measures both regular acceleration and acceleration against gravity. A zero reading from an accelerometer implies that the accelerometer is in freefall, so any force acting on it to counteract that freefall will register as an acceleration. Every small (or large) vibration registers as instantaneous acceleration, which makes accelerometer readings very noisy. We can make the simplifying assumption that the average acceleration (other than that countering gravity) is zero. Over the long term this is a fairly reasonable approximation but of course in the short term it does not hold. If we then take the long term average of the accelerometer readings, this should indicate the acceleration against gravity and serve as an absolute reference for two out of the three axes to determine the craft’s orientation.
Providing the drift from the integrated gyro readings is sufficiently small that the result can be used over the period of twenty or thirty seconds or so, the accelerometer can be used to compensate for the drift and lock the estimate to the absolute orientation measured in the long term by the accelerometer.
The first quadrotor flew for the first time in 2012. This coincided with learning how to fly a quadrotor. Nevertheless, despite a few crashes and rebuilds, it worked reasonably well. But it was not without its problems.
Very occasionally its estimate of the attitude would suddenly shift, usually during another manoeuvre. This was usually something that could be corrected by hovering calmly for 30 seconds while the attitude estimate adjusted itself. However it was possible that it would exceed the control authority available to the pilot, making hovering impossible. In order to debug this problem I had redesigned the I/O assignments to make it possible to attach a microSD card. On the very first day after the road had been cleared towards adding a microSD card for recording the flight data, the bug struck again. This time it far exceeded the control authority and the aircraft quickly passed overhead. Not long afterwards the aircraft ditched in a body of deep water and was never recovered.
In the time that passed during development and the first year of flying the quadrotor, things moved on. The MPU6050 sensor was now readily available at a reasonable price and this was better documented and had fewer quirks that the Wii Motion+. It was possible that one of the quirks of the Wii Motion+ may have been partially responsible for the loss of the first quadrotor and so the second one used the MPU6050 instead. This integrates both a 3-axis gyro and a 3-axis accelerometer into the same device, removing any concern of alignment errors between the two sensors. It took some time to adapt the firmware to use the new sersors. In addition it took considerable time to implement the SD card access routines and the logging system. The second quadrotor did not fly until it was able to log its flight data. I was not willing to lose a second quadrotor to the same bug.
Of course, it took some time before anything similar struck again so that it could be debugged. It was not by any means certain that it would, as the change in sensor could easily have been enough to solve this problem.
But then, one day, it did. Again the error exceeded the control authority and it led to a crash, albeit a much less serious one. But this time I had data.
You can see at around 2:35 into the video that one of the gyro channels saturates. The sets of three bars on the right hand side are the accelerometer (top block) and the gyro (below). This saturation introduces significant errors into the integrated orientation estimate, which is what leads to the crash.
Note that once the quadrotor stops moving, it is actually more or less horizontal. The image of the quadrotor at a funny angle represents the angle that the quadrotor thinks it’s at.
After decreasing the sensitivity of the gyro to allow greater headroom, I’ve not had this type of problem again.
The new quadrotor has sensors on it other than just the MPU6050. None of them actually do anything other than logging to the data recorder, but that logged data can be useful. There is a barometric altimeter on board which is very useful for reviewing flight logs, and there is a 3-axis magnetometer. The mathematics of using magnetometer readings is substantially more hairy than that for the gyro and the accelerometer, and the magnetometer is rather a lot closer to wires carrying tens of amps than I would like, so that is really just there for research purposes right now. The hope is that one day it will be useful to provide an absolute reference for the third orientation axis, yaw. That is required for any sort of automated flight over and above stabilisation.
There is also room for an ultrasonic rangefinder to measure height above the ground when near the ground and a GPS receiver to provide positional information which can be used for flight logging or, more excitingly, for waypoint navigation.
I have now also build a 250 class quadrotor. That one currently has an off the shelf flight controller in it, but I would like to make my own for that too. As a result, I have started work on a flight controller board with a standard form factor. This will be a properly designed PCB and will be much more professional-looking than the hodgepodge of wires, veroboard and gaffer tape that currently resides on the big quadrotor.
There may be more hardware features in the new flight controller, but that will depend on a number of constraints. Watch this space.
The current design is in a form that is very difficult to publish. The software is open source, but is still somewhat tied to this hardware. I would love to open source the hardware as well but that isn’t so easy.
The new flight controller is being designed in KiCad and so it will be much easier to publish those design files.
The software is available here.
I did a talk about this project at EMF in 2014. Watch it below.