MultiWii 2.0 is coming

Wayne · Post by **Wayne** » Tue Mar 13, 2012 2:09 pm

Thank You Alex for 2.0.PV2!

mon_lolo_fr · Post by **mon_lolo_fr** » Tue Mar 13, 2012 3:40 pm

Yes, thanks Alex !

kos · Post by **kos** » Tue Mar 13, 2012 6:59 pm

patch against 2.0_pre2 for 8mhz support .. download/file.php?id=907

Gaza07 · Post by **Gaza07** » Wed Mar 14, 2012 12:49 pm

Quite a few people have the mega and apc220 modules probably from using megapirate, It would be great if multiwii would get the use of serial 3 for this use,
Is this difficult to do or is it some thing that will be added at some point

Alexinparis wrote:
Magnetron wrote:Hi,
I would to try APC220 433MHz Wireless module to monitor GUI during flying.
I have a Flyduino Mega 2560 Board v2. It is possible to use this module on serial 3 without use FTDI port? Or can I connect APC220 on FTDI port directly?
Is it possibile to modify multiwii serial code to connect serial port 3?
Thanks.

currently, only Serial0 can be used for multiwii communication on MEGA.

JussiH · Post by **JussiH** » Wed Mar 14, 2012 1:32 pm

Yes, thanks for the new version, but there is still massive errors introduced in the orientation defines. Copying the working defines from 1.9 into 2.0 only makes gyro and accel respond normally but makes my mag become all screwed up.....

EDIT: this did not work - accel is inverted. I fixed it, but I still cant get the mag to respond properly.

Alex: can you please update this info to reflect the roll/pitch/yaw axises instead of X/Y/Z:
'

by Alexinparis » Mon Jun 20, 2011 11:52 pm

Hi,

Z MAG should be positive and not move a lot if the multi remains flat.
X MAG: ROLL RIGHT = positive; ROLL LEFT = negative
Y MAG: PITCH FORWARD = positive; PITCH backward = negative

I must admit that I dont see any logic in using Roll/pitch/yaw for MAG in the GUI, since the sensor is not working the way a gyro or accel works. It makes absolutely no sense removing the X/Y/Z and replacing them with roll/pitch/yaw. In my book it only adds to confusion when trying to work out the correct orientation of a mag.

Rolling back to Dev 0203 now

timecop · Post by **timecop** » Wed Mar 14, 2012 3:33 pm

Here's how I deal with mag orientation:

1) Get a bunch of people to screw around with it until proper one is found.

I tried doing it this way:
1) Look at graphs
2) Invert stuff
3) Test
4) Goto (1) until 2^3
Then finally got sick of it and let someone else figure it out.

mlebret · Post by **mlebret** » Wed Mar 14, 2012 3:58 pm

I have MultiWii 2.0 preview2 on two boards.

First one is Paris v4 with Sirius sensor board. Flight is OK

Second is Paris V4 with FreeImu 4.3. Flight is OK

MLB

noobee · Post by **noobee** » Wed Mar 14, 2012 4:01 pm

dongs wrote:Here's how I deal with mag orientation:

1) Get a bunch of people to screw around with it until proper one is found.

I tried doing it this way:
1) Look at graphs
2) Invert stuff
3) Test
4) Goto (1) until 2^3
Then finally got sick of it and let someone else figure it out.

i think it might help if we first face the copter to true magnetic north (or north-west) first (use a compass to align to some standard reference). then the behavior of the axis sensors as we roll, pitch and yaw would be consistent?

just imagine the magnetic flux passing through the copter is similar to the gravity vector passing vertically through the copter as well, but for a different sensor type.

didlawowo69 · Post by **didlawowo69** » Wed Mar 14, 2012 4:48 pm

mlebret wrote:I have MultiWii 2.0 preview2 on two boards.

First one is Paris v4 with Sirius sensor board. Flight is OK

Second is Paris V4 with FreeImu 4.3. Flight is OK

MLB

i have a question about this both IMU.In your opinion, which the best is it between sirius and Freeimu ? (différence for MPU and ITG).

thx for your response.

mbrak · Post by **mbrak** » Wed Mar 14, 2012 5:45 pm

hi

just tested 2.0pre2 with allinone imu. works as expected.
the headhold mode is doing a good job. also headfree which is the hardcore mag test function i think.
the alt-pid need a bit more finetune but works good with default pid.
gps hold holds the multi in a range of 10-12 meters now! it was a bit windy but not much. better than pre1 in my opinion. need more flight test. maybe friday on a big field. today i tested in my garden with some trees around. have to stop movement of the copter sometimes

good work alex!!!
if we could get the speed math to the gps code it is nearly perfect in functionality!

thanks jevermeister for buzzer.pde

