MultiWii 2.2 is released

vistauser · Post by **vistauser** » Fri Mar 15, 2013 12:57 pm

Hallo Marc,

good finding. I applied your change and the bat low warning now is as expected.
No negativ side effects seen.
For me the former double blib was the signal for landing, now its the single blib.

Olaf

afonsos · Post by **afonsos** » Fri Mar 15, 2013 5:39 pm

shikra wrote:I also thought that it flies a little better with teh new algo / faster loop times - wasn't sure if that was real on my part

If you fly FPV in horizon mode try the stock code then try again with:

adding this into config.h
#define GYR_CMPF_FACTOR 2000
Reducing level D - reduce to around 55

for me, it improved it significantly. best level mode flying by far. Lazy flying - perfect for AP. An dbest of all, drift issues completely eliminated...

G

Where this line should be added in config.h?
or should we edit #define GYR_CMPF_FACTOR 600 to #define GYR_CMPF_FACTOR 2000 on imu.ino?

Im sorry for the silly question

Hamburger · Post by **Hamburger** » Fri Mar 15, 2013 7:40 pm

mathe70 wrote:Hi,
I hope this is the right place to report errors for the V2.2 code. Please forgive me if it's not.

While trying V2.2 on my Crius AIOP V1.1 board I noticed that the 3 stage VBAT function is not working properly.
When the Lipo voltage goes below the setpoint of 10,7V the buzzer output is going directly to the second battery alarm stage.
So it looks like the buzzer output skips battery alarm stage 1.

The original V2.2 code in the Alarms.ino looks like this:
Code: Select all
#if defined(VBAT)
    if (vbatMin < conf.vbatlevel_crit) alarmArray[6] = 4;
    else if ( (vbat>conf.vbatlevel_warn1)  || (conf.no_vbat > vbat)) alarmArray[6] = 0;
    else if (vbat > conf.vbatlevel_warn2) alarmArray[6] = 2;
    else alarmArray[6] = 4;
  #endif
To get the 3 battery alarm stages working properly I've changed the code to:
Code: Select all
#if defined(VBAT)
    if (vbatMin < conf.vbatlevel_crit) alarmArray[6] = 4;
    else if ( (vbat > conf.vbatlevel_warn1)  || (conf.no_vbat > vbat)) alarmArray[6] = 0;
    else if (vbat > conf.vbatlevel_warn2) alarmArray[6] = 1;
    else if (vbat > conf.vbatlevel_crit) alarmArray[6] = 2;
    else alarmArray[6] = 4;
  #endif
Altough it seems to work correct now, I'm not a programmer so if someone could confirm that this is right, please do!

Marc

Noted. Thank you.

shikra · Post by **shikra** » Fri Mar 15, 2013 10:38 pm

both methods will work!
suggest add anywhere into config.h - might be easier to enable/ disable

afonsos wrote:Where this line should be added in config.h?
or should we edit #define GYR_CMPF_FACTOR 600 to #define GYR_CMPF_FACTOR 2000 on imu.ino?

Im sorry for the silly question

afonsos · Post by **afonsos** » Sat Mar 16, 2013 12:04 am

Thanks shikra,

Line added to config.h just had 2 fpv flights and so far so good,no more weird acc

vpb · Post by **vpb** » Sat Mar 16, 2013 7:39 am

afonsos wrote:Thanks shikra,

Line added to config.h just had 2 fpv flights and so far so good,no more weird acc

I still cannot test on my copter, maybe tomorrow. But, if when you move arround, then release the stick, the copter just gets its level and stop drifting, it's magic! Hunger to try...

skoubri · Post by **skoubri** » Sat Mar 16, 2013 1:15 pm

Hi, tested today 2.2 and have two questions... ANGLE mode seems not to be engaged (GUI).. only HORIZON gets Green when set to aux...

Checking MTK3329 gps which worked on 2.1 now doesn't work.. Do i have to define NMEA and initialize MTK GPS commands? binary mode is better?

