Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to bionic bird
Similar to bionic bird (20)
Recently uploaded
Recently uploaded (20)
bionic bird
- 1. PROJECT BIONICOPTER BY : KIRAN.R.B 1TJ11EC027 NAVYA.M 1TJ11EC043 DHANAPAL.S 1TJ11EC020 LIJI.T.L 1TJ11EC030 Guide : Prof. Srinivas T JOHN INSTITUTE OF TECHNOLOGY
- 2. Board Selection ( Difficulties faced) • WEIGHT: preferably selected to maintain center of gravity of the body • Detailed study of trade off between increased specifications and weight • Wide range of controller board available in the market. To sort out and decide upon was a hectic task. • Board selected: Multiwii pro flight controller
- 3. To brief about Multiwii pro • MultiWii’s name comes from its original sensors. The first revision designed to use the Nintendo Wii Nunchuck gyros and accelerometers(cheap and easily available worldwide). • Current MWP sports a host of sensor upgrades. • The MWP board is based upon the Arduino and utilizes an ATmega2560 processor.
- 4. Board specifications • Multi rotor type • Gimbal • Camera trigger output • GUI • Flight mode • Hardware compatibility
- 5. Multiwii SE V2.5 Flight Controller • Version : 2.5 • Weight : 17 gm • interfaced with GPS, Bluetooth, Camera etc
- 6. Theory of height and motion control Height control:
- 8. To attain stability • What is PID
- 9. • What is PID
- 10. Interfacing and controlling • Loading the MWC Firmware Prerequisites Arduino IDE Setup Downloading the Firmware
- 11. • Config.h Options Selections Select the Copter Type (#define BI) Select the Flight Controller (#define HK_MultiWii_SE_V2) Independent sensors Selection Failsafe Option Motor Stop Option
- 12. • Transmitter Configuration Mixing Setting Setting End Points
- 13. • ESC Calibration External Method Calibration MWC Special Build ESC Calibration
- 14. • GUI Interface Accelerometer Calibration Magnetometer Calibration
- 15. • First Flight Testing Safety First Fight Test PID settings Other
- 16. Basic code
- 17. Slide Title Product A • Feature 1 • Feature 2 • Feature 3 Product B • Feature 1 • Feature 2 • Feature 3
Editor's Notes
- MultiWii Pro Next up is the MultiWii. MultiWii’s name comes from its original sensors. The first revision of the MultiWii was designed to use the Nintendo Wii Nunchuck gyros and accelerometers, as they were cheap and easily available worldwide. Things have changed quite a bit since then. The current MultiWii board, MultiWii Pro (MWP) sports a host of sensor upgrades. The MWP board is based upon the Arduino and utilizes an ATmega2560 processor. Software is written in Arduino’s native wiring language, using everyone’s favorite processing based IDE. The board’s current sensor suite is extensive. In addition to the usual gyros and accelerometers, it has a barometer, magnetometer (compass), and an optional GPS. MultiWii also allows for a number of configuration methods. Off board LCD and OLED displays can be connected for field configuration. A full GUI config program is available via the on-board USB port or a Bluetooth daughterboard. MultiWii’s source is hosted on their Google Code page, though there is a Github mirror for you git fans. MultiWii is quite capable of stabilizing an R/C style airplane, helicopter, or multicopter. The board is on the cusp of being a full-fledged autopilot. It’s not as slick as the APM, partly due to the fact that there isn’t a well funded corporate entity driving development in one direction or another. The core developers are active though, which makes this a good board to watch. MultiWii project related stuffs MultiWii MultiWii is a general purpose software to control a multirotor RC model. It can now use various sensors but was initially developed to support Nintendo Wii console gyroscopes and accelerometers. We can find these sensors in the extensions of the Nintendo WiiMote: Wii Motion Plus and Wii Nunchuk. This project was an opportunity to develop my own software on an Arduino platform. The achieved stability is excellent for FPV and allows any kind of acrobatics. The software is for the moment able to control a tricopter, a quadricopter or a hexacopter. List of supported features multi Rotor type BICOPTER TRICOPTER QUAD + QUAD X HEX Y6 HEX FLAT + HEX FLAT X OCTO X8 OCTO FLAT + OCTO FLAT X Gimbal when associated with an accelerometer, MultiWii is able to drive 2 servos for PITCH and ROLL gimbal system adjustment the gimbal can also be ajdusted via 2 RC channels Camera trigger output a servo output can be dedicated to trigger a camera button. A servo travel pattern is defined in this case GUI: Coded with processing, java core: Linux/MAC/PC compatible, USB connection exhaustive parameter configuration graphical visualization of sensors, motors and RC signal Flight mode: one of the following mode angle velocity driven (accro mode) absolute angle driven (level mode) optional mode, compatible with the 2 previous one altitude assisted mode (baro mode, compatible with the 2 previous mode) head lock assisted mode (magneto mode) Hardware compatibility receiver any standard receiver with a minimum of 4 RC channels any PPM sum receiver servo up to 4 any standard 50Hz servos can be used motor ESCs up to 8 standard ESC can be used, boosted with a 488Hz refresh rate sensors 3 MEMS Gyro 2x IDG-650, 1x ISZ-650 (genuine Wii Motion Plus) ITG3200 3 MEMS Acc (optional) LIS3L02AL (genuine Nunchuk) BMA020 BMA180 3 MEMS magnetometer (optional) HMC5883 HMC5843 1 MEMS barometer (optional) BMP085 LCD for configuration of every parameters on the field any Sparkfun serial 9600 baud LCD 2x16 characters TEXTSTAR LCD 2x16 characters, with its 4 buttons supported
- List of supported features multi Rotor type BICOPTER TRICOPTER QUAD + QUAD X HEX Y6 HEX FLAT + HEX FLAT X OCTO X8 OCTO FLAT + OCTO FLAT X Gimbal when associated with an accelerometer, MultiWii is able to drive 2 servos for PITCH and ROLL gimbal system adjustment the gimbal can also be ajdusted via 2 RC channels Camera trigger output a servo output can be dedicated to trigger a camera button. A servo travel pattern is defined in this case GUI: Coded with processing, java core: Linux/MAC/PC compatible, USB connection exhaustive parameter configuration graphical visualization of sensors, motors and RC signal Flight mode: one of the following mode angle velocity driven (accro mode) absolute angle driven (level mode) optional mode, compatible with the 2 previous one altitude assisted mode (baro mode, compatible with the 2 previous mode) head lock assisted mode (magneto mode) Hardware compatibility receiver any standard receiver with a minimum of 4 RC channels any PPM sum receiver servo up to 4 any standard 50Hz servos can be used motor ESCs up to 8 standard ESC can be used, boosted with a 488Hz refresh rate sensors 3 MEMS Gyro 2x IDG-650, 1x ISZ-650 (genuine Wii Motion Plus) ITG3200 3 MEMS Acc (optional) LIS3L02AL (genuine Nunchuk) BMA020 BMA180 3 MEMS magnetometer (optional) HMC5883 HMC5843 1 MEMS barometer (optional) BMP085 LCD for configuration of every parameters on the field any Sparkfun serial 9600 baud LCD 2x16 characters TEXTSTAR LCD 2x16 characters, with its 4 buttons supported
- proportionally to the input. Its movements are controlled by steering it to a certain orientation and keeping this orientation for a certain time. Due to measurement noise and discrete integration the integrated angles drift about ± 3 degrees per minute. However, this drift can be easily compensated by a human pilot or an autonomous external position control such as a motion capture system. Figure 3 shows the principal structure of our onboard controllers commonly referred to as ”heading-lock”. The controller implementations have been optimized for shortest possible execution time and robustness in almost every flight situation. Three controllers are running in parallel on an 8-bit AVR microcontroller (ATMega8). The loop is interrupt triggered, which enables stable time constants for integration and filtering. By using the AVR’s internal ADCs at a high sampling rate, fixpoint arithmetics only, runtime optimized FIR filter implementations and interrupt driven I2C communication to update the motor speeds, we achieved a system running at a control frequency of 1 kHz . All controller parameters have been set empirically and optimized experimentally over several months. Our central controller board including the controllers is compatible to the Silverlit X-UFO, which is available on the international toy market. From January to September 2006 we had 35 people beta-testing the hardware and optimizing parameters within hundreds of hours of human controlled flight. During this period both, hardware and software, have been optimized as far as possible. The result is a very reliable hardware revision of the central controller board, as well as a set of controller parameters capable of reliable control during slow movements as well as during fast maneuvers, even including loops where the robot is inverted for short periods. 3) Sensorless Brushless Controllers: Our robot uses brushless DC motors. Unlike brushed DC motors, brushless motors are commutated electronically rather than electro- mechanically. The common brushless motors use three phases. Current is always floating through two of these phases, while the third phase floats free and is used to mea- sure the angle of the motor. Then the controllers commutates electronically with a three phase H-bridge. The time when the third phase crosses Vdd/ 2 is called zero-crossing point and triggers the next commutation step after a certain time. The three phases are driven in a semi-sine mode, where the phase difference between any pair of phases is always 120 degree. Most commercially available sensorless brushless con- trollers are sold in the model aircraft market. These are controlled using servo impulses with a 50 Hz update rate. To achieve better stability in every situation, we wish to reduce the deadtime in the control-loop from the gyro measurement to the torque change of the motor. We designed the system for a control-loop frequency of 1 kHz . In order to update the motor speeds fast enough, we use an I2C-Bus connected to four custom built brushless controllers. The microcontroller used on the brushless controller is an Atmel ATMega168 [13]. This microcontroller was selected because it offers all required hardware features like timers, PWM generators and a I2C communication interface with 400 kHz . A challenge with sensorless commutation is the necessary minimum speed to detect the position of the motor. The start up is done open loop in a stepping mode to accelerate the motor. The loop is closed afterwards to control the commutation. As soon as the motor runs in the closed loop mode the current is regulated by the PWM that is com- manded by the central controller board. The commutation loop maintains a synchronization between the motor and the electrical commutation. The I2C Routine and the PWM-Update run on lower priority than the commutation, which is very time critical task. In the worst case, the PWM is updated latest on every commutation. Our motors run between 2000 and 8000 rpm. The motors have two electrical commutations per mechanical commutation. Thus the worst case deadtime from the sensor measurement to the torque change is: t wc = 1 ms + 1 2 ∗ 2000 s = 1250 μs The other advantage of our brushless controllers is the optimization for the low-rpm optimized brushless outrunner motors. 4) Brushless Motors and Rotors: The brushless outrunner motors used in our flying robot are a special design for low rpm applications. The stator diameter is 22 . 5 mm , the stator height 5 mm . The windings result in a motor constant of 1000 rpm/V . The weight of the complete motor is 19 g . The rotor was designed to fit directly to the left and right turning propellers from the Silverlit X-UFO. Those propellers are available very cheap as spare parts of the X-UFO and offer good performance with excellent safety as they are very flexible. In figure 4 you can see measurements of voltage, current, RPM and power per thrust with our motor and the X-UFO propeller
- What is PID? PID (proportional-integral-derivative) is a closed-loop control system that try to get the actual result closer to the desired result by adjusting the input. Quadcopters or multicopters use PID controller to achieve stability. There are 3 algorithms in a PID controller, they are P, I, and D respectively. P depends on the present error, I on the accumulation of past errors, and D is a prediction of future errors, based on current rate of change. These controller algorithms are translated into software code lines. To have any kind of control over the quadcopter or multicopter, we need to be able to measure the quadcopter sensor output (for example the pitch angle), so we can estimate the error (how far we are from the the desired pitch angle, e.g. horizontal, 0 degree). We can then apply the 3 control algorithms to the error, to get the next outputs for the motors aiming to correct the error. You don’t need to understand how PID controller works in order to fly a quadcopter. However, if you want more theory, here is a very interesting and detail explanation of PID controller with examples. This PID tutorial is also very good and easy to understand for beginners. There are three parameters that a pilot can adjust to improve better quadcopter stability. These are the coefficients to the 3 algorithms we mentioned above. The coefficent basically would change the importance and influence of each algorithm to the output. Here we are going to look at what are the effects of these parameters to the stability of a quadcopter .
- The effect of each parameter The variation of each of these parameters alters the effectiveness of the stabilization. Generally there are 3 PID loops with their own P I D coefficients, one per axis, so you will have to set P, I and D values for each axis (pitch, roll and yaw). To a quadcopter, these parameters can cause these behavior. Proportional Gain coefficient – you quadcopter can fly relatively stable without other parameters but this one. This coefficient determines which is more important, human control or the values measured by the gyroscopes. The higher the coefficient, the higher the quadcopter seems more sensitive and reactive to angular change. If it is too low, the quadcopter will appear sluggish and will be harder to keep steady. You might find the multicopter starts to oscillate with a high frequency when P gain is too high. Integral Gain coefficient – this coefficient can increase the precision of the angular position. For example when the quadcopter is disturbed and its angle changes 20 degrees , in theory it remembers how much the angle has changed and will return 20 degrees. In practice if you make your quadcopter go forward and the force it to stop, the quadcopter will continue for some time to counteract the action. Without this term, the opposition does not last as long. This term is especially useful with irregular wind, and ground effect (turbulence from motors). However, when the I value gets too high your quadcopter might begin to have slow reaction and a decrease effect of the Proportional gain as consequence, it will also start to oscillate like having high P gain, but with a lower frequency. Derivative Gain coefficient - this coefficient allows the quadcopter to reach more quickly the desired attitude. Some people call it the accelerator parameter because it amplifies the user input. It also decrease control action fast when the error is decreasing fast. In practice it will increase the reaction speed and in certain cases an increase the effect of the P gain. I have written a more detailed post aiming to explain the PID effects on a multicopter’s flight performance. Aerobatic flight: Requires a slightly higher P Requires a slightly lower I Increase D Gentle smooth flight: requires a slightly lower lower P Requires a slightly higher I Decrease D
- Loading the MWC Firmware Prerequisites Most FCs (flight controllers) come loaded with older versions of Multiwii. Download latest versions of FC Firmware & MW Config & WinGUI (currently 2.3) from http://www.Multiwii .com. Configure for your quad & upload to FC. It is imperative that the firmware on FC & WinGUI /MW Config are same version Arduino IDE Setup If not already done so, download the latest copy of the Arduino IDE from http://www.arduino.cc/ making sure to select the right version for your computer and operating system. Install the IDE per the prescribe procedures. On Windows Operating systems, a USB driver maybe required. The drivers are downloadable from http://www.ftdichip.com/FTDrivers.htm Downloading the Firmware As of July 21, 2014, the main depository is located at https://code.google.com/p/multiwii/. Click the download tab followed by clicking the latest version. Save the file to a location on your file system. Decompress the file using your favor program placing the files in the Arduino IDE work direction. This direction can be located from within the IDE by clicking the Preferences button, the field named Sketchbook is the working location. Preference screen from a MacOS, Windows' Preference screen will vary.
- Config.h Options Selections This segment only covers the minimum configuration and suggested options. More options are available and will be covered in other areas of this wiki. Select the Copter Type In this section, select the copter type, QUADX is default. If QUADX is not the desired type, place // before and remove them on the desired selection. /************************** The type of multicopter ****************************/ //#define GIMBAL //#define BI //#define TRI //#define QUADP #define QUADX //#define Y4 //#define Y6 //#define HEX6 //#define HEX6X //#define HEX6H // New Model //#define OCTOX8 //#define OCTOFLATP //#define OCTOFLATX //#define FLYING_WING //#define VTAIL4 //#define AIRPLANE //#define SINGLECOPTER //#define DUALCOPTER //#define HELI_120_CCPM //#define HELI_90_DEG Select the Flight Controller You will need to know your Flight Control type and information for this segment. Please consult the manufacture for detailed information about your board. Once you have this information at-hand, select the board by removing the preceding //. If your board is not listed here, there is another option providing you know the sensors it has. /*************************** Combined IMU Boards ********************************/ /* if you use a specific sensor board: please submit any correction to this list. Note from Alex: I only own some boards, for other boards, I'm not sure, the info was gathered via rc forums, be cautious */ //#define FFIMUv1 // first 9DOF+baro board from Jussi, with HMC5843 <- confirmed by Alex //#define FFIMUv2 // second version of 9DOF+baro board from Jussi, with HMC5883 <- confirmed by Alex //#define FREEIMUv1 // v0.1 & v0.2 & v0.3 version of 9DOF board from Fabio //#define FREEIMUv03 // FreeIMU v0.3 and v0.3.1 //#define FREEIMUv035 // FreeIMU v0.3.5 no baro //#define FREEIMUv035_MS // FreeIMU v0.3.5_MS <- confirmed by Alex //#define FREEIMUv035_BMP // FreeIMU v0.3.5_BMP //#define FREEIMUv04 // FreeIMU v0.4 with MPU6050, HMC5883L, MS561101BA <- confirmed by Alex //#define FREEIMUv043 // same as FREEIMUv04 with final MPU6050 (with the right ACC scale) //#define NANOWII // the smallest multiwii FC based on MPU6050 + pro micro based proc <- confirmed by Alex //#define PIPO // 9DOF board from erazz //#define QUADRINO // full FC board 9DOF+baro board from witespy with BMP085 baro <- confirmed by Alex //#define QUADRINO_ZOOM // full FC board 9DOF+baro board from witespy second edition //#define QUADRINO_ZOOM_MS// full FC board 9DOF+baro board from witespy second edition <- confirmed by Alex //#define ALLINONE // full FC board or standalone 9DOF+baro board from CSG_EU //#define AEROQUADSHIELDv2 //#define ATAVRSBIN1 // Atmel 9DOF (Contribution by EOSBandi). requires 3.3V power. //#define SIRIUS // Sirius Navigator IMU <- confirmed by Alex //#define SIRIUSGPS // Sirius Navigator IMU using external MAG on GPS board <- confirmed by Alex //#define SIRIUS600 // Sirius Navigator IMU using the WMP for the gyro //#define SIRIUS_AIR // Sirius Navigator IMU 6050 32U4 from MultiWiiCopter.com <- confirmed by Alex //#define SIRIUS_AIR_GPS // Sirius Navigator IMU 6050 32U4 from MultiWiiCopter.com with GPS/MAG remote located //#define SIRIUS_MEGAv5_OSD // Paris_Sirius™ ITG3050,BMA280,MS5611,HMC5883,uBlox http://www.Multiwiicopter.com <- confirmed by Alex //#define MINIWII // Jussi's MiniWii Flight Controller <- confirmed by Alex //#define MICROWII // MicroWii 10DOF with ATmega32u4, MPU6050, HMC5883L, MS561101BA from http://flyduino.net/ //#define CITRUSv2_1 // CITRUS from qcrc.ca //#define CHERRY6DOFv1_0 //#define DROTEK_10DOF // Drotek 10DOF with ITG3200, BMA180, HMC5883, BMP085, w or w/o LLC //#define DROTEK_10DOF_MS // Drotek 10DOF with ITG3200, BMA180, HMC5883, MS5611, LLC //#define DROTEK_6DOFv2 // Drotek 6DOF v2 //#define DROTEK_6DOF_MPU // Drotek 6DOF with MPU6050 //#define DROTEK_10DOF_MPU// //#define MONGOOSE1_0 // mongoose 1.0 http://store.ckdevices.com/ //#define CRIUS_LITE // Crius MultiWii Lite //#define CRIUS_SE // Crius MultiWii SE //#define CRIUS_SE_v2_0 // Crius MultiWii SE 2.0 with MPU6050, HMC5883 and BMP085 //#define OPENLRSv2MULTI // OpenLRS v2 Multi Rc Receiver board including ITG3205 and ADXL345 //#define BOARD_PROTO_1 // with MPU6050 + HMC5883L + MS baro //#define BOARD_PROTO_2 // with MPU6050 + slave MAG3110 + MS baro //#define GY_80 // Chinese 10 DOF with L3G4200D ADXL345 HMC5883L BMP085, LLC //#define GY_85 // Chinese 9 DOF with ITG3205 ADXL345 HMC5883L LLC //#define GY_86 // Chinese 10 DOF with MPU6050 HMC5883L MS5611, LLC //#define GY_521 // Chinese 6 DOF with MPU6050, LLC //#define INNOVWORKS_10DOF // with ITG3200, BMA180, HMC5883, BMP085 available here http://www.diymulticopter.com //#define INNOVWORKS_6DOF // with ITG3200, BMA180 available here http://www.diymulticopter.com //#define MultiWiiMega // MEGA + MPU6050+HMC5883L+MS5611 available here http://www.diymulticopter.com //#define PROTO_DIY // 10DOF mega board //#define IOI_MINI_MULTIWII// www.bambucopter.com //#define Bobs_6DOF_V1 // BobsQuads 6DOF V1 with ITG3200 & BMA180 //#define Bobs_9DOF_V1 // BobsQuads 9DOF V1 with ITG3200, BMA180 & HMC5883L //#define Bobs_10DOF_BMP_V1 // BobsQuads 10DOF V1 with ITG3200, BMA180, HMC5883L & BMP180 - BMP180 is software compatible with BMP085 //#define FLYDUINO_MPU // MPU6050 Break Out onboard 3.3V reg //#define CRIUS_AIO_PRO_V1 //#define DESQUARED6DOFV2GO // DEsquared V2 with ITG3200 only //#define DESQUARED6DOFV4 // DEsquared V4 with MPU6050 //#define LADYBIRD //#define MEGAWAP_V2_STD // available here: http://www.multircshop.com <- confirmed by Alex //#define MEGAWAP_V2_ADV //#define HK_MultiWii_SE_V2 // Hobbyking board with MPU6050 + HMC5883L + BMP085 //#define HK_MultiWii_328P // Also labeled "Hobbybro" on the back. ITG3205 + BMA180 + BMP085 + NMC5583L + DSM2 Connector (Spektrum Satellite) //#define RCNet_FC // RCNet FC with MPU6050 and MS561101BA http://www.rcnet.com //#define RCNet_FC_GPS // RCNet FC with MPU6050 + MS561101BA + HMC5883L + UBLOX GPS http://www.rcnet.com //#define FLYDU_ULTRA // MEGA+10DOF+MT3339 FC //#define DIYFLYING_MAGE_V1 // diyflying 10DOF mega board with MPU6050 + HMC5883L + BMP085 http://www.indoor-flying.hk //#define MultiWii_32U4_SE // Hextronik MultiWii_32U4_SE //#define MultiWii_32U4_SE_no_baro // Hextronik MultiWii_32U4_SE without the MS561101BA for more free flash-memory //#define Flyduino9DOF // Flyduino 9DOF IMU MPU6050+HMC5883l //#define Nano_Plane // Multiwii Plane version with tail-front LSM330 sensor http://www.radiosait.ru/en/page_5324.html Independent sensors Selection This segment requires a little more knowledge about the Flight Controller board used and the axis orientation. (need more work.) /*************************** independent sensors ********************************/ /* leave it commented if you already checked a specific board above */ /* I2C gyroscope */ //#define WMP //#define ITG3200 //#define MPU3050 //#define L3G4200D //#define MPU6050 //combo + ACC //#define LSM330 //combo + ACC /* I2C accelerometer */ //#define NUNCHUCK // if you want to use the nunckuk connected to a WMP //#define MMA7455 //#define ADXL345 //#define BMA020 //#define BMA180 //#define BMA280 //#define NUNCHACK // if you want to use the nunckuk as a standalone I2C ACC without WMP //#define LIS3LV02 //#define LSM303DLx_ACC //#define MMA8451Q /* I2C barometer */ //#define BMP085 //#define MS561101BA /* I2C magnetometer */ //#define HMC5843 //#define HMC5883 //#define AK8975 //#define MAG3110 /* Sonar */ // for visualization purpose currently - no control code behind //#define SRF02 // use the Devantech SRF i2c sensors //#define SRF08 //#define SRF10 //#define SRF23 /* ADC accelerometer */ // for 5DOF from sparkfun, uses analog PIN A1/A2/A3 //#define ADCACC /* enforce your individual sensor orientation - even overrides board specific defaults */ //#define FORCE_ACC_ORIENTATION(X, Y, Z) {imu.accADC[ROLL] = Y; imu.accADC[PITCH] = -X; imu.accADC[YAW] = Z;} //#define FORCE_GYRO_ORIENTATION(X, Y, Z) {imu.gyroADC[ROLL] = -Y; imu.gyroADC[PITCH] = X; imu.gyroADC[YAW] = Z;} //#define FORCE_MAG_ORIENTATION(X, Y, Z) {imu.magADC[ROLL] = X; imu.magADC[PITCH] = Y; imu.magADC[YAW] = Z;} Failsafe Option The term Failsafe by traditional interpretation maybe a misnomer here however it is suggested if you are using a RX that does not have its own failsafe procedures. The MWC failsafe monitor the input from the RX for values within the 1000ms to 2000mz zone and if not, will enable the failsafe. At this stage, failsafe is basically a control crash. It enable auto-leveling if the flight controller has an accelerometer and adjust the throttle to the defined value listed below. Here is addition info on Fail safe. /******** Failsafe settings ********************/ /* Failsafe check pulses on four main control channels CH1-CH4. If the pulse is missing or bellow 985us (on any of these four channels) the failsafe procedure is initiated. After FAILSAFE_DELAY time from failsafe detection, the level mode is on (if ACC or nunchuk is avaliable), PITCH, ROLL and YAW is centered and THROTTLE is set to FAILSAFE_THROTTLE value. You must set this value to descending about 1m/s or so for best results. This value is depended from your configuration, AUW and some other params. Next, after FAILSAFE_OFF_DELAY the copter is disarmed, and motors is stopped. If RC pulse coming back before reached FAILSAFE_OFF_DELAY time, after the small quard time the RC control is returned to normal. */ #define FAILSAFE // uncomment to activate the failsafe function #define FAILSAFE_DELAY 10 // Guard time for failsafe activation after signal lost. 1 step = 0.1sec - 1sec in example #define FAILSAFE_OFF_DELAY 200 // Time for Landing before motors stop in 0.1sec. 1 step = 0.1sec - 20sec in example #define FAILSAFE_THROTTLE (MINTHROTTLE + 200) // (*) Throttle level used for landing - may be relative to MINTHROTTLE - as in this case #define FAILSAFE_DETECT_TRESHOLD 985 Motor Stop Option The MOTOR_STOP option is suggested but not required. What it does is, the motors will not spin up when the throttle is at it lowest point. This can be helpful during the arming procedure. /**************************************************************************************/ /*********************** motor, servo and other presets ***********************/ /**************************************************************************************/ /* motors will not spin when the throttle command is in low position this is an alternative method to stop immediately the motors */ //#define MOTOR_STOP
- Transmitter Configuration Mixing Setting Make sure the set the Transmitter mixing settings to ACRO (No mixing) in the US, type two or type One for else where. This procedure will very according to the brand so please consult your owner manual for special details of how this is done. Setting End Points Adjust the endpoints for the Pitch, Roll, Yaw and Throttle channels to their maximum allowable points or 1000ms for the low and 2000ms for the high. Trim the following channels as required. Throttle: 1000 - 1020 ms Pitch : 1500 Roll : 1500 Yaw : 1500 The GUI may be used as feedback if they are unable to be set via the transmitter. Set your transmitter end points. Using the WinGUI or MW Config open the RC CONTROLS tab look at the live tx data, then use your tx sub trim to set the throttle low at 1000 and all the mid sticks at 1500. Then using the tx end points adjustment make the throttle high point 2000, yaw left 1000, yaw right 2000, pitch down 1000, pitch up 2000, roll left 1000, roll right 2000. You may have to readjust for 1500 center. Ensure that all readings move in direction of TX sticks & switches (maximum value when the sticks are in the upper right corner). Reverse on TX if not. Note: Do not set Ends Points less than 1000 or greater than 2000. Slightly within these limits is better than any value going outside these limits. The remaining channels, set to 1500ms but not critical for setup at this time
- ESC Calibration The ESC Calibration is the very foundation for a well tuned aircraft. With this said, not all ESCs are created equality. Some, the end points are configurable (preferred) where others have a fixed points. Importantly the calibration of the ESCs min/max points using direct connection to RX which should be in the general area of 1050 to 2000ms. For this process, it is strongly suggestion to remove the props and have a means of quickly disconnection the battery if something should go wrong. There are other methods but this is easiest. Ensure motors are turning in correct direction with correct props for rotation & not mounted upside down. External Method Calibration One method is to build a simple connector using header pins with the top (Signal) and the bottom (ground) connected. The 5th pin would be connected to the RX throttle pin. This will assure all ESCs have the same signals values sent to them. MWC Special Build ESC Calibration /********************************************************************/ /**** ESCs calibration ****/ /********************************************************************/ /* to calibrate all ESCs connected to MWii at the same time (useful to avoid unplugging/re-plugging each ESC) Warning: this creates a special version of MultiWii Code You cannot fly with this special version. It is only to be used for calibrating ESCs Read How To at http://code.google.com/p/multiwii/wiki/ESCsCalibration */ #define ESC_CALIB_LOW MINCOMMAND #define ESC_CALIB_HIGH 2000 //#define ESC_CALIB_CANNOT_FLY // uncomment to activate
- GUI Interface Next connect to PC running WinGUI or MW Config. Calibrate ACC with FC level & not moving & Mag by moving FC thru all axis in 30seconds. Check graphs & readouts to confirm accurate calibration. NOTES 1. Don't expect motor speed graphs to rise in sync & hold speed in GUI when quad not flying. This is normal & part of PID control Accelerometer Calibration Place the copter on a level surface and level the copter, a bubble leveler is not required but is helpful for better accuracy. There are two methods for Acc Calibration, By clicking the ACC Cal button in the GUI Or by using the Stick combination. Image shown is for Mode II transmitters.
- First Flight Testing Safety First First and foremost, safely first. (Need to expand) Be aware that if you choose to run the MW version preinstalled on the FC it may have Motor_Stop uncommented. This is not recommended for beginners as motors will not spin on arming & you will not know if Min Throttle is set correctly. Min Throttle should be set to lowest speed that will cause all motors to start reliably every time that quad is armed Fight Test For the very first attempt at fight, it is best to have all modes (auto-leveling, Heading and Altitude Holding etc.) Disabled. Increase throttle slightly then decrease throttle fully and the motors need to be still rotating, if they stop then your min throttle setting needs increasing slightly. With all sensors calibrated correctly and mag declination set, using the default PIDs and in a nice open space ARM with throttle low and yaw right. Throttle-up slowly watching for the first signs of liftoff. Note any variations in Roll and Pitch axis, if the differences are contain, trim the axis in question. If there is Oscillation. this will require adjusting the P value for that axis. Make sure not to over control the copter, at this point in the flight, very little control is necessary. At this stage of testing, ground turbulence is actually a good friend because if the Gyro is well tuned, the copter should be able to correct itself. PID settings Proportional: Stubbornness to say in place Integral: Heading hold, or lenience regarding gradual shifts Derivative : Speed, aggression to make corrections. The P was called many different things in the old days of instrumentation, ratio, rate, band, I/O and many more. It actually means that an input value change will give an output value change times a multiplier. The I value used to be called reset, time, and other things, it means time based on value of input/setpoint or vice versa in some instances multiplied by a corrective value. D the derivative is a bit harder to explain, but means mostly that an upset that happens very quick and/or large enough that it would not be handled by normal more gentle P and I can be handled by a complex calculation. D has to be used cautiously for it can induce violent outputs very quickly. In deeper words, D functions on the angle of the rate of change instead of the rate of change. Other Try again and if the motor idle speed is stable increase throttle quickly to approx. 50% and hover. If it drifts use TX trims to prevent it. Next enable Horizon mode. If quad drifts backwards just land disarm with throttle low yaw left. Then trim ACC with throttle high and hold your pitch roll stick in the opposite direction to the drift so in this case forward hold there until the light on your board flashes 5 times then centre stick, throttle low and rearm and try again. Repeat as required. DO NOT touch TX TRIMS to counter drift as you have already set this in Acro. Remember If you calibrate ACC again using GUI (or ACC stick Cal) you will lose these ACC adjustments & have to do it again. If motors don't have enough power to climb then vibration is probably your issue unless bad or low capacity Lipo. Buy good composite or CF props with quality adapters, balance everything & then retry. You may still need to set Gyro filter to 42Hz in Config.h if it won't climb or flies erratically. You should now have a nice stable quad (or at least as you can get without PID adjustment) & can then move on to GPS modes for which you will find plenty of info on in this Forum. I hope this will help you and maybe others to get flying. It's a big learning curve but definitely worth it! :D 3. If you intend to use advanced GPS functions such as Missions, Land, Fencing etc, download MW2.3 NaviB7 for FC & WinGUI pre 10 for NaviB7 from http://www.eosbandi.com These GPS modes beyond Pos Hold & RTH require an FC with Atmega 2560 microcontroller. The Crius AIOP V1 & V2 are typical. Configure for your quad & upload to FC