ZERO - PIDs Tuner for Multirotors

This topic is about PID auto tuning algorithm that can tune your Quadcopter from PIDs ZERO as a start value.

Introduction

       Adjusting PIDs is a problem for many of Quadcopter’ pilots, it would be nice to get your quadcopter to adjust PIDs for itself. I made some investigation in this area, and found many complex algorithms that are related to Adaptive PIDs, and Fuzzy Logic. Although my background is engineering but I don’t like complex math when you can make simple solutions :)


        I started with multiwii version 2.3, I chose it because its code is not that complex, while it has many GUI tools and debug facilities to trace, and it has one of the largest community that can test and verify the results. Anyway I have developed a new mode that I called G_TUNE, which enables quadcopter to calculate flyable PIDs values for ACRO mode. i.e. PIDs for GYRO.

How to Use

        G_Tune mode starts by resetting all Gyro' PIDs for Roll, Pitch & Yaw to Zero’s.  Then pilot needs to takeoff !!  yes it will take off as the algorithm will start instantly to correct errors and update PIDs parameters accordingly. Pilot should try not to make aggressive maneuvers. That is because the error in multiwii is calculated as (RC_Stick - Gyroreading) as stick position acts as rotation speed target i.e. the target rpm, so moving stick suddenly generates false errors.

       

         The algorithm mainly works as our human eye. what you do is that if you find your quad tilt you give thrust to motor to adjust this tilt. 

      

      

      Below is the state machine for the new mode.

State Diagram of G-Tune

 1- As we can see from above state diagram, You need to disarm your quadcopter, then you switch to G_Tune mode. once you do that all PIDs will be Zero and you can test that by switch back to ACRO mode again and try to fly "be careful as you have no control because all PIDs are ZERO"

  2- You can then switch back to G_TUNE the arm your quadcopter. Try to fly carefully, do not make aggressive moves, your quadcopter should fly reasonably stable.

  3- Now switch to GYRO mode in AIR to stop updating the values. dont try to land first. 

  4- Now fly again in ACRO mode and this time it will fly. 

The algorithm was able to generate the following PIDs values for ACRO mode:

 Both values in the two screen shots flythe quadcopter

Caution

 1- This is a test mode that I tested only on my quadcopter with Simonk ESC, 10x4.5 props and Turnigy 1100 KV. It should work on other configuration, but I have not try it myself.

 2- Moving ELE & ALE sticks just before changing from G_TUNE to ACRO mode could corrupt the values, so please try to fly as stable as possible and switch to ACRO while sticks are almost released for best results.

 3- Switching back from GYRO to G_Tune mode in AIR could be dangerous -however the correction is very fast and it normally works- because PIDs are reset to ZEROs in AIR.

Porting MultiWii to Arduino DUE

Porting MultiWii to Arduino DUE

GitHub is here  please compile code on Arduino-1.5.6r2 or later.

Arduino DUE is a microcontroller board based on the Atmel SAM3X8E ARM Cortex-M3 CPU. It is the next generation of Arduino boards “UNO, Nano, Mini”…etc. It is a very attractive platform for building quadcopter firmware on for the following reasons:

•  A 32-bit core, that allows operations on 4 bytes wide data within a single CPU clock.

·         CPU Clock at 84Mhz compared to 16MHz for other Arduino.

•          96 KBytes of SRAM compared to 8Kbytes for Arduino Mega 2560.
•  512 KBytes of Flash memory for codecompared to 256Kbytes for the nearest giant Arduino Mega, and this number is much less in other Arduinos.
• DMA controller, that can relieve the CPU from doing memory intensive tasks.

All these advantages do not come without a cost. The main two disadvantages from current quadcopters firmware and hardware are:

1- This warning message on Arduino website “Warning: Unlike other Arduino boards, the Arduino Due board runs at 3.3V. The maximum voltage that the I/O pins can tolerate is 3.3V. Providing higher voltages, like 5V to an I/O pin could damage the board.” This means that you cannot just attach your current 5V logic hardware to Arduino DUE.

2-      There is EEPROM memory in Arduino DUE L. And this is another very sad news as you need to have EEPROM in order to be able to save PIDs, sensors calibration values and many other values used for quadcopters. They need to be saved somewhere and without EEPROM you need to use external flash memory which is extra hardware and extra interface.

I can see that these two reasons strongly affected firmware developers to use Arduino for quadcopters. But as we will see below these were only illusions.