good feedback! i realized that on full power my lipo drops down voltage (3s5000 40c) so the level 1 warning sounds

mlebret · Post by **mlebret** » Wed Mar 14, 2012 6:35 pm

didlawowo69 wrote:
mlebret wrote:I have MultiWii 2.0 preview2 on two boards.

First one is Paris v4 with Sirius sensor board. Flight is OK

Second is Paris V4 with FreeImu 4.3. Flight is OK

MLB

i have a question about this both IMU.In your opinion, which the best is it between sirius and Freeimu ? (différence for MPU and ITG).

thx for your response.

Hello,

I have a good experience with Sirius. Baro is not the best but Altitude hold is not that bad with the latest 2.0 dev. On last flight it stay in the +-1m range.

On the paper FreeIMU Baro is better, but I have only little flight time with it, so I cannot confirm the Altitude hold performance.

MLB

JussiH · Post by **JussiH** » Wed Mar 14, 2012 9:09 pm

dongs wrote:Here's how I deal with mag orientation:

1) Get a bunch of people to screw around with it until proper one is found.

I tried doing it this way:
1) Look at graphs
2) Invert stuff
3) Test
4) Goto (1) until 2^3
Then finally got sick of it and let someone else figure it out.

Funniest post all day

I did figure it eventually and got the DEX flying...

I still think that Roll/pitch/yaw makes absolutely no sense whatsover for the mag :?:

Alexinparis · Post by **Alexinparis** » Wed Mar 14, 2012 11:33 pm

Gaza07 wrote:Quite a few people have the mega and apc220 modules probably from using megapirate, It would be great if multiwii would get the use of serial 3 for this use,
Is this difficult to do or is it some thing that will be added at some point

Alexinparis wrote:
Magnetron wrote:Hi,
I would to try APC220 433MHz Wireless module to monitor GUI during flying.
I have a Flyduino Mega 2560 Board v2. It is possible to use this module on serial 3 without use FTDI port? Or can I connect APC220 on FTDI port directly?
Is it possibile to modify multiwii serial code to connect serial port 3?
Thanks.

currently, only Serial0 can be used for multiwii communication on MEGA.

Hi,
No, it's not difficult at all.
Currently, only Serial0 is driven by interrupts for TX transfer. It's needed for GUI communication.
Switching Serial0 with another one is easy to mod in Output.pde.

Alexinparis · Post by **Alexinparis** » Thu Mar 15, 2012 4:02 am

JussiH wrote:Yes, thanks for the new version, but there is still massive errors introduced in the orientation defines. Copying the working defines from 1.9 into 2.0 only makes gyro and accel respond normally but makes my mag become all screwed up.....

EDIT: this did not work - accel is inverted. I fixed it, but I still cant get the mag to respond properly.

Alex: can you please update this info to reflect the roll/pitch/yaw axises instead of X/Y/Z:
'
by Alexinparis » Mon Jun 20, 2011 11:52 pm

Hi,

Z MAG should be positive and not move a lot if the multi remains flat.
X MAG: ROLL RIGHT = positive; ROLL LEFT = negative
Y MAG: PITCH FORWARD = positive; PITCH backward = negative

I must admit that I dont see any logic in using Roll/pitch/yaw for MAG in the GUI, since the sensor is not working the way a gyro or accel works. It makes absolutely no sense removing the X/Y/Z and replacing them with roll/pitch/yaw. In my book it only adds to confusion when trying to work out the correct orientation of a mag.

Rolling back to Dev 0203 now

Hi Jussi,

The orientation of all sensors was recently reviewed in order to match the sensor specs.
It should not impact predefined boards.
I checked it's ok with 2.0 with predefined FREEIMUs, FFIMUs, MiniWii, ...
I will however change configs with individual sensors not listed in the list.

Magnetron · Post by **Magnetron** » Thu Mar 15, 2012 7:23 am

Hi Alex,
I have tested the v2.0Preversion1 and about Moving Average I think that only on gyros was poor because axis gyro values are moving around 0 value and the average will be just around that value, I think real improvement is moving average for accelerometers so I rewrite the routine here with some raccomandations about vector value lenght based on I2C bus speed.
I have also introduced a little idea on altitude hold using accelerometer Z axis.
So.
On config.h I have introduced this:

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

On Sensors.pde in ACC_Common:

Code: Select all

// ****************
// 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 for new Trusted_AccZ_Vel in IMU.pde I have used only the D component of velocity PID using also differential moving average used from marbalon for baro stabilization:

Code: Select all

