Difference between revisions of "S14: Divine WINd"

Revision as of 23:03, 22 May 2014

Grading Criteria

Divine WINd

Abstract

Divine WINd is a quadcopter that focuses on stable flight and simple movement controls. There are two modules in which Divine WINd are composed of: the controller and the quadcopter. The controller module sends a signal to the quadcopter in how the quadcopter's pitch and roll orientation should be set to. The quadcopter's orientation dictates the type of movement the quadcopter will perform.

In order to set to the quadcopter to its desired orientation, an accelerometer and gyrometer are implemented in order to receive the quadcopter's current orientation. The quadcopter will then adjust the speed of its fan blades to balance itself in order to be re-positioned to its the desired orientation.

Objectives & Introduction

Show list of your objectives. This section includes the high level details of your project. You can write about the various sensors or peripherals you used to get your project completed.

Team Members & Responsibilities

• Ryan Marlin
  • (Team role)
• Eriberto Velazquez
  • (Team Role)
• Devin Villarosa
  • (Team Role)

How Quadcopters Fly

All flying machines has three axes of motion: Roll, Pitch, and Yaw. For this design, the quadcopter is only focused in Roll and Pitch. Roll and Pitch movements are enough for basic Quadcopter movements.

Balance is the main importance for flight. A quadcopter has four blades in which two blades spins clockwise and the other two spins counter clockwise. Each pair of blades adjusts its speed to balance out its axis. In order to perform simple movement, the quadcopter must be balanced at a particular orientation in order to move at the desired location

Final Parts List

Schedule

Design & Implementation

The design section can go over your hardware and software design. Organize this section using sub-sections that go over your design and implementation.

Hardware Design

Discuss your hardware design here. Show detailed schematics, and the interface here.

Controller Module

The controller module uses the SJOne's built in accelerometer and Nordic Wireless modules. The user turns the accelerometer in order to move the quadcopter (Forwards, Backwards, Left, Right). The 3 GPIO buttons are used to control the quadcopter's blade speeds. Button 1 is used to increase blade speed (increase altitude), button 2 is used to decrease speed (decrease altitude), and button 3 is used to kill all blades.

Quadcopter Module

The quadcopter is composed of several peripherals.

Inertial measurement unit (IMU) - This module contains a built in Accelerometer and Gyrometer. Using these two sensors, the team is able to determine the quadcopter's orientation.

Nordic Antenna - This on-board module is used to receive the commands sent from the controller.

Electronic Speed Controls (ESC)- This device is used as a medium between the microcontroller and the brushless motors. The ESCs are initially calibrated with a range of PWM signals. After calibration, the ESC's are able to translate the signals to the motor. Additionally, the ESC supplies the necessary current for the motors.

Quadcopter Power Module

In order for the quadcopter to be mobile, a Lipo battery is used. The lipo battery has a 12.1V output. As shown above, through a +5V voltage regulator, the lipo battery powers the SJOne board. Also, the 12.1V is used to power the ESCs and the motors. It is important that a lipo battery is used, because the brushless motors drains at least 20A.

Hardware Interface

In this section, you can describe how your hardware communicates, such as which BUSes used. You can discuss your driver implementation here, such that the Software Design section is isolated to talk about high level workings rather than inner working of your project.

ESC Interface

The SJOne board communicates with the ESCs via PWM. The SJOne's PWM output is connected to the white wire of the ESCs 3 pin input. The ground is connected to the black wire, and the ESCs red wire is left hanging, because it is a 5V output. In order to calibrate the ESCs, so that the ESC can produce the range in which the PWM's duty cycle dictates the rate in which the motor produces, the following steps must take place, depending on the ESC manufacturer.

The following steps are used to calibrate this project's ESC:

1) Disconnect power to the ESC

2) Set PWM to an acceptable ESC frequency (between 100hz - 400hz)

3) Set PWM duty cycle to its maximum rating (99%) (This step simulates using a flight controller's transceiver's throttle to the maximum)

4) Plug power to the ESCs

5) Until ESCs gives "beeping signal" in which it accepted its maximum throttle rating, set PWM to lowest throttle (0%) (This simulates using a flight's controller to its minimum throttle).

6) Wait until ESCs "beeps" to signal that accepted minimum throttle is accepted

7) The ESCs has now internally calibrated its throttle acceptance. The user can now send different duty cycle ratings in order to manipulate all motors.

Inertial Measurement Unit (IMU) Interface

The acceleroeter and gyrometer are packaged in the Sunkee 10DOF 9-axis Attitude Indicator. For this project's application, only the accelerometer and gyrometer are necessary to retrieve the quadcopter's current orientation. Due to this IMU's package, all sensors are tied on the I2C bus and are accessible via I2C.

Wireless Interface

The team decided to use the on board Norton wireless chip found on the SJOne board. This wireless interface is reliable and has enough distance for this project's application

Software Design

Controller Software Design

Quadcopter Software Design

