V2.2 - ACRO PID implementation is wrong, right?

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Noctaro » Fri Jul 05, 2013 8:10 am

Hey,
i am sorry to say, but after rereading this "V2.2 - ACRO PID implementation is wrong" threat, i am more confused then before.
Is there a way to explain in a few simple words, what is the major difference between Alex.K. mod and Oldschool? Also some theory of what changes it should do inflight? A brief summary? I think this would help many testpilots.
I know the basics of PID controllers, but i dont get what different influence PID now has. D is still dampening, but taking care of error angle and stick inputs?

For YAW PID:
please reread this post, this is not a sudden and unexpected change:
viewtopic.php?f=8&t=3213


@Alexinparis
i dont get the point. This has nothing to do with the ?yawbug? i could observe in Alex.K. mod, right?

Greetz Noc
Noctaro
 
Posts: 280
Joined: Thu Sep 08, 2011 11:15 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Phil S. » Fri Jul 05, 2013 11:31 am

I cannot reproduce your yawbug, Noc. But: I use switches to start and stop motors so when arming my props don´t start spinning immediately as they probably do without the use of a throttle hold function. I think it could be possible that the arming procedure at the same time includes a little bit of yaw input as this is the same kind of stick deflection. Being still on the ground the copter is not able to yaw as steered but it is as soon as it gets airborne.
It´s the same story with single rotors and HH gyros. You plug in the battery anywhere close to the airfield, gyro boots and memorizes the actual heading. Then you carry the heli to the pad possibly changing its heading. Since rotors are standing still, gyro can´t correct but hardly tries pitching tail rotor. Imagine the surprise experiencing a 700 size machine suddenly yawing up to 180 degrees immediately after takeoff without any pilot´s input!

Do you kind of flick yaw stick back to center after arming? Try to control it a bit more instead!

To me the big thing of Alex´ mod ist the separation of turn rates from PID values. Looking for agility you don´t have to sacrifice stability any more. And that´s how it feels now, responsive AND stable all the time! Yaw axis mostly benefits from that, it is not inferior to other FCs any more.
Phil S.
 
Posts: 32
Joined: Fri Apr 26, 2013 7:59 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Noctaro » Fri Jul 05, 2013 12:25 pm

Hey Phil S.!

I think it could be possible that the arming procedure at the same time includes a little bit of yaw input as this is the same kind of stick deflection.

Hehehe, you are so right. I was thinking of the same. First i thought of the gyro memorizing power on position.

What you said makes perfect sense, as i do arm my quad using yaw input. I will set it to arm via AUX and give it a try.
Further i will go back to stick arming and try to control the stick more smooth to see if it really is based on the arming procedure.

I will not dare to imagine whats happening in a pilots brain as a 700size machine starts to do its own fun on yaw. Better to get some tank for hiding inside while flying :D

To me the big thing of Alex´ mod ist the separation of turn rates from PID values

Thank you so much, that made things a lot of clearer to me. But it seems that new Oldschool PID controller (DEV1505) does the same now, regarding to the behaviour i could observe at testing.
Even as i lowered LPF to 42hz it was the same behaviour on Input, either i used higher PIDs.
So is there any sense of further testing this mod or should we stick to the tuned oldschool controller as it seems to do the same?

Thank you for your patience with me to understand what is going on :)

Greetz Noc
Noctaro
 
Posts: 280
Joined: Thu Sep 08, 2011 11:15 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby alex.khoroshko » Fri Jul 05, 2013 1:22 pm

Hello!
So is there any sense of further testing this mod
There are some more differences. In my implementation the angle rates loop is always active. The angle and horizon mode are just the additions to rate loop - they are now controlled with single parameter, as the PID is already tuned for ACRO. I guess this parameter would be the same for all possible aircrafts as the airframe dynamics is separated with inner PID loop - I think removing a few parameters from "tune before flying" list is a good thing. Also, horizon mode in my version is initially made for soft leveling, it moves towards horizontal position slowly (it helps hovering a bit but feels totally like ACRO when agressive flying) - me and, I guess, some other guys prefer it this way. Actually, the ordinary ACRO is made this way in ardupilot. I've already modified the code so that it's possible to get the feel from soft leveling (as I like it) to total level mode with flip-enabling addition (as it is in old-school implementation). Tests are planned for tomorrow.
Also, this 'memory effect' issue is strange. Actually, gyros indicate not position, but rates. No matter how far you set the gyro from initial position, is would still output zero. The only place, where the value can be stored is integrator. I observed, that when yawing incorrectly while trying to take off, the tail servo can go to one of the edges on my KK2.0 board. There were no problems to take off after that, though - it moves into the right position as soon as the tri lifts above the ground (there's a tiny overshoot, but nothing criminal). I guess the problem you're discussing is elsewhere.
alex.khoroshko
 
Posts: 27
Joined: Sun Jun 09, 2013 9:17 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Phil S. » Fri Jul 05, 2013 3:24 pm

alex.khoroshko wrote:1: I think removing a few parameters from "tune before flying" list is a good thing.

2: Actually, the ordinary ACRO is made this way in ardupilot.

3: Also, this 'memory effect' issue is strange.

I: Agree, I like this concept of a central control loop, which gets input either directly from Pilot or from GPS or Baro or ACC or anywhere else. There is a similar tendency with ArduPilot at the moment, in terms of reducing parameters as I really don´t have the abillity to talk about codes.

2: Are you familiar with latest developments of ArduCopter, as here and here? Since last week ArduCopter is capable of true aerobatics. I tried it already and it feels pretty much the same as AlexK MW 2.2! Do you see similaritiy to your concept?

3: In single rotor HH gyros there is a kind of memory saving position which is calculated by integrating rate over time. If this is not the case in your code or MW code in general maybe Noc´s problem is kind of trim issue? I.e. being just a bit out of PWM center signal integrator sums up between arming and takeoff resulting in these little yaw jumps?
Phil S.
 
Posts: 32
Joined: Fri Apr 26, 2013 7:59 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby alex.khoroshko » Fri Jul 05, 2013 4:00 pm

Are you familiar with latest developments of ArduCopter, as here and here?

No, never looked through the code. I know for ACRO because I tried the MegaPirateNG and I didn't like the inability to turn on or off this soft self-level feature. It's good idea to learn something from them - I would look through when I have a time.
The loop from second link looks the same. Not surprisingly - this concept is standard for control systems. It is like hardware abstraction level in programming - allows to apply the same for different hardware. I really hope that the concept would allow to move all the coefficients except the rate PID (and may be even these too, see below) into some "advanced" tab of GUI which generally won't need tuning at all. It's important to pass the automatic controls (level, GPS etc) without applying the sticks scaling to avoid the need to retune anything else. Also, old school implementation adjusts the dynamic PID coefficients by sticks even when sticks are not used, like in RTH mode - this looks kinda weird to me.

I've already written this idea in current thread, but it was left unnoticed - the rate PID coefficients and baro coefficients are all scaled with multirotor's thrust to weigh ratio. I have an idea to separate this ratio into the dedicated variable and try to self-tune it. This way there would be, generally, no coefficients to tune at all. If self-tune idea would fail, there's still just one coefficient for unexperienced user to adjust - concept looks good for me. But I need to first test what I've written so far before applying any other modifications.
alex.khoroshko
 
Posts: 27
Joined: Sun Jun 09, 2013 9:17 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Phil S. » Fri Jul 05, 2013 4:23 pm

alex.khoroshko wrote:I didn't like the inability to turn on or off this soft self-level feature.

This is possible, with ArduCopter and MegapirateNG as well. It´s not too obvious, just set ACRO_BAL and ACRO_TRAINER to zero, that´s it. Until latest Ardu mod it was still not possible to flip but any selfleveling was deactivated.
Phil S.
 
Posts: 32
Joined: Fri Apr 26, 2013 7:59 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby alex.khoroshko » Fri Jul 05, 2013 5:03 pm

I didn't know that, thanks - I turned it off using self level slider (or something similar, don't remember the exact name) somewhere in advanced parameters list.
But, I wanted to say to do that in-flight. Here's the reason why I want it. When I fly FPV and I'm on some reasonable altitude, the wind tries to blow the copter away (it does this inconsistently, but on the altitude it's not notable). In pure acro the copter doesn't self level thus there's no need to compensate the drift - I can throw the sticks and the copter stays in the place for a reasonable time because it stays inclined towards the wind. In all the other cases self-leveling (soft or hard) is good. When flying in reasonable winds, I missed the off switch so much, and now the issue is fixed.

This ardupilot thread gave me some, IMO, awesome idea. The ACRO PID is not ideal (the error can not be zero when some external variable forces are applied), so whenever the wind gust happens or alike, the copter changes its angle. To avoid that, we should calculate the current angle, which was set by sticks (it would be continuously changing if the sticks are not centered) and if current, ACC-based angle doesn't match - correct the position by the difference. It would feel exactly like the pure ACRO, but should increase the precision very much - PI regulator would result in zero average angle drift! I would try the idea in the first place tomorrow.
alex.khoroshko
 
Posts: 27
Joined: Sun Jun 09, 2013 9:17 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby copterrichie » Fri Jul 05, 2013 5:15 pm

Question, do anyone believe this topic is more about personal likes and dislike?
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby alex.khoroshko » Fri Jul 05, 2013 5:25 pm

I don't think so. IMO the general purpose software should be able to fit the needs of everyone, that's why the personal preferences are discussed so often here. It's quite a challenge to make the system in the way that everyone would like it.
alex.khoroshko
 
Posts: 27
Joined: Sun Jun 09, 2013 9:17 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Phil S. » Fri Jul 05, 2013 6:19 pm

You are right, Alex, no way to toggle between soft leveling and pure acro at the moment but to adjust level speed by modifying ACRO_BAL directly or by the slider you mentioned. The guys seem to work on the implementation of additional flight modes similar to MW´s Acro ("Pure Acro") and Horizon (of your style).

Talking about personal taste you are right again! FC should be able to fit the needs of every pilot with as simple as possible the setup can be. But to me oldschool WM had limitations impacting the general purpose usability.

The ACRO PID you described not being ideal is MW´s and Ardu uses the ACC angle corrected method?
Phil S.
 
Posts: 32
Joined: Fri Apr 26, 2013 7:59 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Noctaro » Fri Jul 05, 2013 6:59 pm

Hey,
thanks Alex k. for the explanation, i think i can imagine now what your mod does.
thanks Phil s. for the try to reproduce and thinking of my problem.

As i have done further testings, i have some news. It seems to be the yawstick input, what the controller rembers to.
I changed arming procedure to AUX and could takeoff in nearly normal manner.
I figured out, that if i put some yaw to the left before activating arm switch, the copter turns left. If i yaw right and pull the switch it will turn right. (Of course at arming sticks are centered.)
Dont know where this may be based on, but in my case its reproducable, and does explain the yaw to right when using stick arming procedure.

Btw. this only happens with PID control 2, oldschool seems not react to any stick input before arming.

Hope this helped a bit to find the source of this strange and a bit dangerous behaviour. My copter is small and will not do too much damage if it gets out of control, but its still kind of scary to takeoff.
As mentioned, once the copter is in air, everything seems to work as it should. (in ACRO)

Greetz Noc
Noctaro
 
Posts: 280
Joined: Thu Sep 08, 2011 11:15 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby bartwaw » Fri Jul 05, 2013 10:53 pm

Hi,
has anyone compiled conf which can share. I've tried but it is going slowly out of range my knowledge :0

I only like one mode - acro :) so it would be nice to test that great pid controller.