void getEstimatedAltitude(){
  uint8_t index;
  static uint32_t deadLine = INIT_DELAY;
  static int16_t BaroHistTab[BARO_TAB_SIZE];
  static int8_t BaroHistIdx;
  static int32_t BaroHigh,BaroLow;
  int32_t temp32;
  int16_t last;
  
  // Magnetron1 (Michele Ardito) Trusted Z Acc
  #if defined(TRUSTED_ACCZ_VEL)
      #define ACCZ_TAB_SIZE   40
      uint8_t AccZindex;
      static int16_t AccZHistTab[ACCZ_TAB_SIZE];
      static int8_t AccZHistIdx;
      static int32_t AccZHigh,AccZLow;
      int16_t AccZlast;
      
      AccZlast = AccZHistTab[AccZHistIdx];
      AccZHistTab[AccZHistIdx] = accADC[YAW]; // <-- Acc Z axis value
      AccZHigh += AccZHistTab[AccZHistIdx];
      AccZindex = (AccZHistIdx + (ACCZ_TAB_SIZE/2))%ACCZ_TAB_SIZE;
      AccZHigh -= AccZHistTab[AccZindex];
      AccZLow  += AccZHistTab[AccZindex];
      AccZLow  -= AccZlast;
      AccZHistIdx++;
      if (AccZHistIdx == ACCZ_TAB_SIZE) AccZHistIdx = 0;
  #endif

  if (currentTime < deadLine) return;
  deadLine = currentTime + UPDATE_INTERVAL; 

  //**** Alt. Set Point stabilization PID ****
  //calculate speed for D calculation
  last = BaroHistTab[BaroHistIdx];
  BaroHistTab[BaroHistIdx] = BaroAlt/10;
  BaroHigh += BaroHistTab[BaroHistIdx];
  index = (BaroHistIdx + (BARO_TAB_SIZE/2))%BARO_TAB_SIZE;
  BaroHigh -= BaroHistTab[index];
  BaroLow  += BaroHistTab[index];
  BaroLow  -= last;
  BaroHistIdx++;
  if (BaroHistIdx == BARO_TAB_SIZE) BaroHistIdx = 0;

  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;
}

Please evaluate my mod and implement in new preversion (3 I Think) so users can try it and leave us feedbacks.

jevermeister · Post by **jevermeister** » Thu Mar 15, 2012 7:42 am

Alex is right the orientation is now compatible to the sensor spacs.I can confirm that for BMA020 BMA180 and Hmc5883L.

Nils

Zarro · Post by **Zarro** » Thu Mar 15, 2012 9:42 am

Hi,

I used the 2.0 prev1 on a Crius SE board. In the 1.9 it works good. But when I fly with 2.0 the Quad (X) turns suddently on the head (in the level-Mode, no stick-moving, lever + mag on, baro out). First I think it was the wind. I goes back to 1.9 and it`s good. I fly 5 Batteries and than I flashed back the 2.0 prev1 again. The first Batterie was good, at the second he turned suddently on the head. No chance for me to control (no wind, no stick-moving). I´ve seen in the prev2 the orientation is changed. Was that the problem?

Zarro

Magnetron · Post by **Magnetron** » Thu Mar 15, 2012 11:52 am

Zarro wrote:Hi,

I used the 2.0 prev1 on a Crius SE board. In the 1.9 it works good. But when I fly with 2.0 the Quad (X) turns suddently on the head (in the level-Mode, no stick-moving, lever + mag on, baro out). First I think it was the wind. I goes back to 1.9 and it`s good. I fly 5 Batteries and than I flashed back the 2.0 prev1 again. The first Batterie was good, at the second he turned suddently on the head. No chance for me to control (no wind, no stick-moving). I´ve seen in the prev2 the orientation is changed. Was that the problem?

Zarro

Yes it was

mbrak · Post by **mbrak** » Thu Mar 15, 2012 5:30 pm

Hi

mwc 2.0pre2 test!!

just did a long run .... sorry flight....

the altitude-hold works nearly perfect imho. my allinone-imu with bmp085 baro (light-tight with some foam around) has the pid (1.6/15/7). +/- 0.3m max!!

then tested gps-pos hold.
the conditions are light wind (aprox 1-2 m/s) sunny with 15 deg C.
after activating the mode the copter overruns the target point. it moved in a square of 15 by 15m.
i just calmed down the movement with the tx and wow!!! the copter only did a small movement of about 2 by 2 m box. very good !!!!
after that i took my hands off the tx and observed the copter 5 minutes long. absolute rock solid in a box of 2 by 2meters!

the problem is the start-phase after activating the pos-hold mode. the movements of the copter have to calm down first. after that ther is no problem!

so... charging lipos

Gaijin · Post by **Gaijin** » Thu Mar 15, 2012 7:56 pm

Found another bug

Hex6X Mode in 2.0 Pre2 seems to have the pwm outputs on D5 & D6 reversed, the esc's go straight to the setup tones during power up, 1.9 is a-okay.

