MultiWii 2.0 is coming

[Hamburger]

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 !?

I do not understand.
You had this LCD working with v1.9 and the display is ok to read - not the funny characters?
And when you switch to v2.x, you get the funny chars?

[PedAnd]

Thats correct! Just switched back to 1.9 and then all good! No funny characters and fully PID tuning compatibility. Switched back to 2.0 and same messed up interface on the LCD navigation with funny characters.

[UndCon]

About that LCD - it looks just like one I got from china by mistake (I ordered a shield with LCD for Arduino)

The display I got is not even half as good as the genuine one from Sparkfun. When I use the LCD I always pick the Sparkfun version - the china-LCD is going into the bin.

//UndCon

[Hamburger]

Thats correct! Just switched back to 1.9 and then all good! No funny characters and fully PID tuning compatibility. Switched back to 2.0 and same messed up interface on the LCD navigation with funny characters.

which defines do you use for that LCD in config.h?
How do you connect it -3 wire servo cable or 4 wires?

[PedAnd]

which defines do you use for that LCD in config.h?
How do you connect it -3 wire servo cable or 4 wires?

I have tested all listed defines, but this is the define it works on in 1.9 #define LCD_SERIAL3W.
Using a 3 wire servo cable.

[noobee]

possible minor correction/question with 5843/5883 MAG init code (for Alex if useful).

in the Mag_init() routing, we write to configuration register B twice with two different gains:
- for self test with 0x20
- for normal operation with 0x60

1. i think we should be using the same value for both phases, since we are using the result of the self test phase to update magCal[], which is then applied to the values sampled in the normal operation phase.

2. minor: "1.3Ga" and "2.5Ga" numbers are not the configuration gain as in the comments. they are the "recommended sensor field range" to get full 12bit output range. so, the 0x20 setting ("1.3Ga") actually has more gain since it works in a reduced field range. from the 5883 datasheet, the actual gains are 1090 LSb/gauss for 1.3Ga field range (0x20) and 660 LSb/gauss for 2.5Ga field range (0x60). stronger magnetic field, less gain needed.

3. there have been reports that config register B value of 0x20 has too much gain for some locations (including mine ), causing the sensor to overflow. can we set the second initialization value to 0x60 (instead of 0x20) as well, which should work in more locations?

thanks!