Problem Solved

                Naze32 was the first 32-bit board I see for MultiWii. When I found the code for the first time, the first thing I searched for is that EEPROM problem and how can we solve it. Well the solution was obvious; you can use Flash memory instead of EEPROM. You can store the data together with the code.

WAW; I said to myself. It is very nice simple approach. So I searched for similar code for Arduino DUE, and I found one written by cmaglie. That is 50% of the problem solved J

Now back to the 3.3V issue, well it seems someone has the courage to try the 3.3V and guess what, it worked J. I contacted Rouan to make sure that there is no 3.3V tweeks that I need to make, and the answer was no. I believe the 3.3V works with no problems for the following reasons:

1-      For ESC logical 1 is less than 3.3V so 3.3V as input signal for ESC is more than enough to control it.

2-      For RX seems that logical 1 is either less than 5V of maybe because the input is a pulse of with 2ms max with frequency 50Hz makes the average DC is not enough to burn the input pin.

Again the 3.3V is not an issue anymore J

Why MultiWii?

                Well, I am no longer the first one –I know- to write quadcopter code on Arduino DUE, Rouan has already made it. So I decided to pick for myself a new challenge, and I chose to convert MultiWii firmware for the following reasons:

1-      It is a very famous firmware, well known and not so complex.

2-      It is already built to talk with Arduino boards, so supporting Arduino DUE is a natural extend for the firmware.

3-      Arduino community as well as MultiWii community might find this conversion useful to start with to build much powerful updates, as the current code takes only 9% of the available Flash memory.

Steps of porting MultiWii to Arduino DUE

                My target is to build MultiWii code that you can still compile it on 8-bit Arduino boards. It is not a dedicated version for Arduino DUE –although a next version might be so-.

                So I first need to figure out where to put changes and where to keep old code. In the remaining part, I will mention the major changes as well as major challenges I faced during this process.

#if defined (ARDUINO_DUE)

As in all MultiWii code, you need to define specific code for specific board, and I have chosen to use ARDUINO_DUE as the mark. All code under ARDUINO_DUE is specifically compiled when you choose to compile for Arduino DUE only. Some code in MultiWii is generic for all boards, but I can only be executed for 8-bit microprocessors not ARM, for these parts I use #if !defined (ARDUINO_DUE)

Def.H

This is the file you need to edit to define now sensors, vehicle, board ...etc. It is a core file. I started with it and defined:

1-      When ARDUINO_DUE is active.

#if defined (ARDUINO_ARCH_SAM)

                #define ARDUINO_DUE

#endif

ARDUINO_ARCH_SAM is what you need to look for to detect an ARDUINO_DUE.

2-      Define alternatives for pgmspace by including <arm/ pgmspace.h>

3-      ARDUINO_DUE board pin assignments.

THR:      PIN 62  - A8

ALE:       PIN 63  - A9

ELE:        PIN 64  - A10

RUD:      PIN 65  - A11

AUX1:   PIN 66  -DAC0

AUX2:   PIN 67 - DAC1

Motor 1:  PIN 34

Motor 2:  PIN 36

Motor 3:  PIN 38

Motor 4 / Servo 4:  PIN 40

                Other parts of the definition are just code from ARDUINO_MEGA that will make error if activated as it is not converted yet.

    Code Changes

       I used Multiwii version 2.3 as my starting point. Most of the other code is same as MultiWii, Dramatic changes where in EEPROM.cpp Sensors.cpp, RX.cpp and Output.cpp

EEPROM.cpp I used cmaglie Flash class –I updated a paging issue in it- to save configuration structures.

RX.cpp          I used Rouan code, and it was very useful and straight forward.

Output.cpp Again I used Rouan code, but this time it was more tricky to embed with original code of MultiWii due to logic of motor/servo selection and different PWM signal generation.

Sensors.cpp I used original wire.h library, however I renamed it Wire_DUE.h and included as part of the project as I intend to update it later to make it fast. I replicated the same I2C functions that is used in MultiWii so that sensors logic stay untouched. Functions used Wire_DUE.h instead of original code when compiling for Arduino_DUE.

Main Issues I Faced

1.     I first used __CM3_REV instead of ARDUINO_ARCH_SAM to check for DUE, and it made linking errors. I have not run through the root cause yet, but I took couple of days to solve this issue.
2.  Types from uint8_t & int16_t in functions _getADC() in sensors.cpp . You need to make explicit type casting. Without doing so you will get rubbish data from GYRO. This is due the << operation acts without caring about the sign.
   
