Difference between revisions of "F13: Quadcopter"

Revision as of 00:51, 8 December 2013

Grading Criteria

Quadcopter

Abstract

The Quadcopter is a four rotor remote controlled aircraft. It takes in remote commands from a hobbyest remote control, and achieves steady flight by utilizing a 3 axis accelerometer and a 3 axis gyroscope to determine the current attitude. It then takes the values from the remote control, and current attitude, and determines the needed changes to the motors to achieve the desired flight.

Objectives & Introduction

Objectives

The objective of this project is to build a remote controlled quadcopter that is capable stable flight. We will control the quadcopter via a Spektrum DX5E hobbyist controller. We will be creating an Inertial Measurement Unit(IMU) using a 3 axis accelerometer and a 3 axis gyroscope. The IMU will communicate with the SJ One Board via I2C. We will be implementing a complementary filter in software to estimate the quadcopter attitude, and will then have a PID control loop in software to generate outputs to the motors.

Introduction

Before we get started, we must first define a few aircraft terms, and describe how they are manifested on the quadcopter.

Aircraft Motion Primer

The motion of an aircraft can be described by three types of motion: Roll, Pitch and Yaw.

Roll is the rotation of the aircraft around the x axis and makes the aircraft turn left and right. Pitch is rotation about the Y axis, and in an airplane causes the aircraft to climb and dive. On a quadcopter, the pitch controls going forward and backward. Yaw is defined by rotation about the Z axis.

On a quadcopter, two of the rotors move in a counter-clockwise motion, and two move in a clockwise motion. The opposite rotation will allow for flight without uncontrollable yaw due to the angular momentum of the motor/propeller assemblies canceling each other out. Vertical motion is controlled by the motor speed for all rotors. Moving forward/backward is caused by pitching forward or pitching backward. To pitch forward, speed up the rear prop, and slow down the front prop. To pitch backward speed up the front rotor, and slow down the back rotor. To roll left, speed up the right rotor, while slowing down the left rotor. To roll right, speed up the left rotor, while slowing down the right rotor. To Yaw right, speed up both the left and right rotors, while slowing down the front and back rotors. To yaw left, speed up the front and back rotors, and slow down the left and right rotors.

Team Members & Responsibilities

• Craig Farless
  • Airframe Design
  • Sensor Design
  • Remote Control Interface Design
  • Flight Controller Software Design

Schedule

Parts List & Cost

The table below summarizes the parts used and the cost for the Quadcopter project.

Design & Implementation

Hardware Design

The quadcopter consists of two main groups: the airframe, and the flight controller subsystem. The airframe consists of arms of 1/2 inch aluminum trim channel arms, sandwiched by 1/16 inch aluminum diamond plate. The assembled airframe is show below.

The quadcopter project flight controller subsystem block diagram is shown below. The major components are the SJ One board, the remote RX, the quad 2 input or gate, the accelerometer, the gyroscope, and the magnetometer, the 4 ESC modules, and the motors connected to the ESCs.

The quadcopter power distribution diagram is shown below. All power comes from the on board 3S 4000mAh 25C Lithium Polymer battery. The battery puts out 11.1V nominal, and the ESC takes in the 11.1V and outputs a 5V output for use by the rest of the flight controller. The SJ One board takes in the 5V and creates 3.3V to be used by the rest of the components.

Hardware Interface

PWM In From Remote Ctrl

The DX5e on board receiver outputs 5 channels of PWM input running at a 50Hz refresh rate. The voltage levels of the PWM in are 5V. The SJ One board is not 5V tolerant, and there are not 5 channels of input capture pins available. In order to get the values requested by the remote control, one needs to translate the voltage levels to 3.3V, and to try to combine the signals to a single input. After researching on line, an example design was found that took the 5 channels of input and or'ed all of them together to get a single pulse train out. The example design also suggested a 5V tolerant part that would output 3.3V. After investigating the hardware that is used on the Quadcopter project, it was decided that this could work. A logic analyzer capture of the receiver output is shown below, as well as the output of the or gate. As is shown, the pulse train does not overlap, so the or gate is sufficient to handle both the level shift to 3.3V and the combining of signals.

Below is a logical representation of how the or gate is wired.

PWM Out

Quadcopters by nature need fast refresh rate on current position, and need low latency thru the control loop to actual commands to the motors. To help keep the latency low, the output PWM was ran at a faster than normal rate. The output PWM is running at 400hz instead of the normal 50hz refresh rate. The minimum pulse width is approx 1ms and the maximum pulse width is about 2 ms.

I2C Sensor Bus

The sensors all run off of a single I2C bus. The accelerometers base address is 0xE5, the magnetometer base address is 0x48, and the gyroscope base address is 0xD3. The I2C bus clock rate is 400kHz to help minimize the control loop latency.

Software Design & Implementation

The top level software block diagram is shown below. The quadcopter project utilized free RTOS to help with scheduling. The following sections will go into the details on each block shown.

RX Capture ISR

The PWM input is connected to Capture pin CAP1.1 on gpio P1.19. The CAP input is setup to trigger an interrupt on each rising edge and each falling edge of the input PWM pulse train. The TIMER1_IRQHandler is setup to give a semaphore to get_remote_ctrl_values task, and then quickly clears the current interrupt. The get_remote_ctrl_values task is shown in the block diagram below.