[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

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.

Brilliant, that was the problem (I re-calibrated the esc's, this time with the receiver not my servo tester which must overdrive end points) setting the Mincommand back to 1000 fixed the problem, she arms and hovers now though I can't properly test it in my tiny garden, thanks very much Alex

By the way thanks for the Aux solution, I'll check that out but I'm still requesting a define in config.h when the feature freeze is complete, it'll save people like me a lot of frustration (and remembering every time we upgrade).

Finally, noticed a strange problem when testing pre 3 with a Crius SE in my quad, I don't have enough thrust to get airborne, all it will do is hop, now it has been in need of more than usual throttle for liftoff ever since I had to replace the landing gear with some sturdier units, but it has never failed to actually takeoff before.

pre 2 on a Quadrino on the same quad flew okay last weekend, has something changed in the way PWM is output lowering it all, other settings are identical?

[fr3d]

I've tested mw 2.0 p3 this afternnon
windy sun and cold weather. but flyable. original PiD except "yaw rate": +40 and "throttle rate +20"
quadX 60cm diag, kda20-22L, esc 30A, 10" props, flyduino board, mediatek gps,3S2200 mah and allinone sensors)
about eight minutes in the air.


acro mode very pleasant to fly
stab mode was not wonderful due to the wind ?? argh I remember I didn't care about leveled the quad during acc calibrating so stupid I am.
altitude "D" term modified but without a good stable mode it was not easy to appreciate the multiwii team works.

I switch mode stab, camstab and mag with the same switch (so in the same time ) heading hold was not good. I had pushed many times the quad and it didn't come back to his original heading. changed Mag "P" term and so it was not enable to keep his oritentaion 3.9 turn it spin left 4.1 it turn right
mag calibrarte was done of course.
With my old version mw1.7 heading was pretty good

I don't understand how to use GPS fonctions.
is it in this way ?
one aux channel position to memorize gps home ?
an another one to come back home ?

[Alexinparis]

Thats correct! Just switched back to 1.9 and then all good! No funny characters and fully PID tuning compatibility. Switched back to 2.0 and same messed up interface on the LCD navigation with funny characters.

Hi,
in the Serial.pde file, there is a line:

Code: Select all

    #define BITDELAY 102

Try to decrease 102, it might help

[Alexinparis]

possible minor correction/question with 5843/5883 MAG init code (for Alex if useful).

in the Mag_init() routing, we write to configuration register B twice with two different gains:
- for self test with 0x20
- for normal operation with 0x60

1. i think we should be using the same value for both phases, since we are using the result of the self test phase to update magCal[], which is then applied to the values sampled in the normal operation phase.

2. minor: "1.3Ga" and "2.5Ga" numbers are not the configuration gain as in the comments. they are the "recommended sensor field range" to get full 12bit output range. so, the 0x20 setting ("1.3Ga") actually has more gain since it works in a reduced field range. from the 5883 datasheet, the actual gains are 1090 LSb/gauss for 1.3Ga field range (0x20) and 660 LSb/gauss for 2.5Ga field range (0x60). stronger magnetic field, less gain needed.

3. there have been reports that config register B value of 0x20 has too much gain for some locations (including mine ), causing the sensor to overflow. can we set the second initialization value to 0x60 (instead of 0x20) as well, which should work in more locations?

thanks!

Hi,
1: the self test mode is used to get the proportion between each mag axis measurement. the settings should not affect the proportion if a non saturated situation.
2: yes but the range is in fact larger, not smaller: 1090 LSB/gauss means +/- 1.87 gauss
3: quite strange:
http://en.wikipedia.org/wiki/Earth's_magnetic_field
The intensity of the field is greatest near the poles and weaker near the Equator. It is generally reported in nanoteslas (nT) or gauss, with 1 gauss = 100,000 nT. It ranges from about 25,000–65,000 nT, or 0.25–0.65 gauss.
You encounter a magnetic field which can reach 1.3 Gauss (or 1.87) in your area ?

[Alexinparis]

I've tested mw 2.0 p3 this afternnon
windy sun and cold weather. but flyable. original PiD except "yaw rate": +40 and "throttle rate +20"
quadX 60cm diag, kda20-22L, esc 30A, 10" props, flyduino board, mediatek gps,3S2200 mah and allinone sensors)
about eight minutes in the air.

which props ?

acro mode very pleasant to fly
stab mode was not wonderful due to the wind ?? argh I remember I didn't care about leveled the quad during acc calibrating so stupid I am.
altitude "D" term modified but without a good stable mode it was not easy to appreciate the multiwii team works.

the quality of the level mode is hard to grasp with some wind

I switch mode stab, camstab and mag with the same switch (so in the same time ) heading hold was not good. I had pushed many times the quad and it didn't come back to his original heading. changed Mag "P" term and so it was not enable to keep his oritentaion 3.9 turn it spin left 4.1 it turn right
mag calibrarte was done of course.
With my old version mw1.7 heading was pretty good

Note that if you have too much yaw trim, the head lock mag doesn't lock.
The props quality is also important to have a good yaw accuracy.
(I ask about props, because I bought some months ago very unbalanced HK props which degrade a lot the flying quality included the yaw. Flyduino props are way better)

I don't understand how to use GPS fonctions.
is it in this way ?
one aux channel position to memorize gps home ?
an another one to come back home ?

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

[Alexinparis]

except major bugs, I hope the preversion 4 is the last one before the official 2.0

[noobee]

Hi,
1: the self test mode is used to get the proportion between each mag axis measurement. the settings should not affect the proportion if a non saturated situation.
2: yes but the range is in fact larger, not smaller: 1090 LSB/gauss means +/- 1.87 gauss
3: quite strange:
http://en.wikipedia.org/wiki/Earth's_magnetic_field
The intensity of the field is greatest near the poles and weaker near the Equator. It is generally reported in nanoteslas (nT) or gauss, with 1 gauss = 100,000 nT. It ranges from about 25,000–65,000 nT, or 0.25–0.65 gauss.
You encounter a magnetic field which can reach 1.3 Gauss (or 1.87) in your area ?

thanks for your response, Alex!

i'll probably need to understand better how magCal[] is used through the calibration process.

re. point 3: i'm not sure if the sensors are overflowing or something else, but i've had to set the gain setting to 0x60 for the sensors to report properly. otherwise, the values are all over the place. perhaps i should debug it more closely.

some have report the problem and suggested a similar change:

http://www.multiwii.com/forum/viewtopic.php?f=6&t=257&p=1945&hilit=0x60+5883#p1945

could also be a problem with my particular sensor:

http://www.rcgroups.com/forums/showthread.php?t=1358869&page=29&pp=50&highlight=5883l+overflow#post17792249

it's probably some error with my particular setup

thanks again!

[ankimo]

BMP085 does not work by mw2.0p3.
Is it already ending with solution?
In mw2.0p2, it works well.

Flyduino
Drotek 10DOF

Kazz

[captaingeek]

Flying pretty well, skip to the middle of the video. Flying with ACC and Mag active:

http://vimeo.com/38758899

I turned up P for ptch / roll thats it. Need to spend some time with PID tuning I think. It was windy but was flying very loose. Could not fly without the ACC / lev mode activated, if I tried it would try to tilt backwards which is probably due to the CG being off. MAG needs to be turned up a bunch.

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.

[fr3d]

error sorry

[fr3d]

I've tested mw 2.0 p3 this afternnon
windy sun and cold weather. but flyable. original PiD except "yaw rate": +40 and "throttle rate +20"
quadX 60cm diag, kda20-22L, esc 30A, 10" props, flyduino board, mediatek gps,3S2200 mah and allinone sensors)
about eight minutes in the air.

which props ?

flyduino black props the best one for me.

acro mode very pleasant to fly
stab mode was not wonderful due to the wind ?? argh I remember I didn't care about leveled the quad during acc calibrating so stupid I am.
altitude "D" term modified but without a good stable mode it was not easy to appreciate the multiwii team works.

the quality of the level mode is hard to grasp with some wind

so It will be better today it's 0/5km/h yesterday it was a bit stronger 25/35km/h....but flying with wind in acro was a real pleasure.
(here is a link of my brother in law camera during a night fly test with some french north wind....:http://www.youtube.com/watch?v=dDD8Nl6hhmA&context=C41f16eaADvjVQa1PpcFMaReBP9OgPxk9jU9RwQwLNajQsM61L_W4= it was funny)

I switch mode stab, camstab and mag with the same switch (so in the same time ) heading hold was not good. I had pushed many times the quad and it didn't come back to his original heading. changed Mag "P" term and so it was not enable to keep his oritentaion 3.9 turn it spin left 4.1 it turn right
mag calibrarte was done of course.
With my old version mw1.7 heading was pretty good

Note that if you have too much yaw trim, the head lock mag doesn't lock.
The props quality is also important to have a good yaw accuracy.
(I ask about props, because I bought some months ago very unbalanced HK props which degrade a lot the flying quality included the yaw. Flyduino props are way better)

yeah paul blake supply good props at good price, hk are chinese and quality is not often here.I've bought a lot of hk props, they need to be balanced a lot and they don't like little crash even somes breaks during flight. But they are very good to mix epoxy glue

I don't understand how to use GPS fonctions.
is it in this way ?
one aux channel position to memorize gps home ?
an another one to come back home ?

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

gps was configured to output only gp gga sentence (done before prev 3) @ 38400 bps and multiwiiconf /multiwinconf give a good feedback after this.

ok will try to reduce yaw rate, original is too slow for me. Maybee it's because I 'm used to fly with fast A/C on my copters(sceadu and trex600). will try to configure my rc transmitter with a different expo and reduce yaw rate too.

[PedAnd]

Thats correct! Just switched back to 1.9 and then all good! No funny characters and fully PID tuning compatibility. Switched back to 2.0 and same messed up interface on the LCD navigation with funny characters.

Hi,
in the Serial.pde file, there is a line:

Code: Select all

    #define BITDELAY 102

Try to decrease 102, it might help

I did try to decrease and increase 102, but didn't help. I saw some changes one the characters,but only made the situation worse. Then I have to stay with v. 1.9

Thanks for the help so far!

[Waldmensch]

The Description in config.h for INTERLEAVING_DELAY is wrong. If commented out the sketch doesn't build with or without Nunchuck. So it is used also without Nunchuck somewhere in code.

[PatrikE]

It's in computeIMU ().
But since NB and WMP is standard if no other sensors is defined it's always used.
But only when ( if (!ACC && nunchuk) )is true.

/Patrik

[Alexinparis]

BMP085 does not work by mw2.0p3.
Is it already ending with solution?
In mw2.0p2, it works well.

Flyduino
Drotek 10DOF

Kazz

Hi, code for baro is identical between pre2 and pre3.
what is exactly the problem ?

[capt]

Bmp085 working good on pre 3 for me.

[captaingeek]

baro's working great for me too. check it out:

http://www.youtube.com/watch?v=XGTxi5ZTnqk

hands free from 2:50 - ~ 3:30

I think if I dial it in some more it will do handsfree almost indefinately. nice going alex.

[ankimo]

BMP085 does not work by mw2.0p3.
Is it already ending with solution?
In mw2.0p2, it works well.

Flyduino
Drotek 10DOF

Kazz

Hi, code for baro is identical between pre2 and pre3.
what is exactly the problem ?

Hi Alex

I am sorry .
It is my mistake.
It had made a mistake in board selection.
It solved.

Kazz

[noobee]

re. point 3: i'm not sure if the sensors are overflowing or something else, but i've had to set the gain setting to 0x60 for the sensors to report properly. otherwise, the values are all over the place. perhaps i should debug it more closely.

just a quick followup.

i think it turns out that my crius se 5883l mag sensor is really broken.

the Y sensor raw (magADC[PITCH]) values will report -4096, which is outside the valid range, at some angles. it'll go from -500 to -550 to -600 then jump abruptly to -4096. only the Y sensor is weird, the X and Z both behave normally. also, all three sensors work ok with the lower gain setting in config register B (0x60)

let's see how the seller handles this RMA now.

[howardhb]

In Port Elizabeth, South Africa, I have to run the my 5883L gain set at 0x30, otherwise, I get "saturated" values like you report.
You should always re-calibrate the Mag (after changing gain settings) by pressing CALIB_MAG in the GUI.
Also, when calibrating, make sure that you turn the copter at least 2 revolutions in each axis.
H.

[noobee]

In Port Elizabeth, South Africa, I have to run the my 5883L gain set at 0x30, otherwise, I get "saturated" values like you report.
You should always re-calibrate the Mag (after changing gain settings) by pressing CALIB_MAG in the GUI.
Also, when calibrating, make sure that you turn the copter at least 2 revolutions in each axis.
H.

interesting. in my case, the raw adc values coming from the sensor are bad, but only for one axis. calibration just uses the min and max of the sampled adc values to establish a center, so it might not help in my case. but, it brings me to the next point (which might explain yours)

i looked a little closer at the code and am trying to figure out how magCal[] is used.

magCal is based on initial sample value in order to scale subsequent readings to around magnitude 1000 for each axis individually.

during init:
<magcal> = 1000.0 / <first adc>

during calibration:
<reading> = <next adc> * <magcal>
record <min> = min({<readings>})
record <max> = max({<readings>})
at end of calibration:
compute <mid> = midpoint of <min> and <max>

subsequently:
<reading> = <next adc> * <cal> - <mid>

<adc> is a 16 bit value (range is -32768 to 32767). if the ratio of subsequent <adc> to the initial <first adc> exceeds around 32, then the computation will overflow. fortunately, it looks like the range of the sampled values is like -200 to -500 for example in my case. it might not be in your case (location dependent).

but it also does raise the question of how accurate is this normalization (to 1000) if we only relied on the initial sampled value to scale.

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

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

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

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

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

thanks.

[MicroRaptor]

For this who are having problems with the mag, it would help if you are aware of your area's magnetic declination and inclination. Essentially, the earths magnetic field is only parallel to the earths surface near the equator, it's XY component is less nearer the poles. Z component is different from southern to northern hemisphere.

[fr3d]

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

[Joachim08]

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 ?.
I further noticed that the calibration data might not be stored because after i applied power again the ACC-values were unequal to 0, even
though the quad stands level. I have to recalibrate each time i apply power. I dont think thats correct as it works flawless with 1.9.

Any clue on the above ?

Regards

Joachim

[ciskje]

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

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

[Magnetron]

ALEX,

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

Code: Select all

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

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

Code: Select all

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

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

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

Code: Select all

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

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

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

[aamorin]

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

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

Thanks for the hard work and keep going like that !

[PedAnd]

Hi!

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

PedAnd

[JussiH]

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

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

Thanks

Jussi

[Joachim08]

Alex,

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

Thanks

Joachim

[fr3d]

Alex,

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

Thanks

Joachim

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

[Joachim08]

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

[marbalon]

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

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

Thanks

Jussi

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

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

[Alexinparis]

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

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

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

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

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

thanks.

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

[Alexinparis]

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

they are not included yet in the LCD conf

[Alexinparis]

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

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

[Alexinparis]

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

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

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

[Alexinparis]

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

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

[Alexinparis]

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

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

Thanks for the hard work and keep going like that !

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

[gionag]

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

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

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

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

What do you think ?

Thanks

[PatrikE]

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

[UndCon]

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

I just downloaded v.4 and do some tests on my gear - seems to work as expected with vanilla hardware
(Paris v4, genuine WMP/NK, BMP085)

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

[Magnetron]

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

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

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

[ciskje]

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.