I'm little fighting with my small quad on HK Nanowii. My lately problems with it:
http://www.rcgroups.com/forums/showthread.php?t=1814075
bartwaw
 
Posts: 18
Joined: Thu May 05, 2011 9:43 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby alex.khoroshko » Sat Jul 06, 2013 1:45 am

Hope this helped a bit to find the source of this strange and a bit dangerous behaviour

Thank you, I got it. Original PID sets to zero the I component of control when the error is too big (for example when on the ground). Mine doesn't for purpose to keep I control at extreme maneuvers - my bad quad flies better this way. I would search for workaround, may be tweak the I limit value or alike.
alex.khoroshko
 
Posts: 27
Joined: Sun Jun 09, 2013 9:17 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby -ralf- » Sat Jul 06, 2013 8:50 am

bartwaw wrote:Hi,
has anyone compiled conf which can share. I've tried but it is going slowly out of range my knowledge :0


Download the latest dev ....

http://multiwii.googlecode.com/files/MultiWii_dev_2013_07_05_r1514.zip
-ralf-
 
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Nickman1200 » Sat Jul 06, 2013 11:32 am

bartwaw wrote:Hi,
has anyone compiled conf which can share. I've tried but it is going slowly out of range my knowledge :0

I only like one mode - acro :) so it would be nice to test that great pid controller.

I'm little fighting with my small quad on HK Nanowii. My lately problems with it:
http://www.rcgroups.com/forums/showthread.php?t=1814075


Here is a build i made 1 hour ago.
https://www.dropbox.com/s/y37ptyen5adfims/application.windows32.zip
Nickman1200
 
Posts: 36
Joined: Sat Jul 06, 2013 10:31 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby bartwaw » Sat Jul 06, 2013 7:31 pm

Hi

thanks for links with compiled conf.
Here' my last baby - strictly acro quad (made in hungary :) )


vid from test flights with new PID controller.

http://www.youtube.com/watch?v=Zv2t-vf1 ... wfytQwYVUA
FHD vid.

Settings:
Image


