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
Joachim08
Posts: 31
Joined: Sat Mar 17, 2012 10:10 am

Re: MultiWii 2.0 is coming

Post by Joachim08 »

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 ?

User avatar
mgros
Posts: 90
Joined: Thu Jan 20, 2011 12:32 am

Re: MultiWii 2.0 is coming

Post by mgros »

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?
Last edited by mgros on Fri Mar 23, 2012 11:48 pm, edited 1 time in total.

copterrichie
Posts: 2261
Joined: Sat Feb 19, 2011 8:30 pm

Re: MultiWii 2.0 is coming

Post by copterrichie »

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
Posts: 31
Joined: Sat Mar 17, 2012 10:10 am

Re: MultiWii 2.0 is coming

Post by Joachim08 »

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

Re: MultiWii 2.0 is coming

Post by ronco »

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

User avatar
dramida
Posts: 473
Joined: Mon Feb 28, 2011 12:58 pm
Location: Bucharest
Contact:

Re: MultiWii 2.0 is coming

Post by dramida »

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.

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

Re: MultiWii 2.0 is coming

Post by Hamburger »

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

Waldmensch
Posts: 31
Joined: Sat Dec 31, 2011 12:10 am

Re: MultiWii 2.0 is coming

Post by Waldmensch »

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

Re: MultiWii 2.0 is coming

Post by Alexinparis »

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

Re: MultiWii 2.0 is coming

Post by Alexinparis »

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

Re: MultiWii 2.0 is coming

Post by Alexinparis »

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

Re: MultiWii 2.0 is coming

Post by Alexinparis »

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
Posts: 136
Joined: Sun Jan 22, 2012 7:26 pm

Re: MultiWii 2.0 is coming

Post by pm1 »

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

User avatar
UndCon
Posts: 293
Joined: Mon Feb 21, 2011 2:10 pm

Re: MultiWii 2.0 is coming

Post by UndCon »

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
Posts: 136
Joined: Sun Jan 22, 2012 7:26 pm

Re: MultiWii 2.0 is coming

Post by pm1 »

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

Re: MultiWii 2.0 is coming

Post by Alexinparis »

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

Re: MultiWii 2.0 is coming

Post by Alexinparis »

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

pm1
Posts: 136
Joined: Sun Jan 22, 2012 7:26 pm

Re: MultiWii 2.0 is coming

Post by pm1 »

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
Posts: 136
Joined: Sun Jan 22, 2012 7:26 pm

Re: MultiWii 2.0 is coming

Post by pm1 »

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
Posts: 31
Joined: Sat Mar 17, 2012 10:10 am

Re: MultiWii 2.0 is coming

Post by Joachim08 »

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
Posts: 136
Joined: Sun Jan 22, 2012 7:26 pm

Re: MultiWii 2.0 is coming

Post by pm1 »

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

Re: MultiWii 2.0 is coming

Post by noobee »

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


CONGRATULATIONS!

it's a MAJOR milestone!

Wayne
Posts: 86
Joined: Sun Jul 31, 2011 10:44 pm

Re: MultiWii 2.0 is coming

Post by Wayne »

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

Joachim08
Posts: 31
Joined: Sat Mar 17, 2012 10:10 am

Re: MultiWii 2.0 is coming

Post by Joachim08 »

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
Posts: 35
Joined: Fri Jan 21, 2011 7:37 am

Re: MultiWii 2.0 is coming

Post by dodecopter »

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


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
Posts: 51
Joined: Tue Mar 20, 2012 8:41 pm

Re: MultiWii 2.0 is coming

Post by Cronalex »

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
Posts: 136
Joined: Sun Jan 22, 2012 7:26 pm

Re: MultiWii 2.0 is coming

Post by pm1 »

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
Posts: 4
Joined: Fri Mar 09, 2012 6:04 pm

Re: MultiWii 2.0 is coming

Post by Christian1990 »

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
Posts: 51
Joined: Tue Mar 20, 2012 8:41 pm

Re: MultiWii 2.0 is coming

Post by Cronalex »

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
Posts: 84
Joined: Tue Aug 16, 2011 10:01 am

Re: MultiWii 2.0 is coming

Post by Lapino »

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

Cronalex
Posts: 51
Joined: Tue Mar 20, 2012 8:41 pm

Re: MultiWii 2.0 is coming

Post by Cronalex »

with version 1.9 I don't have these problems... yes sensor orientation is ok (GUI)

wilco1967
Posts: 156
Joined: Thu Aug 18, 2011 6:04 pm
Location: Winterswijk, Netherlands

Re: MultiWii 2.0 is coming

Post by wilco1967 »