Remote Command Translator

I2C Driver

Data Smoothing

Due to vibrational noise, an additional lowpass filter was added before the sensor fusion and after the I2C input. The filter acts on the raw sensor data after it has been scaled correctly. The code for the filter is quite simple:

smoothed_value = smoothed_value + alpha * (input - smoothed_value);

There is very little latency thru the filter, and it really seemed to help with data noise.

Sensor Fusion

Sensor fusion is the act of taking reading from two or more sensors, and combining them in a meaning full way. Sensor fusion is used in this case because we are taking data from a noisy accelerometer, and from a gyro scope that shows accumulated error on readings over a long time (more than a sec). We combine them such that we are taking the stable instantaneous values from the gyro and combining them with the stable over a long period values from the accelerometer. We manage this via a Complementary Filter. A complementary sends the angle values from both the accelerometer and the gyroscope and low pass filters the accelerometer,and high pass filters the integrated angular velocity from the gyroscope. See the figure below.

This function can be implemented in a couple of lines of code for each axis.

// Complementary Filter Implementation

filtered_angle = (A)*(filtered_angle+gyro_rate*dt);

filtered_angle += (1-A)*acc_angle;

There is a complementary filter for both the X and the Y axis. It was decided as the project was winding down to not implement yaw control due to schedule constraints. When there is time, there will be a complementary filter taking in gyro values and values from magnetometer to measure yaw and feed that into an additional PID stage.

PID

PWM Out

The error values out of the PID section are applied directly to the PWM pulse width math. See the code below:

           motor_front_sum = throttle_in +  error_in.errorX;
           motor_back_sum  = throttle_in + -error_in.errorX;
           motor_left_sum  = throttle_in +  error_in.errorY;
           motor_right_sum = throttle_in + -error_in.errorY;

Note, what was added to one half of front/back is subtracted from the other half. Same holds true for the left/right pair. The design also has limitations of pulse widths min and max to make sure not to disable the motors. If the throttle in + error is larger than the max value for pulse width, it clips at the max value. The same is true if throttle in + error is less than min pulse width. It holds the minimum value.

Testing & Technical Challenges

Testing

The first testing attempted was I2C read/write testing. Once the sensors were wired up, a quick while loop with a delay was implemented to show that the sensors could be read reliably.

The next portion of testing was the PWM input testing. This took a while to get right due to ISR issues. Once the ISR was working, it was possible to printf the pulsewidth values calculated and compare to what the input controls were set to.

Technical Challenges

One of the largest technical challenges found was getting the PWM input ISR to not crash the processor, and to operate correctly. After long hours of debugging it was found that there was a low level driver that was using the same timer interrupt. Once this was solved, the development went a lot smoother, and we were able to reliably receive the commands from the remote control, and have the flight control software act upon these commands.

The largest technical challenge found is only partly overcome. There seem to be some issues with the data coming out of the sensors. In an attempt to clean this up, there was some additional data smoothing added to both the gyro output and the accel output. This did help the stability of the flight correction, but there are still issues.

Another technical challenge found was the process of tuning the PID gain values. This will continue to be a work in progress until the sensor reads are clean and accurate.

Describe the challenges of your project. What advise would you give yourself or someone else if your project can be started from scratch again? Make a smooth transition to testing section and described what it took to test your project.

Include sub-sections that list out a problem and solution, such as:

Wifi Connection Issues

Many wifi connection issues were encountered. To solve this problem, a dedicated task was created to re-connect to wifi if the connection was ever lost.

Conclusion

The quadcopter was a very challenging project. While I was not able to achieve the stable flight I had been hoping for, the quadcopter did fly. The project was a great learning experience. I learned a lot about the LPC1758. I learned a lot about interrupt service routines. I learned a lot about IMU's and flight control software. I learned a lot about how to implement and tune a PID control loop.

The next steps for the quadcopter project will be to continue attempting to clean up the data from the sensors. There may be some issues with noise and or discontinuities. This will be facilitated by getting data logging to the mico SD card working. I will then be able to characterize any data problems off line via matlab, and target filtering and or changes to sensor reads to fix the issues.

Project Video

Upload a video of your project and post the link here.

Project Source Code

Send me your zipped source code and I will upload this to SourceForge and link it for you.

References

Acknowledgement

I would like to acknowledge and thank my patient wife for putting up with all the time spent on the project.

I would like to acknowledge and thank Brandon for loaning me his logic analyzer.

I would like to acknowledge and thank Rob for lending me his RC expertise, and answering all of my silly questions.

I would like to acknowledge and thank Preet for the help with the ISR issues encountered.

References Used

http://nicisdigital.wordpress.com/category/quadcopter/

http://web.mit.edu/scolton/www/filter.pdf

http://theboredengineers.com/2012/05/the-quadcopter-basics/

http://theboredengineers.com/2012/05/the-quadcopter-part-1-genesis-of-the-project/

http://www.instructables.com/id/RC-Quadrotor-Helicopter/?ALLSTEPS

http://blog.oscarliang.net/quadcopter-pid-explained-tuning/

Appendix

You can list the references you used.