First thoughts:
1. Nice
2. Nice
3. don't works changing to angle/horizon - but who cares, this is strictly acro machine.
4. flips makes much more different than in 2.1, little overshot then fast back to desired position (but please notice i didn't specially play with PID values)
5. Yaw has little drift. On 2.1 didn't saw this behaviour
6. on fast descend quad is very stable.
7. good initialisation of stabilisation (when you go to much low with throttle)
8. don't pitch up on FF

If you want i have logs from multiwii EZ-GUI when i was flying.

Code: Select all
  /**************************    The type of multicopter    ****************************/
   
    #define QUADX
 

  /****************************    Motor minthrottle    *******************************/
    /* Set the minimum throttle command sent to the ESC (Electronic Speed Controller)
       This is the minimum value that allow motors to run at a idle speed  */
    //#define MINTHROTTLE 1300 // for Turnigy Plush ESCs 10A
    //#define MINTHROTTLE 1120 // for Super Simple ESCs 10A
    #define MINTHROTTLE 1064 // special ESC (simonk)
    //#define MINTHROTTLE 1050 // for brushed ESCs like ladybird
    //#define MINTHROTTLE 1150 // (*) (**)

  /****************************    Motor maxthrottle    *******************************/
    /* this is the maximum value for the ESCs at full power, this value can be increased up to 2000 */
    #define MAXTHROTTLE 1970

  /****************************    Mincommand          *******************************/
    /* this is the value for the ESCs when they are not armed
       in some cases, this value must be lowered down to 900 for some specific ESCs, otherwise they failed to initiate */
    #define MINCOMMAND  1000

  /**********************************    I2C speed   ************************************/
    #define I2C_SPEED 100000L     //100kHz normal mode, this value must be used for a genuine WMP
    //#define I2C_SPEED 400000L   //400kHz fast mode, it works only with some WMP clones

  /***************************    Internal i2c Pullups   ********************************/
    /* enable internal I2C pull ups (in most cases it is better to use external pullups) */
    //#define INTERNAL_I2C_PULLUPS

  /**************************************************************************************/
  /*****************          boards and sensor definitions            ******************/
  /**************************************************************************************/

    /***************************    Combined IMU Boards    ********************************/
     
      #define NANOWII         // the smallest multiwii FC based on MPU6050 + pro micro based proc <- confirmed by Alex
     
     
     

/*************************************************************************************************/
/*****************                                                                 ***************/
/****************  SECTION  2 - COPTER TYPE SPECIFIC OPTIONS                               *******/
/*****************                                                                 ***************/
/*************************************************************************************************/

  /********************************  PID Controller *********************************/
    /* choose one of the alternate PID control algorithms
     * 1 = evolved oldschool algorithm (similar to v2.2)
     * 2 = new experimental algorithm from Alex Khoroshko http://www.multiwii.com/forum/viewtopic.php?f=8&t=3671&start=10#p37387
     * */
    #define PID_CONTROLLER 2

    /* NEW: not used anymore for servo coptertypes  <== NEEDS FIXING - MOVE TO WIKI */
    #define YAW_DIRECTION 1
    //#define YAW_DIRECTION -1 // if you want to reverse the yaw correction direction

  /********************************    ARM/DISARM    *********************************/
   /* optionally disable stick combinations to arm/disarm the motors.
     * In most cases one of the two options to arm/disarm via TX stick is sufficient */
    #define ALLOW_ARM_DISARM_VIA_TX_YAW
    //#define ALLOW_ARM_DISARM_VIA_TX_ROLL

  /********************************    SERVOS      *********************************/
   
  /***********************          Cam Stabilisation             ***********************/
 
  /***********************          Airplane                       ***********************/
    //#define USE_THROTTLESERVO // For use of standard 50Hz servo on throttle.

    //#define FLAPPERONS    AUX4          // Mix Flaps with Aileroins.
    #define FLAPPERON_EP   { 1500, 1700 } // Endpooints for flaps on a 2 way switch else set {1020,2000} and program in radio.
    #define FLAPPERON_INVERT { -1, 1 }    // Change direction om flapperons { Wing1, Wing2 }
   
    //#define FLAPS                       // Traditional Flaps on SERVO3.
    //#define FLAPSPEED     3             // Make flaps move slowm Higher value is Higher Speed.

  /***********************      Common for Heli & Airplane         ***********************/

 
  /***********************          Heli                           ***********************/
    /* Channel to control CollectivePitch */
    #define COLLECTIVE_PITCH      THROTTLE

    /* Limit the range of Collective Pitch. 100% is Full Range each way and position for Zero Pitch */
    #define COLLECTIVE_RANGE { 80, 0, 80 }// {Min%, ZeroPitch offset from 1500, Max%}.
    #define YAWMOTOR                 0       // If a motor is used as YAW Set to 1 else set to 0.

    /* Servo mixing for heli 120
                         {Coll,Nick,Roll} */
    #define SERVO_NICK   { +10, -10,  0 }
    #define SERVO_LEFT   { +10, +5, +10 }
    #define SERVO_RIGHT  { +10, +5, -10 }

    /* Limit Maximum controll for Roll & Nick  in 0-100% */
    #define CONTROL_RANGE   { 100, 100 }      //  { ROLL,PITCH }

    /* use servo code to drive the throttle output. You want this for analog servo driving the throttle on IC engines.
       if inactive, throttle output will be treated as a motor output, so it can drive an ESC */
    //#define HELI_USE_SERVO_FOR_THROTTLE

  /***********************      your individual mixing     ***********************/
 
/*************************************************************************************************/
/*****************                                                                 ***************/
/****************  SECTION  3 - RC SYSTEM SETUP                                            *******/
/*****************                                                                 ***************/
/*************************************************************************************************/

  /**************************************************************************************/
  /********                       special receiver types             ********************/
  /**************************************************************************************/

    /****************************    PPM Sum Reciver    ***********************************/
      /* The following lines apply only for specific receiver with only one PPM sum signal, on digital PIN 2
         Select the right line depending on your radio brand. Feel free to modify the order in your PPM order is different */
      #define SERIAL_SUM_PPM         PITCH,YAW,THROTTLE,ROLL,AUX1,AUX2,AUX3,AUX4,8,9,10,11 //For Graupner/Spektrum
      //#define SERIAL_SUM_PPM         ROLL,PITCH,THROTTLE,YAW,AUX1,AUX2,AUX3,AUX4,8,9,10,11 //For Robe/Hitec/Futaba
      //#define SERIAL_SUM_PPM         ROLL,PITCH,YAW,THROTTLE,AUX1,AUX2,AUX3,AUX4,8,9,10,11 //For Multiplex
      //#define SERIAL_SUM_PPM         PITCH,ROLL,THROTTLE,YAW,AUX1,AUX2,AUX3,AUX4,8,9,10,11 //For some Hitec/Sanwa/Others
   

    /**********************    Spektrum Satellite Reciver    *******************************/
   
/*************************************************************************************************/
/*****************                                                                 ***************/
/****************  SECTION  4 - ALTERNATE CPUs & BOARDS                                    *******/
/*****************                                                                 ***************/
/*************************************************************************************************/

  /**************************************************************************************/
  /********                      Promini Specifig Settings           ********************/
  /**************************************************************************************/

    /**************************    Hexa Motor 5 & 6 Pins    *******************************/
   
    /*********************************    Aux 2 Pin     ***********************************/
   


  /**************************************************************************************/
  /*****************             Teensy 2.0 Support                    ******************/
  /**************************************************************************************/
   
  /**************************************************************************************/
  /********   Settings for ProMicro, Leonardo and other Atmega32u4 Boards     ***********/
  /**************************************************************************************/

    /*********************************    pin Layout     **********************************/
      /* activate this for a better pinlayout if all pins can be used => not possible on ProMicro */
      //#define A32U4ALLPINS

    /**********************************    PWM Setup     **********************************/
      /* activate all 6 hardware PWM outputs Motor 5 = D11 and 6 = D13.
         note: not possible on the sparkfun promicro (pin 11 & 13 are not broken out there)
         if activated:
         Motor 1-6 = 10-bit hardware PWM
         Motor 7-8 = 8-bit Software PWM
         Servos    = 8-bit Software PWM
         if deactivated:
         Motor 1-4 = 10-bit hardware PWM
         Motor 5-8 = 10-bit Software PWM
         Servos    = 10-bit Software PWM */
      //#define HWPWM6

    /**********************************    Aux 2 Pin     **********************************/
      /* AUX2 pin on pin RXO */
      //#define RCAUX2PINRXO

      /* aux2 pin on pin D17 (RXLED) */
      //#define RCAUX2PIND17

    /**********************************    Buzzer Pin    **********************************/
      /* this moves the Buzzer pin from TXO to D8 for use with ppm sum or spectrum sat. RX (not needed if A32U4ALLPINS is active) */
      #define D8BUZZER

    /***********************      Promicro version related     ****************************/
      /* Inverted status LED for Promicro ver 10 */
      //#define PROMICRO10


  /**************************************************************************************/
  /********                      override default pin assignments    ********************/
  /**************************************************************************************/

  /* only enable any of this if you must change the default pin assignment, e.g. your board does not have a specific pin */
  /* you may need to change PINx and PORTx plus #shift according to the desired pin! */
  //#define OVERRIDE_V_BATPIN                   A0 // instead of A3    // Analog PIN 3

  //#define OVERRIDE_PSENSORPIN                 A1 // instead of A2    // Analog PIN 2

  //#define OVERRIDE_LEDPIN_PINMODE             pinMode (A1, OUTPUT); // use A1 instead of d13
  //#define OVERRIDE_LEDPIN_TOGGLE              PINC |= 1<<1; // PINB |= 1<<5;     //switch LEDPIN state (digital PIN 13)
  //#define OVERRIDE_LEDPIN_OFF                 PORTC &= ~(1<<1); // PORTB &= ~(1<<5);
  //#define OVERRIDE_LEDPIN_ON                  PORTC |= 1<<1;    // was PORTB |= (1<<5);

  //#define OVERRIDE_BUZZERPIN_PINMODE          pinMode (A2, OUTPUT); // use A2 instead of d8
  //#define OVERRIDE_BUZZERPIN_ON               PORTC |= 1<<2 //PORTB |= 1;
  //#define OVERRIDE_BUZZERPIN_OFF              PORTC &= ~(1<<2); //PORTB &= ~1;

/*************************************************************************************************/
/*****************                                                                 ***************/
/****************  SECTION  5 - ALTERNATE SETUP                                            *******/
/*****************                                                                 ***************/
/*************************************************************************************************/

  /******                Serial com speed    *********************************/
    /* This is the speed of the serial interfaces */
    #define SERIAL0_COM_SPEED 115200
    #define SERIAL1_COM_SPEED 115200
    #define SERIAL2_COM_SPEED 115200
    #define SERIAL3_COM_SPEED 115200

    /* interleaving delay in micro seconds between 2 readings WMP/NK in a WMP+NK config
       if the ACC calibration time is very long (20 or 30s), try to increase this delay up to 4000
       it is relevent only for a conf with NK */
    #define INTERLEAVING_DELAY 3000

    /* when there is an error on I2C bus, we neutralize the values during a short time. expressed in microseconds
       it is relevent only for a conf with at least a WMP */
    #define NEUTRALIZE_DELAY 100000


  /**************************************************************************************/
  /********                              Gyro filters                ********************/
  /**************************************************************************************/

    /*********************    Lowpass filter for some gyros    ****************************/
      /* ITG3200 & ITG3205 Low pass filter setting. In case you cannot eliminate all vibrations to the Gyro, you can try
         to decrease the LPF frequency, only one step per try. As soon as twitching gone, stick with that setting.
         It will not help on feedback wobbles, so change only when copter is randomly twiching and all dampening and
         balancing options ran out. Uncomment only one option!
         IMPORTANT! Change low pass filter setting changes PID behaviour, so retune your PID's after changing LPF.*/
      //#define ITG3200_LPF_256HZ     // This is the default setting, no need to uncomment, just for reference
      //#define ITG3200_LPF_188HZ
      //#define ITG3200_LPF_98HZ
      //#define ITG3200_LPF_42HZ
      //#define ITG3200_LPF_20HZ
      //#define ITG3200_LPF_10HZ      // Use this only in extreme cases, rather change motors and/or props

      /* MPU6050 Low pass filter setting. In case you cannot eliminate all vibrations to the Gyro, you can try
         to decrease the LPF frequency, only one step per try. As soon as twitching gone, stick with that setting.
         It will not help on feedback wobbles, so change only when copter is randomly twiching and all dampening and
         balancing options ran out. Uncomment only one option!
         IMPORTANT! Change low pass filter setting changes PID behaviour, so retune your PID's after changing LPF.*/
      //#define MPU6050_LPF_256HZ     // This is the default setting, no need to uncomment, just for reference
      //#define MPU6050_LPF_188HZ
      //#define MPU6050_LPF_98HZ
      //#define MPU6050_LPF_42HZ
      //#define MPU6050_LPF_20HZ
      //#define MPU6050_LPF_10HZ
      //#define MPU6050_LPF_5HZ       // Use this only in extreme cases, rather change motors and/or props

    /******                Gyro smoothing    **********************************/
      /* GYRO_SMOOTHING. In case you cannot reduce vibrations _and_ _after_ you have tried the low pass filter options, you
         may try this gyro smoothing via averaging. Not suitable for multicopters!
         Good results for helicopter, airplanes and flying wings (foamies) with lots of vibrations.*/
      //#define GYRO_SMOOTHING {20, 20, 3}    // (*) separate averaging ranges for roll, pitch, yaw

    /************************    Moving Average Gyros    **********************************/
      //#define MMGYRO 10                      // (*) Active Moving Average Function for Gyros
      //#define MMGYROVECTORLENGTH 15          // Length of Moving Average Vector (maximum value for tunable MMGYRO
      /* Moving Average ServoGimbal Signal Output */
      //#define MMSERVOGIMBAL                  // Active Output Moving Average Function for Servos Gimbal
      //#define MMSERVOGIMBALVECTORLENGHT 32   // Lenght of Moving Average Vector

  /************************    Analog Reads              **********************************/
    /* if you want faster analog Reads, enable this. It may result in less accurate results, especially for more than one analog channel */
    //#define FASTER_ANALOG_READS

/*************************************************************************************************/
/*****************                                                                 ***************/
/****************  SECTION  6 - OPTIONAL FEATURES                                          *******/
/*****************                                                                 ***************/
/*************************************************************************************************/

  /************************        Angele throttle correction         ********************/
  /* Automatically increase throttle based on the angle of the copter
     Original idea by Kraut Rob, first implementation HAdrian                     */

  //#define THROTTLE_ANGLE_CORRECTION 40
 
 /*************************        Advanced Headfree Mode             ********************/
 /* In Advanced Headfree mode when the copter is farther than ADV_HEADFREE_RANGE meters then
    the  bearing between home and copter position will become the control direction
   IF copter come closer than ADV_HEADFREE_RANGE meters, then the control direction freezed to the
   bearing between home and copter at the point where it crosses the ADV_HEADFREE_RANGE meter distance
   first implementation by HAdrian, mods by EOSBandi
 */

   //#define ADVANCED_HEADFREE                           //Advanced headfree mode is enabled when this is uncommented
   //#define ADV_HEADFREE_RANGE 15                        //Range where advanced headfree mode activated


  /************************        continuous gyro calibration        ********************/
  /* Gyrocalibration will be repeated if copter is moving during calibration. */
    //#define GYROCALIBRATIONFAILSAFE

  /************************        AP FlightMode        **********************************/
    /* Temporarily Disables GPS_HOLD_MODE to be able to make it possible to adjust the Hold-position when moving the sticks.*/
    #define AP_MODE 40  // Create a deadspan for GPS.
       
  /************************   Assisted AcroTrainer    ************************************/
    /* Train Acro with auto recovery. Value set the point where ANGLE_MODE takes over.
       Remember to activate ANGLE_MODE first!...
       A Value on 200 will give a very distinct transfer */
    //#define ACROTRAINER_MODE 200   // http://www.multiwii.com/forum/viewtopic.php?f=16&t=1944#p17437


  /********                          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


  /*****************                DFRobot LED RING    *********************************/
    /* I2C DFRobot LED RING communication */
    //#define LED_RING

  /********************************    LED FLASHER    ***********************************/
    //#define LED_FLASHER
    //#define LED_FLASHER_DDR DDRB
    //#define LED_FLASHER_PORT PORTB
    //#define LED_FLASHER_BIT PORTB4
    //#define LED_FLASHER_INVERT
    //#define LED_FLASHER_SEQUENCE        0b00000000      // leds OFF
    //#define LED_FLASHER_SEQUENCE_ARMED  0b00000101      // create double flashes
    //#define LED_FLASHER_SEQUENCE_MAX    0b11111111      // full illumination
    //#define LED_FLASHER_SEQUENCE_LOW    0b00000000      // no illumination


  /*******************************    Landing lights    *********************************/
  /* Landing lights
     Use an output pin to control landing lights.
     They can be switched automatically when used in conjunction
     with altitude data from a sonar unit. */
    //#define LANDING_LIGHTS_DDR DDRC
    //#define LANDING_LIGHTS_PORT PORTC
    //#define LANDING_LIGHTS_BIT PORTC0
    //#define LANDING_LIGHTS_INVERT

    /* altitude above ground (in cm) as reported by sonar */
    //#define LANDING_LIGHTS_AUTO_ALTITUDE 50

    /* adopt the flasher pattern for landing light LEDs */
    //#define LANDING_LIGHTS_ADOPT_LED_FLASHER_PATTERN

  /*************************    INFLIGHT ACC Calibration    *****************************/
    /* This will activate the ACC-Inflight calibration if unchecked */
    //#define INFLIGHT_ACC_CALIBRATION

  /*******************************    OSD Switch    *************************************/
    // This adds a box that can be interpreted by OSD in activation status (to switch on/off the overlay for instance)
  //#define OSD_SWITCH

  /**************************************************************************************/
  /***********************                  TX-related         **************************/
  /**************************************************************************************/

    /* introduce a deadband around the stick center
       Must be greater than zero, comment if you dont want a deadband on roll, pitch and yaw */
    //#define DEADBAND 6

    /* defines the neutral zone of throttle stick during altitude hold, default setting is
       +/-40 uncommend and change the value below if you want to change it. */
    //#define ALT_HOLD_THROTTLE_NEUTRAL_ZONE 40


  /**************************************************************************************/
  /***********************                  GPS                **************************/
  /**************************************************************************************/

    /* GPS using a SERIAL port
       if enabled, define here the Arduino Serial port number and the UART speed
       note: only the RX PIN is used in case of NMEA mode, the GPS is not configured by multiwii
       in NMEA mode the GPS must be configured to output GGA and RMC NMEA sentences (which is generally the default conf for most GPS devices)
       at least 5Hz update rate. uncomment the first line to select the GPS serial port of the arduino */
       
    //#define GPS_SERIAL 2         // should be 2 for flyduino v2. It's the serial port number on arduino MEGA
    //#define GPS_PROMINI_SERIAL   // Will Autosense if GPS is connected when ardu boots.

    // avoid using 115200 baud because with 16MHz arduino the 115200 baudrate have more than 2% speed error (57600 have 0.8% error)
    #define GPS_BAUD   57600

   /* GPS protocol
       NMEA  - Standard NMEA protocol GGA, GSA and RMC  sentences are needed
       UBLOX - U-Blox binary protocol, use the ublox config file (u-blox-config.ublox.txt) from the source tree
       MTK_BINARY16 and MTK_BINARY19 - MTK3329 chipset based GPS with DIYDrones binary firmware (v1.6 or v1.9)
       With UBLOX and MTK_BINARY you don't have to use GPS_FILTERING in multiwii code !!! */

   
    //#define NMEA
    //#define UBLOX
    //#define MTK_BINARY16
    //#define MTK_BINARY19
    //#define INIT_MTK_GPS        // initialize MTK GPS for using selected speed, 5Hz update rate and GGA & RMC sentence or binary settings

   
    /* I2C GPS device made with an independant arduino + GPS device
       including some navigation functions
       contribution from EOSBandi   http://code.google.com/p/i2c-gps-nav/
       You have to use at least I2CGpsNav code r33 */
    //#define I2C_GPS
    // If your I2C GPS board has Sonar support enabled
    //#define I2C_GPS_SONAR

    /* I2C GPS device made with an indeedent ATTiny[24]313 + GPS device and
       optional sonar device.    https://github.com/wertarbyte/tiny-gps/ */
    /* get GPS data from Tiny-GPS */
    //#define TINY_GPS
    /* get sonar data from Tiny-GPS */
    //#define TINY_GPS_SONAR

    /* GPS data readed from Misio-OSD - GPS module connected to OSD, and MultiWii read GPS data from OSD - tested and working OK ! */
    //#define GPS_FROM_OSD

    /* indicate a valid GPS fix with at least 5 satellites by flashing the LED  - Modified by MIS - Using stable LED (YELLOW on CRIUS AIO) led work as sat number indicator
      - No GPS FIX -> LED blink at speed of incoming GPS frames
      - Fix and sat no. bellow 5 -> LED off
      - Fix and sat no. >= 5 -> LED blinks, one blink for 5 sat, two blinks for 6 sat, three for 7 ... */
    #define GPS_LED_INDICATOR

    //#define USE_MSP_WP                        //Enables the MSP_WP command, which is used by WinGUI to display and log Home and Poshold positions

    //#define DONT_RESET_HOME_AT_ARM             // HOME position is reset at every arm, uncomment it to prohibit it (you can set home position with GyroCalibration)

    /* GPS navigation can control the heading */
   
    #define NAV_CONTROLS_HEADING       true      // copter faces toward the navigation point, maghold must be enabled for it
    #define NAV_TAIL_FIRST             false     // true - copter comes in with tail first
    #define NAV_SET_TAKEOFF_HEADING    true      // true - when copter arrives to home position it rotates it's head to takeoff direction
   
   
    /* Get your magnetic declination from here : http://magnetic-declination.com/
       Convert the degree+minutes into decimal degree by ==> degree+minutes*(1/60)
       Note the sign on declination it could be negative or positive (WEST or EAST) */
    //#define MAG_DECLINATION  3.96f              //For Budapest Hungary.
    #define MAG_DECLINATION  0.0f   //(**)

    #define GPS_LEAD_FILTER                      // Adds a forward predictive filterig to compensate gps lag. Code based on Jason Short's lead filter implementation
   
    //#define GPS_FILTERING                        // add a 5 element moving average filter to GPS coordinates, helps eliminate gps noise but adds latency comment out to disable
    #define GPS_WP_RADIUS              200       // if we are within this distance to a waypoint then we consider it reached (distance is in cm)
    #define NAV_SLEW_RATE              30        // Adds a rate control to nav output, will smoothen out nav angle spikes


  /**************************************************************************************/
  /***********************        LCD/OLED - display settings       *********************/
  /**************************************************************************************/

    /* http://www.multiwii.com/wiki/index.php?title=Extra_features#LCD_.2F_OLED */

    /*****************************   The type of LCD     **********************************/
      /* choice of LCD attached for configuration and telemetry, see notes below */
      //#define LCD_DUMMY       // No Physical LCD attached.  With this & LCD_CONF defined, TX sticks still work to set gains, by watching LED blink. 
      //#define LCD_SERIAL3W    // Alex' initial variant with 3 wires, using rx-pin for transmission @9600 baud fixed
      //#define LCD_TEXTSTAR    // SERIAL LCD: Cat's Whisker LCD_TEXTSTAR Module CW-LCD-02 (Which has 4 input keys for selecting menus)
      //#define LCD_VT100       // SERIAL LCD: vt100 compatible terminal emulation (blueterm, putty, etc.)
      //#define LCD_TTY         // SERIAL LCD: useful to tweak parameters over cable with arduino IDE 'serial monitor'
      //#define LCD_ETPP        // I2C LCD: Eagle Tree Power Panel LCD, which is i2c (not serial)
      //#define LCD_LCD03       // I2C LCD: LCD03, which is i2c
      //#define OLED_I2C_128x64 // I2C LCD: OLED http://www.multiwii.com/forum/viewtopic.php?f=7&t=1350
      //#define OLED_DIGOLE     // I2C OLED from http://www.digole.com/index.php?productID=550

    /******************************   Display settings   ***********************************/
      #define LCD_SERIAL_PORT 0    // must be 0 on Pro Mini and single serial boards; Set to your choice on any Mega based board

      //#define SUPPRESS_OLED_I2C_128x64LOGO  // suppress display of OLED logo to save memory

    /* double font height for better readability. Reduces visible #lines by half.
     * The lower part of each page is accessible under the name of shifted keyboard letter :
     * 1 - ! , 2 - @ , 3 - # , 4 - $ , 5 - % , 6 - ^ , 7 - & , 8 - * , 9 - (
     * You must add both to your lcd.telemetry.* sequences
     */
      //#define DISPLAY_FONT_DSIZE //currently only aplicable for OLED_I2C_128x64 and OLED_DIGOLE

    /* style of display - AUTODETECTED via LCD_ setting - only activate to override defaults */
      //#define DISPLAY_2LINES
      //#define DISPLAY_MULTILINE
      //#define MULTILINE_PRE 2  // multiline configMenu # pref lines
      //#define MULTILINE_POST 6 // multiline configMenu # post lines
      //#define DISPLAY_COLUMNS 16
    /********************************    Navigation     ***********************************/
    /* keys to navigate the LCD menu */
      #define LCD_MENU_PREV 'p'
      #define LCD_MENU_NEXT 'n'
      #define LCD_VALUE_UP 'u'
      #define LCD_VALUE_DOWN 'd'

      #define LCD_MENU_SAVE_EXIT 's'
      #define LCD_MENU_ABORT 'x'

  /**************************************************************************************/
  /***********************      LCD configuration menu         **************************/
  /**************************************************************************************/

    /* uncomment this line if you plan to use a LCD or OLED for tweaking parameters
     * http://www.multiwii.com/wiki/index.php?title=Extra_features#Configuration_Menu */
      //#define LCD_CONF

    /* to include setting the aux switches for AUX1 -> AUX4 via LCD */
      //#define LCD_CONF_AUX

    /* optional exclude some functionality - uncomment to suppress unwanted aux channel configuration options */
      //#define SUPPRESS_LCD_CONF_AUX2
      //#define SUPPRESS_LCD_CONF_AUX34

  /**************************************************************************************/
  /***********************      LCD       telemetry            **************************/
  /**************************************************************************************/

    /* to monitor system values (battery level, loop time etc. with LCD
     * http://www.multiwii.com/wiki/index.php?title=LCD_Telemetry */

    /********************************    Activation     ***********************************/
    //#define LCD_TELEMETRY

    /* to enable automatic hopping between a choice of telemetry pages uncomment this. */
    //#define LCD_TELEMETRY_AUTO "123452679" // pages 1 to 9 in ascending order
    //#define LCD_TELEMETRY_AUTO  "212232425262729" // strong emphasis on page 2

    /* manual stepping sequence; first page of the sequence gets loaded at startup to allow non-interactive display */
    //#define LCD_TELEMETRY_STEP "0123456789" // should contain a 0 to allow switching off.

    /* optional exclude some functionality - uncomment to suppress some unwanted telemetry pages */
    //#define SUPPRESS_TELEMETRY_PAGE_1
    //#define SUPPRESS_TELEMETRY_PAGE_2
    //#define SUPPRESS_TELEMETRY_PAGE_3
    //#define SUPPRESS_TELEMETRY_PAGE_4
    //#define SUPPRESS_TELEMETRY_PAGE_5
    //#define SUPPRESS_TELEMETRY_PAGE_6
    //#define SUPPRESS_TELEMETRY_PAGE_7
    //#define SUPPRESS_TELEMETRY_PAGE_8
    //#define SUPPRESS_TELEMETRY_PAGE_9
    //#define SUPPRESS_TELEMETRY_PAGE_R

  /********************************************************************/
  /****                             RSSI                           ****/
  /********************************************************************/
    //#define RX_RSSI
    //#define RX_RSSI_PIN A3

  /********************************************************************/
  /****                             Buzzer                         ****/
  /********************************************************************/
    #define BUZZER
    //#define RCOPTIONSBEEP         // uncomment this if you want the buzzer to beep at any rcOptions change on channel Aux1 to Aux4
    //#define ARMEDTIMEWARNING 330  // (*) Trigger an alarm after a certain time of being armed [s] to save you lipo (if your TX does not have a countdown)
    //#define PILOTLAMP             //Uncomment if you are using a X-Arcraft Pilot Lamp

  /********************************************************************/
  /****           battery voltage monitoring                       ****/
  /********************************************************************/
    /* for V BAT monitoring
       after the resistor divisor we should get [0V;5V]->[0;1023] on analog V_BATPIN
       with R1=33k and R2=51k
       vbat = [0;1023]*16/VBATSCALE
       must be associated with #define BUZZER ! */
    #define VBAT              // uncomment this line to activate the vbat code
    #define VBATSCALE       126 // (*) (**) change this value if readed Battery voltage is different than real voltage
    #define VBATNOMINAL     126 // 12,6V full battery nominal voltage - only used for lcd.telemetry
    #define VBATLEVEL_WARN1 109 // (*) (**) 10,9V
    #define VBATLEVEL_WARN2  99 // (*) (**) 9.9V
    #define VBATLEVEL_CRIT   96 // (*) (**) 9.6V - critical condition: if vbat ever goes below this value, permanent alarm is triggered
    #define NO_VBAT          16 // Avoid beeping without any battery


  /********************************************************************/
  /****           powermeter (battery capacity monitoring)         ****/
  /********************************************************************/

    /* enable monitoring of the power consumption from battery (think of mAh)
       allows to set alarm value in GUI or via LCD
      Full description and howto here http://www.multiwii.com/wiki/index.php?title=Powermeter
       Two options:
       1 - hard: - (uses hardware sensor, after configuration gives very good results)
       2 - soft: - (good results +-5% for plush and mystery ESCs @ 2S and 3S, not good with SuperSimple ESC)    */
    //#define POWERMETER_SOFT
    //#define POWERMETER_HARD
    #define PSENSORNULL 510 /* (*) hard only: set to analogRead() value for zero current; for I=0A my sensor
                                   gives 1/2 Vss; that is approx 2.49Volt; */
    #define PINT2mA 132     /* (*) hard: one integer step on arduino analog translates to mA (example 4.9 / 37 * 1000) ;
                                   soft: use fictional value, start with 100.
                                   for hard and soft: larger PINT2mA will get you larger value for power (mAh equivalent) */

  /********************************************************************/
  /****           altitude hold                                    ****/
  /********************************************************************/

    /* uncomment to disable the altitude hold feature.
     * This is useful if all of the following apply
     * + you have a baro
     * + want altitude readout and/or variometer
     * + do not use altitude hold feature
     * + want to save memory space
     */
    //#define SUPPRESS_BARO_ALTHOLD

  /* Natural alt change for rapid pilots. It's temporary switch OFF the althold when throttle stick is out of deadband defined with ALT_HOLD_THROTTLE_NEUTRAL_ZONE
   * but if it's commented: Smooth alt change routine is activated, for slow auto and aerophoto modes (in general solution from alexmos). It's slowly increase/decrease
   * altitude proportional to stick movement (+/-100 throttle gives about +/-50 cm in 1 second with cycle time about 3-4ms)
   */
  #define ALTHOLD_FAST_THROTTLE_CHANGE

  /********************************************************************/
  /****           altitude variometer                              ****/
  /********************************************************************/

    /* enable to get audio feedback upon rising/falling copter/plane.
     * Requires a working baro.
     * For now, Output gets sent to an enabled vt100 terminal program over the serial line.
     * choice of two methods (enable either one or both)
     * method 1 : use short term movement from baro ( bigger code size)
     * method 2 : use long term observation of altitude from baro (smaller code size)
     */
    //#define VARIOMETER 12            // possible values: 12 = methods 1 & 2 ; 1 = method 1 ; 2 = method 2
    //#define SUPPRESS_VARIOMETER_UP   // if no signaling for up movement is desired
    //#define SUPPRESS_VARIOMETER_DOWN // if no signaling for down movement is desired
    //#define VARIOMETER_SINGLE_TONE   // use only one tone (BEL); neccessary for non-patched vt100 terminals

  /********************************************************************/
  /****           baord naming                                     ****/
  /********************************************************************/

    /*
     * this name is displayed together with the MultiWii version number
     * upon powerup on the LCD.
     * If you are without a DISPLAYD then You may enable LCD_TTY and
     * use arduino IDE's serial monitor to view the info.
     *
     * You must preserve the format of this string!
     * It must be 16 characters total,
     * The last 4 characters will be overwritten with the version number.
     */
    #define BOARD_NAME "MultiWii   V-.--"
    //                  123456789.123456

  /*************      Support multiple configuration profiles in EEPROM     ************/
    //#define MULTIPLE_CONFIGURATION_PROFILES

  /*************      do no reset constants when change of flashed program is detected ***********/
    //#define NO_FLASH_CHECK

/*************************************************************************************************/
/*****************                                                                 ***************/
/****************  SECTION  7 - TUNING & DEVELOPER                                  **************/
/*****************                                                                 ***************/
/*************************************************************************************************/

  /**************************************************************************************/
  /********   special ESC with extended range [0-2000] microseconds  ********************/
  /**************************************************************************************/
    //#define EXT_MOTOR_RANGE // using this with wii-esc requires to change MINCOMMAND to 1008 for promini and mega

  /**************************************************************************************/
  /***********************     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

    /* some radios have not a neutral point centered on 1500. can be changed here */
    #define MIDRC 1500

  /***********************         Servo Refreshrates            ***********************/
    /* Default 50Hz Servo refresh rate*/
    #define SERVO_RFR_50HZ

    /* up to 160Hz servo refreshrate .. works with the most analog servos*/
    //#define SERVO_RFR_160HZ

    /* up to 300Hz refreshrate it is as fast as possible (100-300Hz depending on the cound of used servos and the servos state).
       for use with digital servos
       dont use it with analog servos! thay may get damage. (some will work but be careful) */
    //#define SERVO_RFR_300HZ
   
  /***********************             HW PWM Servos             ***********************/
    /* HW PWM Servo outputs for Arduino Mega.. moves:
      Pitch   = pin 44
      Roll    = pin 45
      CamTrig = pin 46
      SERVO4  = pin 11 (aileron left for fixed wing or TRI YAW SERVO)
      SERVO5  = pin 12 (aileron right for fixed wing)
      SERVO6  = pin 6   (rudder for fixed wing)
      SERVO7  = pin 7   (elevator for fixed wing)
      SERVO8  = pin 8   (motor for fixed wing)       */

    #define MEGA_HW_PWM_SERVOS
 
    /* HW PWM Servo outputs for 32u4 NanoWii, MicroWii etc. - works with either the variable SERVO_RFR_RATE or
     * one of the 3 fixed servo.refresh.rates *
     * Tested only for heli_120, i.e. 1 motor + 4 servos, moves..
     * motor[0] = motor       = pin  6
     * servo[3] = nick  servo = pin 11
     * servo[4] = left  servo = pin 10
     * servo[5] = yaw   servo = pin  5
     * servo[6]  = right servo= pin  9
     */
    //#define A32U4_4_HW_PWM_SERVOS

    #define SERVO_RFR_RATE  50    // In Hz, you can set it from 20 to 400Hz, used only in HW PWM mode for mega and 32u4
    //#define SERVO_PIN5_RFR_RATE  200    // separate yaw pwm rate.
                                          // In Hz, you can set it from 20 to 400Hz, used only in HW PWM mode for 32u4


  /********************************************************************/
  /****           Memory savings                                   ****/
  /********************************************************************/

    /* options to counter the general shortage of both flash and ram memory, like with leonardo m32u4 and others */

    /**** suppress handling of serial commands.***
     * This does _not_ affect handling of RXserial, Spektrum or GPS. Those will not be affected and still work the same.
     * Enable either one or both of the following options  */

      /* Remove handling of all commands of the New MultiWii Serial Protocol.
       * This will disable use of the GUI, winGUI, android apps and any other program that makes use of the MSP.
       * You must find another way (like LCD_CONF) to tune the parameters or live with the defaults.
       * If you run a LCD/OLED via i2c or serial/Bluetooth, this is safe to use */
      //#define SUPPRESS_ALL_SERIAL_MSP // saves approx 2700 bytes

      /* Remove handling of other serial commands.
       * This includes navigating via serial the lcd.configuration menu, lcd.telemetry and permanent.log .
       * Navigating via stick inputs on tx is not affected and will work the same.  */
      //#define SUPPRESS_OTHER_SERIAL_COMMANDS // saves  approx 0 to 100 bytes, depending on features enabled

    /**** suppress keeping the defaults for initial setup and reset in the code.
     * This requires a manual initial setup of the PIDs etc. or load and write from defaults.mwi;
     * reset in GUI will not work on PIDs
     */
    //#define SUPPRESS_DEFAULTS_FROM_GUI
   
    //#define DISABLE_SETTINGS_TAB  // Saves ~400bytes on ProMini

  /********************************************************************/
  /****           diagnostics                                      ****/
  /********************************************************************/

    /* to log values like max loop time and others to come
       logging values are visible via LCD config
       set to 1, enable 'R' option to reset values, max current, max altitude
       set to 2, adds min/max cycleTimes
       set to 3, adds additional powerconsumption on a per motor basis (this uses the big array and is a memory hog, if POWERMETER <> PM_SOFT) */
    //#define LOG_VALUES 1

    /* Permanent logging to eeprom - survives (most) upgrades and parameter resets.
     * used to track number of flights etc. over lifetime of controller board.
     * Writes to end of eeprom - should not conflict with stored parameters yet.
     * Logged values: accumulated lifetime, #powercycle/reset/initialize events, #arm events, #disarm events, last armedTime,
     *                #failsafe@disarm, #i2c_errs@disarm
     * Enable one or more options to show the log
     */
    //#define LOG_PERMANENT
    //#define LOG_PERMANENT_SHOW_AT_STARTUP // enable to display log at startup
    //#define LOG_PERMANENT_SHOW_AT_L // enable to display log when receiving 'L'
    //#define LOG_PERMANENT_SHOW_AFTER_CONFIG // enable to display log after exiting LCD config menu
    //#define LOG_PERMANENT_SERVICE_LIFETIME 36000 // in seconds; service alert at startup after 10 hours of armed time

    /* to add debugging code
       not needed and not recommended for normal operation
       will add extra code that may slow down the main loop or make copter non-flyable */
    //#define DEBUG
    //#define DEBUG_FREE // will add 'F' command to show free memory

    /* Use this to trigger LCD configuration without a TX - only for debugging - do NOT fly with this activated */
    //#define LCD_CONF_DEBUG

    /* Use this to trigger telemetry without a TX - only for debugging - do NOT fly with this activated */
    //#define LCD_TELEMETRY_DEBUG    //This form rolls between all screens, LCD_TELEMETRY_AUTO must also be defined.
    //#define LCD_TELEMETRY_DEBUG 6  //This form stays on the screen specified.

    /* Enable string transmissions from copter to GUI */
    //#define DEBUGMSG


  /********************************************************************/
  /****           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

  /****           internal frequencies                             ****/
    /* frequenies for rare cyclic actions in the main loop, depend on cycle time
       time base is main loop cycle time - a value of 6 means to trigger the action every 6th run through the main loop
       example: with cycle time of approx 3ms, do action every 6*3ms=18ms
       value must be [1; 65535] */
    #define LCD_TELEMETRY_FREQ 23       // to send telemetry data over serial 23 <=> 60ms <=> 16Hz (only sending interlaced, so 8Hz update rate)
    #define LCD_TELEMETRY_AUTO_FREQ 1967// to step to next telemetry page 967 <=> 3s
    #define PSENSOR_SMOOTH 16           // len of averaging vector for smoothing the PSENSOR readings; should be power of 2; set to 1 to disable
    #define VBAT_SMOOTH 16              // len of averaging vector for smoothing the VBAT readings; should be power of 2; set to 1 to disable
    #define RSSI_SMOOTH 16              // len of averaging vector for smoothing the RSSI readings; should be power of 2; set to 1 to disable

  /********************************************************************/
  /****           Dynamic Motor/Prop Balancing                     ****/
  /********************************************************************/
  /*                   !!! No Fly Mode !!!                            */
      
    //#define DYNBALANCE   // (**) Dynamic balancing controlled from Gui

  /********************************************************************/
  /****           Regression testing                               ****/
  /********************************************************************/

    /* for development only:
       to allow for easier and reproducable config sets for test compiling, different sets of config parameters are kept
       together. This is meant to help detecting compile time errors for various features in a coordinated way.
       It is not meant to produce your flying firmware
       To use:
       - do not set any options in config.h,
       - enable with #define COPTERTEST 1, then compile
       - if possible, check for the size
       - repeat with other values of 2, 3, 4 etc.
        */
    //#define COPTERTEST 1

/*************************************************************************************************/
/*****************                                                                 ***************/
/****************  SECTION  8 - DEPRECATED                                                 *******/
/*****************                                                                 ***************/
/*************************************************************************************************/

  /* these features will be removed in the unforseeable future. Do not build new products or
   * functionality based on such features. The default for all such features is OFF.
   */

  /**************************    WMP power pin     *******************************/
  //#define D12_POWER      // Use D12 on PROMINI to power sensors. Will disable servo[4] on D12
  /* disable use of the POWER PIN (allready done if the option RCAUXPIN12 is selected) */
  #define DISABLE_POWER_PIN


/*************************************************************************************************/
/****           END OF CONFIGURABLE PARAMETERS                                                ****/
/*************************************************************************************************/



I get lucky on 4:51
bartwaw
 
Posts: 18
Joined: Thu May 05, 2011 9:43 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby copterrichie » Sat Jul 06, 2013 7:41 pm

@Bartwaw, KUDOS!!! VERY NICE JOB, very nice!
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby NikTheGreek » Sat Jul 06, 2013 9:00 pm

I like the sound of the motors when flies near the camera :D
User avatar
NikTheGreek
 
Posts: 348
Joined: Thu Dec 08, 2011 4:17 pm
Location: Greece

Postby BarneyG » Sat Jul 06, 2013 9:30 pm

just have to say ... epic video .... I tried those settings (well I turned the rates down a fair bit :)) on my 450 clone and wow ... the best flight I've had with the thing since I started in the hobby a few months back. The arm were rock solid ... very few of the little twitches I've been seeing and descending through itsmown propwash was an absolute dream. The yaw was a bit off for mine ... it kept going even after the stick was centered. It still hasn't got rid of its tendency to randomly yaw a few degrees to the right or left (though more frequently to the right)