All other stuff seems OK!.. flies pretty good, PH, RTH almost perfect... THANKS multiwii community!!!

Dietrich_M · Post by **Dietrich_M** » Sun Mar 17, 2013 10:02 am

It seems to be, the MINTHROTTLE function is changed in V2.2.
When I input MINTHROTTLE=1100 in the config.h this value is ignored by the software, the MultiWiiConf-program shoes 1180 after arming? I tried to input different values but always 1180 is indicated.
How can I change MINTHROTTLE now?

mathe70 · Post by **mathe70** » Sun Mar 17, 2013 10:58 am

Dietrich_M wrote:It seems to be, the MINTHROTTLE function is changed in V2.2.
When I input MINTHROTTLE=1100 in the config.h this value is ignored by the software, the MultiWiiConf-program shoes 1180 after arming? I tried to input different values but always 1180 is indicated.
How can I change MINTHROTTLE now?

Try to erase Eeprom before you flash the software into the FC.
That worked for me at least.

Marc

-ralf- · Post by **-ralf-** » Sun Mar 17, 2013 12:58 pm

I've a problem with WultiWii2.2 and SBus .... (same a friend of mine)

Look the video .... all signals have extreme jitter! It's the same on different
boards; this is Crius AIOP V1.1 with Orange RX9. Channels 9-18 are commented
in rx.ino.

In this video the board is armed and throttle is 50%. Same jitter when board is
not armed and throttle at 0%.

http://www.youtube.com/watch?v=TJ_O_EWC2yc&feature=youtu.be

EDIT: Same configuration, and with MultiWii 2.1 it works fine.
Maybe there is a conflict between the baud settings in config.h and rx.ino?

farzadsw · Post by **farzadsw** » Tue Mar 19, 2013 9:04 am

Hi everyone
I have been working on sonar sensor (SRF02) past few days, and I find following glitches in the code (both 2.1 and 2.2):
1. in sensors library, line 1535 the "SRF08_SENSOR_FIRST" is set to 0xF0, but it should be changed to 0x78, because i2c functions will shift the address later(0x78<<1=0xF0). By the way, my sensor address has been changed to 0x79, so I use this code:

Code: Select all

#if !defined(SRF08_SENSOR_FIRST) 
  #define SRF08_SENSOR_FIRST    0x79    // the first sensor i2c address (after it has been moved)
#endif

2.the SRF02 sensors (not SRF08) require more delay time between each reading for a valid measurement (specially in long ranges) . I changed this values in line 1526 (twice the default values):

Code: Select all

#if !defined(SRF08_RANGE_WAIT) 
  #define SRF08_RANGE_WAIT     160000      // delay between Ping and Range Read commands
#endif

#if !defined(SRF08_RANGE_SLEEP) 
  #define SRF08_RANGE_SLEEP    70000      // sleep this long before starting another Ping
#endif

3. The "SONAR_MULTICAST_PING" will not work for SRF02 sensors as they don't have a general broadcast address. It should be disabled for SRF02 sensors in line 1542.

I hope this helps new users to use sonar sensors.

Farzad

phenolic · Post by **phenolic** » Tue Mar 19, 2013 9:13 pm

I looked through the thread, I hope I didn't miss this but about the new PID calculations/values... When using PID RATEs do those need to be proportionally modified as well or do they stay the same to keep the same behaviour?

mcashatt · Post by **mcashatt** » Fri Mar 22, 2013 5:23 am

Nice work guys!

One quick question--Did the stick commands for "Angle" mode change in v2.2?

I used to be able to disarm, increase throttle stick to 100%, and then trim my ACC with stick movements on the Pitch and Roll axes. Each time I made an adjustment, a LED would blink a confirmation.

Now it seems that is gone?

Thanks!

Matt

mrrf900 · Post by **mrrf900** » Fri Mar 22, 2013 10:29 am

mcashatt wrote:Nice work guys!

One quick question--Did the stick commands for "Angle" mode change in v2.2?

