one motor less power

NikTheGreek · Post by **NikTheGreek** » Sat Sep 15, 2012 7:23 pm

Hi again.
As you can see the REAR_L motor have less power than the others.
Calibrating my quad seems that it doesnt effect the motor power.
In my first test flight my Quad lift of the ground but tilting left and back.
Is it a motor problem or software ?

bill516 · Post by **bill516** » Sat Sep 15, 2012 8:48 pm

You can trim that out by using the trim switches on the Tx but only in gyro mode, that is level mode not switched on. You can get it flying hands off in this state then you can set about trimming in stable mode. Trim in stable mode is done by either using the sticks to trim or by using the in flight calibration routine, much easier and quicker.

To get a basic trim setting remove props and power up to 50% throttle while hooked up to the GUI then adjust trims to give you equal power to all motors. When you have that set fit the props and do a test flight, you will more than likely need to adjust the trim to get it to fly hands off, or as near as. Doing it this way makes it easier to do the inflight calibration method and even the stick trim method as you can flick stable mode off if your copter lurches around which it might very well do until you get the stable mode trimmed. Once you have it trimmed in gyro and stable mode you should be able to flick between the two modes and not notice a difference.

NikTheGreek · Post by **NikTheGreek** » Sun Sep 16, 2012 10:46 am

My English are poor so i'll try to "decode" ... :oops:

IN VER 2.1

bill516 wrote:You can trim that out by using the trim switches on the Tx but only in gyro mode, that is level mode not switched on.

1.You mean in PASSTHROU MODE right ?

bill516 wrote:You can get it flying hands off in this state then you can set about trimming in stable mode

2.Adjust the motors in PASSTHROU MODE and try to fly it in this mode HANDS OFF(Only throtle) Right ?

bill516 wrote:Trim in stable mode is done by either using the sticks to trim or by using the in flight calibration routine, much easier and quicker.

When step 2 is done recalibrate the quad with PASSTHROU MODE OFF using sticks combination or in flight calibration. Right ?

doughboy · Post by **doughboy** » Sun Sep 16, 2012 10:46 am

What exactly do you mean by flying hands off?

Also, how exactly do you make the motors all have the same power using trims? I also have this problem, and seems like many others do also, so it seems to be a software issue.

Let's just use the example here. Only the rear left motor is low. How do you trim this? Adjusting yaw, roll or pitch will always change the speed of two motors. So if you adjust to make the rear left motor to the correct speed, another motor will not be at the right speed. How do you adjust this?

I also observed while attempting to trim adjust the speeds that the motor speeds can change randomly, making it seem impossible to make all four motors run at the same speed.

Perhaps someone can come up with steps on what trims to adjust to increase or decrease a particular motor speed.

NikTheGreek · Post by **NikTheGreek** » Sun Sep 16, 2012 11:30 am

I made a test by switching places of the back motors.
Back_L <-----> Back_R
What i saw was exactly the same as previus tests(Back_L lower)
which means...
a.my TX is creating the problem ?
b. it is a software problem ?

am i wrong ?

cardboard · Post by **cardboard** » Sun Sep 16, 2012 11:48 am

Was that screenshot taken with the copter in flight or was it held/tethered?

As for trimming, your not trimming direct motor power but overall motion. Imagine a octocopter, you don't a control axis for each motor, the flight controller mixes your inputs (pitch, roll, yaw, throttle) and distributes the control between all the motors to achieve the movement you want. In your case you need to trim both pitch and roll, at the moment you have to much pitch backwards and to much left roll, if you represent this motion as motor power it means the left rear is lowest.

With a brand new copter I like to focus on one axis at a time during trim, for example with your copter....

I would take off in acro mode and fell which way it wants to drift (back and left).
land then trim forward some.
take off again and see if the pitch component is closer to neutral.
land and repeat until pitch is correct.
repeat with roll.
then with yaw if need be.

cardboard · Post by **cardboard** » Sun Sep 16, 2012 11:51 am

Note: pass through mode is only for fixed wing aircraft, you always need the mixing component for a multiecopter.

bill516 · Post by **bill516** » Sun Sep 16, 2012 2:10 pm

Basics on trim.

