MultiWii 2.0 is coming

ciskje · Post by **ciskje** » Tue Mar 20, 2012 8:59 pm

Earth magnetic field is [0.2;0.7] (from equator to the poles) Gauss
Positive BIAS during init for x&y is 1.16 Gauss, z is 1.08 (check this difference Alex!)
Maximum field is so 1.86 Gauss
We can work without problem with 1.3 Ga scale. (and a lot far away from overflow with the 2.5Ga during init).

If you can overflow it, it is a soft or hard iron problem (motors, speakers, or too much metal near the sensor).

Magnetron · Post by **Magnetron** » Tue Mar 20, 2012 11:32 pm

ALEX,

I found GYRO_SMOOTHING define option that implement a moving average like mine, but mine is loop-optimized also.
I think GYRO_SMOOTHING must be removed and explained more the use of average.
Please reintroduce accelerometers averaging and repost my code modifications like I posted in some posts ago. Many users had tryed my code and multirotors go better on a little average enabled like some explanation in comments in code.
Evaluate my sequence in config.h:

Code: Select all

//####################################################################
// Moving Average Gyros by Magnetron1 (Michele Ardito) ########## beta
// if the I2C speed is 100kHz use MMGYROVECTORLENGHT from 2 to 6 best was 2 and MMACCVECTORLENGHT from 4 to 10 best was 6
// if the I2C speed is 400kHz use MMGYROVECTORLENGHT from 2 to 6 best was 4 and MMACCVECTORLENGHT from 4 to 12 best was 8
//#define MMGYRO                         // Active Moving Average Function for Gyros
#define MMGYROVECTORLENGHT 4           // Lenght of Moving Average Vector
// Moving Average Accelerometers by Magnetron1
//#define MMACC                          // Active Moving Average Function for Accelerometers
#define MMACCVECTORLENGHT 8            // Lenght of Moving Average Vector
// Moving Average ServoGimbal Signal Output
//#define MMSERVOGIMBAL                  // Active Output Moving Average Function for Servos Gimbal
#define MMSERVOGIMBALVECTORLENGHT 16   // Lenght of Moving Average Vector
/* Trusted AccZ Velocity Vector Magnetron1
/* This option should be uncommented if ACC Z is accurate enough when motors are running*/
#define TRUSTED_ACCZ_VEL

my moving average routines (in sensors.pde) that are faster than others:

Code: Select all