How are people tuning the pids with this new algorithm, what I've been trying to do was starting from the default, drop I to 0 and then increase P till oscillations start. I've had this up to over 6 and still not had any oscillations, so I've not got to doing the D or I values yet.
BarneyG
 
Posts: 39
Joined: Tue May 07, 2013 4:42 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby szepnorbee » Sun Jul 07, 2013 11:23 am

Hi

The f.HORIZON_MODE and f.ANGLE_MODE why don't work with new pid controller? It is something limitation? Why is it necessary?

Thx
szepnorbee
 
Posts: 4
Joined: Wed Dec 26, 2012 10:15 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby ummagawd » Mon Jul 08, 2013 5:47 am

So Ive read the first 2 pages and the last 3... This sounds exciting as I've been reading up on other FCs (not that I'm dissatisfied, but mwc is my first FC). I fly a T-copter and am in this mainly for aggressive/acrobatic flying, and am now venturing into FPV land.

The new enhancements sound intriguing (feels like acro when you want it, but still holds position like horizon/angle when you want it) that sounds like the best for both aggressive acro and FPV without really needing to flip a switch.

I get the PID separation from scaling though I haven't toyed enough to notice it. I think I understand the changes from a technical standpoint (sounds like the PID algorithm is leaner).

Would I be able to replace only a certain portion of the code to try this? I'm running a unlocked GPS, and DFR LED ring. And am just afraid to mess that up.