I used to be able to disarm, increase throttle stick to 100%, and then trim my ACC with stick movements on the Pitch and Roll axes. Each time I made an adjustment, a LED would blink a confirmation.

Now it seems that is gone?

Thanks!

Matt

Still works that way for me using 2.2.

Have you checked your end point values?

Goetz · Post by **Goetz** » Fri Mar 22, 2013 11:12 am

I had it on serveral MW-Versions with differnt Boards, that the the calibration (NOT Trimming) at least once had to me made by Sticks, otherwise the trimming by sticks wasn't stored. ACC-Calibration by sticks is (when not armed) full roll, full throttle and full yaw left.

TextZombie · Post by **TextZombie** » Sat Mar 30, 2013 4:44 pm

I'm not sure if this is working as designed but I've found tweaking 2.2 very confusing until I realised a few of the values in config.h that appear to be static are actually written and read from eeprom. This looks to have come about due to the multiple configuration profiles feature, even when that feature is disabled. This means that just changing the values and uploading doesn't actually change them any more. It seems the only way to have these changes read is by erasing the eeprom, though I may be missing something.

To show the problem I'm describing, you can clear the eeprom of your board, set MINTHROTTLE to be 1200, compile and flash your board. Now when you arm, you can see in the GUI the motors jump to 1200 as expected.

Then go back to config.h and change MINTHROTTLE to say 1050, recompile and upload. I'd expect arming now would have the motors set to the new 1050 value, but the 1050 in config.h is overwritten with 1200 from eeprom.

As far as I can tell there's no way to write to the eeprom value directly, you'd have to clear the eeprom completely to have this value changed.
The same seems to be the case for VBATSCALE and I imagine other setting too.

P

Hamburger · Post by **Hamburger** » Sat Mar 30, 2013 4:58 pm

P
What you observed is described in length at top of config.h in note 1

phenolic · Post by **phenolic** » Sat Mar 30, 2013 5:05 pm

There doesn't appear to be any way to change many of those settings other than a full reset though. I guess it's suppose to be configurable but I don't see any MSP that change them. Things like minthrottle, etc.

TextZombie · Post by **TextZombie** » Sat Mar 30, 2013 6:07 pm

Seems whenever I post to a forum I end up feeling foolish :oops:

thanks for pointing that out Hamburger, I knew I must have missed something.

At least I know it's by design even though it seems very counter intuitive to me.I'm guessing long term these will need MSP messages defining for them and inclusion in the GUI.

Short term I saved myself a lot of messing about by adding the following to the end of the readEEPROM function, at least whilst I get set up.

Code: Select all

#ifndef MULTIPLE_CONFIGURATION_PROFILES
  conf.minthrottle = MINTHROTTLE;    
  conf.vbatscale = VBATSCALE;
#endif

P

Hamburger · Post by **Hamburger** » Sat Mar 30, 2013 9:38 pm

phenolic wrote:There doesn't appear to be any way to change many of those settings other than a full reset though. I guess it's suppose to be configurable but I don't see any MSP that change them. Things like minthrottle, etc.

You could always enable LCD_TTY, LCD_CONF and use whatever serial terminal program you prefer (or the Serial Monitor from arduino IDE). allows you to tune all params which are marked with (*) in config.h. I wrote some more info into the wiki just before the release.

Yes, the gui (and the MSP) is lagging behind. PatrikE made a huge step towards the gui catching up and supporting many more tunable params but that enhancement did not make it into the last release and not into the main branch.

vpb · Post by **vpb** » Sun Mar 31, 2013 10:34 am

shikra wrote:I also thought that it flies a little better with teh new algo / faster loop times - wasn't sure if that was real on my part

If you fly FPV in horizon mode try the stock code then try again with:

adding this into config.h
#define GYR_CMPF_FACTOR 2000
Reducing level D - reduce to around 55

for me, it improved it significantly. best level mode flying by far. Lazy flying - perfect for AP. An dbest of all, drift issues completely eliminated...

G