// ****************
// GYRO common part
// ****************
void GYRO_Common() {
  static int16_t previousGyroADC[3] = {0,0,0};
  static int32_t g[3];
  uint8_t axis;
  
#if defined MMGYRO       
  // Moving Average Gyros by Magnetron1
  //---------------------------------------------------
  static int16_t mediaMobileGyroADC[3][MMGYROVECTORLENGHT];
  static int32_t mediaMobileGyroADCSum[3];
  static uint8_t mediaMobileGyroIDX;
  //---------------------------------------------------
#endif
  if (calibratingG>0) {
    for (axis = 0; axis < 3; axis++) {
      // Reset g[axis] at start of calibration
      if (calibratingG == 400) g[axis]=0;
      // Sum up 400 readings
      g[axis] +=gyroADC[axis];
      // Clear global variables for next reading
      gyroADC[axis]=0;
      gyroZero[axis]=0;
      if (calibratingG == 1) {
        gyroZero[axis]=g[axis]/400;
        blinkLED(10,15,1+3*nunchuk);
      }
    }
    calibratingG--;
  }
#ifdef MMGYRO       
  mediaMobileGyroIDX = ++mediaMobileGyroIDX % MMGYROVECTORLENGHT;
  for (axis = 0; axis < 3; axis++) {
    gyroADC[axis]  -= gyroZero[axis];
    mediaMobileGyroADCSum[axis] -= mediaMobileGyroADC[axis][mediaMobileGyroIDX];
    //anti gyro glitch, limit the variation between two consecutive readings
    mediaMobileGyroADC[axis][mediaMobileGyroIDX] = constrain(gyroADC[axis],previousGyroADC[axis]-800,previousGyroADC[axis]+800);
    mediaMobileGyroADCSum[axis] += mediaMobileGyroADC[axis][mediaMobileGyroIDX];
    gyroADC[axis] = mediaMobileGyroADCSum[axis] / MMGYROVECTORLENGHT;
#else 
  for (axis = 0; axis < 3; axis++) {
    gyroADC[axis]  -= gyroZero[axis];
    //anti gyro glitch, limit the variation between two consecutive readings
    gyroADC[axis] = constrain(gyroADC[axis],previousGyroADC[axis]-800,previousGyroADC[axis]+800);
#endif    
    previousGyroADC[axis] = gyroADC[axis];
  }
}

// ****************
// ACC common part
// ****************
void ACC_Common() {
  static int32_t a[3];
  uint8_t axis;
#if defined MMACC       
  // Moving Average Accelerometers by Magnetron1
  //---------------------------------------------------
  static int16_t mediaMobileAccADC[3][MMACCVECTORLENGHT];
  static int32_t mediaMobileAccADCSum[3];
  static uint8_t mediaMobileAccIDX;
  //---------------------------------------------------
#endif
  if (calibratingA>0) {
    for (uint8_t axis = 0; axis < 3; axis++) {
      // Reset a[axis] at start of calibration
      if (calibratingA == 400) a[axis]=0;
      // Sum up 400 readings
      a[axis] +=accADC[axis];
      // Clear global variables for next reading
      accADC[axis]=0;
      accZero[axis]=0;
    }
    // Calculate average, shift Z down by acc_1G and store values in EEPROM at end of calibration
    if (calibratingA == 1) {
      accZero[ROLL]  = a[ROLL]/400;
      accZero[PITCH] = a[PITCH]/400;
      accZero[YAW]   = a[YAW]/400-acc_1G; // for nunchuk 200=1G
      accTrim[ROLL]   = 0;
      accTrim[PITCH]  = 0;
      writeParams(); // write accZero in EEPROM
    }
    calibratingA--;
  }
  #if defined(InflightAccCalibration)
      static int32_t b[3];
      static int16_t accZero_saved[3]  = {0,0,0};
      static int16_t  accTrim_saved[2] = {0, 0};
      //Saving old zeropoints before measurement
      if (InflightcalibratingA==50) {
         accZero_saved[ROLL]  = accZero[ROLL] ;
         accZero_saved[PITCH] = accZero[PITCH];
         accZero_saved[YAW]   = accZero[YAW] ;
         accTrim_saved[ROLL] = accTrim[ROLL] ;
         accTrim_saved[PITCH] = accTrim[PITCH] ;
      }
      if (InflightcalibratingA>0) {
        for (uint8_t axis = 0; axis < 3; axis++) {
          // Reset a[axis] at start of calibration
          if (InflightcalibratingA == 50) b[axis]=0;
          // Sum up 50 readings
          b[axis] +=accADC[axis];
          // Clear global variables for next reading
          accADC[axis]=0;
          accZero[axis]=0;
        }
        //all values are measured
        if (InflightcalibratingA == 1) {
          AccInflightCalibrationActive = 0;
          AccInflightCalibrationMeasurementDone = 1;
          blinkLED(10,10,2);      //buzzer for indicatiing the start inflight
        // recover saved values to maintain current flight behavior until new values are transferred
         accZero[ROLL]  = accZero_saved[ROLL] ;
         accZero[PITCH] = accZero_saved[PITCH];
         accZero[YAW]   = accZero_saved[YAW] ;
         accTrim[ROLL] = accTrim_saved[ROLL] ;
         accTrim[PITCH] = accTrim_saved[PITCH] ;
        }
        InflightcalibratingA--;
      }
      // Calculate average, shift Z down by acc_1G and store values in EEPROM at end of calibration
      if (AccInflightCalibrationSavetoEEProm == 1){  //the copter is landed, disarmed and the combo has been done again
        AccInflightCalibrationSavetoEEProm = 0;
        accZero[ROLL]  = b[ROLL]/50;
        accZero[PITCH] = b[PITCH]/50;
        accZero[YAW]   = b[YAW]/50-acc_1G; // for nunchuk 200=1G
        accTrim[ROLL]   = 0;
        accTrim[PITCH]  = 0;
        writeParams(); // write accZero in EEPROM
      }
  #endif
#ifdef MMACC
  //Moving Average Accelerometers by Magnetron1
  mediaMobileAccIDX = ++mediaMobileAccIDX % MMACCVECTORLENGHT;
  for (axis = 0; axis < 3; axis++) {
    accADC[axis]  -= accZero[axis];
   //new implementation of Moving Average for fast response
   mediaMobileAccADCSum[axis] -= mediaMobileAccADC[axis][mediaMobileAccIDX];
    mediaMobileAccADC[axis][mediaMobileAccIDX] = accADC[axis];
   mediaMobileAccADCSum[axis] += mediaMobileAccADC[axis][mediaMobileAccIDX];
   accADC[axis] = mediaMobileAccADCSum[axis] / MMACCVECTORLENGHT;
  }
#else 
  accADC[ROLL]  -=  accZero[ROLL] ;
  accADC[PITCH] -=  accZero[PITCH];
  accADC[YAW]   -=  accZero[YAW] ;
#endif    
}

and the use of TRUSTED_ACCZ_VEL to compensate derive on Z axis for barometer stabilization:

Code: Select all

  BaroPID = 0;
  //D
  temp32 = D8[PIDALT]*(BaroHigh - BaroLow) / 40;
  BaroPID-=temp32;
  EstAlt = BaroHigh*10/(BARO_TAB_SIZE/2);
  temp32 = AltHold - EstAlt;
  if (abs(temp32) < 10 && BaroPID < 10) BaroPID = 0;  //remove small D parametr to reduce noise near zoro position
  // Magnetron1 (Michele Ardito) Trusted Z Acc
  #if defined(TRUSTED_ACCZ_VEL)
      BaroPID -= D8[PIDVEL]*(AccZHigh - AccZLow) / 30;
  #endif
  
  //P
  BaroPID += P8[PIDALT]*constrain(temp32,(-2)*P8[PIDALT],2*P8[PIDALT])/100;   
  BaroPID = constrain(BaroPID,-150,+150); //sum of P and D should be in range 150

  //I
  errorAltitudeI += temp32*I8[PIDALT]/50;
  errorAltitudeI = constrain(errorAltitudeI,-30000,30000);
  temp32 = errorAltitudeI / 500; //I in range +/-60
  BaroPID+=temp32;

Introduce this variants and remove GYRO_SMOOTHING... it is a duplicate routine, it is a mistake: if some user enable it and my moving average will become a mistake...

aamorin · Post by **aamorin** » Wed Mar 21, 2012 1:48 pm

Alexinparis wrote:[...]
for Serial GPS device:
gps should be configured by yourself to ouput NMEA frames
home is memorired as soon as possible when the power is on, the status led should blink accordingly once a fix is ok.
RTH o PH is activated via a checkbox and in level mode only.

Let me try to understand.. this means that in order to the GPS work correctly, I should also enable the level mode ? (via checkbox)

Thanks for the hard work and keep going like that !

PedAnd · Post by **PedAnd** » Thu Mar 22, 2012 8:21 am

Hi!

Any solution to the issue due to funny characters and messed up navigation on the LCD for the Crius in MultiWii v 2.0?

PedAnd

JussiH · Post by **JussiH** » Thu Mar 22, 2012 5:42 pm

Trying out preversion 4 on my mini, very stable with reflashed ESC´s - good work.

Can someone do a short explanation of the Altitude PID controller. What does each parameter control?

Thanks

Jussi

Joachim08 · Post by **Joachim08** » Thu Mar 22, 2012 6:17 pm

Alex,

please explain what you have changed from 1.9 to 2.0pre4 so as my WMP and BMA020 on D&I board are not working proberly anymore. I understood that you have changed some
code so "it maches with the datasheet" (whatever that means). I have changed the direction for acc roll and yaw. ACC-Z is now showing 65 only. The ACC control is totally out
of control. With standard pid values like is use on 1.9 i get the toilet bowl effect when i enable ACC. On 1.9 everything works out of the box, so something must be different.
As a newcomer it is very difficult for me to cope with the problem.
Can you bring some light into the darkness ?

Thanks

Joachim

fr3d · Post by **fr3d** » Thu Mar 22, 2012 9:40 pm

Joachim08 wrote:Alex,

please explain what you have changed from 1.9 to 2.0pre4 so as my WMP and BMA020 on D&I board are not working proberly anymore. I understood that you have changed some
code so "it maches with the datasheet" (whatever that means). I have changed the direction for acc roll and yaw. ACC-Z is now showing 65 only. The ACC control is totally out
of control. With standard pid values like is use on 1.9 i get the toilet bowl effect when i enable ACC. On 1.9 everything works out of the box, so something must be different.
As a newcomer it is very difficult for me to cope with the problem.
Can you bring some light into the darkness ?

Thanks

Joachim

Both Acc & Gyro should show positive/neagtive values at the same time on the multiwiiconf software.
Roll positive when tilting to the Right.
Pitch positive when tilting forward.

Joachim08 · Post by **Joachim08** » Thu Mar 22, 2012 9:48 pm

The direction of the amplitude is not the problem, i have changed the direction accordingly
The real problem is the toilet bowl effect when ACC is activated. My quad turns around
the yaw axis slowly, maybe in 20 seconds time. I am not able to get rid of this movement by
changing pid values. I dont have this problem with 1.9 so i assume it is a problem with the sketch
somewhere. Also other people have reported this problem, so it has nothing to do specificly with my quad.
Is there an influence if i fly X or Plus ?

marbalon · Post by **marbalon** » Thu Mar 22, 2012 10:45 pm

JussiH wrote:Trying out preversion 4 on my mini, very stable with reflashed ESC´s - good work.

Can someone do a short explanation of the Altitude PID controller. What does each parameter control?

Thanks

Jussi

P - is proportional to alt error, so if your quad return to base position to slow you need to increase it, if it overshot base position decrease P
I - only to compensate battery discharge and to correct throttle hold a little Please keed about 0.010-15
D - this parametr is used to stop your quad when it reaches holded postion, so when it overshot try to increase this value.

But be careful because when you increase P and D too much you quad became a little nervous. Firs try to fly with default values and then try to experiment with P and D.

Alexinparis · Post by **Alexinparis** » Fri Mar 23, 2012 12:24 am

noobee wrote:i had thought that magCal should really be computed after establishing the min, max and mid of the raw <adc> values during calibration, for each axis individually:

during calibration:
record <min> = min({<adc>})
record <max> = max({<adc>})
at end of calibration:
<mid> = midpoint of <min> and <max>
magCal = 1000.0 / (<max> - <min>)

subsequently:
<reading> = (<next adc> - <mid>) * magCal

in this approach, all 3 axis will be normalized to the same range (which is important for the vector computation).

sorry for the long writeup, i hope to be able to get to the bottom of this and help towards the effort.

thanks.

According to the specs, magCal per axis is obtained after the subtraction of the current magnetic field (ie there are 2 measurements, one with an artificial mag field of ~1.1 gauss, and one with nothing)
So mix/max should not have impact on magCal definition.

Alexinparis · Post by **Alexinparis** » Fri Mar 23, 2012 12:25 am

fr3d wrote:have seen that gps Pids on pre3 are not available with LCD ?
did I miss something ?

they are not included yet in the LCD conf

Alexinparis · Post by **Alexinparis** » Fri Mar 23, 2012 12:26 am

Joachim08 wrote:I am just changing from MK to Multiwii and have changed from 1.9 to pre4. I am using a quad with BMA020, WMO and D&I Board.
After changing the direction for ACC-Roll and ACC-Pitch and calibration of the acc i recognized that ACC-Z is only around 64 instead of
256 with 1.9. Is that correct ?.

yes it is correct, it's due to the new 8G settings for BMA020

Alexinparis · Post by **Alexinparis** » Fri Mar 23, 2012 12:31 am

ciskje wrote:Earth magnetic field is [0.2;0.7] (from equator to the poles) Gauss
Positive BIAS during init for x&y is 1.16 Gauss, z is 1.08 (check this difference Alex!)
Maximum field is so 1.86 Gauss
We can work without problem with 1.3 Ga scale. (and a lot far away from overflow with the 2.5Ga during init).

If you can overflow it, it is a soft or hard iron problem (motors, speakers, or too much metal near the sensor).

Hi,
The spec is not so clear for me.
The spec says:
"For example, if the configuration register B is set to 0x60 (Gain=3), values around +766 LSB (1.16 Ga * 660 LSB/Ga) will be placed in the X and Y data output registers and around +713 (1.08 Ga * 660 LSB/Ga) will be placed in Z data output register."
So I understand it's an example of what could be measured, but not a specific scaled factor.

Alexinparis · Post by **Alexinparis** » Fri Mar 23, 2012 12:36 am

Magnetron wrote:ALEX,
I found GYRO_SMOOTHING define option that implement a moving average like mine, but mine is loop-optimized also.
I think GYRO_SMOOTHING must be removed and explained more the use of average.

GYRO_SMOOTHING is based on a customized LPF, 1 setting per axis. It was introduced to soften the servo response in case or fix wing conf, not for multirotor escs. 1 setting per axis is important here.
MMGYRO is based on a customized length moving average filter, 1 setting for the 3 axis.

Alexinparis · Post by **Alexinparis** » Fri Mar 23, 2012 12:39 am

aamorin wrote:
Alexinparis wrote:[...]
for Serial GPS device:
gps should be configured by yourself to ouput NMEA frames
home is memorired as soon as possible when the power is on, the status led should blink accordingly once a fix is ok.
RTH o PH is activated via a checkbox and in level mode only.

Let me try to understand.. this means that in order to the GPS work correctly, I should also enable the level mode ? (via checkbox)

Thanks for the hard work and keep going like that !

GPS mode principle: apply an inclination to the multi in level mode, based on distance&direction.
So yes LEVEL mode must be activated for GPS mode.

gionag · Post by **gionag** » Fri Mar 23, 2012 1:03 am

I don't know if it is a feature or a bug.

In the 2.0 PRE 4 i can arm motors with Throttle_Down/Yaw_right and also with Trotthle_Down/Roll_Right

so i can arm with Yaw and also with the Roll stick... is it ok ? or is a bug ??

If i put throttle (in disarm mode) at % different from 0% i can't use roll for arming...

What do you think ?

Thanks

PatrikE · Post by **PatrikE** » Fri Mar 23, 2012 8:51 am

It's OK.
If you use a Tri you can Arm without tilting the rear motor and risk the prop hitting the ground...

UndCon · Post by **UndCon** » Fri Mar 23, 2012 10:27 am

Enable by dual sticks was introduced several versions back...

I just downloaded v.4 and do some tests on my gear - seems to work as expected with vanilla hardware

(Paris v4, genuine WMP/NK, BMP085)

How it performs in air is still untested to me as my Quad needs a new boom.
//UndCon

Magnetron · Post by **Magnetron** » Fri Mar 23, 2012 10:50 am

Alexinparis wrote:
Magnetron wrote:ALEX,
I found GYRO_SMOOTHING define option that implement a moving average like mine, but mine is loop-optimized also.
I think GYRO_SMOOTHING must be removed and explained more the use of average.

GYRO_SMOOTHING is based on a customized LPF, 1 setting per axis. It was introduced to soften the servo response in case or fix wing conf, not for multirotor escs. 1 setting per axis is important here.
MMGYRO is based on a customized length moving average filter, 1 setting for the 3 axis.

You're right.
Please integrate MMACC code and explaing comments to use it also. Have you seen or tryed my TRUSTED_ACC_Z function? It must be used after activating MMACC moving average...

ciskje · Post by **ciskje** » Fri Mar 23, 2012 1:07 pm

Alexinparis wrote:
ciskje wrote:Earth magnetic field is [0.2;0.7] (from equator to the poles) Gauss
Positive BIAS during init for x&y is 1.16 Gauss, z is 1.08 (check this difference Alex!)
Maximum field is so 1.86 Gauss
We can work without problem with 1.3 Ga scale. (and a lot far away from overflow with the 2.5Ga during init).

If you can overflow it, it is a soft or hard iron problem (motors, speakers, or too much metal near the sensor).

Hi,
The spec is not so clear for me.
The spec says:
"For example, if the configuration register B is set to 0x60 (Gain=3), values around +766 LSB (1.16 Ga * 660 LSB/Ga) will be placed in the X and Y data output registers and around +713 (1.08 Ga * 660 LSB/Ga) will be placed in Z data output register."
So I understand it's an example of what could be measured, but not a specific scaled factor.

page 2 (summary specifications HMC5883L):

Self Test X & Y Axes
±1.16

Z Axis
±1.08
gauss

BIAS are different for x&y and z.

Joachim08 · Post by **Joachim08** » Fri Mar 23, 2012 6:46 pm

Alexinparis wrote:
Joachim08 wrote:I am just changing from MK to Multiwii and have changed from 1.9 to pre4. I am using a quad with BMA020, WMO and D&I Board.
After changing the direction for ACC-Roll and ACC-Pitch and calibration of the acc i recognized that ACC-Z is only around 64 instead of
256 with 1.9. Is that correct ?.

yes it is correct, it's due to the new 8G settings for BMA020

Alex, thanks thats understood now.

If you have time, can you check your code for the "toilet bowl effect" when on ACC hold with BMA020 ? Also others have
experienced the same problem, maybe and decay value in PID control ?

mgros · Post by **mgros** » Fri Mar 23, 2012 7:52 pm

I'm testing my new FREEIMUv04 and im my opinion, seeing the beaviour of ACC angle corrections in GUI
There is a better angle calculation if you put in MPU6050 ACC section in sensors.pde

Code: Select all

acc_1G = 512;

instead

Code: Select all

acc_1G = 255;

Can anyother confirm it?

copterrichie · Post by **copterrichie** » Fri Mar 23, 2012 8:37 pm

Joachim08 wrote:
Alex, thanks thats understood now.

If you have time, can you check your code for the "toilet bowl effect" when on ACC hold with BMA020 ? Also others have
experienced the same problem, maybe and decay value in PID control ?

Is there a remote possibility that the BMA020 is defective?

Joachim08 · Post by **Joachim08** » Fri Mar 23, 2012 11:26 pm

copterrichie wrote:
Is there a remote possibility that the BMA020 is defective?

I dont think so. It works with 1.9 without any issue.

ronco · Post by **ronco** » Sat Mar 24, 2012 12:16 am

mgros wrote:I'm testing my new FREEIMUv04 and im my opinion, seeing the beaviour of ACC angle corrections in GUI
There is a better angle calculation if you put in MPU6050 ACC section in sensors.pde
Code: Select all
acc_1G = 512; 
instead
Code: Select all
acc_1G = 255; 
Can anyother confirm it?

Hi,

confirmed! i use a MPU only setup .. so if i tilt it vertical it overshootes with z 255 .. with z 512 it looks right.

regards

Felix

dramida · Post by **dramida** » Sat Mar 24, 2012 12:38 am

PedAnd wrote:Hi!

Any solution to the issue due to funny characters and messed up navigation on the LCD for the Crius in MultiWii v 2.0?

PedAnd

I confirm that Crius Multiwii Board don't work on V2.0 pre 4 with standard serial LCD, it shows the words and values messed up among other funny characters.

Hamburger · Post by **Hamburger** » Sat Mar 24, 2012 12:53 am

Please try fix from thread about seriall tx error. Does it help?

Waldmensch · Post by **Waldmensch** » Sat Mar 24, 2012 9:12 am

Is it normal that Baro shows negative results in GUI in pre4

If I Enable Baro on my 8" Quad it jumps 3m up and fall down and so on. I have Alt PID reduced to 0.7/0.015/7 doesn't change. The Baro curve looks good in GUI - normal up/down like a sinus curve. I have no i2c errors

Alexinparis · Post by **Alexinparis** » Sun Mar 25, 2012 1:51 am

ciskje wrote:
Alexinparis wrote:
ciskje wrote:Earth magnetic field is [0.2;0.7] (from equator to the poles) Gauss
Positive BIAS during init for x&y is 1.16 Gauss, z is 1.08 (check this difference Alex!)
Maximum field is so 1.86 Gauss
We can work without problem with 1.3 Ga scale. (and a lot far away from overflow with the 2.5Ga during init).

If you can overflow it, it is a soft or hard iron problem (motors, speakers, or too much metal near the sensor).

Hi,
The spec is not so clear for me.
The spec says:
"For example, if the configuration register B is set to 0x60 (Gain=3), values around +766 LSB (1.16 Ga * 660 LSB/Ga) will be placed in the X and Y data output registers and around +713 (1.08 Ga * 660 LSB/Ga) will be placed in Z data output register."
So I understand it's an example of what could be measured, but not a specific scaled factor.

page 2 (summary specifications HMC5883L):

Self Test X & Y Axes
±1.16

Z Axis
±1.08
gauss

BIAS are different for x&y and z.

ok, right.
I didn't look enough at this page

I will correct it in the next version

Alexinparis · Post by **Alexinparis** » Sun Mar 25, 2012 1:52 am

Joachim08 wrote:
Alexinparis wrote:
Joachim08 wrote:I am just changing from MK to Multiwii and have changed from 1.9 to pre4. I am using a quad with BMA020, WMO and D&I Board.
After changing the direction for ACC-Roll and ACC-Pitch and calibration of the acc i recognized that ACC-Z is only around 64 instead of
256 with 1.9. Is that correct ?.

yes it is correct, it's due to the new 8G settings for BMA020

Alex, thanks thats understood now.

If you have time, can you check your code for the "toilet bowl effect" when on ACC hold with BMA020 ? Also others have
experienced the same problem, maybe and decay value in PID control ?

I've not experienced the same effect, so difficult to analyse...

Alexinparis · Post by **Alexinparis** » Sun Mar 25, 2012 1:55 am

Waldmensch wrote:Is it normal that Baro shows negative results in GUI in pre4

If I Enable Baro on my 8" Quad it jumps 3m up and fall down and so on. I have Alt PID reduced to 0.7/0.015/7 doesn't change. The Baro curve looks good in GUI - normal up/down like a sinus curve. I have no i2c errors

The absolute altitude given by the baro is not accurate at all and could be negative.
It depends on the current atmospheric pressure.

Alexinparis · Post by **Alexinparis** » Sun Mar 25, 2012 1:58 am

ronco wrote:
mgros wrote:I'm testing my new FREEIMUv04 and im my opinion, seeing the beaviour of ACC angle corrections in GUI
There is a better angle calculation if you put in MPU6050 ACC section in sensors.pde
Code: Select all
acc_1G = 512; 
instead
Code: Select all
acc_1G = 255; 
Can anyother confirm it?
Hi,

confirmed! i use a MPU only setup .. so if i tilt it vertical it overshootes with z 255 .. with z 512 it looks right.

regards

Felix

everyone is right here

explanation:
http://forum.sparkfun.com/viewtopic.php?f=14&t=30624
I got one of the first series and the code is for it.
You probably have recent one with acc scale MPU bug corrected.
I will correct it for the 2.0

pm1 · Post by **pm1** » Sun Mar 25, 2012 9:39 am

BMP085 and OSS=2

The oversampling setting was reduced from 8 to 4 samples. The reason was to get more unique samples. But in my opinion now the processor does exactly the same what the BMP085 does internally. Unless there is a bug in the internal oversampling, this is only a waste of CPU time. I have set the oversampling back to 8 samples witout any visual difference...

UndCon · Post by **UndCon** » Sun Mar 25, 2012 9:47 am

Is there any difference in cycles between 4 and 8 samples?

If there are no difference go with 4 (I also have a BMP85)

//UndCon

pm1 · Post by **pm1** » Sun Mar 25, 2012 10:00 am

The BMP085 needs roughly about 3-4.5 milliseconds for one sample. Either the chip averages up to to 8 samples internally (faster), or you read every sample yourself and make an average in code. Since the pressure calculation is relatively complex, your can save a lot of CPU time (at least for the 8 bit AVRs).

Alexinparis · Post by **Alexinparis** » Sun Mar 25, 2012 2:53 pm

pm1 wrote:BMP085 and OSS=2

The oversampling setting was reduced from 8 to 4 samples. The reason was to get more unique samples. But in my opinion now the processor does exactly the same what the BMP085 does internally. Unless there is a bug in the internal oversampling, this is only a waste of CPU time. I have set the oversampling back to 8 samples witout any visual difference...

It was a mod made by marbalon.
I don't know if it makes a difference in flight, by it works.
I understand your view, but I think it was a way to introduce more samples in the moving average vector.

Alexinparis · Post by **Alexinparis** » Sun Mar 25, 2012 2:54 pm

I hope the number of remaining bugs is low, because 2.0 is now released

pm1 · Post by **pm1** » Sun Mar 25, 2012 3:45 pm

Alexinparis wrote:... but I think it was a way to introduce more samples in the moving average vector.

marbalon said, he had more *unique* samples now. But that isn't true, since now are even less samples taken -> The internal averaging is a bit faster and you'll save the time for the temperature sampling.
With 8 times oversampling you can reduce the average vector to half length with the same result.

pm1 · Post by **pm1** » Sun Mar 25, 2012 4:01 pm

Waldmensch wrote:Is it normal that Baro shows negative results in GUI in pre4

That depends on the height above sea-level where you are living. The calculated height is based on an atmospheric pressure of 1013 hPa. At the the moment, we have a pressure of about 1030 hPa here. The calculated height is therefore about 100 m lower that the reality.

Joachim08 · Post by **Joachim08** » Sun Mar 25, 2012 4:03 pm

Alexinparis wrote:I hope the number of remaining bugs is low, because 2.0 is now released

...and i cannot use it because of the toilet bow effect with ACC on and BMA020...
Looks like if have to get other sensors.....

pm1 · Post by **pm1** » Sun Mar 25, 2012 4:18 pm

Joachim08 wrote:...and i cannot use it because of the toilet bow effect with ACC on and BMA020...
Looks like if have to get other sensors.....

Maybe a bit of debugging and fixing the problem is an option too

One yaw rotation in 20 seconds is not much. Did you already try to compensate with trim? Does the level functionality work beside this rotation?

noobee · Post by **noobee** » Sun Mar 25, 2012 4:24 pm

Alexinparis wrote:I hope the number of remaining bugs is low, because 2.0 is now released

CONGRATULATIONS!

it's a MAJOR milestone!

Wayne · Post by **Wayne** » Sun Mar 25, 2012 4:25 pm

Thank you Alex and all.
Let March 25 always be known as 2.0 Day!

Joachim08 · Post by **Joachim08** » Sun Mar 25, 2012 4:32 pm

pm1 wrote:
Joachim08 wrote:...and i cannot use it because of the toilet bow effect with ACC on and BMA020...
Looks like if have to get other sensors.....

Maybe a bit of debugging and fixing the problem is an option too

One yaw rotation in 20 seconds is not much. Did you already try to compensate with trim? Does the level functionality work beside this rotation?

Unfortunately i am not a coder....

It is not a yaw movement. Hm how can i describe it..... Maybe i will try to shot a video....
It looks similar like this : http://www.youtube.com/watch?v=txT1oh-BpPI
... when ACC is on. Level doesnt work because of this effect.
Changing PID didnt help.
It is working on 1.9 so i dont think its a problem with BMA020 or my quad

dodecopter · Post by **dodecopter** » Sun Mar 25, 2012 5:32 pm

Alexinparis wrote:
dodecopter wrote:
Alexinparis wrote:
Better efficiency for hardware pwm: digitalWrite arduino function was removed in order to address directly the output ports.
One consequence: motor order is no more easily configurable.

is there no chance to modify motor-outs anymore?
that would be the only drawback for me and some others, who burnt a single motor-out pin from their flyduino mega...

seems that i have to change my "handicapped" mega to a new one.

It's less easier to modify the order, but it's still possible.
It's just more complicated than moving 2 numbers.

i took a looooong look at the code, but i got no idea how to solve my motor-order problem ........

is there someone with a hint, how motor-order can be changed?

Cronalex · Post by **Cronalex** » Sun Mar 25, 2012 5:56 pm

hi, i have a multiwii crius se i have charged multiwii relase 2.0 but i have a problem
when start my quadcopter and give power to motor the quad do a flip forward but if i charge 1.9 version it's ok have you an idea for my problem?
thanks
best regards

motor suppo 2212 1000kv
esc hobbywing skywalker 20a

pm1 · Post by **pm1** » Sun Mar 25, 2012 6:09 pm

Cronalex wrote:hi, i have a multiwii crius se i have charged multiwii relase 2.0 but i have a problem
when start my quadcopter and give power to motor the quad do a flip forward but if i charge 1.9 version it's ok have you an idea for my problem?

If you are using level mode, calibrate ACC before use!

Christian1990 · Post by **Christian1990** » Sun Mar 25, 2012 6:13 pm

GPS from Flyduino to firmware 2.0 pre1

Today I spent some time around the part to move up and running, unfortunately it has not succeeded,

So GPS LED indicates
RX to RX, TX GND on TX of course connected to 5 volts also.

kommmentiert in software GPS Serial 2, at 9600 baud to 4800 and also trying times 115200, all
Tries with different serial ports Bautraten no GPS feature both in space and outdoors.
it all takes on the MEGA board with Bmp 020, 085 and also the Mag Bma values so the GPS.

What did I do wrong, by the way on the 1.9 is not the part that

Am grateful for every opinion

Mfg.
Christian

Cronalex · Post by **Cronalex** » Sun Mar 25, 2012 6:27 pm

pm1 wrote:
Cronalex wrote:hi, i have a multiwii crius se i have charged multiwii relase 2.0 but i have a problem
when start my quadcopter and give power to motor the quad do a flip forward but if i charge 1.9 version it's ok have you an idea for my problem?

If you are using level mode, calibrate ACC before use!

no level mode activate .. No functions Activate .. start quadcopter gyro

Lapino · Post by **Lapino** » Sun Mar 25, 2012 6:32 pm

Cronalex wrote:
pm1 wrote:
Cronalex wrote:hi, i have a multiwii crius se i have charged multiwii relase 2.0 but i have a problem
when start my quadcopter and give power to motor the quad do a flip forward but if i charge 1.9 version it's ok have you an idea for my problem?

If you are using level mode, calibrate ACC before use!

no level mode activate .. No functions Activate .. start quadcopter gyro

Do the copter movings match the ones displayed in the Gui? Maybe some sort of orientation error? ...just a guess