When you move a trim in one direction it has the opposite effect on the other side, i.e. left motor low, right motor high, trim to reduce high motor will also increase left motor so that they will both match at one point if you go too far with trim then your original problem will be reversed. What you are trying to achieve with trim is a balance, if every thing was perfect you would not need to use trim as everything would be spot on but reality likes to throw spanners into the works. Even though you have your motor rpms perfectly matched if does not mean this will give you level flight or hover, because once you are airborne things like material density come into play and centre of gravity. This might mean that one side is slightly heavier than the other so you need to increase the motor rpm for that side which is done by trim as we only have one throttle input, if you looked at the motor rpm now you would see the heavier side had a higher rpm than the lighter side.

Pass through is not only for fixed wing but multicopter as well. http://ncopters.blogspot.de/2012/04/how ... on-in.html , describes how to use inflight calibration. This is why I said to manually trim the copter using the Tx trim switches (the ones by your Tx sticks) to achieve hands off hover i.e. you dont need to go putting stick input to keep it in one place in gyro only mode. In flight calibration can then be used using the pass through mode to set your stable mode trims, much quicker than stick trim, fly land, stick trim, fly until you get it right.

1. remove props and connect batt and gui

2. throttle up to 50% power then using the trims on the Tx move appropriate trim/s until motor rpms are all equal. Note no sensors are active at this time only the gyro which is on by default.

3. with rpms equal attach props and test fly, adjust Tx trims as required to hover, you should be able to let go of the sticks and the copter remain in the same place. You need to do this in calm conditions so you are not fighting the wind. A slight drift is OK if you are happy with it, what you dont want is any sudden change of direction if you let go of the sticks

4. When flying ok in acro mode follow the link to achieve stable trim. You need to assign a switch to pass through and enable inflight calibration in the sketch.

Once you have done the in flight calibration you should be able to flick stable mode on and off and not notice any big difference in your copter. What you will have to do is remove the trim you added earlier to get level flight as the inflight calibration resets the level point for the gyros and acc, why? Before the inflight calibration the gyro and acc saw a different horizon to you so it was always trying to get to its own level but you counteracted that by applying trim, now by using the inflight calibration you have effectively tilted the gyro and acc to match the real world horizon so you no longer need the trim to counteract the gyro and acc.

doughboy · Post by **doughboy** » Sun Sep 16, 2012 5:29 pm

This info should be in sticky or wiki documentation.

If I am not mistaken, I don't see an option to turn on pass thru mode anymore in 2.1, so in flight calibration is not possible?

I just checked the code,

#if defined(FIXEDWING) || defined(HELICOPTER)
BOXPASSTHRU,
#endif

as such passthru option is available only for FIXEDWING and HELICOPTER type. Hence it is not possible to enable PASSTHRU in QuadX or Quad+ hence the inflight acc calibration using method B cannot be done in 2.1 anymore.

for method a,
Step 3: When copter is leveled (no drift) switch off engines while airborne: copter beeps

this does not lierally shut off the motors right? or does it? looking at the code, it looks like it will actually turn the motors off in mid flight.

if (!f.ARMED)
motor[i] = MINCOMMAND;

ok, I tested by assigning ARMED box to AUX1 switch.
with switch off, I cannot arm via stick. if I switch on, then I can arm with the stick by moving throttle to MIN. while switch is on, I cannot disarm via stick. if I turn the switch off while armed, motor stay armed, and I can disarm using stick by moving throttle to MIN.

doughboy · Post by **doughboy** » Sun Sep 16, 2012 5:37 pm

bill516 wrote:Basics on trim.

When you move a trim in one direction it has the opposite effect on the other side, i.e. left motor low, right motor high, trim to reduce high motor will also increase left motor so that they will both match at one point

I did try this and seems easier said than done because speed is changed two motors at a time. If the software is the one controlling the speed to each motor, and it does not know the quad is unbalanced, then one would think by default, it should be putting out exactly the same speed to all motors no? I still think the software can be improved here. And perhaps add a calibration mode to adjust one motor at a time.

NikTheGreek · Post by **NikTheGreek** » Sun Sep 16, 2012 7:23 pm

One more test.
I replaced the "broken" ESC-Motor pair with a different one and the problem remains as it was, even when i switch the "broken" with one of the other three the problem persists in the READ_L in the GUI !!!!

I'm confused !!!!

HELP !!!!

doughboy · Post by **doughboy** » Sun Sep 16, 2012 7:29 pm

each motors value is determined by this