Thanks for the continuing evolution of mwc
ummagawd
 
Posts: 21
Joined: Fri May 24, 2013 3:47 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby trello » Sun Jul 14, 2013 12:45 pm

I was trying to get the r1514 to work with the new algorithm, i just changed this line in the config:

Code: Select all
#define PID_CONTROLLER 2


I get very high values on two motors, looks like some issue with yaw? Did i miss anything? Board is a Crius SE v2.

Image
trello
 
Posts: 19
Joined: Wed Apr 10, 2013 1:04 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby sorg » Sun Jul 14, 2013 1:35 pm

So, i tried AlexK Pid today:

Gyro mode is working nice. I ended with more or less the same tuning as the oldschool controller. I can find that the stick are a lot more sensitive... this lead me to do some mistake and to crash twice. I wil have to get used to it.

Yaw is less stable than before. I have not been able to find suitable tuning.

Angle mode is weird... It is not gyro mode... (I feel that something is keeping me not to far from horizontal), but it is not self levelling... I tried to move P-level from 0 to 20 ithout good result (except one broken arm on my frame while playing with high value of P).

I don't know if it is the expected result, but it i not suitable for me...I love the level mode for the safety I get when i fly too far from me too see in what direction is angled my quad.
sorg
 
Posts: 34
Joined: Mon Apr 08, 2013 2:49 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby U.Sentenza » Sun Jul 14, 2013 4:26 pm