3. Alignment !!!!! This was a very wicked tricky issue that I faced when trying to connect to WiiGUI. The application displays data correctly but gives false alarm of suiting to BARO mode –Altitude Hold- for example. And I found that this error was due to serializing structures in protocol.cpp, and the 32bit compiler stored structure items 4byte-aligned, This makes gaps between different variables and translated wrongly by WinGUI. This is why you found __attribute__ ((packed)) at each and every structure and union. This was a very time consuming bug, and very random and distributed between C# code on PC and C++ code in firmware
4. GYRO Hopping. 

            scale = (currentT - previousT) * (GYRO_SCALE * 65536);

Scale variable that is vital for measuring angular velocity of Gyro was giving hopping from 0 to 100 even without touching any sensor. The behavior disappeared when I used int32_t for both currentT & previousT as used in the main loop in Multiwii.cpp

Code Status

                The code is not 100% converted i.e. not all features, however you compile it for Quadcopter or Tricopter and fly in different modes. I have not test GPS, sonar. I only used GY_80 as well as the HK 328 board.

                Code is still under development, and as any firmware it can contain serious issues, so fly safe and on your own risk.

Good Luck J

KK2 v1.5 Firmware Explained Part#1

Yes, it has been a long time since I published my Article "Quadrocopter Firmware (4 Rotor) Explained" . Actually it was long enough to develop my own system on KK2 and get it listed in KK2FlashTool.

HefnyCopter-II Firmware for KK2 Board

Although my firmware has lots of new features, but KK2 code is very mature and respectable and I know that a lot of us wants to explore.

Well KK2 firmware is much more complicated that its parent firmware of KK. This is mainly because KK2 has more sensors, also has LCD which consumes big part of memory and code. So in this article I will only concentrate on stabilization algorithms of KK2.

KK2 has two flying modes, first the ACRO mode where we use only gyros to make balancing. This is fairly easy, all  you need is to read data from gyro and scale it then use a simple PID control to control motors. the other mode is Stabilization mode. This mode uses gyros and accelerometers together to calculate the angle of quadcopter "pitch-roll" and then uses PID control to calculate motor actions.

I will not go into details of gyro and acc here as you can find many articles in talks about this subject in details. but let us take an idea that enable us to proceed with code.