#define PIDMIX(X,Y,Z) rcCommand[THROTTLE] + axisPID[ROLL]*X + axisPID[PITCH]*Y + YAW_DIRECTION * axisPID[YAW]*Z
#ifdef QUADX
motor[0] = PIDMIX(-1,+1,-1); //REAR_R
motor[1] = PIDMIX(-1,-1,+1); //FRONT_R
motor[2] = PIDMIX(+1,+1,+1); //REAR_L
motor[3] = PIDMIX(+1,-1,-1); //FRONT_L
#endif

and axisPID[] values are calculated from corresponding pitch, roll, yaw stick reading, sensor reading and the PID values.
axisPID[axis] = PTerm + ITerm - DTerm;

so it seems to be important that pitch, roll and yaw sticks center point must all be the same value (e.g. 1500) (since all gyro readings will be 0 at rest)
multiwii software relies on your TX to make sure this is the case. I think other software will take the different values and map that internally to all center, since this trimming procedure is not needed for other software.

what still does not make sense though is how one motor can end up with a value so far from the three others. I mean, it makes sense if two motors on the same axis are different from the two motors on the other axis.

doughboy · Post by **doughboy** » Sun Sep 16, 2012 8:12 pm

in 2.1 if I enable INFLIGHT_ACC_CALIBRATION
I get this error during compile

MultiWii.cpp: In function 'void loop()':
MultiWii:834: error: 'BOXPASSTHRU' was not declared in this scope

and since PASSTHRU cannot be enabled unless you are using fixedwing or helicopter,so it seems inflight acc calibration feature is completely broken in 2.1

ok, correction. it is broken in 2.1 shared code. the regular 2.1 code shows all options, while the 2.1 shared tries to show only options that are enabled, but somehow completely removed the passthru option.

I like the improvements in 2.1 shared so I just modifed the code in MultiWii main program file around line 830 as follows (adding ifdef fixedwing and helicopter) so the code will compile with inflight_acc_calibration enabled. I can now do the inflight acc calib using armed switch on 2.1 shared code

#if defined(INFLIGHT_ACC_CALIBRATION)
if (AccInflightCalibrationArmed && f.ARMED && rcData[THROTTLE] > MINCHECK && !rcOptions[BOXARM] ){ // Copter is airborne and you are turning it off via boxarm : start measurement
InflightcalibratingA = 50;
AccInflightCalibrationArmed = 0;
}
#if defined(FIXEDWING) || defined(HELICOPTER)
if (rcOptions[BOXPASSTHRU]) { // Use the Passthru Option to activate : Passthru = TRUE Meausrement started, Land and passtrhu = 0 measurement stored
if (!AccInflightCalibrationActive && !AccInflightCalibrationMeasurementDone){
InflightcalibratingA = 50;
}
}else
#endif
if(AccInflightCalibrationMeasurementDone && !f.ARMED){
AccInflightCalibrationMeasurementDone = 0;
AccInflightCalibrationSavetoEEProm = 1;
}
#endif

bill516 · Post by **bill516** » Mon Sep 17, 2012 9:36 am

what still does not make sense though is how one motor can end up with a value so far from the three others. I mean, it makes sense if two motors on the same axis are different from the two motors on the other axis.[/quote]

Its Mother nature again, you have to think friction, bearings, windings and magnets etc. In a quad there are four motors and the fact we get three of them to be a same is a small miracle really.

cardboard · Post by **cardboard** » Mon Sep 17, 2012 9:57 am

bill516 wrote:what still does not make sense though is how one motor can end up with a value so far from the three others. I mean, it makes sense if two motors on the same axis are different from the two motors on the other axis.

Its Mother nature again, you have to think friction, bearings, windings and magnets etc. In a quad there are four motors and the fact we get three of them to be a same is a small miracle really.[/quote]

That makes allot of sense, those motor outputs are related to thrust which is not 1:1 relationship to throttle, although it will be close things like friction and others mentioned above play a part in this.
Is your copters CG at the intersecting line of all motors? this would also effect thrust distribution.

NikTheGreek · Post by **NikTheGreek** » Mon Sep 17, 2012 10:45 am

and how do you explain the fact that the problem remains at the same motor even when i switch places in motors and escs ?

cardboard · Post by **cardboard** » Mon Sep 17, 2012 10:55 am

Fair point, I was just making a general statement.

chris ables · Post by **chris ables** » Mon Sep 17, 2012 1:09 pm