Also I second the Crius SE sensor issue, the magnetometer is at least 90 deg out in the gui, haven't flown it to test the others

Is the Flytron.com Navigatron ready yet? I need some of this GPS Action

kos · Post by **kos** » Thu Mar 15, 2012 11:31 pm

Gaijin wrote:Hex6X Mode in 2.0 Pre2 seems to have the pwm outputs on D5 & D6 reversed, the esc's go straight to the setup tones during power up, 1.9 is a-okay.

hardawre is mega ? proMini ?

Gaijin · Post by **Gaijin** » Fri Mar 16, 2012 7:09 am

Promini Based All in One boards - Quadrino Zoom and Crius SE

haley0918 · Post by **haley0918** » Fri Mar 16, 2012 11:12 am

Magnetron wrote:
I have also introduced a little idea on altitude hold using accelerometer Z axis.

I like this idea of alt hold using acc Z, thumbs up. That means there's no measurement relative to anything to determine alt change. Unlike baro relative to sea level and sonar relative to nearest object.

But of course the magnitude of acc Z will change when tilted in flight so this have to be calculated with the tilt angle to get good result.

Alexinparis · Post by **Alexinparis** » Fri Mar 16, 2012 11:27 am

Magnetron wrote:I think that only on gyros was poor because axis gyro values are moving around 0 value and the average will be just around that value,

Hi,
I don't understand the argument.
A moving averege filter doesn't care about the mean value (0 or something else).

Currently:

- I'm not convinced for a gyro implementation. (worse on my setups) I leave it there for the moment to have more feedbacks because I want to believe you

and I would like to see a video showing clearly the benefits before/after.

- I thing it's really useful for servo output.

- I think it's useless for ACC as there is already a LFP which allreay averages data.

Alexinparis · Post by **Alexinparis** » Fri Mar 16, 2012 11:35 am

mbrak wrote:Hi

mwc 2.0pre2 test!!

just did a long run .... sorry flight....

the altitude-hold works nearly perfect imho. my allinone-imu with bmp085 baro (light-tight with some foam around) has the pid (1.6/15/7). +/- 0.3m max!!

then tested gps-pos hold.
the conditions are light wind (aprox 1-2 m/s) sunny with 15 deg C.
after activating the mode the copter overruns the target point. it moved in a square of 15 by 15m.
i just calmed down the movement with the tx and wow!!! the copter only did a small movement of about 2 by 2 m box. very good !!!!
after that i took my hands off the tx and observed the copter 5 minutes long. absolute rock solid in a box of 2 by 2meters!

the problem is the start-phase after activating the pos-hold mode. the movements of the copter have to calm down first. after that ther is no problem!

so... charging lipos

Hi,
This was exactly what I noticed also.
When the copter is very near for it's PH point, the GPS code is working very good.
The problem is when it comes to this point with a velocity. next step

Alexinparis · Post by **Alexinparis** » Fri Mar 16, 2012 11:41 am

Gaijin wrote:Found another bug

Hex6X Mode in 2.0 Pre2 seems to have the pwm outputs on D5 & D6 reversed, the esc's go straight to the setup tones during power up, 1.9 is a-okay.

Also I second the Crius SE sensor issue, the magnetometer is at least 90 deg out in the gui, haven't flown it to test the others

Is the Flytron.com Navigatron ready yet? I need some of this GPS Action

in 2.0 pre2, the code for CRIUS_SE was updated according to a contribution in _shared: (r627)

Code: Select all

  #define ACC_ORIENTATION(X, Y, Z)  {accADC[ROLL]  = -X; accADC[PITCH]  = -Y; accADC[YAW]  =  Z;}
  #define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] =  Y; gyroADC[PITCH] = -X; gyroADC[YAW] = -Z;}
  #define MAG_ORIENTATION(X, Y, Z)  {magADC[ROLL]  =  X; magADC[PITCH]  =  Y; magADC[YAW]  = -Z;}

I don't own this board and can't confirm

So is it right or wrong according to http://www.multiwii.com/faq#How_should_ ... directions ?

Magnetron · Post by **Magnetron** » Fri Mar 16, 2012 1:31 pm

Alexinparis wrote:
Magnetron wrote:I think that only on gyros was poor because axis gyro values are moving around 0 value and the average will be just around that value,

Hi,
I don't understand the argument.
A moving averege filter doesn't care about the mean value (0 or something else).

Currently:

- I'm not convinced for a gyro implementation. (worse on my setups) I leave it there for the moment to have more feedbacks because I want to believe you
and I would like to see a video showing clearly the benefits before/after.

- I thing it's really useful for servo output.

- I think it's useless for ACC as there is already a LFP which allreay averages data.

As you wish...

Bledi · Post by **Bledi** » Fri Mar 16, 2012 1:59 pm

