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

QuadCopter Stabilization & Control System "X & Plus Configuration"

QuadCopter Balancing & Controlling Separation

This topic discusses how to separate between balancing quadcopter and controlling it.

First let us discuss the balancing control techniques in different quadcopter modes. Quadcopter can fly in (+) configuration and (X) configuration. The only difference between these modes is where the front of the quad is.

The following diagram illustrates the difference.

Quadcopter Configuration "X & Plus"

Plus (+) Configuration Control

In this configuration the control as follows:

// Pitch Control
M1 = M1 + RX(Elevator);
M4 = M4 - RX(Elevator);

// Roll Control
M2 = M2 + RX(Aileron);
M3 = M3 - RX(Aileron);

This is very simple control and is found in all quadcopter code. Sure there are some checks here and there to avoid motor stopping or saturating.  But the flying logic is always as above. There is also a scaling factor that is used to determine the sensitivity of the sticks and a Divide factor that limits the value range.

X Configuration Control

In this configuration the control as follows:

// Pitch Control
M1 = M1 + RX(Elevator) /2;
M3 = M3 + RX(Elevator) /2;
M4 = M4 - RX(Elevator) /2;
M2 = M2 - RX(Elevator) /2;

// Roll Control 
M1 = M1 + RX(Aileron)/2;
M2 = M2 + RX(Aileron) /2;
M3 = M3 - RX(Aileron) /2;
M4 = M4 - RX(Aileron) /2;

As we can see this is the same logic, we only assumes that M1 & M3 together acts as a single virtual motor in the front, and M2 & M4 together acts as a virtual motor in the rear. Other than that it is the very same logic.

Same considerations and factors applied in the PLUS configuration go here as well.

Stabilization System

Now let us see the stabilization system. The idea is simple, if the quad is falling to the right then speed up the right motor and slow the left one with the same amount and vice versa. Also if the quad is falling down from the front arm then speed up the M1 motor and slow down  M4. The rule is written as follows.

M1 = M1 + PitchAmount  *  PitchGain
M4 = M4 -  PitchAmount  *  PitchGain

M2 = M2 + RollAmount   *   RollGain
M3 = M3  - RollAmount   *   RollGain

This is the basic rule that should be found in all quadcopter programs. The main difference between the different firmware approaches is how to calculate PitchAmount and RollAmount. This can simply be read from a Gyro sensor and multiply it by a constant factor to adjust the range, or we can use PID approach or even Kalman filter and combine Gyro with Acc sensors to get the exact degree.

The Gain factor is used to determine the sensitivity. Other checks such as trimming are common in quadcopter code.

Do we need Different Stabilization for X-Configuration?

Well in almost all quadcopter programs you will find that stabilization and control calculation follows the same concept. i.e. if we use X-Quadcopter then we add the PitchAmount to both motors M1 & M2. Also RollAmount is added to motors M1 & M3. This is valid approach but in fact it is not necessary at all, also there is a major drawback here.

It is not necessary because the stabilization control of Plus configuration can stabilize quadcopter if there is a simultaneous picth & roll forces, that means if the Control System is Plus of X the Stabilization System can stabilize both using the same PLUS configuration.

The main drawback is that Stabilization control requires the orient the control board so that its onboard gyro and acc are in the right directions, so you cannot switch between PLUS configuration to X-Configuration without reorient the board. So if we can keep the Stabilization System and only change the Control System we don’t need to reorient the board as Control System has nothing to do with the board sensors it only change the signal values sent to different motors.

HefnyCopter has implemented this idea successfully as in the below video.

Also please read my other topic about Gyro Noise Filtering.

See newest article Quadcopter Flight-Control  Framework

My X-525 QuadCopter

This is my second trial of building a quadcopter. The first quadcopter -is the one we can see below- was totally homemade, the arms were too thin and U-shape so motors were twisting the bars and it was unstable.

early steps in building frame

My hand-made frame

My second quadcopter uses exactly the same motors and board, I decided to use Hobby King X-525 Quadcopter Frame.

Building the body was easy it took 40 min to assemble it. and another 4 hours in mounting motors and soldering connections.

rubber to reduce vibrations

Flying results was different, QuadCopter is much stable now.

X-525 Frame with folding bars

Still I need training, below was my first trial, now I fly it much better however still a beginner.

If you are interested in building your quad, below is a complete list of items you need to buy. Building a quadcopter is an interesting task, although it does not require as high skills as building a scale RC plane or a helicopter where mechanics are too complex. Quadcopter are very easy to balance as well, they mainly depends on their control board for balancing so minor mismatch in CG is not an issue at all.

Bill of Materials:
   
       - Quadcopter Frame Hobbyking X666 Glass Fiber Quadcopter Frame 666mm
   
       - Propellers you need two propellers CW & two propellers CCW. I tried both GWS 9x5 CW & CCW as well as SF 10x45 CW & CCW. if you are a newbie here, then you need to get at least extra 4 propeller of each type i.e. CW & CCW as you should expect that the first thing you will break here are propellers.

       - 4 x Brushless FC28-22

       - 4 x ESC HobbyKing 20A BlueSeries Brushless Speed Controller or Mystery 30A BEC Brushless Speed Controller (Blue Series)

       - Hobby King Multi-Rotor Control Board V3.0 (Atmega 328 PA) or the newer Hobbyking KK2.0 Multi-rotor LCD Flight Control Board with LCD and additional accelerometer sensors.

       - 1 x LIPO Battery Turnigy 2200mAh 3S 40C Lipo Pack . The quad flies for +10 min.

      - 1 x Receiver 6CH such as OrangeRx R610 Spektrum DSM2 6Ch 2.4Ghz Receiver (w/ Sat Port) it is fully compatible with Spektrum & JR yet it costs lest that 1/10 of the price of original receivers.



Other Misc. Stuff are:

       - 1 x 2mm Gold Connectors 10 pairs (20pc) These connectors are slim and very suitable for your FC 28-22 wires. You will need them to connect motor to ESC.

       - 1 x 10CM Male to Male Servo Lead (JR) 26AWG (10pcs/set) the set contains 10 pieces which are enough for the quadcopter . . . actually you will need four or five based on the control board you choose.

       - 1 x Hobby King Quadcopter Power Distribution Board This links your power wires from ESCs together to connect them to the battery. You can also use Single Male to 4 x 3.5mm Female adapter instead based on your quadcopter size.

      - 1 x Turnigy 5mm Heat Shrink Tube - BLACK (1mtr) This is important and easy to use as well. It keeps your connections tight and clean. you need a simple air drier to shrink them. It is great to isolate connectors and keep them together.

     - 1 x HobbyKing Programming card for BlueSeries Brushless Speed Controller This is important to avoid the hassle of programming your ESC using transmitters and magical beeps. The quad has four ESC, you need easy and accurate programming tool to make your life easier.
 
Extra Stuff:

      - 1 x On Board Lipoly Low Voltage Alarm (2s~4s) actually I would not say it is all extra, it is important if you plan to fly your quad high. . . you need an alarm to tell you that your battery is about to finish and you need to bring your quad down before it gets down by itself :)

    - LEDs exists in different types  RED - GREEN - BLUE they are great if you plan to fly quad at night



HefnyCopter Code

  The video below show my quad flying using my own Hefny Copter Firmware. The new feature in this firmware is that your ability to switch between X-Quad configuration and + Quad Configuration using your remote TX only. no need to reorient the board or recompile the code.