http://m.youtube.com/#/watch?v=knagzCgX ... nagzCgXGEg

crashlander · Post by **crashlander** » Mon Sep 17, 2012 1:17 pm

If you can see difference in GUI and noticed it in flight (like in your case) I suggest that you clear EEPROM (Arduino > File > Examples >EEPROM > eeprom_clear) and than upload corresponding MWII sketch!
Because in almost all occasions it is something wrong (predefined/mixed/scrambled) in EEPROM.

Regards Andrej

NikTheGreek · Post by **NikTheGreek** » Mon Sep 17, 2012 3:53 pm

chris ables wrote:http://m.youtube.com/#/watch?v=knagzCgXGEg&desktop_uri=%2Fwatch%3Fv%3DknagzCgXGEg

Thank you but....nothing

crashlander wrote:If you can see difference in GUI and noticed it in flight (like in your case) I suggest that you clear EEPROM (Arduino > File > Examples >EEPROM > eeprom_clear) and than upload corresponding MWII sketch!
Because in almost all occasions it is something wrong (predefined/mixed/scrambled) in EEPROM.

The same.

What ever i do REAR_L remains low

chris ables · Post by **chris ables** » Mon Sep 17, 2012 5:01 pm

The motor output on the GUI is not equal on both sides with a neutral RC input
This is the normal PID loop behaviour, the I-term is actually cumulating the error over time & tries to compensate for that but the copter is hand-held or fixed on the table.
When the I-term is zeroed, the this will not happen.
A flying multicopter will actually use the I-term in the PID to correct itself again to the same level as before the disturbance.
( maybe try and lower the I value in gui !) got this out of FAQ on multiwii.com !

doughboy · Post by **doughboy** » Mon Sep 17, 2012 5:05 pm

regarding trimming, after thinking more about it, its like a rubiks cube puzzle.

say hypothetically the motor speed are as follows (midway throttle)

1500 1500
1400 1500

pitch down to make front motors lower by 100 (pitch down may not be the correct term, but you know what I mean)
1400 1400
1400 1500

yaw left halfway to increase RL and FR by 50

1400 1450
1450 1500

roll right to increase left motors by 50
1450 1450
1500 1500

pitch up to even, increase by 50

1500 1500
1500 1500

I'm sure other combinations are possible to end up with all equal speed for different motor you want to correct.

the interesting thing in the above step, you can at the end combine them all together, and do the steps in any order and still end up with all motors with the same speed.

pitch, decrease 100, increse 50, net is decrease by 50
yaw increae by 50
roll right increase by 50

so you can do pitch trim decrease by 50, yaw right trim by 50, roll right trim by 50 in any order and achieve the same result.

try it.

doughboy · Post by **doughboy** » Mon Sep 17, 2012 5:08 pm

chris ables wrote:The motor output on the GUI is not equal on both sides with a neutral RC input
This is the normal PID loop behaviour, the I-term is actually cumulating the error over time & tries to compensate for that but the copter is hand-held or fixed on the table.
When the I-term is zeroed, the this will not happen.
A flying multicopter will actually use the I-term in the PID to correct itself again to the same level as before the disturbance.
( maybe try and lower the I value in gui !) got this out of FAQ on multiwii.com !

I'm not sure PID affects this. we are talking about the quad is on the floor with props off, so gyro readings are 0 and you just set throttle to 50%. When I looked at the math behind this, it seems only the values of the RC sticks matter. I'm sure what you are saying is correct while flying, but that is not what we are talking about here in this thread. FWIW, the default PID values are fine left as is. I only did the trimming to get the motors to about the same speed, and was able to fly it level and stable, well at least more level and stable than I have seen on my quad.

NikTheGreek · Post by **NikTheGreek** » Mon Sep 17, 2012 6:19 pm

I'm about to explode !!!! :evil:

I've followed all your valuable advices , and thank you very much for your effort and time.
What i've seen is that what ever i do the motors align for 2-3 seconds and gradually the Rear_L is decreased and the REAR_R increased !!!!
I dont know what else i could do . :?:

doughboy · Post by **doughboy** » Mon Sep 17, 2012 6:47 pm

One more thing you can try.

Load the latest "shared" code from trunk. You have to do an SVN checkout of trunk branch to get the file. Then add the multiwii shared folder into your arduino sketch folder and rename the multiwii_shared folder to just multiwii and load that to your flight controller, after changing config.h settings obviously.

