MultiWii 2.0 is coming

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
Wayne
Posts: 86
Joined: Sun Jul 31, 2011 10:44 pm

Re: MultiWii 2.0 is coming

Post by Wayne »

Thank You Alex for 2.0.PV2!

mon_lolo_fr
Posts: 40
Joined: Tue Nov 15, 2011 9:50 am

Re: MultiWii 2.0 is coming

Post by mon_lolo_fr »

Yes, thanks Alex !

User avatar
kos
Posts: 286
Joined: Thu Feb 16, 2012 4:51 am
Location: Fr

Re: MultiWii 2.0 is coming

Post by kos »

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

Gaza07
Posts: 12
Joined: Sat Apr 23, 2011 9:28 pm
Location: Nottingham Uk

Re: MultiWii 2.0 is coming

Post by Gaza07 »

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
Posts: 39
Joined: Thu Jan 20, 2011 1:16 am

Re: MultiWii 2.0 is coming

Post by JussiH »

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
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: MultiWii 2.0 is coming

Post by timecop »

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
Posts: 17
Joined: Thu Jan 26, 2012 9:12 am

Re: MultiWii 2.0 is coming

Post by mlebret »

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
Posts: 66
Joined: Fri Feb 25, 2011 2:57 pm

Re: MultiWii 2.0 is coming

Post by noobee »

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
Posts: 38
Joined: Tue Oct 11, 2011 1:42 pm

Re: MultiWii 2.0 is coming

Post by didlawowo69 »

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.

User avatar
mbrak
Posts: 136
Joined: Sat Dec 03, 2011 8:08 pm
Location: Germany, Lemgo

Re: MultiWii 2.0 is coming

Post by mbrak »

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
Posts: 17
Joined: Thu Jan 26, 2012 9:12 am

Re: MultiWii 2.0 is coming

Post by mlebret »

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
Posts: 39
Joined: Thu Jan 20, 2011 1:16 am

Re: MultiWii 2.0 is coming

Post by JussiH »

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 :D 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
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: MultiWii 2.0 is coming

Post by Alexinparis »

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
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: MultiWii 2.0 is coming

Post by Alexinparis »

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
Posts: 124
Joined: Tue Jul 05, 2011 4:32 pm

Re: MultiWii 2.0 is coming

Post by Magnetron »

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.

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: MultiWii 2.0 is coming

Post by jevermeister »

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

Nils

Zarro
Posts: 1
Joined: Thu Mar 15, 2012 9:18 am

Re: MultiWiihttp://www.multiwii.com/forum/posting. 2.0 is co

Post by Zarro »

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
Posts: 124
Joined: Tue Jul 05, 2011 4:32 pm

Re: MultiWiihttp://www.multiwii.com/forum/posting. 2.0 is co

Post by Magnetron »

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

User avatar
mbrak
Posts: 136
Joined: Sat Dec 03, 2011 8:08 pm
Location: Germany, Lemgo

Re: MultiWii 2.0 is coming

Post by mbrak »

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 :)

User avatar
Gaijin
Posts: 82
Joined: Sat Jan 14, 2012 8:00 am

Re: MultiWii 2.0 is coming

Post by Gaijin »

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

User avatar
kos
Posts: 286
Joined: Thu Feb 16, 2012 4:51 am
Location: Fr

Re: MultiWii 2.0 is coming

Post by kos »

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 ?

User avatar
Gaijin
Posts: 82
Joined: Sat Jan 14, 2012 8:00 am

Re: MultiWii 2.0 is coming

Post by Gaijin »

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

haley0918
Posts: 28
Joined: Tue Mar 06, 2012 9:09 am

Re: MultiWii 2.0 is coming

Post by haley0918 »

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. :D
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
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: MultiWii 2.0 is coming

Post by Alexinparis »

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
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: MultiWii 2.0 is coming

Post by Alexinparis »

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
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: MultiWii 2.0 is coming

Post by Alexinparis »

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
Posts: 124
Joined: Tue Jul 05, 2011 4:32 pm

Re: MultiWii 2.0 is coming

Post by Magnetron »

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...
:(

User avatar
Bledi
Posts: 187
Joined: Sat Sep 10, 2011 6:36 pm

Re: MultiWii 2.0 is coming

Post by Bledi »

"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 ???...

User avatar
Gaijin
Posts: 82
Joined: Sat Jan 14, 2012 8:00 am

Re: MultiWii 2.0 is coming

Post by Gaijin »

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.
Posts: 16
Joined: Mon Mar 05, 2012 7:22 am

Re: MultiWii 2.0 is coming

Post by karsten j. »

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

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: MultiWii 2.0 is coming

Post by Hamburger »

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
Posts: 28
Joined: Tue Mar 06, 2012 9:09 am

Re: MultiWii 2.0 is coming

Post by haley0918 »

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
Posts: 317
Joined: Thu Aug 18, 2011 2:58 pm

Re: MultiWii 2.0 is coming

Post by ronco »

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
Posts: 32
Joined: Tue Mar 01, 2011 10:01 pm

Re: MultiWii 2.0 is coming

Post by dynai »

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
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: MultiWii 2.0 is coming

Post by Alexinparis »

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
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: MultiWii 2.0 is coming

Post by Alexinparis »

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
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: MultiWii 2.0 is coming

Post by Alexinparis »

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 ?

User avatar
Gaijin
Posts: 82
Joined: Sat Jan 14, 2012 8:00 am

Re: MultiWii 2.0 is coming

Post by Gaijin »

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
Last edited by Gaijin on Sat Mar 17, 2012 12:25 pm, edited 3 times in total.

PatrikE
Posts: 1976
Joined: Tue Apr 12, 2011 6:35 pm
Location: Sweden
Contact:

Re: MultiWii 2.0 is coming

Post by PatrikE »

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
Posts: 32
Joined: Tue Mar 01, 2011 10:01 pm

Re: MultiWii 2.0 is coming

Post by dynai »

Alexinparis wrote:could you look a little bit more ;)

:shock: 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
Posts: 2
Joined: Sat Nov 26, 2011 5:38 pm
Location: Tennessee, USA

Re: MultiWii 2.0 is coming

Post by dshutters »

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
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: MultiWii 2.0 is coming

Post by Alexinparis »

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
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: MultiWii 2.0 is coming

Post by Alexinparis »

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
Posts: 166
Joined: Wed Nov 23, 2011 10:50 am
Location: Hamburg, Germany
Contact:

Re: MultiWii 2.0 is coming

Post by LenzGr »

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.

User avatar
captaingeek
Posts: 228
Joined: Fri Jan 28, 2011 6:42 pm

Re: MultiWii 2.0 is coming

Post by captaingeek »

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

User avatar
captaingeek
Posts: 228
Joined: Fri Jan 28, 2011 6:42 pm

Re: MultiWii 2.0 is coming

Post by captaingeek »

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
Posts: 27
Joined: Wed Mar 14, 2012 10:30 am

Re: MultiWii 2.0 is coming

Post by cestb »

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
Posts: 6
Joined: Sat Mar 17, 2012 6:34 pm
Location: Norway

Re: MultiWii 2.0 is coming

Post by PedAnd »

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

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: MultiWii 2.0 is coming

Post by Hamburger »

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
Posts: 6
Joined: Sat Mar 17, 2012 6:34 pm
Location: Norway

Re: MultiWii 2.0 is coming

Post by PedAnd »

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!

Post Reply