Quadcopter Build Log
This document captures all the relevant efforts that were made in construction of this quadcopter. The timeframe of the project is January 2011 to April2011.
This document captures all the relevant efforts that were made in construction of this quadcopter. The timeframe of the project is January 2011 to April2011.
The Arduino platform is selected for this project, mainly due to its open software and hardware nature which has resulted in availability of extensive technical information. As a result there are many tutorials and example project available for this platform. A list of arduino boards can be found here. Many of these boards including Arduino Uno and Arduino Mega are perfectly capable of flying a quad copter. In this project, the Arduino compatible Seeeduino board is used; specifically, Seeeduino Mega v1.1 mainly since it was available at hand. This was an intentional design constraint based on the purpose of this project as a test run for a future class offering of the mechatronics class - to use a different controller would obsolete much of the hardware available for the class.
Many electric devices such as blow dryer and CPU fan use brushed direct current (DC) motors. They are called brushed since they use a carbon brush to keep the current flowing into the rotating section (called shaft or rotor) inside the motor. We use four brushless DC motors, specifically this motor. 10g brushless Brushless motors are more suitable for this project since they deliver much higher revolutions per minute (RPM). Since they dont use brush to deliver current to the shaft, there is much less friction; therefore, they are much more efficient and can produce more torque. There is some variation between motors, following some advice on the internet we ordered an extra one and were glad we did. The speed variation was annoying, but the benefit really came out in one of the crashes!
Four Turnigy plush 6amp brushless speed controllers (Plush 6A) are used in this project. Plush 6A
The initial propeller attempt was a 4.5x4.5E two bladed propeller. This is well below the motor specification size recommended on the website of the supplier, which called for a 7x5E propeller. The motors would not even spin this large propeller, though, so it can only be concluded that the website specification is incorrect. The propeller tests were completed by attaching the airframe and motors to a weight, and placing this weight on a scale. The weight used was approximately the diameter of the arduino board, so airflow characteristics should be comparable to those during flight. The initial weight of the airframe, motors, arduino, ESCs, battery monitor, plus the weight, was 1763g. This was well above what the motors could be expected to lift, so the total lift was calculated as the difference between initial weight (with the motors stopped) and final weight (with the motors at full power.)Here is a video demonstrating a test using this technique:
Initial weight at 4.5x4.5E 1763g final weight 1400g
for a total thrust of 363g. This quickly falls off as the battery drains, so subsequent tests are to be completed only on a fully charged battery.
For additional test propellers, in most cases there is only a single propeller available. It is not feasible to run only one motor, because the tether to the weight is fixed and a single motor does not provide lift as much as it simply changes the balance and threatens to topple the weight. To address this, additional propeller tests are accomplished by means of running two opposing motors, but with only one new propeller attached. Since the difference in thrust of a propeller change will be a fractional proportion of the total lift, the lowest final weight will be presumed to be the propeller with most lift. First, the original 4.5x4.5E propellers are run in this configuration. Initial weight at 4.5x4.5E 1763g final weight, two motors 1547g thrust = 216g
Next, one of the propeller was replaced with a 8x4.5E two bladed propeller.
* PROBLEM* one of the 8x4.5 props is contra-rotating! It pushes down. Had to try the other prop.
Initial weight 1765g final weight 1532g thrust = 233g
Not that much benefit and we can't actually use 4 8 inch props on the current frame because they will interfere with each other.
Next, one propeller was replaced with a 3 bladed 5 inch with less pitch (labelled GWS EP-5030x3)
initial weight 1762g final weight 1515g thrust = 247g
Next the orange 6 inch propeller was run (GWS EP-6030) initial weight 1766g final weight 1530g thrust = 236g Of course, there is a confound between prop size and pitch. It is unknown what a 4.5 pitch 6 inch prop would do, and since the specification cannot be trusted, it is unclear which is preferred by this motor.
Finally, the GWS EP-4025 was run.
Initial weight 1765g final weight 1536g thrust = 229g
The 5 inch 3-blade propeller seems to be the best performer for the size. The shallower pitch also seems to be an advantage. It is possible that these motors simply do not have sufficient torque to drive a higher pitch propeller.
Four 3 bladed 5 inch props with a 3.0 inch pitch. Model GWS EP-5030x3
Initial weight 1758g
final weight 1290g
(first pulse, quickly drops to around 1370g sustained)
thrust = 468g (peak) 388g (sustained)
The goal is to get to lift capability with a maximum of 90% of motor thrust for a sustained period so that the remaining 10% of capacity can be used for manoeuvring. This will be documented in the battery section.
A Rhino 610mAh 3S 11.1v 20C Lipoly Pack is used that was purchased from hobby king.
This is the first frame attempt and is made from 1/2 inch wide, 1/16th inch thick aluminum, in two 11" sections. The length is based on the propeller size of 4.5" originally planned and constrained the test of larger propellers. The frame sections are joined by cutting out a section of each frame in the centre, to halfway down the frame, and joining the two sections with a small bolt and nut. This frame is very rigid and sturdy. The motors connect to it with two small bolts and nuts. It is heavier than is desirable, though. The complete frame, with motors and ESCs and battery and Arduino weighs 303g. The following images illustrate the frame construction.
This frame is cut out of one inch thick pink styrofoam.
The pattern on the right is drawn on the styrofoam and cut with the hot wire.
For the purpose of this documentation, we name this design four leaved clover frame.
1. Drawing the pattern on the one inch thick styrofoam
2. Cutting the styrofoam with hot wire
3.Inside edges are filed smooth to aid air flow
4. Legs are cut out of half circles with diameter of two inches.
5. Aluminium round tubes that are used for mounting the motors.
6. Aluminium tube sitting on the leg piece before gluing the leg to the frame.
7. A small indent is made on the frame body, and on the legs, for the aluminium piece to sit in
8. Glue is applied to the leg piece and the frame
9. Pressure is applied for about an hour to ensure a strong joint
A 9 degree of freedom sensor, which is a board with a magnetometer, accelerometer, and gyro is used on this quadcopter.
Below is a video that shows the first results of integrating the 9D sensor stick into the quadcopter. A software tool called Configurator is used to calibrate the sensors and monitor the readings.
There were some problems with the sensors. The primary one is that although the Arduino must be the largest market for this sensor, the vendor saw fit to release it with I2C pins that did not match the order on the Arduino. This necessited the creation of small jumper wires to reverse the SDA and SCL pins which had the effect of slightly skewing the sensor from the planned square alignment to the Arduino. This had later ramifications in terms of the ability to cleanly separate the channels of sensor data. In addition, the stability of the magnetometer was not ideal. Until code was in place to correct it's drift by means of the accelerometers it was not really usable.
For wireless communication with the quadcopter, a pair of XBee Modules and Arduino XBee Shield were also explored.
The serial connection between the modules can be tested with a blinking LED light.
The following video which is based on this arduino xbee shield tutorial, demonstrates the plug and play functionality of this modules.
In the first iteration of a control strategy, a Wii Nunchuk controller was envisioned as the flight control. This controller, described here, has a 4 way rocker on top and two buttons on the front, as well as 3 degrees of accelerometer. It was planned that the buttons would chord to allow up, down, stop, and start to be conveyed while the rocker would be used for directional control. In a complete and tested system with all stable modes working properly this could be feasible, but it getting to that point this was not nearly enough channels of input to fly the quadcopter. It was an interesting experiment, however, and hooking up the Nunchuk was quite straightforward as the Wii uses I2C for it's controllers!
The four brushless motors on the quadcopter are controlled via an electronic speed controller each. Here is a minimal sketch that uses servo library to control four ESC and the motors connected to them using keyboard. The charachters pressed on the keyboard are passed to Arduino board on the quadcopter via a serial connection. The instruction on how to use this code are documented inside the sketch.
Although the initial integration involved quite a large number of changes, the AeroQuad code kept moving in ways that it was desirable to keep up with. For that reason, the initial strategy of declaring a UVic type and keeping all of our changes in that block was abandoned for the more straightforward approach of modifying one of their types. This allowed us to make only a few changes with each integration into one of their releases. In the end, to integrate into a new release took the following changes:
take over mega_v2 defn - therefore our code changes will break the existing mega_v2
put in mini acc - we use an accelerometer from the Arduino Mini rather than the mega (this was a nice change! In the first build picked up this definition was not there and had to be coded directly from the datasheet. Their definition resolved a troublesome unit conversion bug that had crept into the UVic code.)
change gyro address to 0x68 and change return value for check (because the gyro was on the same I2C port as other devices the sparkfun board chose to put it on a different address
change receiver pin assigments (this differs by each receiver and seems arbitrary. The assignments were found by trial and error in configurator.)
change signs in accel and gyro (because the sensor board was mounted in a different orientation on the 9DOF board than on the shield that the AeroQuad software was designed for, this had to be adjusted.)
As shown in the configurator video above (in the sensors section), the sensors must be calibrated before flight. This allows them to determine where flat and level is and then changes to this during flight result in corrective changes from the motors. Please note that this does NOT correct for a skewed sensor install! This was a point of some pain during this project. Calibration of the gyro and accelerometer was quick and simple, just place the craft flat and press calibrate. Calibration of the magnetometer was a bit more involved because the magnetic field is subject to many non-linear disturbances which outweigh the effects of the earth's magnetic field. The magnetometer is put into calibration mode and the craft rotated through all axes to create a map of magnetometer readings. The software then takes that into account for calculating heading during flight. This does not, however, take into account local magnetic differences during flight - if the pilot were to fly near a large transformer for instance, the heading could be expected to deviate wildly.
The flight controls must also be calibrated. During the previous section the receiver pin assignments were derived from this calibration, but in fact the calibration itself must be performed on a regular basis. Each flight controller has somewhat different characteristics in terms of the maximum and minimum values that it sends, and these appear to be somewhat effected by local conditions as well, so it is useful to calibrate frequently. This just involves turning off the motor power and moving each control stick to the extent of it's travel in each direction.
The electronic speed controllers must also be calibrated. This allows them to adjust for the minimum and maximum levels to be sent to each motor. This was slightly problematic in our case with the one motor running consistently slower than the others. Calibrating the ESCs helped adjust for this but did not entirely resolve the problem. Calibration of the ESCs requires a carefully timed power off of the entire board and then a re-initialization into a calibration mode. Repeatable with some practice, but initially the ESCs could not be calibrated due to an inability to properly follow the directions to remove power.
Here is a checklist of final things to test before moving on to PID tuning and flight.
Tuning of the controller must be done for each individual quad. The specifics of motor speed and size, frame material and balance, and other aspects of the construction mean that a proper PID tuning for one craft will likely not apply to one even slightly different. The tuning process is easiest to explain (and perform!) in the acrobatic mode. The document here goes through a good description of the process. Basically, the terms that control how strongly the motors adjust for a change in orientation away from level are moved upwards until the craft strongly resists these changes. At this point, there is likely some significant oscillation going on, so the term that controls the decay of the response is adjusted until the oscillation goes away. Then the same is done for the other axis. This is all most easily accomplished when the craft is stably held in one hand and the other is used to adjust values. Watch out for the propellers!
Moving on to the stable mode PID tuning is more challenging and is best addressed in the document above.
A good block diagram of the control strategies in the various stability modes can be found here
Most of the experimentation that was done on this quad was in acrobatic mode. The stable mode was never entirely effective, probably due to problems in properly tuning it (and perhaps the aforementioned sensor alignment issue.)
The control strategies for the more complex stability modes are quite interesting. Although not much use was made of them in this project, they are a definite point of future exploration. The strategy that is overtaking all others not just in the AeroQuad project but the other quad designs is a Directional Cosine Matrix (DCM) control strategy. It is beautifully outlined here. This strategy is not quite as effective as Kalman filters, but is much less computationally intensive. A good discussion of the two approaches can be found here
There are very many future directions that this work could take. First, of course, is getting accurate control and tuning of the stability modes. Including the addition of a barometer for altitude heading. Some quads have become very advanced with GPS and onboard vision systems, these approaches generally require more processor resources than could be acommodated by the Mega1280 used in this project, but are potentially interesting avenues to explore in the far future. Seeing the fruition of the Wii nunchuk flight controller strategy on a well-tuned quad would be an exciting first step to a remote controlled camera platform that would be great to experiment with. Having seen the indoor flight arena at ETH Zurich (see here) the fifth and sixth floor atrium areas now covered by paper airplanes could form a fantastic display of autonomous quads that would be both a mechatronics work area and a fantastic advertisement for UVic.