While doing this, grab the latest configuration program under branches folder under magnetron.

I did this and seem to be able to get all motors aligned without even trimming (maybe just minor trimming, but it pretty much worked right out of the box so to speak). I think it might have to do with clearing the eeproms as someone pointed out.

bill516 · Post by **bill516** » Mon Sep 17, 2012 6:49 pm

OK you've moved a motor around and the problem remains so move an esc if the problem moves its an esc problem may be just need re-calibrating or it may be a bad one. All four esc's are setup the same are they, it is not hard to miss a step and leave the brake on or set number or battery cells wrong if you are doing it by the Tx, if you have a card programmer then its even easier to check if they all the same.

There have been a few people on here who have had strange problems that did not respond to normal diagnostics and it turned out it was the Tx set up wrongly. Ensure Tx trims are set to mid range, throttle trim can be set to fully down, whether that is needed I dont know, I think its a throw back from gasser models where they needed it for tick over. Setup stick limits set to 100% or 125% all sub-trims zero, mid or whatever you Tx calls it and channels assigned as needed, you dont need to bother about aux channels at the mo just get the 4 channels working so you can control the motors. When you power up you copter it will power up in gyro only mode as that is the only sensor that is activated at startup.

doughboy · Post by **doughboy** » Mon Sep 17, 2012 6:58 pm

Bill, your posts should be in sticky or wiki.
Yes, I had to figure out how to get my darned tx sticks to go min 1000 max 2000 and mid 1500.
As I have mentioned in my earlier post, when I went through the math, it appears the stick values are the main contributors hence it is important to get then all in the same range.

Other software, aero quad to be specific, does not require this. All you need to do in the aero quad configuration is swing the sticks to all 4 corners and it remembers your stick min and max and just maps that to 1000 and 2000 so you really don't have to mess with your TX.

chris ables · Post by **chris ables** » Mon Sep 17, 2012 7:17 pm

doughboy wrote:
chris ables wrote:The motor output on the GUI is not equal on both sides with a neutral RC input
This is the normal PID loop behaviour, the I-term is actually cumulating the error over time & tries to compensate for that but the copter is hand-held or fixed on the table.
When the I-term is zeroed, the this will not happen.
A flying multicopter will actually use the I-term in the PID to correct itself again to the same level as before the disturbance.
( maybe try and lower the I value in gui !) got this out of FAQ on multiwii.com !

I'm not sure PID affects this. we are talking about the quad is on the floor with props off, so gyro readings are 0 and you just set throttle to 50%. When I looked at the math behind this, it seems only the values of the RC sticks matter. I'm sure what you are saying is correct while flying, but that is not what we are talking about here in this thread. FWIW, the default PID values are fine left as is. I only did the trimming to get the motors to about the same speed, and was able to fly it level and stable, well at least more level and stable than I have seen on my quad.

Thats what this say's ! The i term is actually cumilating the error over time & tries to compensate for that but the copter is in hand or fixxed on table ( sitting on floor with props off is like fixed on table )

NikTheGreek · Post by **NikTheGreek** » Mon Sep 17, 2012 7:20 pm

doughboy wrote:One more thing you can try.

Load the latest "shared" code from trunk. You have to do an SVN checkout of trunk branch to get the file. Then add the multiwii shared folder into your arduino sketch folder and rename the multiwii_shared folder to just multiwii and load that to your flight controller, after changing config.h settings obviously.

While doing this, grab the latest configuration program under branches folder under magnetron.

I did this and seem to be able to get all motors aligned without even trimming (maybe just minor trimming, but it pretty much worked right out of the box so to speak). I think it might have to do with clearing the eeproms as someone pointed out.

Sure..i ll do that later this evening.

bill516 wrote:OK you've moved a motor around and the problem remains so move an esc if the problem moves its an esc problem may be just need re-calibrating or it may be a bad one. All four esc's are setup the same are they, it is not hard to miss a step and leave the brake on or set number or battery cells wrong if you are doing it by the Tx, if you have a card programmer then its even easier to check if they all the same.

There have been a few people on here who have had strange problems that did not respond to normal diagnostics and it turned out it was the Tx set up wrongly. Ensure Tx trims are set to mid range, throttle trim can be set to fully down, whether that is needed I dont know, I think its a throw back from gasser models where they needed it for tick over. Setup stick limits set to 100% or 125% all sub-trims zero, mid or whatever you Tx calls it and channels assigned as needed, you dont need to bother about aux channels at the mo just get the 4 channels working so you can control the motors. When you power up you copter it will power up in gyro only mode as that is the only sensor that is activated at startup.