Cronalex wrote:with version 1.9 I don't have these problems... yes sensor orientation is ok (GUI)


are you sure ?
the orientation was changed between 1.9 and 2.0 on a lot of sensors.

http://www.multiwii.com/faq#How_should_ ... directions

Cronalex
Posts: 51
Joined: Tue Mar 20, 2012 8:41 pm

Re: MultiWii 2.0 is coming

Post by Cronalex »

wilco1967 wrote:
Cronalex wrote:with version 1.9 I don't have these problems... yes sensor orientation is ok (GUI)


are you sure ?
the orientation was changed between 1.9 and 2.0 on a lot of sensors.

http://www.multiwii.com/faq#How_should_ ... directions

yes is ok orientation... I use the crius Se and I defined the voice crius SE In the config.h

Cronalex
Posts: 51
Joined: Tue Mar 20, 2012 8:41 pm

Re: MultiWii 2.0 is coming

Post by Cronalex »

I did this test control by:
TILT the MULTI to the RIGHT (left side up):

MAG_ROLL, ACC_ROLL and GYRO_ROLL goes up
MAG_Z and ACC_Z goes down

TILT the MULTI forward (tail up):

MAG_PITCH, ACC_PITCH and GYRO_PITCH goes up
MAG_Z and ACC_Z goes down

Rotating the copter clockwise (YAW):

GYRO_YAW goes up

The copter stays level:

MAG_Z is positive ; ACC_Z is positive



P.S: Sorry for my English I use the translator

kalle123
Posts: 106
Joined: Sun Oct 09, 2011 10:07 am

Re: MultiWii 2.0 is coming

Post by kalle123 »

@cronalex.

You are posting here in SOFTWARE - CURRENT DEVELOPMENTS AND BUGS.

Next time better post in GETTING STARTED or GENERAL DISCUSSION.

BR/

Cronalex
Posts: 51
Joined: Tue Mar 20, 2012 8:41 pm

Re: MultiWii 2.0 is coming

Post by Cronalex »

kalle123 wrote:@cronalex.

You are posting here in SOFTWARE - CURRENT DEVELOPMENTS AND BUGS.

Next time better post in GETTING STARTED or GENERAL DISCUSSION.

BR/

sorry

Cronalex
Posts: 51
Joined: Tue Mar 20, 2012 8:41 pm

Re: MultiWii 2.0 is coming

Post by Cronalex »

sorry guys .. but I solved the problem by enabling // Moving Average Gyros by Magnetron1 (Michele Ardito) ########## beta

#define MMGYRO // Active Moving Average Function for Gyros
#define MMGYROVECTORLENGHT 10 // Lenght of Moving Average Vector

The quadricopter is stable now, but now I wonder why? if it is activated not working .. I before using this version I used the 1.9 with Average Gyros

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

Re: MultiWii 2.0 is coming

Post by Hamburger »

Mwii 2.0 is out.

Pleaze start new threads.

Magnetron
Posts: 124
Joined: Tue Jul 05, 2011 4:32 pm

Re: MultiWii 2.0 is coming

Post by Magnetron »

Alex, please implement in future version my moving average for gyros and for accs... users on BaroneRosso (italian forum) will appretiate it - they tell me days over days the success of moving averaging stability improvement, please add my comments also that explain hot to set it and try TRUSTED_ACCZ_VEL function to stabilize altitude in association with barometric sensor...
the link on discussion...
viewtopic.php?f=8&t=1290&start=180#p10679

Cronalex
Posts: 51
Joined: Tue Mar 20, 2012 8:41 pm

Re: MultiWii 2.0 is coming

Post by Cronalex »

Cronalex wrote:sorry guys .. but I solved the problem by enabling // Moving Average Gyros by Magnetron1 (Michele Ardito) ########## beta

#define MMGYRO // Active Moving Average Function for Gyros
#define MMGYROVECTORLENGHT 10 // Lenght of Moving Average Vector

The quadricopter is stable now, but now I wonder why? if it is activated not working .. I before using this version I used the 1.9 with Average Gyros


moving average of the gyros is really good... I have to try that on the accelerometers I keep you informed!!!

for now I have a problem loading I get this error:

MultiWii_2_0.cpp: In function 'void getEstimatedAltitude()':
MultiWii_2_0:1337: error: 'AccZHigh' was not declared in this scope
MultiWii_2_0:1337: error: 'AccZLow' was not declared in this scope

stay tuned!!! :)

Magnetron wrote:Alex, please implement in future version my moving average for gyros and for accs... users on BaroneRosso (italian forum) will appretiate it - they tell me days over days the success of moving averaging stability improvement, please add my comments also that explain hot to set it and try TRUSTED_ACCZ_VEL function to stabilize altitude in association with barometric sensor...
the link on discussion...
viewtopic.php?f=8&t=1290&start=180#p10679