Hello Trello, i too have the same problem ...
Does anyone have any idea?
User avatar
U.Sentenza
 
Posts: 17
Joined: Fri May 17, 2013 11:44 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby chris_kmn » Sun Jul 14, 2013 6:29 pm

U.Sentenza wrote:Hello Trello, i too have the same problem ...
Does anyone have any idea?


I experienced the same on my quad. Two props are reving quite high and the other two are on idle. Could it be related to an overflow? My Tri-problem with silly reving props described before also seems very awkward..... I stopped testing/using the new PID algorithm.
Last edited by chris_kmn on Sun Jul 14, 2013 8:53 pm, edited 1 time in total.
chris_kmn
 
Posts: 31
Joined: Sun Jun 09, 2013 11:11 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby brm » Sun Jul 14, 2013 8:28 pm

trello wrote:I was trying to get the r1514 to work with the new algorithm, i just changed this line in the config:

Code: Select all
#define PID_CONTROLLER 2


I get very high values on two motors, looks like some issue with yaw? Did i miss anything? Board is a Crius SE v2.

Image


the copter is armed - what do you expect?
the board is ok - the operator needs a few afterscool lessons ...
brm
 
Posts: 287
Joined: Mon Jun 25, 2012 12:00 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby chris_kmn » Sun Jul 14, 2013 8:55 pm