What i've done so far....
1. Switch motor places
2. Switch both ESC and Motor
3.Trim by TX
4.Trim by sticks

Concerning my ESCs are all four flashed with simonk firmware.

Concerning my TX to be honest i'm not an expert on how to setup and calibrate it but everything seems OK

Thank you once again for your help.

doughboy · Post by **doughboy** » Mon Sep 17, 2012 9:18 pm

chris ables wrote:Thats what this say's ! The i term is actually cumilating the error over time & tries to compensate for that but the copter is in hand or fixxed on table ( sitting on floor with props off is like fixed on table )

ok, go back to the code.
axisPID[axis] = PTerm + ITerm - DTerm;
PTerm is the actual stick reading.
ITerm and DTerm are ALWAYS 0 because gyro readings are 0. (Nick if your gyro is not zero, then you should check that)

So motor speed is only affected by stick reading.
You are correct again if in flight or the quad is moving.

it's all in the code below. gyroData[axis] is always 0 therefore error and delta are always 0. rcCommand[axis] is the stick reading.

Code: Select all

  int16_t prop;
  prop = max(abs(rcCommand[PITCH]),abs(rcCommand[ROLL])); // range [0;500]
  
  for(axis=0;axis<3;axis++) {
    if (!f.ANGLE_MODE || axis == 2 ) { // MODE relying on GYRO or YAW axis
      if (abs(rcCommand[axis])<350) error =          rcCommand[axis]*10*8/conf.P8[axis] ; // 16 bits is needed for calculation: 350*10*8 = 28000      16 bits is ok for result if P8>2 (P>0.2)
                               else error = (int32_t)rcCommand[axis]*10*8/conf.P8[axis] ; // 32 bits is needed for calculation: 500*5*10*8 = 200000   16 bits is ok for result if P8>2 (P>0.2)
      error -= gyroData[axis];

      PTermGYRO = rcCommand[axis];
      
      errorGyroI[axis]  = constrain(errorGyroI[axis]+error,-16000,+16000);          // WindUp   16 bits is ok here
      if (abs(gyroData[axis])>640) errorGyroI[axis] = 0;
      ITermGYRO = (errorGyroI[axis]/125*conf.I8[axis])>>6;                                   // 16 bits is ok here 16000/125 = 128 ; 128*250 = 32000
    }

    PTerm = PTermGYRO;
    ITerm = ITermGYRO;

    if (abs(gyroData[axis])<160) PTerm -=          gyroData[axis]*dynP8[axis]/10/8; // 16 bits is needed for calculation   160*200 = 32000         16 bits is ok for result
                            else PTerm -= (int32_t)gyroData[axis]*dynP8[axis]/10/8; // 32 bits is needed for calculation   

    delta          = gyroData[axis] - lastGyro[axis];                               // 16 bits is ok here, the dif between 2 consecutive gyro reads is limited to 800
    lastGyro[axis] = gyroData[axis];
    deltaSum       = delta1[axis]+delta2[axis]+delta;
    delta2[axis]   = delta1[axis];
    delta1[axis]   = delta;
 
    if (abs(deltaSum)<640) DTerm = (deltaSum*dynD8[axis])>>5;                       // 16 bits is needed for calculation 640*50 = 32000           16 bits is ok for result 
                      else DTerm = ((int32_t)deltaSum*dynD8[axis])>>5;              // 32 bits is needed for calculation
                      
    axisPID[axis] =  PTerm + ITerm - DTerm;

doughboy · Post by **doughboy** » Mon Sep 17, 2012 9:28 pm

if your REAR_L is always low,

#ifdef QUADX
motor[0] = PIDMIX(-1,+1,-1); //REAR_R
motor[1] = PIDMIX(-1,-1,+1); //FRONT_R
motor[2] = PIDMIX(+1,+1,+1); //REAR_L
motor[3] = PIDMIX(+1,-1,-1); //FRONT_L
#endif

from that, you see it adds PID term for all axis for rear_l
since
PIDMIX(X,Y,Z) rcCommand[THROTTLE] + axisPID[ROLL]*X + axisPID[PITCH]*Y + YAW_DIRECTION * axisPID[YAW]*Z
that means the motor value for REAR_L is the sum of
throttle reading + roll reading, + pitch reading + yaw reading. (again, assuming your gyro values are all 0)

since the value is low, do you think perhaps your yaw direction is incorrect? I think there is a setting in config.h to reverse yaw direction.
is your front right lower also compared to front left and rear right?

ok, I checked your screen shot in first post, and the front right is indeed slightly lower than the front left and rear right.

BTW, you can check if your yaw direction is correct by turning the quad clockwise quickly. The gyro Z value must increase.

doughboy · Post by **doughboy** » Tue Sep 18, 2012 1:06 am

the more I look into this, the more I think this is a software bug.

First of all, ESC and motor has nothing to do with this, as my esc is completely disconnected. So only thing running is FC and receiver.
Second, my gyro reading is always 0, so only stick values should come into play.

Yet I just now observed, that although when I first push the throttle up that all speeds are the same, one motor definitely slowly drift downward, to the point it is ridiculously way off. And my sticks value are exactly the same this whole time.

I think something in the program loop is introducing a calculation error.

doughboy · Post by **doughboy** » Tue Sep 18, 2012 1:19 am

I don't think its a problem with your quad. I have the exact problem. and I just flew my quad yesterday and it was fine.

doughboy · Post by **doughboy** » Tue Sep 18, 2012 1:26 am

I changed the YAW direction in config and the opposite happens, my front_r is now drifting to a ridiculously high value.

the debug function is really nice. I enabled #define DEBUG and added this line

debug[0]=rcCommand[THROTTLE];debug[1]=axisPID[ROLL];debug[2]=axisPID[PITCH];debug[3]=axisPID[YAW];

and I can see the throttle value is constant, but roll value drifts higher, and yaw value just goes straight to 105. pitch value is stable. so something in roll calculation is causing the problem

gyro roll value always shows zero, but value for gyroData[ROLL] is always 1, therefore it introduces an error of 1 on each loop up to a maximum of 16000.

doughboy · Post by **doughboy** » Tue Sep 18, 2012 3:11 am

the error is introduced by the gyro reading fluctuating between 0 and 1, and accumulates over time. if it is always 0, then this problem won't exist. enabling gyro smoothing does nothing.

doughboy · Post by **doughboy** » Tue Sep 18, 2012 3:31 am

ok, I found the problem. your roll, pitch, yaw center value MUST be exactly 1500 in order to have no error accumulating.
this kinda suck. I think it should have some margin of error, say +/-10 or 20.

doughboy · Post by **doughboy** » Tue Sep 18, 2012 3:40 am

motors all same speed, pitch, roll, yaw values at about 1500. so it really all goes back to bill's instructions to set the transmistter min max and mid to 1000-1500-2000. who would have thought a difference of 4us would matter a lot. if you look at my first picture, my roll is below 1500, and that was causing the problem.

doughboy · Post by **doughboy** » Tue Sep 18, 2012 5:24 am

one more thing besides trimming min-mid-max

you must set #define DEADBAND 6
in your config.h.

the value is based on how much your sticks fluctuate from 1500 when it is at midpoint.
I had to set mine to 24, and the motor speeds are now super stable.

man these things should be in the wiki, or if they are already there, should be highlighted!!
I wonder how many multiwii FC ended up in the trash because of this.

NikTheGreek · Post by **NikTheGreek** » Tue Sep 18, 2012 9:36 am

doughboy wrote:one more thing besides trimming min-mid-max

you must set #define DEADBAND 6
in your config.h.

the value is based on how much your sticks fluctuate from 1500 when it is at midpoint.
I had to set mine to 24, and the motor speeds are now super stable.

Seems that #DEFINE DEADBAND is doin the job !!!

im testing it and i will give here the results.

crashlander · Post by **crashlander** » Tue Sep 18, 2012 9:50 am

On properly balanced multi with good TX-RX system you should use as little as possible DEADBAND. Your flying experience will be heavily hampered with DEADBAND of 24! In flight you probably will not notice mall noise in RX signal +-2 or +-3. Same way you probably won't notice (in acro mode) gyro drift of +-1. But on the table (without props.) when PID controller is running without actual control of multi's attitude the error will accumulate and will be clearly seen in GUI.

Regards Andrej

NikTheGreek · Post by **NikTheGreek** » Tue Sep 18, 2012 2:19 pm

Finally , seems that i discovered what is the problem.(i'm not sure) :oops:

Yes the #define DEADBAND options when used is giving a solution but in fact we cover the problem under the carpet.

The problem is there and is nothing else than bad aligned sensors.
I discover this the hard way..three days now.
The slightest balance error creating this kind of behaviour.
The sensors must be perfectly aligned ,
The fact that in GUI we take zero reading from gyro it doesn't mean that is correctly aligned.

If for instance ,in my case , the gyro tilting to the right the "system" assumes that the quad is tilting right this way and gradually increases the REAR_R motor and decreases the REAR_L.

I'm not an expert but this is my opinion .

bill516 · Post by **bill516** » Tue Sep 18, 2012 2:59 pm

It should not make a difference, if you calibrate your gyro on a 5deg slope you are telling it that the world tilts 5 deg, when you then put it on a level surface it will tell you that it is tilted 5deg in the opposite direction and will try to get back to what it thinks is level. In flight this would mean that the gyro would always want to lean your copter 5 deg whereas you would be trying to level it with the horizon.

Its easy to see this in action just prop up one side of your copter and calibrate gyro and acc, GUI will say that the copter is level and when you remove the prop it will now show it leaning to one side. Even if you mounted the gyro on slant in your copter and calibrated it on a level surface it would show as being level even though the gyro is not level. All calibration does is tell the sensors what is level, you could mount the sensor upside down and it would say it was the right way up, which it would be as far as it was concerned but when you moved it then all the readings would be reversed unless you change the orientation of the axis.

Now where getting into land where I my knowledge is lacking and I'm waiting for someone to enlighten me.

crashlander · Post by **crashlander** » Tue Sep 18, 2012 4:10 pm

The gyro is measuring angle velocity and not angle itself (we can get actual angle from known position and integrating gyro readings...), so the gyro calibration only calibrates gyro drift/noise and can be done under any angle (it is done every time you power on the board).
ACC measures actual angle and is calibrated on demand (from GUI or by stick command).
But both of them must be properly aligned to multy X Y Z axis to properly measure multy's attitude and/or rotation (that is he reason you have different defines for X or + configurations of quad, hexa or octo)...

Regards Andrej

tovrin · Post by **tovrin** » Tue Sep 18, 2012 4:26 pm

After reading all of this, im curious if you have tried flying it yet. you see post after post of motor levels not matching on ground, with and without props, but once they get the bird leveled and in air they see little problem.

get it 4 feet in the air and see if it will level. I use a deadband of 5 for my TX is cheap and sloppy, it stopped a lot of twitching for me, but makes my stick sluggish when in hover mode.

doughboy · Post by **doughboy** » Tue Sep 18, 2012 6:36 pm

tovrin wrote:After reading all of this, im curious if you have tried flying it yet. you see post after post of motor levels not matching on ground, with and without props, but once they get the bird leveled and in air they see little problem.

get it 4 feet in the air and see if it will level. I use a deadband of 5 for my TX is cheap and sloppy, it stopped a lot of twitching for me, but makes my stick sluggish when in hover mode.

I agree while actually flying, the error introduced will eventually be corrected since you will be actively moving the sticks to correct it. I don't see any difference with the quad on a table and hovering in place, which is probably not acheivable due to this issue, and probably one of the reasons why the quad will drift.

doughboy · Post by **doughboy** » Wed Sep 19, 2012 4:57 pm

Nik, read this post

viewtopic.php?f=8&t=2474&start=10#p23177

NikTheGreek · Post by **NikTheGreek** » Wed Sep 19, 2012 5:12 pm

doughboy wrote:Nik, read this post

viewtopic.php?f=8&t=2474&start=10#p23177

Thank you ... i ll test this in a few hours.

NikTheGreek · Post by **NikTheGreek** » Wed Sep 19, 2012 6:42 pm

Im using this all the time

What realy save me is the DEADBAND...
i put it to 10 and is much better..probably i can set it to 8 with a litle more effort.
BTW..yesterday i had my first "flight"...[url]http://www.multiwii.com/forum/viewtopic.php?f=9&t=2477
[/url]
Thank you.

heavyturtle · Post by **heavyturtle** » Tue Oct 30, 2012 6:13 pm

I got the same trouble but my Rear_L is more power than anyone else over 1000.