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 ?
![Image](http://i47.tinypic.com/sdgpjd.jpg)
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.
bill516 wrote:You can get it flying hands off in this state then you can set about trimming in stable mode
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.
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
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.
chris ables wrote:http://m.youtube.com/#/watch?v=knagzCgXGEg&desktop_uri=%2Fwatch%3Fv%3DknagzCgXGEg
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.
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 !
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.
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.
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.
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 )
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 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.
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.