The MPU-9150 consists of a 3-axis accelerometer, 3axis Gyroscope and a 3 axis magnetometer. its a one chip IMU solution with onboard Motion processor for sensor fusion.Though it inherently supports on board Sensor Fusion, the IP is undisclosed. Therefore we used the library for arduino by Pansenti. (https://github.com/Pansenti) The 6 axis sensor fusion (accel+gyro) is done on the MPU and sent to an arduino where the magnetometer data is used for YAW correction. The arduino transmits the orientation data over UART which is recieved by the SJONE for further processing.

For testing, we coded a GUI in python. The code parses the serial data from the arduino and displays the orientation of the IMU in real-time using Vpython.(video and code to be linked).

Software Implementation

Controller Software Implementation

The controller software makes use of the SJONE’s on-board accelerometer and Nordic Wireless capabilities. By interfacing one SJONE board with three external buttons, the controller is able to send commands to a second SJONE board that is mounted on the quadcopter.

The controller operates on a very simple program. It consistently sends new information to the quadcopter based on the controller-board’s orientation, by reading from the accelerometer or the buttons. The external buttons set part of the package that is sent wirelessly, they control the pwm value being sent from the controller. There are a total of three external buttons and their corresponding commands are: lower pwm, increase pwm, or kill-switch. Depending on its orientation, the controller will send one of the following commands to the quadcopter:

• Forward – sent when the controller is tipped forward, causes the quadcopter move in a forward fashion.
• Backward – sent when the controller is tipped backward, causes the quadcopter to reverse.
• Lean right – sent when the controller is tilted to the right, causes the quadcopter to pan to the right.
• Lean left – sent when the controller is tilted to the left, causes the quadcopter to pan to the left.
• Ascend – sent when the “increase pwm” button is pressed, makes the quadcopter ascend.
• Descend – sent by pressing the “decrease pwm” button, makes the quadcopter descend.
• Hover – the default state, causes the quadcopter to hover in place.

The controller forms a wireless packet containing a pwm value and a command, as listed above, unless the kill-switch is in effect. In the case of the kill-switch being activated, the controller sends a pwm value that shuts down the propellers.

Quadcopter Software Implementation

From the previous section, it is possible to see that the controller software sends two values: a pwm motor value which represents the maximum speed of the motors and an orientation value. Therefor the quadcopter software design must incorporate a command decode and wireless receive functionality as well as the balancing algorithm in order to interact with the controller successfully. Our quadcopter software implementation can be divided into two main parts at a high level: an Rx Task and Balancing Task. These tasks must somehow communicate and so we have chosen to implement a queue for communication between the tasks. A top level diagram of this system can be seen below:

As seen in our top level diagram, our on board quadcopter system is composed of two main tasks. However, it is important to note the priority in which these two tasks have been implemented. From a design standpoint it must be the top priority to run the balancing algorithm, or else the quadcopter will simply fall out of the sky. Therefore, the quadcopter balancing task must be given top priority when scheduling the tasks. However, some weight must be given to the Rx task because it is quite important as well. For instance, if a kill command comes in, the quadcopter needs to know quickly. Therefore, after every balancing run, the balancing task will go to sleep for a very short time and the OS will switch to running the Rx task in order to check for new commands.

Now that the top level view is understand a little better, it is possible to focus on the balancing algorithm directly. There are many algorithms to choose from when trying to balance a quadcopter. Due to time constraints and certain hardware problems we encountered, we chose to go with the simplest approach, which is the complementary filter combined with a low pass software filter. The complementary filter can be summarize by the following equation:

angle = (1 - accel_weight)*(angle + gyroData * dt) + (accel_weight * accelData)

where typically accel_weight is a small number, such as .05. This formula basically allows us to use the data from the gyroscope to accurately measure the angle in the short term, but use the accelerometer data for the long run. The reason for this is that at very high speeds, there is quite a bit of vibration from the motors on the quadcopter. This vibration causes quite a bit of noise in accelerometer data and makes it quite untrustworthy in the short term. For instance you might get data value like: 10 10 11 12 52 48 26 13 10 11. This random spike could really mess up your system if you relied solely on the accelerometer data. However, by using the complementary filter, it allows us to smooth the data out. A top level diagram of this system can be described as follows:

Testing & Technical Challenges

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:

Shipping Time

Problem: The first quadcopter kit was shipping from China. This problem may result in a possible 2-4 weeks delay in working on the project.

Solution: In order to place it safe, the team ordered the same kit from an American retailer on Amazon. Additionally, the initial kit from China was delivered 10 days after ordering.

Suggestion: Make sure parts are ordered in America

Shorting Lipo Battery

Problem: The team terminated the battery wires so that powering the quadcopter system will be convenient. When terminating, the power and ground wires touched, causing the Lipo battery to short and break. Lipo batteries are very volatiles and needs to be handled with care.

Solution: Team ordered a higher-grade Lipo battery in order to increase quadcopter's flight time

Suggestion: Make sure that power and ground do not cross

Flimsy Quadcopter Supplies

Problem: ESCs and motors are bound to break. Team ordered an extra ESC online, but of a different brand. This resulted in a stronger ESC, which causes an imbalance when flying the quadcopter and delay in progress.

Solution: Used spare parts from second quadcopter

Suggestion: Order 2 more ESCs and motors of the same brand

Vibration and noise

Problem: The accelerometer is very sensitive to movements. With all four blades spinning at the same time, a significant amount of noise is affecting the accelerometer's readings.

Solution: Used a rubber sheet over the accelerometer to damper the vibration.

Suggestion: Use any type of dampering object. The most popular ones are moon gel or rubber.

Wrong Algorithm Approach

Problem: The team approached the Complementary Filtering Algorithm due to its simplicity and easy implementation. This approach is not suitable for self-balance on a quadcopter due to not being able to adjust balance efficiently.

Solution: Tried to optimize and fine tune the weighting of the algorithm and the PWM acceleration

Suggestion: Use PID algoritm or flight controller

Conclusion

Conclude your project here. You can recap your testing and problems. You should address the "so what" part here to indicate what you ultimately learnt from this project. How has this project increased your knowledge?

Overall, the team was not able to complete the project due to very limited time constraints and the initial approach. The team's approach to use complementary filtering was not suitable for creating a self-balancing quadcopter.

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

Any acknowledgement that you may wish to provide can be included here.

References Used

http://www.pieter-jan.com/node/11

Appendix

You can list the references you used.