if it works it works like that of the gyroscopes is a bomb ... is to be loaded in the next version

you are a big Magnetron!!! :P

Magnetron
Posts: 124
Joined: Tue Jul 05, 2011 4:32 pm

Re: MultiWii 2.0 is coming

Post by Magnetron »

Cronalex wrote:
Cronalex wrote:sorry guys .. but I solved the problem by enabling // Moving Average Gyros by Magnetron1 (Michele Ardito) ########## beta

#define MMGYRO // Active Moving Average Function for Gyros
#define MMGYROVECTORLENGHT 10 // Lenght of Moving Average Vector

The quadricopter is stable now, but now I wonder why? if it is activated not working .. I before using this version I used the 1.9 with Average Gyros


moving average of the gyros is really good... I have to try that on the accelerometers I keep you informed!!!

for now I have a problem loading I get this error:

MultiWii_2_0.cpp: In function 'void getEstimatedAltitude()':
MultiWii_2_0:1337: error: 'AccZHigh' was not declared in this scope
MultiWii_2_0:1337: error: 'AccZLow' was not declared in this scope

stay tuned!!! :)

Magnetron wrote:Alex, please implement in future version my moving average for gyros and for accs... users on BaroneRosso (italian forum) will appretiate it - they tell me days over days the success of moving averaging stability improvement, please add my comments also that explain hot to set it and try TRUSTED_ACCZ_VEL function to stabilize altitude in association with barometric sensor...
the link on discussion...
viewtopic.php?f=8&t=1290&start=180#p10679


if it works it works like that of the gyroscopes is a bomb ... is to be loaded in the next version

you are a big Magnetron!!! :P


Hi,
here is a fully barometric routine that will solve your problem:

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

Cronalex
Posts: 51
Joined: Tue Mar 20, 2012 8:41 pm

Re: MultiWii 2.0 is coming

Post by Cronalex »

Magnetron wrote:
Cronalex wrote:
Cronalex wrote:sorry guys .. but I solved the problem by enabling // Moving Average Gyros by Magnetron1 (Michele Ardito) ########## beta

#define MMGYRO // Active Moving Average Function for Gyros
#define MMGYROVECTORLENGHT 10 // Lenght of Moving Average Vector

The quadricopter is stable now, but now I wonder why? if it is activated not working .. I before using this version I used the 1.9 with Average Gyros


moving average of the gyros is really good... I have to try that on the accelerometers I keep you informed!!!

for now I have a problem loading I get this error:

MultiWii_2_0.cpp: In function 'void getEstimatedAltitude()':
MultiWii_2_0:1337: error: 'AccZHigh' was not declared in this scope
MultiWii_2_0:1337: error: 'AccZLow' was not declared in this scope

stay tuned!!! :)

Magnetron wrote:Alex, please implement in future version my moving average for gyros and for accs... users on BaroneRosso (italian forum) will appretiate it - they tell me days over days the success of moving averaging stability improvement, please add my comments also that explain hot to set it and try TRUSTED_ACCZ_VEL function to stabilize altitude in association with barometric sensor...
the link on discussion...
viewtopic.php?f=8&t=1290&start=180#p10679


if it works it works like that of the gyroscopes is a bomb ... is to be loaded in the next version

you are a big Magnetron!!! :P


Hi,
here is a fully barometric routine that will solve your problem:

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

yes DONE COMPILING

THE FUNCTION MUST BE // ?? to use the moving average on accelerometers:

/* This option should be uncommented if ACC Z is accurate enough when motors are running*/
/* should now be ok with BMA020 and BMA180 ACC */
//#define TRUSTED_ACCZ

???

tnx

Magnetron
Posts: 124
Joined: Tue Jul 05, 2011 4:32 pm

Re: MultiWii 2.0 is coming

Post by Magnetron »

This is config.h portion file to activate the functions:

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