Hi Shikra, I just test your method. Yes I see that it solve nearly complete the acc issue. My LEVEL PID was 4.0 30 80, and I feel like the stock settings with Level's P 8.0, decreasing D downto 60 makes it softer but it's still harder than stock GYR_CMPF_FACTOR. Maybe I need to tune P & I a bit. But it's very good now

. Thank you again!

blues13 · Post by **blues13** » Tue Apr 02, 2013 11:00 pm

Hi all,

although being a noob (this is my first post) I perhaps have found a bug.
I am using MultiWii for nearly a year now. Quite successful I would claim... at least when you consider my background

So I am far from being an expert nor a developer.
And actually for me MW 2.2 means a hugh improvement: Flying default PIDs on my small quad and do not even have to use LPF any more.
So reaaaaaaaaly nice, actually. Thanks a lot for that.

Still I have to bother. During what was supposed to be a PID-Tuning-Session but -instead- ended up in a lot of fun ... I twice observed the following:
Flying in HORIZON-Mode I did some fast forward flights, change to fast backwards, change to fast forward flights, etc. (I know: It is not a really thrilling maneuver but my garden is really small..)
So I was only pushing nick for a few seconds then gently (kind of) transitioning to pulling and so on and did the necessary throttle compensation.
(Now comes the hard part to explain)
During that it happened twice that the copter started to lose altitude more than expected. (Initial altitude was about 5 meters.)
So I centred nick to let it level, actually slightly compensating to fight the horizontal speed.
Although I nearly stopped horizontal movement it continued descending.
Tried to fight it with more throttle... going up to full throttle ... but it kept descending completely ignoring my throttle input... nearly gently touched the ground and went up again like a rocket...
That descend while on full throttle happened with nearly no noticeable wooble.

After that I was able to fly a few more minutes, so I guess it wasn't a battery issue.
I was able to re-produce this once more.
A friend of mine had a similar experience when doing some wild flying with a different setup (hexa, bigger, different board, will post his specs as soon as I got them).

My quick "reference":

Now this post became much larger than expected... sorry for that.
Besides: Is this the right topic to post a bug at all? (Should have asked first I guess..., sorry for that as well.)

Any hints/ advice... much appreciated.
Perhaps I should try to get it on video...
Regards

nova1529 · Post by **nova1529** » Wed Apr 03, 2013 11:04 am

I am using crius AIOP v2 with multiwii2.2 but it will have I2C error
it disturb me so long..
but finally find where the bug is~

when the MultiWii 2.1
it define is MPU6050_EN_I2C_BYPASS
but in MultiWii 2.2
it define is MPU6050_I2C_AUX_MASTER

So change the define way to the v2.1 and the error is gone~~
that is how solve it!

RCvertt · Post by **RCvertt** » Sat Jul 06, 2013 10:32 pm

Hamburger wrote:P
What you observed is described in length at top of config.h in note 1

Can you please explain to me how this works. I assume you are referring to the note...

/* Notes:
* 1. parameters marked with (*) in the comment are stored in eeprom and can be tweaked via serial monitor or LCD.
* Changing those values in config.h and upload will require a 'Reset' from the GUI to take effect
*/

How do I use the Reset button in the GUI? Do I change a value in the code, upload the code, then press the "Reset" button to see the resulting code change?

-----------
I ask because so far I am unable to get an Arduino Mega working with Nintendo WMP/Nunchuck sensors in (2.2). They work fine with (1.7).

In (2.2) the Nintendo sensors only show up in the GUI if I uncomment this below and pitch and roll are moving in the wrong direction...

/* enforce your individual sensor orientation - even overrides board specific defaults */
#define FORCE_ACC_ORIENTATION(X, Y, Z) {accADC[ROLL] = Y; accADC[PITCH] = -X; accADC[YAW] = Z;}
#define FORCE_GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] = Y; gyroADC[PITCH] = -X; gyroADC[YAW] = Z;}

...changing the sign before the Y,X, Z has no affect even if I press the GUI "Reset" button. I have also tried uploading the Arduino example "eeprom_clear" sketch before making a sign change and I still see no change in the GUI pitch and roll indicator.