"gyro values are moving around 0" is a classic problem on inertial system. The problem is that the external noise (electronic, magnetic, ...) is arround zero.
On the past I had working on inertial central for army fighters and to estimate (and eliminate) the external noise they add a physical sinusoidal oscillation on the gyros. It's like adding an "offset" so you can observe the noise and the gyro at 0 as 2 differents datas.
I think it's perhaps a very good ideal but now what is the best solution ???...

Gaijin · Post by **Gaijin** » Fri Mar 16, 2012 5:41 pm

Alexinparis wrote:
Gaijin wrote:Found another bug

Hex6X Mode in 2.0 Pre2 seems to have the pwm outputs on D5 & D6 reversed, the esc's go straight to the setup tones during power up, 1.9 is a-okay.

Also I second the Crius SE sensor issue, the magnetometer is at least 90 deg out in the gui, haven't flown it to test the others

Is the Flytron.com Navigatron ready yet? I need some of this GPS Action

in 2.0 pre2, the code for CRIUS_SE was updated according to a contribution in _shared: (r627)
Code: Select all
  #define ACC_ORIENTATION(X, Y, Z)  {accADC[ROLL]  = -X; accADC[PITCH]  = -Y; accADC[YAW]  =  Z;}
  #define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] =  Y; gyroADC[PITCH] = -X; gyroADC[YAW] = -Z;}
  #define MAG_ORIENTATION(X, Y, Z)  {magADC[ROLL]  =  X; magADC[PITCH]  =  Y; magADC[YAW]  = -Z;}
I don't own this board and can't confirm

So is it right or wrong according to http://www.multiwii.com/faq#How_should_ ... directions ?

It's right, as far as I can tell, I can't do a flight test right now, will hopefully try this weekend on the test quad, ignore my magnetometer comment.

Any thoughts on the Hex6X problem, the motors arm on 1.9 but she wants to roll and I cant use cam Stab among other improvements, I get strong overcompensation from the left and right motors when I test holding it down

karsten j. · Post by **karsten j.** » Fri Mar 16, 2012 8:14 pm

I have still a problem with my yaw and the MAG

When I tilted the system in all direction, the orientation initially follows and then slowly drifting back to level

The MAG doesn´t work when I fly.

What do I have to change ?!

Greets
Karsten

Hamburger · Post by **Hamburger** » Fri Mar 16, 2012 9:02 pm

karsten j. wrote:I have still a problem with my yaw and the MAG

When I tilted the system in all direction, the orientation initially follows and then slowly drifting back to level

The MAG doesn´t work when I fly.

What do I have to change ?!

did you setup sensors' orientation? A tutorial is in the faq section.

haley0918 · Post by **haley0918** » Sat Mar 17, 2012 3:13 am

karsten j. wrote:
When I tilted the system in all direction, the orientation initially follows and then slowly drifting back to level

Does your I2C error keep on increasing? If so, your acc can't be read and probably is because of wrong address.

ronco · Post by **ronco** » Sat Mar 17, 2012 10:06 am

Hi,

there is one small bug in 2.0 pre 3 (it was also in 2) for the promicro (32u4) usb communication the serial buffer must be defined before serialCom().

Code: Select all

#if defined(PROMINI) 
  uint8_t serialBufferRX[256][1];
  volatile uint8_t serialHeadRX[1],serialTailRX[1];
#endif
#if defined(PROMICRO)
  uint8_t serialBufferRX[256][2];
  volatile uint8_t serialHeadRX[2],serialTailRX[2];
  uint8_t usb_use_buf = 0;
#endif
#if defined(MEGA)
  uint8_t serialBufferRX[256][4];
  volatile uint8_t serialHeadRX[4],serialTailRX[4];
#endif