brm wrote:
the copter is armed - what do you expect?
the board is ok - the operator needs a few afterscool lessons ...


Do you need reading and understanding lessons ? Or just some behaviour lessons ?
chris_kmn
 
Posts: 31
Joined: Sun Jun 09, 2013 11:11 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby brm » Sun Jul 14, 2013 9:32 pm

the alg. works great.

armed means the pid calculations are active. the i term will wind up.
the Picture Shows an expected behaviour - nothing unusual.
brm
 
Posts: 287
Joined: Mon Jun 25, 2012 12:00 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby BarneyG » Sun Jul 14, 2013 11:33 pm

sorg wrote:So, i tried AlexK Pid today:

Gyro mode is working nice. I ended with more or less the same tuning as the oldschool controller. I can find that the stick are a lot more sensitive... this lead me to do some mistake and to crash twice. I wil have to get used to it.

Yaw is less stable than before. I have not been able to find suitable tuning.

Angle mode is weird... It is not gyro mode... (I feel that something is keeping me not to far from horizontal), but it is not self levelling... I tried to move P-level from 0 to 20 ithout good result (except one broken arm on my frame while playing with high value of P).

I don't know if it is the expected result, but it i not suitable for me...I love the level mode for the safety I get when i fly too far from me too see in what direction is angled my quad.



Strange ... I've back ported these changes into the 2.2 release and I'm finding angled mode self levels just fine not that I've used it much since I've put them in as Acro mode has been so stable for me. Of course since I'm new to RC flying things I'd only just got my head round doing banking turns with Angle mode on ... I've got to relearn now :)
BarneyG
 
Posts: 39
Joined: Tue May 07, 2013 4:42 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Noctaro » Mon Jul 15, 2013 7:26 am

Hi there,
and thank you Alex for your answer, now i do understand why this yaw bahaviour happened to me ;)
But i have a further question.
Alex.K. (you) recommended me to play with the "I- limit" value.
That sounds a bit scary to me. Isnt there a way to ignore "I-Windup" before leaving minthrottle state?
At least for yaw?
Its not too funny to counter the Yaw I windup at arming by moving yaw-stick and listening to my motors rpm. Thats the only way i managed to takeoff without unwanted yaw for now.

Greetz Noc
Noctaro
 
Posts: 280
Joined: Thu Sep 08, 2011 11:15 am

Patch Re: V2.2 - ACRO PID implementation is wrong, right?

Postby SergioC » Mon Jul 15, 2013 10:36 am

I think I found it. errorGyroI[YAW] is not zeroed when throttle is below MINCHECK.
This is due the two different sets of variables/arrays used by the two PID implementations.

The errorGyroI accumulator variables are zeroed at idle throttle in the following code (MultiWii.cpp:818):
Code: Select all
    // perform actions   
    if (rcData[THROTTLE] <= MINCHECK) {            // THROTTLE at minimum
      errorGyroI[ROLL] = 0; errorGyroI[PITCH] = 0; errorGyroI_YAW = 0;
      errorAngleI[ROLL] = 0; errorAngleI[PITCH] = 0;
      if (conf.activate[BOXARM] > 0) {             // Arming/Disarming via ARM BOX
        if ( rcOptions[BOXARM] && f.OK_TO_ARM ) go_arm(); else if (f.ARMED) go_disarm();
      }
    }


the oldschool controller uses errorAngleI_YAW, the new one uses errorAngleI[YAW], but only the former is zeroed at idle throttle.

So the quickest way to fix is to change into this:
Code: Select all
    // perform actions   
    if (rcData[THROTTLE] <= MINCHECK) {            // THROTTLE at minimum
#if PID_CONTROLLER == 1
      errorGyroI[ROLL] = 0; errorGyroI[PITCH] = 0; errorGyroI_YAW = 0;
#elif PID_CONTROLLER == 2
      errorGyroI[ROLL] = 0; errorGyroI[PITCH] = 0; errorGyroI[YAW] = 0;
#endif
      errorAngleI[ROLL] = 0; errorAngleI[PITCH] = 0;
      if (conf.activate[BOXARM] > 0) {             // Arming/Disarming via ARM BOX
        if ( rcOptions[BOXARM] && f.OK_TO_ARM ) go_arm(); else if (f.ARMED) go_disarm();
      }
    }


You still have to takeoff as soon as you rise the throttle above MINCHECK (1100), if you rev the props some time above idle before taking off the effect is more or less the same: errorGyroI[YAW] will winds up. Also the same happens when you rev at the bench without props.

WARNING: I didn't tested this patch.

Sergioc.
SergioC
 
Posts: 19
Joined: Sat Dec 22, 2012 11:33 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby trello » Mon Jul 15, 2013 4:30 pm

Thanks Sergioc, i tested your code without props and it seems to work fine. I'm also arming with AUX for safe measures. I will fly tonight to see if everything is working well.
trello
 
Posts: 19
Joined: Wed Apr 10, 2013 1:04 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby -ralf- » Mon Jul 15, 2013 4:57 pm

Works for me, thanks Sergioc, with code a little bit smaller ....