the line
//#define TRUSTED_ACCZ
is indipendent from my routines... I suggest you to leave it activate (without //)

karsten j.
Posts: 16
Joined: Mon Mar 05, 2012 7:22 am

Re: MultiWii 2.0 is coming

Post by karsten j. »

Hi

I have a question regarding the Lipo-Alarm built in the software
This is the code

/* for V BAT monitoring
after the resistor divisor we should get [0V;5V]->[0;1023] on analog V_BATPIN
with R1=33k and R2=51k
vbat = [0;1023]*16/VBATSCALE */
#define VBAT // comment this line to suppress the vbat code
#define VBATSCALE 131 // change this value if readed Battery voltage is different than real voltage
#define VBATLEVEL1_3S 107 // 10,7V
#define VBATLEVEL2_3S 103 // 10,3V
#define VBATLEVEL3_3S 99 // 9.9V
#define NO_VBAT 16 // Avoid beeping without any battery

means, the buzzer should slowly beep at 10,7 V , shouldn´t it ?
But when I connect a full 12.4 V Lipo battery, the Buzzer beeps ....
What figures must I change to avoid this ?

Karsten

User avatar
fr3d
Posts: 97
Joined: Sun Feb 06, 2011 11:21 am
Location: Cappelle la grande near the ch'ti village
Contact:

Calculate vbatscale

Post by fr3d »

karsten j. wrote:Hi

I have a question regarding the Lipo-Alarm built in the software
This is the code

/* for V BAT monitoring
after the resistor divisor we should get [0V;5V]->[0;1023] on analog V_BATPIN
with R1=33k and R2=51k
vbat = [0;1023]*16/VBATSCALE */
#define VBAT // comment this line to suppress the vbat code
#define VBATSCALE 131 // change this value if readed Battery voltage is different than real voltage
#define VBATLEVEL1_3S 107 // 10,7V
#define VBATLEVEL2_3S 103 // 10,3V
#define VBATLEVEL3_3S 99 // 9.9V
#define NO_VBAT 16 // Avoid beeping without any battery

means, the buzzer should slowly beep at 10,7 V , shouldn´t it ?
But when I connect a full 12.4 V Lipo battery, the Buzzer beeps ....
What figures must I change to avoid this ?

Karsten

it's not a mw 2.0 error ...
may be you do not configure right the vbatscale value I use 121
...or you have swapped you resistor...
check your lipo battery voltage (ex :12v6)
check you midle point voltage betwen the 33k & 51k (ex:3v85)

some maths :

3.85 * [(1024/5)] = 3.85 * [204.8] = 788.48

788.48*16 = 12615.68
12615/126 =100 (126 is your 12.6v in mwc :mrgreen: )
100 is your vbatscale
simple non ?

warthox
Posts: 65
Joined: Sat Jan 29, 2011 10:05 pm

Re: MultiWii 2.0 is coming

Post by warthox »

there seems to be a problem with hex x config in fw2.0

today i tried the actual fw 2.0. it flew ok but sometimes in left roll there was something wrong.
it seemed that the left motor, connected to A0, reacts wrong.
in a left roll the motor should decraese rpm but instead the rpm increased for some seconds and fighted against the other motors on the left.
this happened not everytime i made a left roll. 3 times in the flight of maybe 4min. doesnt happen in the other directions.

fc. mwc board with pro mini and freeimu v0.4.3
A0 and A1 for left and right motor.
ppm sum rx.

Joachim08
Posts: 31
Joined: Sat Mar 17, 2012 10:10 am

Re: MultiWii 2.0 is coming

Post by Joachim08 »

At the end of the day i sadly switched back to 1.9...
There are too many bugs in 2.0 for me so i cannot fly my quad without
problems.

Maybe i try it again with another IMU which i have just ordered from Drotek...

User avatar
fr3d
Posts: 97
Joined: Sun Feb 06, 2011 11:21 am
Location: Cappelle la grande near the ch'ti village
Contact:

Another mw 2.0 bug

Post by fr3d »

today I've play with my little quad I 've noticed a strange bug,
I'was flying with a level pid "D" term less then 100,@ 90 exactly, the copter level smoother but after a moment the copter fall down....
may this help in debugging the "buggy" 2.0.

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Another mw 2.0 bug

Post by Alexinparis »

fr3d wrote:today I've play with my little quad I 've noticed a strange bug,
I'was flying with a level pid "D" term less then 100,@ 90 exactly, the copter level smoother but after a moment the copter fall down....
may this help in debugging the "buggy" 2.0.

please be more accurate: "after a moment the copter fall down"

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: MultiWii 2.0 is coming

Post by Alexinparis »

warthox wrote:there seems to be a problem with hex x config in fw2.0

today i tried the actual fw 2.0. it flew ok but sometimes in left roll there was something wrong.
it seemed that the left motor, connected to A0, reacts wrong.
in a left roll the motor should decraese rpm but instead the rpm increased for some seconds and fighted against the other motors on the left.
this happened not everytime i made a left roll. 3 times in the flight of maybe 4min. doesnt happen in the other directions.

fc. mwc board with pro mini and freeimu v0.4.3
A0 and A1 for left and right motor.
ppm sum rx.


Hi Markus,
There is apparently a bug about HEX configs (and probably octo) on a promini with 2.0.
I will try to reproduce it.

Post Reply