Alexinparis · Post by **Alexinparis** » Sat Jul 06, 2013 11:59 pm

The board orientation is not something that can be changed from GUI.
If your WMP+NK orientation is correct according to multiwii site), you shouldn't have to comment out the 2 #define lines.
the 2 #define are here if you plan to change the default orientation for instance.

RCvertt · Post by **RCvertt** » Sun Jul 07, 2013 1:25 am

Thanks Alex. Got it working following your advice.

Turns out the problem was that I wasn't calibrating the gyro. The graph moved so little and so fast when calibrating the gyro that I didn't notice it, like I could for the accel. Now that I know what to look for, all is well. Thanks again.
--------------

I must have had my sensors mounted wrong but was able to reverse the roll and pitch in (Sensors.ino) with this...

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] );    
    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] );

    } 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_ORIENTATION( -( (rawADC[3]<<2)      | ((rawADC[5]>>4)&0x02) ) ,
                        ( (rawADC[2]<<2)      | ((rawADC[5]>>3)&0x02) ) ,
                        ( ((rawADC[4]>>1)<<3) | ((rawADC[5]>>5)&0x06) ) );

For others, the first image is the gyro calibration, the second image is the accel..

riahut.com · Post by **riahut.com** » Fri Jul 12, 2013 12:17 am

I just installed 2.2 on my IOI MUltiWii, what I don't see anymore that is ACC mode, is that ON be default or what?
Also is there any changes in PID tweaking ?

felixrising · Post by **felixrising** » Fri Jul 12, 2013 1:59 am

Gyro mode is on by default (Acro mode), Acc is only on during Level/Angle or Horizon modes.. It's in the wiki.

scanman · Post by **scanman** » Tue Jul 23, 2013 2:39 pm

blues13 wrote:
Tried to fight it with more throttle... going up to full throttle ... but it kept descending completely ignoring my throttle input... nearly gently touched the ground and went up again like a rocket...

this happens to me when i switch on Baro and my baro is not tuned. are you sure you didnt put the baro switch on?

RCvertt · Post by **RCvertt** » Wed Jul 31, 2013 1:13 am

riahut.com wrote:...what I don't see anymore that is ACC mode, is that ON be default or what?...

You are right. The "Active" indication for "Level" mode appears to be gone in the (2.2) GUI.

RCvertt · Post by **RCvertt** » Wed Jul 31, 2013 1:17 am

How do we print to the monitor?
I would like to print out the values of servo[5] for the tricopter in (output.ino).

Using

Code: Select all

Serial.println(servo[5]);

in output.ino throws up errors.

mOuchadino · Post by **mOuchadino** » Mon Aug 05, 2013 9:32 pm

I have to build multiwii 2.2 with mpu 6050 acc + I2C Gps nav beta version :mrgreen:

the video as bellow

and my accident video :p :mrgreen:

i,m use tx turnigt with ER9x firmware + 6 position mixing switch

subaru4wd · Post by **subaru4wd** » Mon Aug 05, 2013 9:35 pm

mOuchadino wrote:and my accident video :p

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

Awe man! I thought I was going to get to see the inside of your cat!

sismeiro · Post by **sismeiro** » Tue Aug 06, 2013 1:15 am

Hi, the good sense should tell you to keep people and animals away from the rotating knifes (aka propellers) of multicopters. Please be careful, there are already to many bad examples of careless people with multicopters in the Internet. BR, Luis Sismeiro

mOuchadino · Post by **mOuchadino** » Fri Aug 09, 2013 10:32 am

sismeiro wrote:Hi, the good sense should tell you to keep people and animals away from the rotating knifes (aka propellers) of multicopters. Please be careful, there are already to many bad examples of careless people with multicopters in the Internet. BR, Luis Sismeiro

I should to repel the cats for first

MultiWii

MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released, bug?

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released, bug?

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released

Re: MultiWii 2.2 is released