Code: Select all
    // perform actions   
    if (rcData[THROTTLE] <= MINCHECK) {            // THROTTLE at minimum
      errorGyroI[ROLL] = 0; errorGyroI[PITCH] = 0; errorGyroI_YAW = 0; errorGyroI[YAW] = 0;
      errorAngleI[ROLL] = 0; errorAngleI[PITCH] = 0;
      if (conf.activate[BOXARM] > 0) {             // Arming/Disarming via ARM BOX
        if ( rcOptions[BOXARM] && f.OK_TO_ARM ) go_arm(); else if (f.ARMED) go_disarm();
      }
    }
-ralf-
 
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Noctaro » Mon Jul 15, 2013 11:16 pm

Hey Sergioc,
thank you for your fast response, good catch. Also for sharing this patch.
Thanks trello and ralf for testing and minimizing code.
I will test it tomorrow :)

Greetz Noc
Noctaro
 
Posts: 280
Joined: Thu Sep 08, 2011 11:15 am

DANGER!!! Re: V2.2 - ACRO PID implementation is wrong, right

Postby SergioC » Wed Jul 17, 2013 10:31 am

-ralf- wrote:Works for me, thanks Sergioc, with code a little bit smaller ....

Code: Select all
    // perform actions   
    if (rcData[THROTTLE] <= MINCHECK) {            // THROTTLE at minimum
      errorGyroI[ROLL] = 0; errorGyroI[PITCH] = 0; errorGyroI_YAW = 0; errorGyroI[YAW] = 0;
      errorAngleI[ROLL] = 0; errorAngleI[PITCH] = 0;
      if (conf.activate[BOXARM] > 0) {             // Arming/Disarming via ARM BOX
        if ( rcOptions[BOXARM] && f.OK_TO_ARM ) go_arm(); else if (f.ARMED) go_disarm();
      }
    }


DANGER: this will work ONLY if you use the Alex PID implementation. The errorGyroI array is only 2 elements long if PID_CONTROLLER is 1 leading to a array overflow when errorGyroI[YAW] is set. Very dangerous. It will zero some other variable. DON'T use this shorter patch, please use my patch (still to be optimized).

Sergioc.

edit: I see the errorGyroI_YAW variable is defined outside the #ifdef PID_CONTROLLER but is used only inside.
SergioC
 
Posts: 19
Joined: Sat Dec 22, 2012 11:33 pm

Re: DANGER!!! Re: V2.2 - ACRO PID implementation is wrong, r

Postby -ralf- » Wed Jul 17, 2013 3:54 pm

SergioC wrote:
-ralf- wrote:Works for me, thanks Sergioc, with code a little bit smaller ....

Code: Select all
    // perform actions   
    if (rcData[THROTTLE] <= MINCHECK) {            // THROTTLE at minimum
      errorGyroI[ROLL] = 0; errorGyroI[PITCH] = 0; errorGyroI_YAW = 0; errorGyroI[YAW] = 0;
      errorAngleI[ROLL] = 0; errorAngleI[PITCH] = 0;
      if (conf.activate[BOXARM] > 0) {             // Arming/Disarming via ARM BOX
        if ( rcOptions[BOXARM] && f.OK_TO_ARM ) go_arm(); else if (f.ARMED) go_disarm();
      }
    }


DANGER: this will work ONLY if you use the Alex PID implementation. The errorGyroI array is only 2 elements long if PID_CONTROLLER is 1 leading to a array overflow when errorGyroI[YAW] is set. Very dangerous. It will zero some other variable. DON'T use this shorter patch, please use my patch (still to be optimized).

Sergioc.

edit: I see the errorGyroI_YAW variable is defined outside the #ifdef PID_CONTROLLER but is used only inside.


OK, I only tested with PID_CONTROLLER==2 .... mea culpa ....

This might be better !?
Code: Select all
    // perform actions   
    if (rcData[THROTTLE] <= MINCHECK) {            // THROTTLE at minimum
      errorGyroI[ROLL] = 0; errorGyroI[PITCH] = 0; errorGyroI_YAW = 0;
      #if PID_CONTROLLER == 2
        errorGyroI[YAW] = 0;
      #endif
      errorAngleI[ROLL] = 0; errorAngleI[PITCH] = 0;
      if (conf.activate[BOXARM] > 0) {             // Arming/Disarming via ARM BOX
        if ( rcOptions[BOXARM] && f.OK_TO_ARM ) go_arm(); else if (f.ARMED) go_disarm();
      }
    }
-ralf-
 
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby janekx » Sat Jul 20, 2013 1:14 pm

Did try this new PID and I am very happy with this, Xquad is smooth. Nice job Alex K.
Did play with PID setting and found something interesting.
The PID change the behaviour only a little like it have own calibration.
Did put on one arm a 200g weight, nice compensation with change I 0.010 to 0.018, impressive.
But looks that PID values changes PID engine only a little, isn't it bad ?
Did noticed small Yaw drift ...
janekx
 
Posts: 63
Joined: Wed Sep 12, 2012 10:08 pm
Location: Brno, Czech Republic

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby bartwaw » Mon Jul 22, 2013 10:28 am

Still happy with 2.2 Alex.
But my quad is not so happy it eats propellers like dragon ;)

http://www.youtube.com/watch?v=IWrNnmCpCmg&feature
bartwaw
 
Posts: 18
Joined: Thu May 05, 2011 9:43 pm

Postby janekx » Sun Jul 28, 2013 7:01 pm

SergioCs code should be added to main multiwii trunk !!!
janekx
 
Posts: 63
Joined: Wed Sep 12, 2012 10:08 pm
Location: Brno, Czech Republic

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Spacefish » Wed Aug 07, 2013 12:30 pm

I use the new PID implementation. Acro mode works pretty well for me,
however i can´t get angle nor horizon mode to do anything, i played arround with the pids for level activated / deactivated the modes, but the quad just behaves like acro-mode no auto-leveling at all.
ACC is calibrated and works (it works with the old PID controls). There is absolutely no change in any motor speed if i tilt the copter 45° and activate Horizon or Anglemode..
Spacefish
 
Posts: 9
Joined: Wed Aug 07, 2013 12:26 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Hamburger » Wed Aug 07, 2013 5:59 pm

We still need suitable default values for pid.controller=2 that would work for most copters and types beyond quad. With no sufficient support the new pid.controller may vanish.
Come on. There was a lot of enthusiasm in the beginning. Now is time to share defaults and values
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby copterrichie » Wed Aug 07, 2013 6:07 pm

Personally, I believe we are pissing on the wrong fire hydrant. But hey, nothing ventured, nothing gain. :)
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby scrat » Thu Aug 08, 2013 8:05 am

Hamburger wrote:We still need suitable default values for pid.controller=2 that would work for most copters and types beyond quad. With no sufficient support the new pid.controller may vanish.
Come on. There was a lot of enthusiasm in the beginning. Now is time to share defaults and values


There was a lot of enthusiasm at the beginning...it is a shame that people leave in the middle of something.
scrat
 
Posts: 925
Joined: Mon Oct 15, 2012 9:47 am
Location: Slovenia

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby felixrising » Thu Aug 08, 2013 8:21 am

People are using it... just need to take some screen caps. Its been implemented in both Baseflight and Harakiri.. I generally find it less forgiving of bad parameters than original Multiwii. Come on people, post your screenshots!
felixrising
 
Posts: 244
Joined: Sat Mar 23, 2013 12:34 am
Location: Australia

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby hinkel » Thu Aug 08, 2013 11:28 am

I test this new PID implementation and it's working just in acro mode with Naze32 and Harakiri code, in angle mode
it is very unsatisfactory for me, this code seems not to be design for Angle mode for the moment so I go back to actual Mwii Harakiri (float) PID code . Screenshots are useless for the moment, if code not work for all application !
hinkel
 
Posts: 109
Joined: Sun Sep 09, 2012 7:24 am

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby gektor » Thu Aug 08, 2013 11:40 am

I've tested the AlexK PID implementation and I liked it very much on my tri.

The Frame is X900 from Hobbyking. I used very small propellers (9x4,5) and 1350 KW Motors for this test.

After Activating GPS I hat an immediate Crash. Perhaps I forgot to engage Angle mode? Or who knows...
Attachments
Tricopter AlexK 01.png
gektor
 
Posts: 10
Joined: Thu Jul 18, 2013 5:20 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby copterrichie » Thu Aug 08, 2013 1:57 pm

The general consensus seems to be, the AlexK PID works well in Acro Mode but does not work well in Angle mode. Which is the mode that I personally tested with on my bicopter resulting in a broken prop. :(
copterrichie
 
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby Hamburger » Thu Aug 08, 2013 5:10 pm

Hm, it was the yaw spiral of death on a tri in horizon mode for me.
Could it be the initial sucess stories came from quads?
User avatar
Hamburger
 
Posts: 2557
Joined: Tue Mar 01, 2011 2:14 pm
Location: air

Re: V2.2 - ACRO PID implementation is wrong, right?

Postby brm » Thu Aug 08, 2013 6:13 pm

the alternative pid Controller works well.
the drawback is the required re-tuning.

this thread is half dead.
the u/int16_t view of doing things causes mw to die slowly.

2nd order harmonic oscilation/vibration can cause serious problems.
brm
 
Posts: 287
Joined: Mon Jun 25, 2012 12:00 pm

PreviousNext

Return to Software development

Who is online

Users browsing this forum: No registered users and 9 guests

cron