v1.8

[johnnyquad]

Fix for orientation of (Gyro) Wii Motion plus in sensors.pde line ~888

change code from

Code: Select all

// Wii Motion Plus Data
  if ( (rawADC[5]&0x03) == 0x02 ) {
    // Assemble 14bit data 
    gyroADC[ROLL]  = - ( ((rawADC[5]>>2)<<8) | rawADC[2] ); //range: +/- 8192
    gyroADC[PITCH] = - ( ((rawADC[4]>>2)<<8) | rawADC[1] );
    gyroADC[YAW]  =  - ( ((rawADC[3]>>2)<<8) | rawADC[0] );
    GYRO_Common();
    // Check if slow bit is set and normalize to fast mode range
    gyroADC[ROLL]  = (rawADC[3]&0x01)     ? gyroADC[ROLL]/5  : gyroADC[ROLL];  //the ratio 1/5 is not exactly the IDG600 or ISZ650 specification 
    gyroADC[PITCH] = (rawADC[4]&0x02)>>1  ? gyroADC[PITCH]/5 : gyroADC[PITCH]; //we detect here the slow of fast mode WMP gyros values (see wiibrew for more details)
    gyroADC[YAW]   = (rawADC[3]&0x02)>>1  ? gyroADC[YAW]/5   : gyroADC[YAW];   // this step must be done after zero compensation    
    return 1;
  } else if ( (rawADC[5]&0x03) == 0x00 ) { // Nunchuk Data
    ACC_ORIENTATION(  ( (rawADC[3]<<2)      | ((rawADC[5]>>4)&0x02) ) ,
                    - ( (rawADC[2]<<2)      | ((rawADC[5]>>3)&0x02) ) ,
                      ( ((rawADC[4]>>1)<<3) | ((rawADC[5]>>5)&0x06) ) );
    ACC_Common();
    return 0;

to

Code: Select all

// Wii Motion Plus Data
if ( (rawADC[5]&0x03) == 0x02 ) {
    // Assemble 14bit data 
    GYRO_ORIENTATION( - ( ((rawADC[5]>>2)<<8) | rawADC[2] ), //range: +/- 8192
                     - ( ((rawADC[4]>>2)<<8) | rawADC[1] ),
                     - ( ((rawADC[3]>>2)<<8) | rawADC[0] ) );
    GYRO_Common();
    // Check if slow bit is set and normalize to fast mode range
    gyroADC[ROLL]  = (rawADC[3]&0x01)     ? gyroADC[ROLL]/5  : gyroADC[ROLL];  //the ratio 1/5 is not exactly the IDG600 or ISZ650 specification 
    gyroADC[PITCH] = (rawADC[4]&0x02)>>1  ? gyroADC[PITCH]/5 : gyroADC[PITCH]; //we detect here the slow of fast mode WMP gyros values (see wiibrew for more details)
    gyroADC[YAW]   = (rawADC[3]&0x02)>>1  ? gyroADC[YAW]/5   : gyroADC[YAW];   // this step must be done after zero compensation    
    return 1;
  } else if ( (rawADC[5]&0x03) == 0x00 ) { // Nunchuk Data
    ACC_ORIENTATION(  ( (rawADC[3]<<2)      | ((rawADC[5]>>4)&0x02) ) ,
                    - ( (rawADC[2]<<2)      | ((rawADC[5]>>3)&0x02) ) ,
                      ( ((rawADC[4]>>1)<<3) | ((rawADC[5]>>5)&0x06) ) );
    ACC_Common();
    return 0;

any changes to orientation will now work correctly for WM+

j

[Alexinparis]

Hi,

Based on your suggestion, I removed the gyro orientation correction for the WMP because the implementation was not correct.
Here I think it's still not correct because the slow/fast mode compensation won't be apply on the good axis.

example for the first axis: rawADC[3]&0x01 is tied to ((rawADC[5]>>2)<<8) | rawADC[2]

[jevermeister]

Hi,

I cannot find the reason why the motors are still stuttering after the failsafe shut them down. When youz look at the GUI u can see the speed alternating between 0 and failsafe throttle.
Something is trying to start the engines again.


Another issue: I was trying to make a branch and upload my modified buzzer routine but there was an unknown server error.

Is there a problem with the server or with my pc?

Nils

[Hamburger]

errenous missing line break in LCD.pde line 347 in v1.8 and up to r224:

Code: Select all

    #define ACCLIMIT 30 // threshold: for larger values replace bar with dots LCDprint(0xFE); LCDprint('L'); LCDprint(1); LCDprintChar("G "); //refresh line 1 of LCD

must read

Code: Select all

   #define ACCLIMIT 30 // threshold: for larger values replace bar with dots      
   LCDprint(0xFE);LCDprint('L');LCDprint(1);LCDprintChar("G "); //refresh line 1 of LCD

sorry, Hamburger

[johnnyquad]

Hi,

Based on your suggestion, I removed the gyro orientation correction for the WMP because the implementation was not correct.
Here I think it's still not correct because the slow/fast mode compensation won't be apply on the good axis.

example for the first axis: rawADC[3]&0x01 is tied to ((rawADC[5]>>2)<<8) | rawADC[2]

With the current logic of the code there is absolutely no easy way around this. The only easy way around is to allow the values to be scaled before being passed to GYRO_common().

One of many solutions I have tried is

Code: Select all

#define FAST_MODE_ORIENTATION(X, Y, Z) \
    inline uint8_t isFastMode##X(){return (rawADC[3]&0x01 == 0);} \
    inline uint8_t isFastMode##Y(){return (rawADC[4]&0x02 == 0);} \
    inline uint8_t isFastMode##Z(){return (rawADC[3]&0x02 == 0);}
    
  FAST_MODE_ORIENTATION(Roll, Pitch, Yaw)
  //ROLL 5 2 3:1
  //PITCH 4 1 4:2
   //YAW 3 0 3:2
...
gyroADC[ROLL]  = ( isFastModeRoll()    ?  gyroADC[ROLL] : gyroADC[ROLL]/5);

Although this works (providing rawADC declaration is moved) it relies on the user typing Roll, Pitch and Yaw correctly.

Another solution is

Code: Select all

uint8_t swapTable[3] = {PITCH, ROLL, YAW};
  uint8_t isFastMode(uint8_t axis)
  {
    switch(swapTable[axis])
    {
      case ROLL:
        return (rawADC[3]&0x01 == 0);
      case PITCH:
        return (rawADC[4]&0x02 == 0);
      case YAW:
        return (rawADC[3]&0x02 == 0);
    } 
  }

[crashlander]

Hello.
I have problem with my quad not like to fly fast!
My setup is:
- CONFIG 1: QuadX, ProMini, TGY Plush 10A, ATAVRSBIN1 (default LPF), SW v1.8
With that setup I'm unable to do FF flight since Quad is always trying to somehow level it-self additionaly if I add some back pull on stick it tries to backflip almost vertically (I'm flying in acro mode so it is not normal). On slow fly Quad fly stable and controlled.

- CONFIG 2: same as config 1 but instead of ATAVRSBIN1 I'm using (just) original WM+
That setup is O.K., and enables me to do FFF, fast turns and some mild acro.

Is there some known bug/solution to my problem with ATAVRSBIN1?

Best regards
Andrej

[captaingeek]

Try lowering the LPF.

[ziss_dm]

Hi crashlander,
What about your PIDs?

[cardboard]

I have an odd isssue where my tri losses all settings, pids and all go to 0. its an intermittent fault and happens on some power ups. the annoying thing is the lack or a reset default pid button on the gui
any other cases of settings going weird on people??

[crashlander]

Hi crashlander,
What about your PIDs?

PIDs that works with WM+ are: Roll 3.5 0.029 25, Pitch 3.8 0.029 25, Yaw 8.5 0 0
Same PIDs were used at the beginning also for ATAVRSBIN1, but later I used also (combinations of) Pitch PIDs of: 4.0 0.030 15, 4.0 0.030 10, 4.0 0.030 25, P of 3.5, I of 0.025.
And the "don't want to fly fast" symptoms were always present.

@ captaingeek
I'll try to lower LPF later today, but I believe that LPF only influences random oscillations....

[jevermeister]

I made a branch concerning a new buzzer routine, what do you guys think?

branch name: jevermeister

[PatrikE]

The annoying thing is the lack of a reset default pid button on the gui

Based on the files from SVN
http://code.google.com/p/multiwii/source/browse/#svn%2Ftrunk%2FMultiWii

It will reset PIDs but not calibrations.

/Patrik

[crashlander]

Try lowering the LPF.

Thank you!
It seems it works. I went down (in steps) to 98Hz and now is flyable again. Maybe I'll try 42Hz because I can still observe some leveling tendency after fast turn.
Today tests were done with PIDs of: 4.0 0.029 25 for pitch and roll and 8.5 0 0 for yaw (of corse they were not fine tuned).

[captaingeek]

I made a branch concerning a new buzzer routine, what do you guys think?

branch name: jevermeister

I think if you could make the LED / Pin 13 blink when the battery was low that would be awesome!

bonus for making it blink slowly at 40%, medium at 30 and fast below 20%.

[jevermeister]

I will try to include that, good idea!

Nils

[Hamburger]

I think if you could make the LED / Pin 13 blink when the battery was low that would be awesome!
bonus for making it blink slowly at 40%, medium at 30 and fast below 20%.

is not that the exact behavior we already have with the different battery levels?

[captaingeek]

if it is im not aware of how to enable it or configure.

[mr.rc-cam]

if it is im not aware of how to enable it or configure.

1) Software side: Open v1.8's config.h file. Find the "V Bat monitoring" define section. Ensure that "#define VBAT" is not commented (must be shown in bold text).
2) Hardware side: The 3S battery voltage must be reduced to a safe 0-5V range via a 33K / 51K ohm resistor pair. This attenuated voltage will go to Analog Pin-3 of the Arduino (exact pin number depends on chosen Arduino chip). If your shield board does not have the attenuator resistors then review the published multiwii's technical info for the details.

[jevermeister]

is not that the exact behavior we already have with the different battery levels?

The vBat currently works with the buzzer only - as far as I know.

The LED works via LED switch, this is very dependant of the given state of the LED.
The Problem with ressources that are use by multiple routines is, that the current state is uncontrollable, that is why I coded the buzzer routin that is priority driven, the same should happen with the LED.
The LED is default 1 if the copter is armed and 0 if not.
We have to rethink these states. What is more important, should the led blink while the copter is unarmed, etc etc.

I could code the LED into the same priority code but this will be a bigger task, because it is used by so many routines.

Nils

[mr.rc-cam]

The vBat currently works with the buzzer only - as far as I know.

That is correct, it provides three different buzzer alerts depending on the battery's voltage.

I have some animated LED's on my Quad that flash along with the low voltage buzzer alarm. But rather than use the existing status LED I have a I2C controlled I/O expander board that drives several strings of LED's. It is very attention getting!