Gyro: sensors that detect quadcopter rotation, its output is deg/sec. so it detects rotation of quadcopter in three dimensions. Gyros are great, accurate and fast, so you can integrate the reading to get the absolute angle, but this is not the real case :( . as gyros has a problem called drift, if you leave the board not touchable and try to integrate gyro readings it will not be zero, although it is not moving or rotating in any way. but for a short time -less than a second- gyro drift can be considered zero.

Acc: sensors that detect acceleration i.e. forces. because "g" is earth acceleration you can use acc sensor to detect pitch and roll directly using simple calculations. however because quadcopter is not fixed, there are other forces such as linear acceleration and centrifugal forces that make acceleration sensors not accurate for fast readings, so you need to apply low pass filter to get a reliable value. 

So what we do is to calculate angles using gyro, then use accelerometers to correct the drift.

Imu:       ;--- Get Sensor Data ---

Step#1: Read Gyro & Acc values and refer them to Zero

                call AdcRead                                                                      ;Calculate gyro output

                ;---M.Hefny

                ;--- Gyro = Gyro - GyroZero for Roll,Pitch & YAW

                b16sub GyroRoll, GyroRoll, GyroRollZero

                b16sub GyroPitch, GyroPitch, GyroPitchZero

                b16sub GyroYaw, GyroYaw, GyroYawZero

                ;---M.Hefny

                ;--- Acc = Acc - AccZero for X Y & Z

                b16sub AccX, AccX, AccXZero                                     ;remove offset from Acc

                b16sub AccY, AccY, AccYZero

                b16sub AccZ, AccZ, AccZZero                     

                ;---M.Hefny

                ;--- AccX = AccX + AccTrimPitch

                b16add AccX, AccX, AccTrimPitch                                              ;add trim

                b16add AccY, AccY, AccTrimRoll

Step#2: Apply complementary filter to Acc to remove noise.

                ;---M.Hefny

                ;--- Low Pass Filter

                b16ldi Temper, 0.03                                                        ;SF LP filter the accerellometers

                ;---M.Hefny

                ;--- AccXfilter = AccXfilter + Temper * (AccX - AccXFilter)

                b16sub Error, AccX, AccXfilter

                b16mul Error, Error, Temper

                b16add AccXfilter, AccXfilter, Error

                ;---M.Hefny

                ;--- AccYfilter = AccYfilter + Temper * (AccY - AccYFilter)

                b16sub Error, AccY, AccYfilter

                b16mul Error, Error, Temper

                b16add AccYfilter, AccYfilter, Error

                ;---M.Hefny

                ;--- AccZfilter = AccZfilter + Temper * (AccZ - AccZFilter)

                b16sub Error, AccZ, AccZfilter

                b16mul Error, Error, Temper

                b16add AccZfilter, AccZfilter, Error

Step#3: Correct Gyro-Based calculated angles using Acc readings.

                ;---  calculate tilt angle with the acc. (this approximation is good to about 20 degrees) --

                b16ldi Temp, 0.7

                b16mul AccAngleRoll, AccYfilter, Temp

                b16mul AccAnglePitch, AccXfilter, Temp

                ;--- Add correction data to gyro inputs based on difference between Euler angles and acc angles ---

                b16ldi Temp, 20                                ;skip correction at angles greater than +-20

                b16cmp AccAnglePitch, Temp

                longbrge im40

                b16cmp AccAngleRoll, Temp

                longbrge im40 ;M.Hefny: Skip correction

                b16neg Temp  ;M.Hefny compare -20

                b16cmp AccAnglePitch, Temp

                longbrlt im40 ;M.Hefny: Skip correction

                b16cmp AccAngleRoll, Temp

                longbrlt im40 ;M.Hefny: Skip correction

                b16ldi Temp, 60                ;skip correction if vertical acceleration is outside 0.5 to 1.5 G

                b16cmp AccZfilter, Temp

                longbrge im40 ;M.Hefny: Skip correction

                b16neg Temp

                b16cmp AccZfilter, Temp

                longbrlt im40 ;M.Hefny: Skip correction

               

                ;---- M.Hefny

                ;--- GyroRoll = GyroRoll + (EulerAngleRoll - AccAngleRoll) / 2;

                b16sub Temp, EulerAngleRoll, AccAngleRoll         ;add roll correction

                b16fdiv Temp, 2

                b16add GyroRoll, GyroRoll, Temp

                ;---- M.Hefny

                ;--- GyroPitch = GyroPitch + (EulerAnglePitch - AccAnglePitch) / 2;b16sub Temp, EulerAnglePitch, AccAnglePitch                ;add pitch correction

                b16fdiv Temp, 2

                b16add GyroPitch, GyroPitch, Temp

                ;rvsetflagtrue flagDebugBuzzerOn

                rjmp im41

im40:     ;rvsetflagfalse flagDebugBuzzerOn

                                ;---- M.Hefny

                                ;--- im40 skipping to im40 means skipping correction.

                               

Step#4: Calculate Gyro-Based calculated angles.

im41:

                ;--- Rotate up-direction 3D vector with gyro inputs ---

                call Rotate3dVector

                call Lenght3dVector

                call ExtractEulerAngles

                ;--debug

                ;--- Calculate Stick and Gyro  ---

                rvbrflagfalse flagThrottleZero, im7           ;reset integrals if throttle closed

                b16clr IntegralRoll

                b16clr IntegralPitch

                b16clr IntegralYaw

im7:      

                b16fdiv RxRoll, 4                                               ;Right align to the 16.4 multiply usable bit limit.

                b16fdiv RxPitch, 4

                b16fdiv RxYaw, 4

                b16mul RxRoll, RxRoll, StickScaleRoll        ;scale Stick input.

                b16mul RxPitch, RxPitch, StickScalePitch

                b16mul RxYaw, RxYaw, StickScaleYaw

                b16mul RxThrottle, RxThrottle, StickScaleThrottle

;----- Self level ----

                rvbrflagtrue flagSelflevelOn, im31            ;skip if false

                rjmp im30           

im31:    

;--- M.Hefny

;--- Calculate Self Leveling PID using P only factor.

;--- Roll Axis Self-level P ---

                b16neg RxRoll

                ;--- M.Hefny

                ;--- RxRoll = RxRoll / 2

                b16fdiv RxRoll, 1

                ;--- M.Hefny

                ;--- TargetAngleRoll = (QuadRoll - StickRollAngle)              / 16

                b16sub Error, EulerAngleRoll, RxRoll        ;calculate error

                b16fdiv Error, 4

                ;--- M.Hefny

                ;--- calculate P term of PID.

                b16mul Value, Error, SelflevelPgain         ;Proposjonal gain

                ;--- M.Hefny

                ;---- Limit value to SelflevelPlimit

                b16mov LimitV, SelflevelPlimit                   ;Proposjonal limit

                rcall limiter

                ;--- M.Hefny

                ;--- RxRoll = Limit(SelfLevelPgain * (EulerAngle-RXRoll)/16,SelflevelPlimit)/2

                b16mov RxRoll, Value

                b16fdiv RxRoll, 1

;--- Pitch Axis Self-level P ---

                b16neg RxPitch

                ;--- M.Hefny

                ;--- RxPitch = RxPitch / 2

                b16fdiv RxPitch, 1

                ;--- M.Hefny

                ;--- TargetAnglePitch = (QuadPitch - StickPitchAngle) / 16             

                b16sub Error, EulerAnglePitch, RxPitch   ;calculate error

                b16fdiv Error, 4

                ;--- M.Hefny

                ;--- calculate P term of PID.

                b16mul Value, Error, SelflevelPgain         ;Proposjonal gain

                ;--- M.Hefny

                ;---- Limit value to SelflevelPlimit

                b16mov LimitV, SelflevelPlimit                   ;Proposjonal limit

                rcall limiter

                ;--- M.Hefny

                ;--- RxPitch = Limit(SelfLevelPgain * (EulerAngle-RXPitch)/16,SelflevelPlimit)/2

                b16mov RxPitch, Value

                b16fdiv RxPitch, 1

                ;--- M.Hefny

                ;--- EOF leveling procedure.

               

im30:

;--- Roll Axis PI ---

               

                ;--- M.Hefny

                ;--- Calculate GYRO ... Gyro is used for stabilization only.

               

                b16sub Error, GyroRoll, RxRoll                    ;calculate error

                b16fdiv Error, 1

                b16mul Value, Error, PgainRoll                   ;Proposjonal gain

                b16mov LimitV, PlimitRoll                             ;Proposjonal limit

                rcall limiter

                b16mov CommandRoll, Value

                b16fdiv Error, 3

                b16mul Temp, Error, IgainRoll                     ;Integral gain

                b16add Value, IntegralRoll, Temp

                b16mov LimitV, IlimitRoll                              ;Integral limit

                rcall limiter

                b16mov IntegralRoll, Value

                b16add CommandRoll, CommandRoll, IntegralRoll

;--- Pitch Axis PI ---

                b16sub Error, RxPitch, GyroPitch               ;calculate error

                b16fdiv Error, 1

                b16mul Value, Error, PgainPitch                 ;Proposjonal gain

                b16mov LimitV, PlimitPitch                          ;Proposjonal limit

                rcall limiter

                b16mov CommandPitch, Value

                b16fdiv Error, 3

                b16mul Temp, Error, IgainPitch                  ;Integral gain

                b16add Value, IntegralPitch, Temp

                b16mov LimitV, IlimitPitch                            ;Integral limit

                rcall limiter

                b16mov IntegralPitch, Value

                b16add CommandPitch, CommandPitch, IntegralPitch

;--- Yaw Axis PI ---

                b16sub Error, RxYaw, GyroYaw                  ;calculate error

                b16fdiv Error, 1

                b16mul Value, Error, PgainYaw                  ;Proposjonal gain

                b16mov LimitV, PlimitYaw                            ;Proposjonal limit

                rcall limiter

                b16mov CommandYaw, Value

                b16fdiv Error, 3

                b16mul Temp, Error, IgainYaw                    ;Integral gain

                b16add Value, IntegralYaw, Temp

                b16mov LimitV, IlimitYaw                             ;Integral limit

                rcall limiter

                b16mov IntegralYaw, Value

                b16add CommandYaw, CommandYaw, IntegralYaw

;------

                ret

;--- M.Hefny

;--- Function to limit value between high and low limits

limiter:

                b16cmp Value, LimitV    ;high limit

                brlt lim5

                b16mov Value, LimitV

lim5:      b16neg LimitV                   ;low limit

                b16cmp Value, LimitV

                brge lim6

                b16mov Value, LimitV

lim6:      ret

HefnyCopter2 Gyro Noise Filtering

HefnyCopter

HefnyCopter is a firmware specially designed for KK boards. There are two types of this firmware.

HefnyCopter

                This version targets the green and blue KK boards from HobbyKing. The main feature of this version is that it allows awitching your Quadcopter from X to PLUS mode without the need to reorient the board. The main concept of this feature explained in this topic “quadcopter-stabilization-control-system”.

                The hex & sourcecode is available here . Please make sure that you read the manual well before flying as POTS functions are not the same as the original firmware of KK boards.

HefnyCopter2

                This is a complete new version and goes in parallel with HefnyCopter, i.e. there are still updates on HefnyCopter so they are two parallel tracks.

                This firmware targets KK2 board. The board has LCD, Accelerometers, and Gyro. As well as a beter processor ATMega324. This means you have better capabilities here to help you to build a better firmware.

                HefnyCopter2 still has the feature of mode switching from X to Plus. But now you can connect your board via XBEE to your PC and receive telemetry data, you can work better on you stabilization algorithm and enhance your quadcopter stability.

                HefnyCopter2 also has the feature of supporting two TX, that means you can fly it with a friend and train him/her how to fly the quad.

How HefnyCopter2 Helps to Improve Stabilization

Because of the ability of sending data to PC using XBEE, I was able to visualize the data and try different approaches to filter out the noise.

The Windows application that connects to XBEE has nice GUI interface for realtime display, however the more useful part is the CSV file that it dumps for the received data. In the below figure we can see the received data. Columns in order are:

Gyro_X, Gyro_Y, GyroX, Acc_X, Acc_Y, Acc_Z, M1, M2, M3, M4

Raw Data as received from XBEE in csv format

Please note that Acc_X represent the pitch so it goes with Gyro_Y, also Gyro_Y increase when quadcopter rotates forward, while Acc_X increase while quadcopter rotates backward. i.e. Acc_X is related to Gyro_Y and with negative sign. Same applied for Acc_Y & Gyro_Y.

Acc_Z represents the gravity effects that is why it is not 0, it is 100 which is equivalent to 9.8 m/s, Gyro_Z is used to detect YAW so it has nothing to do with Acc_Z.

Values ranges from 500 to -500, while motor ranges from 0 to 1000. To keep logged data at reasonable size data is only transmitted when quadcopter is armed and motors are on. that is why the minimum values of motors Ms is 100 here in the sheet as below this values quadcopter ignores TX signal and send Zero to motors.

Let now study Gyro_Y values and apply some math on it.

Gyro_Y Data received from XBEE

as we can see above this is Gyro_Y data, I added three more columns:

Move Avg

   

        This is a moving average column, which means each value is added to the total and then divide the total over two.

       Gyro_Y_Total = (Gyro_Y_Total + Gyro_Y ) /2

LPF

    LPF stands for Low-Pass-Filter, here i used a complementary filter to reduce noise. Complementary filter is not a complex math at all, at least if we focus on the formula not the derivation, and try to understand it from the simple view point. The formula is as follows:

     Gyro_Y_Total = (0.95 * Gyro_Y_Total) + (0.05 * Gyro_Y)

   Each time we take small part of the signal and sum it to the total. assuming that the signal has high frequency noise, so we need to smooth it by taking part of the signal and accumulate it, to avoid taking peaks that represents high frequency.

  Yes there are better ways to filter noise and at specific frequencies -as we can find in sound equalizer-, but computation is difficult and time consuming. If you are interested for more complex algorithms try Kalman Filter, or read topics about Fast Fourier Transform.

LPF2

    This is the same as LPF. I only changed the factors, and took double the amount in LPF.

     Gyro_Y_Total = (0.90 * Gyro_Y_Total) + (0.10 * Gyro_Y)

Gyro_Y under different filters

You can see clearly from above how complementary filter does remove noise from signal. There are two lines red & blue in the complementary filter the one with some noise is LPF2 and the red smoother one is LPF where we take only 0.05 of the signal value.

HefnyCopter2 now implements complementary filters for Gyro_X, Gyro_Y & Gyro_Z and the result was a much smooth flying.

I am still working on studying different behaviors and values received from my quadcopter. I believe there is a much yet to be discovered -at least for me-. 

Data Analysis Files can be downloaded from here.

Please follow up with us on HefnyCopter.net