void serialCom() {
...
...

because it uses it different.

maybe its better to move the definitions to def.h?

regards Felix

dynai · Post by **dynai** » Sat Mar 17, 2012 11:24 am

Hi,

found a small one at the end of the gps.pde

Code: Select all

#endif
#endif

but why does the compass flip from north to south on roll and not on pitch?

kind regards christoph

Alexinparis · Post by **Alexinparis** » Sat Mar 17, 2012 11:44 am

ronco wrote:Hi,

there is one small bug in 2.0 pre 3 (it was also in 2) for the promicro (32u4) usb communication the serial buffer must be defined before serialCom().
Code: Select all
#if defined(PROMINI) 
  uint8_t serialBufferRX[256][1];
  volatile uint8_t serialHeadRX[1],serialTailRX[1];
#endif
#if defined(PROMICRO)
  uint8_t serialBufferRX[256][2];
  volatile uint8_t serialHeadRX[2],serialTailRX[2];
  uint8_t usb_use_buf = 0;
#endif
#if defined(MEGA)
  uint8_t serialBufferRX[256][4];
  volatile uint8_t serialHeadRX[4],serialTailRX[4];
#endif


void serialCom() {
...
...
because it uses it different.

maybe its better to move the definitions to def.h?

regards Felix

Hi,
Sorry, I moved this without thinking about pro micro.
I prefer to move it again at the beginning of the file.

Alexinparis · Post by **Alexinparis** » Sat Mar 17, 2012 11:48 am

dynai wrote:Hi,

found a small one at the end of the gps.pde
Code: Select all
#endif
#endif

could you look a little bit more

but why does the compass flip from north to south on roll and not on pitch?

It's true, it's due to the current angle calculation algo.
But note it happens only when the copter reaches a 90 deg inclination which should never happen if you rely on the compass.

Alexinparis · Post by **Alexinparis** » Sat Mar 17, 2012 11:52 am

Gaijin wrote:Any thoughts on the Hex6X problem, the motors arm on 1.9 but she wants to roll and I cant use cam Stab among other improvements, I get strong overcompensation from the left and right motors when I test holding it down

I checked the code and see nothing that can explain a switch signal between D5 and D6.
I probably don't understand your problem.
Did you set mincommand <1000 ?

Gaijin · Post by **Gaijin** » Sat Mar 17, 2012 11:57 am

Can we (meaning you smarter types) add the ability to turn off Aux3 & 4 as camera gimbal inputs in config.h whilst using cam stable?

e.g I have a Roll and pitch capable camera mount but would like to use Aux 3 for MultiWii functions but not camera Roll and keep Aux 4 for camera Pitch only

Also 2.0 preversion 3 is the same for the Hex6x issue (the D5 & 6 Outputs produce a high PWM output at power on e.g 2000 rather than 1000 so the esc's will not arm), the 1.9 issue was i think a reversal of motors 5 & 6 connections, my error sorry!

Min command is set at 900 for the Hobbywing Flyfun 25A Esc's, 3, 10, 11 & 9 all arm and function normally

Thanks

Photo's of the Hex (and rest of the family) below, it's an XAircraft diy Hex kit with Flyfun camera gimbal
https://plus.google.com/photos/108235385012513539305/albums/5719134899069227921?authkey=CLDts8j4kN-xFw

PatrikE · Post by **PatrikE** » Sat Mar 17, 2012 12:08 pm

Hi,

You can set a fixed value for roll by changing.

Code: Select all

//from
    servo[1] = constrain(TILT_ROLL_MIDDLE + TILT_ROLL_PROP   * angle[ROLL]  /16 + rcCommand[ROLL], TILT_ROLL_MIN, TILT_ROLL_MAX);

//To
servo[1] =constrain( 1500, TILT_ROLL_MIN, TILT_ROLL_MAX)

//of if you use SERVO_TILT
    S_ROLL  = TILT_ROLL_MIDDLE  + rcData[AUX4]-1500;
//To
    S_ROLL  = 1500;

Then you have AUX4 free.

dynai · Post by **dynai** » Sat Mar 17, 2012 1:28 pm

Alexinparis wrote:could you look a little bit more

ups my mistaked

Alexinparis wrote:It's true, it's due to the current angle calculation algo.
But note it happens only when the copter reaches a 90 deg inclination which should never happen if you rely on the compass.

thanks a lot for explaining.

kind regards christoph

dshutters · Post by **dshutters** » Sat Mar 17, 2012 3:29 pm

Had problems compiling 2.0pre when aux2 is defined on pin 12. Got an I2C_PULLUPS_ENABLE not defined in scope error. Had to change existing code in def.h so that "#define I2C_PULLUPS_ENABLE" is outside the scope of the #if !defined(RCAUXPIN12) construct.

Existing:

Code: Select all

  #if !defined(RCAUXPIN12)
    #define POWERPIN_PINMODE           pinMode (12, OUTPUT);
    #define POWERPIN_ON                PORTB |= 1<<4;
    #define POWERPIN_OFF               PORTB &= ~(1<<4); //switch OFF WMP, digital PIN 12
    #define I2C_PULLUPS_ENABLE         PORTC |= 1<<4; PORTC |= 1<<5;   // PIN A4&A5 (SDA&SCL)
  #else
    #define POWERPIN_PINMODE           ;
    #define POWERPIN_ON                ;
    #define POWERPIN_OFF               ;
    #define RCAUXPIN
  #endif
  #define I2C_PULLUPS_DISABLE        PORTC &= ~(1<<4); PORTC &= ~(1<<5);

Revised:

Code: Select all

  #if !defined(RCAUXPIN12)
    #define POWERPIN_PINMODE           pinMode (12, OUTPUT);
    #define POWERPIN_ON                PORTB |= 1<<4;
    #define POWERPIN_OFF               PORTB &= ~(1<<4); //switch OFF WMP, digital PIN 12
   #else
    #define POWERPIN_PINMODE           ;
    #define POWERPIN_ON                ;
    #define POWERPIN_OFF               ;
    #define RCAUXPIN
  #endif
  #define I2C_PULLUPS_ENABLE         PORTC |= 1<<4; PORTC |= 1<<5;   // PIN A4&A5 (SDA&SCL)
  #define I2C_PULLUPS_DISABLE        PORTC &= ~(1<<4); PORTC &= ~(1<<5);

Thanks to Alex and others for all of your great work.

Dave

Alexinparis · Post by **Alexinparis** » Sat Mar 17, 2012 4:13 pm

dshutters wrote:Had problems compiling 2.0pre when aux2 is defined on pin 12. Got an I2C_PULLUPS_ENABLE not defined in scope error. Had to change existing code in def.h so that "#define I2C_PULLUPS_ENABLE" is outside the scope of the #if !defined(RCAUXPIN12) construct.

Existing:

Code: Select all

  #if !defined(RCAUXPIN12)
    #define POWERPIN_PINMODE           pinMode (12, OUTPUT);
    #define POWERPIN_ON                PORTB |= 1<<4;
    #define POWERPIN_OFF               PORTB &= ~(1<<4); //switch OFF WMP, digital PIN 12
    #define I2C_PULLUPS_ENABLE         PORTC |= 1<<4; PORTC |= 1<<5;   // PIN A4&A5 (SDA&SCL)
  #else
    #define POWERPIN_PINMODE           ;
    #define POWERPIN_ON                ;
    #define POWERPIN_OFF               ;
    #define RCAUXPIN
  #endif
  #define I2C_PULLUPS_DISABLE        PORTC &= ~(1<<4); PORTC &= ~(1<<5);

Revised:

Code: Select all

  #if !defined(RCAUXPIN12)
    #define POWERPIN_PINMODE           pinMode (12, OUTPUT);
    #define POWERPIN_ON                PORTB |= 1<<4;
    #define POWERPIN_OFF               PORTB &= ~(1<<4); //switch OFF WMP, digital PIN 12
   #else
    #define POWERPIN_PINMODE           ;
    #define POWERPIN_ON                ;
    #define POWERPIN_OFF               ;
    #define RCAUXPIN
  #endif
  #define I2C_PULLUPS_ENABLE         PORTC |= 1<<4; PORTC |= 1<<5;   // PIN A4&A5 (SDA&SCL)
  #define I2C_PULLUPS_DISABLE        PORTC &= ~(1<<4); PORTC &= ~(1<<5);

Thanks to Alex and others for all of your great work.

Dave

Thanks, good catch.
it was probably a typo error.

Alexinparis · Post by **Alexinparis** » Sat Mar 17, 2012 4:20 pm

Gaijin wrote:Can we (meaning you smarter types) add the ability to turn off Aux3 & 4 as camera gimbal inputs in config.h whilst using cam stable?

e.g I have a Roll and pitch capable camera mount but would like to use Aux 3 for MultiWii functions but not camera Roll and keep Aux 4 for camera Pitch only

Also 2.0 preversion 3 is the same for the Hex6x issue (the D5 & 6 Outputs produce a high PWM output at power on e.g 2000 rather than 1000 so the esc's will not arm), the 1.9 issue was i think a reversal of motors 5 & 6 connections, my error sorry!

Min command is set at 900 for the Hobbywing Flyfun 25A Esc's, 3, 10, 11 & 9 all arm and function normally

Thanks

Photo's of the Hex (and rest of the family) below, it's an XAircraft diy Hex kit with Flyfun camera gimbal
https://plus.google.com/photos/108235385012513539305/albums/5719134899069227921?authkey=CLDts8j4kN-xFw

Hi,
Sorry, but with software pwm (motor 5,6,7,8 on a promini) you can't decrease MINCOMMAND below 1000. Otherwise, you will get what you noticed (something like 2000 instead of 1000)

if you want to remove the AUX3/4 pitch or roll component of cam stab, you have to edit Output.pde

Code: Select all

    S_PITCH = TILT_PITCH_MIDDLE + rcData[AUX3]-1500;
    S_ROLL  = TILT_ROLL_MIDDLE  + rcData[AUX4]-1500;

and remove rcData[AUXn]-1500
this way you can still reuse AUXn for other things.

LenzGr · Post by **LenzGr** » Sat Mar 17, 2012 4:44 pm

Hi, just wanted to report my experiences with a current pull from the SVN trunk (SVN revno: 637) using an "allinone" board connected to a Seeeduino Mega. RX is a Spektrum Satellite receiver. I recently flashed my ESCs (HK SS 18A) using Simon Kirby's "tgy" firmware and I am extremely pleased with the stability! Enabling the compass helps a lot to compensate some yaw drift I am experiencing with my frame. I just did some basic testing in the backyard, maybe I'll find a moment to test the alt hold code using the barometer this weekend.

I have a GPS (MediaTek MT3329) and a Sonar (SRF02) here, but they are not hooked up yet - that's going to be my next action.

Good job, everyone! Release 2.0 looks promising.

Update:

the only small code correction I would like to suggest is the following one to def.h:

Code: Select all

 #if defined(ALLINONE)
   #define ITG3200
   #define BMA180
+  #define BMA180_ADDRESS 0x82
   #define BMP085
   #define HMC5883
   #define ACC_ORIENTATION(X, Y, Z)  {accADC[ROLL]  =  X; accADC[PITCH]  = Y; accADC[YAW]  = Z;}

This matched the default configuration my allinone board was shipped with.

captaingeek · Post by **captaingeek** » Sat Mar 17, 2012 5:14 pm

testing multiwii version 2.0 pre release 3 (not the final 2.0) now. im hoping to set it up with the following hardware:

pro mini
atmel atavrsbin1
baro
in a hex using ppm with a flysky rx

captaingeek · Post by **captaingeek** » Sat Mar 17, 2012 5:16 pm

obviously any notes would be helpful for things to watch out for.

my config settings outside of defaults:
#define HEX6X
#define ATAVRSBIN1
#define BMP085
disable failsafe
#define MOTOR_STOP

I'm not sure which ppm setting to use im going to try
#define SERIAL_SUM_PPM PITCH,YAW,THROTTLE,ROLL,AUX1,AUX2,AUX3,AUX4 //For Graupner/Spektrum

I will probably have to use the MPU6050 Low pass filter settings later.

cestb · Post by **cestb** » Sat Mar 17, 2012 6:08 pm

Hi,

i'm not sure it's a bug but i could arm and disarm motor with Ail channel and with Rud channel. It's the same thing with 1.9 and 2.0 (not my report in 2.0 but confirmed).
I broke a prop during test because of Ail channel arming...

PedAnd · Post by **PedAnd** » Sat Mar 17, 2012 6:47 pm

Hi!

First post!

I'm having an issue whit the CRIUS MultiWii LCD made to do configuration on the PID settings after the updating to v. 2.0 (Pre 1,2 and 3). All of the different parameters coming on the LCD are typed in Chinese symbols and letters are missing. This makes it hard to navigate and make changes in the PID tuning.
The LCD I use is this one: http://www.ebay.com/itm/MWC-MultiWii-Lite-SE-flight-control-board-LCD-debugger-adjust-parameters-tool-/140656310926?pt=Radio_Control_Parts_Accessories&hash=item20bfc4fa8e

Hoping to solve this problem, so i can get flying!

Andreas

Hamburger · Post by **Hamburger** » Sat Mar 17, 2012 7:29 pm

Andreas,

PedAnd wrote:I'm having an issue whit the CRIUS MultiWii LCD made to do configuration on the PID settings after the updating to v. 2.0 (Pre 1,2 and 3). All of the different parameters coming on the LCD are typed in Chinese symbols and letters are missing. This makes it hard to navigate and make changes in the PID tuning.
The LCD I use is this one: http://www.ebay.com/itm/MWC-MultiWii-Lite-SE-flight-control-board-LCD-debugger-adjust-parameters-tool-/140656310926?pt=Radio_Control_Parts_Accessories&hash=item20bfc4fa8e

it was discussed here before viewtopic.php?f=18&t=1303&p=9785.
We did not get any feedback from the original poster if/how he ever resolved the problem.
Good luck.

PedAnd · Post by **PedAnd** » Sat Mar 17, 2012 7:55 pm

Hamburger wrote:Andreas,
PedAnd wrote:I'm having an issue whit the CRIUS MultiWii LCD made to do configuration on the PID settings after the updating to v. 2.0 (Pre 1,2 and 3). All of the different parameters coming on the LCD are typed in Chinese symbols and letters are missing. This makes it hard to navigate and make changes in the PID tuning.
The LCD I use is this one: http://www.ebay.com/itm/MWC-MultiWii-Lite-SE-flight-control-board-LCD-debugger-adjust-parameters-tool-/140656310926?pt=Radio_Control_Parts_Accessories&hash=item20bfc4fa8e

it was discussed here before viewtopic.php?f=18&t=1303&p=9785.
We did not get any feedback from the original poster if/how he ever resolved the problem.
Good luck.

Then it looks like i have to go back to the "old" 1.9 to use the LCD to do some PID tuning.

It has to be a fix to this, the LCD works fine in v 1.9 !?

Thanks to all for the good work put down in the MultiWii coding!