MultiWii

Posted: **Sat Nov 09, 2013 7:49 pm**

http://code.google.com/p/multiwii/downloads/list

I would like to thank all of you for making it possible

main changes 2.2 -> 2.3

***Control mode***

- main PITCH/ROLL/YAW PID modification (r1474)
- the sticks scaling is no more affected by PID coefficients
- yaw rate (to the right of the PIDs in GUI) now works as stick scaling
- default yaw rate is increased (with yaw rate at 0)
- yaw PID principle is now different from PITCH&ROLL PID:
- yaw ITerm windup is very high, allowing an 'elastic' direction return after a manual perturbation
- yaw ITerm is also constrained with a windup independent limit
- yaw PTerm is constrained in order to counter the yaw jump effect.
use yaw DTerm to increase this constrain (r1573)
- yaw ITerm is canceled if the yaw stick is not centered

- Throttle angle correction (r1374)

- Advanced Headfree mode added (see config.h for instructions) (r1374)

- DYNBALANCE option, individual motor can be controled via GUI, to test individual vibration
viewtopic.php?f=7&t=3294

- better gyro & acc calibration accuracy (r1546)
viewtopic.php?f=7&t=3880

- cannot arm is baro mode is on (r1550)
viewtopic.php?f=8&t=3910
! baro mode should be activated only when the multi is nearly Z stable !
- only one baro mode : vario around a throttle deadband (r1554)

- magHold is reset when arm is switched on (r1553)
viewtopic.php?f=8&t=3910

- ONLYARMWHENFLAT option (r1587)
viewtopic.php?f=8&t=4077&hilit=coming&start=40#p41755

***receiver & UART***

- RCSERIAL is now deeply integrated. If a MSP_SET_RAW_RC comes, it will just override legacy RX data. (r1420)
as a consequence, RCSERIAL is no more an option

- no RC averaging for Spektrum & SBUS (r1545)

- SBUS center define (r1568)
viewtopic.php?f=8&t=3957

- FAILSAFE_DETECT_TRESHOLD configurable

***GPS***

- Enables sonar altitude from i2c-gps-nav board (1424)

- navigation code will follow after 2.3

***GUI***

- Gui with Servosettings. (r1441 & r1450)
All models with servo included.

- GUI globalsettings (for some settings previously only in config.h)

- do not display /dev/cu.* devices but only corresponding /dev/tty.* (r1442)

- GUI baudrate as configurable setting

***LCD***

- lcd.telemtry: show max ground speed from gps data (r1398)

- lcd.telemetry: allow separate suppression of aux2 configuration (r1456)

- new display support 1.3" i2c OLED from digole.com (r1413)

- config.menu: when abort, revert all values back to last saved state

- visual feedback from servos during midpoint trim via LCD

***IMU and baro***

- correct GYRO_SCALE for all gyro (r1428)

- no more small angles while shaking the board (r1579)
viewtopic.php?f=8&t=4112

- baro Alt based on ground temp compensation (r1570)
viewtopic.php?f=8&t=4059

- not I reset for FIWEDWING (r1590)
viewtopic.php?f=7&t=2456&start=330#p42355

- add 6DOF LSM330 sensor (r1571)

- add ACC BMA280 sensor (r1600)

*** SERVO management ***

warning:
The pins for coptertypes with servos have been changed.
Attaching a servo to a motor pin can quickly destroy your servo.
All connection diagrams out there from v2.2 or older are no longer valid for v2.3 with servos using hardware PWM.

http://www.multiwii.com/wiki/index.php? ... figuration

- add 8 hardware PWM's for servos on MEGA boards. Servo outputs are 44,45,46,11,12,6,7,8 (r1384)

- Allow any servo refresh rate from 20 to 400Hz on Mega hardware PWM servos. (r1386)

- Tri servo moved to SERVO4 (pin11) on mega boards with HW PWM's. (r1392)

- a32u4 (nanoWii, MicroWii etc) HW PWM for 4 servos; warning different pins!!
(with lots of info and help from ronco)
(r1464 & r1470)

- add a generic way to configure servo settings : conf struct + MSP read/set messages (r1383)

- Added general servo handler (r1421 & r1429)
viewtopic.php?f=8&t=3498

- allow preset of some servo stuff from config.h (r1432)

- Gui with Servosettings. (r1441)

- add gimbal servo stretcher usable with HW PWM's. (r1384)
We can get 180 degrees servo move without servo modification.
- note about gimbal: settings for neutral&endpoints are no more in config.h, but only in GUI

- do not update servos during unarmed calibration of sensors which are sensitive to vibration (r1408)

***internal improvements***

- migration to a cpp/h code structure (r1515 & r1516)
viewtopic.php?f=8&t=3773
viewtopic.php?f=8&t=2931

- huge flash size optimization (around 1k)
thanks to fine struct definitions + serialization over MSP (r1369)

- make powermeter computation time based (again) to reduce config hassle and increase accuracy (r1375)

- read at most one analog channel per MWii main loop cycle (r1375)

- smoothing of RX_RSSI (r1379)

- make faster analog reads an option with default off to increase accuracy (r1375)

- detangle vbat & buzzer dependancy (r1375)

- optimization : small approximation bit shift used instead of * or / number
for TPA, rates, dynP, dynD and expo curb (r1376)

- Added checking for flash content change, and reload config parameters in this case. (r1389)

- split Serial into Serial(core UART management) & Protocol (r1548)

- loop is globally faster

***add-ons***

- option to suppress defaults in mwc sketch and load via gui from file instead (r1365)

- add OVERRIDE_PSENSORPIN option (r1375)

- manual for using Multiwii in Eclipse environment
http://www.multiwii.com/wiki/index.php? ... in_Eclipse

- add amperage to MSP_ANALOG (r1542)

- MY_PRIVATE_DEFAULTS (r1559)
viewtopic.php?f=8&t=3987

- no more than one MSP per port and per cycle
should smooth the delay while requesting MSP, especially for USB port on micro

Posted: **Sat Nov 09, 2013 8:01 pm**

Hi,

Thank you Alex and all the developers that contributed to this new release, I will say it is the best one so far.

I will update 2.3 in my Xcopter later today and fly it tomorrow morning.

Regards,
Luis Sismeiro

Posted: **Sun Nov 10, 2013 3:14 am**

Nice, I now have a reason to wake up early tomorrow. Time to play with the quad

Posted: **Sun Nov 10, 2013 6:02 am**

Good going! Congrats to all the many who contributed with code, documentation and testing.

Posted: **Sun Nov 10, 2013 10:16 am**

Very good, nice job!
thanks

Posted: **Sun Nov 10, 2013 11:42 am**

Good, good, good!!!

Posted: **Sun Nov 10, 2013 1:19 pm**

This sounds awesome! So much stuff I've been so keen to see, Christmas has come early :-)

Great job!

Posted: **Sun Nov 10, 2013 2:46 pm**

A minor bug in def.h is still in place (at least since 2.1), i corrected this locally some time ago.

/*
#define PINMODE_LCD DDRD |= (1<<2); // ProDrone: wrong PIN definition - commented out!
#define LCDPIN_OFF PORTD &= ~1;
#define LCDPIN_ON PORTD |= 1;
*/
#define PINMODE_LCD DDRD |= (1<<2); // ProDrone: working PIN definition for RX pin as intended
#define LCDPIN_OFF PORTD &= ~(1<<2);
#define LCDPIN_ON PORTD |= (1<<2);
---
Also i created a motor balancing feature some time back (like now in release 2.3).
The one i did was implemented in v2.1 and works entirely via your radio.

I do not know how to properly give code i locally develop back to the MultiWii project (any explanation will be appreciated...).
---
Also i made my external LED strips FOLLOW the STATUS led, but only when NOT armed. Because status led on FC is -most of times build inside.
Armed state also turns on the LED strip. To control this i used a simple transistor switch. This way you can see what happens, and be safe since armed state is also visible.
---
If wanted i can send my modified 2.1 sources.

Posted: **Sun Nov 10, 2013 3:05 pm**

what happened to the "#define TILT_PITCH_AUX_CH AUX4 line"?

Posted: **Sun Nov 10, 2013 4:07 pm**

redscorpio wrote:what happened to the "#define TILT_PITCH_AUX_CH AUX4 line"?

Use GUI for setup gimbal and AUX channels for gimbal control.

Posted: **Sun Nov 10, 2013 4:51 pm**

Mis wrote:
redscorpio wrote:what happened to the "#define TILT_PITCH_AUX_CH AUX4 line"?
Use GUI for setup gimbal and AUX channels for gimbal control.

I don't see this in my multiwii conf in servo settings.

Gimbal is working but , manual overwrite is nowhere to be found?

Posted: **Sun Nov 10, 2013 5:00 pm**

prodrone wrote:I do not know how to properly give code i locally develop back to the MultiWii project (any explanation will be appreciated...).

Hi,

To contribute to the MultiWii project you should check the latest source files because they where modified to be developed more easily with other IDEs than Arduino. Use a SVN client and configure it to http://code.google.com/p/multiwii/source/checkout, then read the contribution guideline in the README.txt file.

Regards,
Luis Sismeiro

Posted: **Sun Nov 10, 2013 11:59 pm**

i Like new Multiwiiconf for mac...

baud speed selection is now available - nice!

thanks for your work!

Posted: **Mon Nov 11, 2013 12:15 pm**

Hi,
in my config(32U4-Leonardo, QuadX) i can't compile the Version2.3 with "#define VARIOMETER" without a LCDConfig.
Can anyone check this?

Marc

Posted: **Mon Nov 11, 2013 2:13 pm**

No big surprise as the variomter currently uses the lcd (plus lcd builtin beeper) to communicate the variometer info via tones.

Maybe ezgui has some variometer functionality too? Then it would compute it on its own from the altitude values.

Posted: **Mon Nov 11, 2013 8:08 pm**

redscorpio wrote:
Mis wrote:
redscorpio wrote:what happened to the "#define TILT_PITCH_AUX_CH AUX4 line"?
Use GUI for setup gimbal and AUX channels for gimbal control.

I don't see this in my multiwii conf in servo settings.

Gimbal is working but , manual overwrite is nowhere to be found?

Same problem here.gimbal works but i cant manually control tilt anymore

Posted: **Tue Nov 12, 2013 1:42 pm**

Slide the MID slider max to left, and... you get it

Posted: **Tue Nov 12, 2013 8:07 pm**

Mis wrote:Slide the MID slider max to left, and... you get it

Thanks, i wouldn't have found that if it wasn't for you
Everything works as it should now.

BTW in 2.2 i was struggling to get rid of my wobbles, now with 2.3 i have none, even with stock PID's.

Many thanks to the developers for this update

Posted: **Tue Nov 12, 2013 8:16 pm**

Looks like I2CGpsNav not functional anymore - when #define I2C_GPS - i2c is not functional. Same hardware works fine with v2.2.
Bug? Feature?
Board Crius v2.5, OLED is functional through i2c.

Posted: **Tue Nov 12, 2013 8:35 pm**

roddie1154 wrote:
Same problem here.gimbal works but i cant manually control tilt anymore

I solved by editing the file output.cpp in this way:

Code: Select all

#if defined(SERVO_TILT)
    servo[0] = get_middle(0);
    servo[1] = get_middle(1);
    if (rcOptions[BOXCAMSTAB]) {
      servo[0] += ((int32_t)conf.servoConf[0].rate * att.angle[PITCH]) /50L;
      servo[1] += ((int32_t)conf.servoConf[1].rate * att.angle[ROLL])  /50L;
    }
      servo[0] += rcData[AUX4]-1500;        //add this line <---
  #endif

Posted: **Tue Nov 12, 2013 8:42 pm**

varvar wrote:Looks like I2CGpsNav not functional anymore - when #define I2C_GPS - i2c is not functional. Same hardware works fine with v2.2.
Bug? Feature?
Board Crius v2.5, OLED is functional through i2c.

Hello, I think it necessary to wait for I2C GPS NAV 2.3 (http://www.multiwii.com/forum/viewtopic.php?f=8&t=3989&start=20#p42062)

Posted: **Tue Nov 12, 2013 9:39 pm**

U.Sentenza wrote:Hello, I think it necessary to wait for I2C GPS NAV 2.3 (viewtopic.php?f=8&t=3989&start=20#p42062)

Any suggestion what is causing i2c failing?
For me looks like even one module is not functional, rest should be ok, correct? At least if "slave" is not doing something unacceptable.
Just point me out please where can be issue.

Posted: **Wed Nov 13, 2013 6:38 pm**

varvar wrote:Looks like I2CGpsNav not functional anymore - when #define I2C_GPS - i2c is not functional. Same hardware works fine with v2.2.
Bug? Feature?
Board Crius v2.5, OLED is functional through i2c.

hi,
i just uploaded 2.3 to crius_se with MTK navigatron i2c gps and works fine.

Posted: **Thu Nov 14, 2013 2:42 pm**

Problems with Gimbal since upgrade. Worked OK with 2.2 and I can't see anything wrong with setup

Gimbal Pitch output works fine but nothing on the roll. Ouput is reading 1500 consistently

pro-mini 328
Hex-H coptertype
#define A0_A1_PIN_HEX
#define RCAUXPIN8
with #servo_tilt

When using A0_A1, servo outputs should go to and A2 and D12

Can anyone else confirm?

Posted: **Thu Nov 14, 2013 6:29 pm**

The link with the new motor layouts isn't as clear as the old ones, what would be the new motor layout for a tricopter?

Posted: **Thu Nov 14, 2013 8:16 pm**

jaames74 wrote:
varvar wrote:Looks like I2CGpsNav not functional anymore - when #define I2C_GPS - i2c is not functional. Same hardware works fine with v2.2.
Bug? Feature?
Board Crius v2.5, OLED is functional through i2c.

hi,
i just uploaded 2.3 to crius_se with MTK navigatron i2c gps and works fine.

I have checked one more time. During first start board tries to read i2c_gps and failed

if reset i2c_gps after - communication start to be working:

but looks like an algorithm doing something else after - I can clearly see communication between MPU6050 and i2c_gps, but error counter increase, IMU is not functional - but gps is functional:

Posted: **Fri Nov 15, 2013 2:50 pm**

jaames74 wrote:
hi,
i just uploaded 2.3 to crius_se with MTK navigatron i2c gps and works fine.

I uploaded 2.3 to my MultiWii 328P Flight Controller w/FTDI & DSM2 (from HobbyKing) together with a Flytron Navigatron v2 GPS board - in fact, I tried it on 2 FC boards, with the same result. The LED flashes, probably to indicate an error condition, the GUI shows no signs of sensible incoming data, and the I2C error count goes up very fast.

The board and GPS board work perfectly in v2.2

Posted: **Fri Nov 15, 2013 3:00 pm**

@varvar:
MPU6050 requires initialization! So if you have I2C connection problems the sensor will not recover. When I had the problem a capacitor over VCC/GND near the MPU6050 solved it for me. Looks like the voltage was not stable enough ...

Posted: **Fri Nov 15, 2013 3:55 pm**

David J wrote:I uploaded 2.3 to my MultiWii 328P Flight Controller w/FTDI & DSM2 (from HobbyKing) together with a Flytron Navigatron v2 GPS board - in fact, I tried it on 2 FC boards, with the same result. The LED flashes, probably to indicate an error condition, the GUI shows no signs of sensible incoming data, and the I2C error count goes up very fast.

The board and GPS board work perfectly in v2.2

well,
here is mine with 2.3 and I2C_GPS_NAV_v2.2Beta1-r62 (MTK_BINARY19)
Boards: CRIUS_SE (non MPU6050) with Flytron Navigatron v2 GPS board

the 3 i2cgps errors were there since r15xx, but it works ok

Posted: **Fri Nov 15, 2013 4:48 pm**

David
What happens when you disable the gps support in config.h

Posted: **Fri Nov 15, 2013 5:50 pm**

Hamburger wrote:David
What happens when you disable the gps support in config.h

It works perfectly, as long as the I2C GPS is unplugged as well - no problems found (although I haven't tried flying it yet - but no problems expected).

Posted: **Sun Nov 17, 2013 11:29 am**

Hi Alexinparis,

please fix this bug - in EEPROM.cpp you have

Code: Select all

  #if GPS
    GPS_set_pids();    // at this time we don't have info about GPS init done
  #endif

but should be (as in the previous version)

Code: Select all

 
  #if GPS
    if (f.I2C_INIT_DONE) GPS_set_pids();    // at this time we don't have info about GPS init done
  #endif

in this case if i2c_gps connected, program will send i2c command before i2c have been initialized, as result i2c sends parcel with baud rate 1MHz (or more?), and i2c_gps hang up the bus.
Thanks!
Vladimir

Posted: **Sun Nov 17, 2013 1:47 pm**

varvar wrote:Hi Alexinparis,

please fix this bug - in EEPROM.cpp you have
Code: Select all
  #if GPS
    GPS_set_pids();    // at this time we don't have info about GPS init done
  #endif
but should be (as in the previous version)
Code: Select all
 
  #if GPS
    if (f.I2C_INIT_DONE) GPS_set_pids();    // at this time we don't have info about GPS init done
  #endif
in this case if i2c_gps connected, program will send i2c command before i2c have been initialized, as result i2c sends parcel with baud rate 1MHz (or more?), and i2c_gps hang up the bus.
Thanks!
Vladimir

Hi,

I think it's cleaner to specify it in GPS part and not EEPROM part.
Tell me if it's ofkin last dev.

Posted: **Sun Nov 17, 2013 4:50 pm**

Alexinparis wrote: Hi,

I think it's cleaner to specify it in GPS part and not EEPROM part.
Tell me if it's ofkin last dev.

Hi,

I have no idea, where is the best place, I just found what is causing i2c issues. And I had replaced this piece of code by old one from your previous version.
At least my hardware is functional now

BTW - thank you for your great job! It is amazing!

Posted: **Sun Nov 17, 2013 10:16 pm**

Alexinparis,

I don't know if it helps - but I tried varvar's modification, and I can confirm that it does work.

There may well be a nicer way to achieve this, but at least it proves that the bug has been found.

Posted: **Mon Nov 18, 2013 12:42 am**

Hi Alex,

We still have problems on Witespy Pro2/3 boards with buzzer and Pilot Lamp. In def.h, we need the following changes in bold.

Best regards.

Code: Select all

/**************************  all the Mega types  ***********************************/
#if defined(MEGA)
  #define LEDPIN_PINMODE             pinMode (13, OUTPUT);pinMode (30, OUTPUT);
  #define LEDPIN_TOGGLE              PINB  |= (1<<7); PINC  |= (1<<7);
  #define LEDPIN_ON                  PORTB |= (1<<7); PORTC |= (1<<7);
  #define LEDPIN_OFF                 PORTB &= ~(1<<7);PORTC &= ~(1<<7);
[b]  #define BUZZERPIN_PINMODE DDRH |= (1<<5) ; 
  #if defined PILOTLAMP
    #define    PL_PIN_ON    PORTH |= 1<<5;
    #define    PL_PIN_OFF   PORTH &= ~(1<<5);
  #else
    #define BUZZERPIN_ON    PORTH |= 1<<5;
    #define BUZZERPIN_OFF   PORTH &= ~(1<<5);
  #endif [/b]

Posted: **Mon Nov 18, 2013 9:03 pm**

Hello everybody.
I have uplodad 2.3 to my hexacopter.
First problem(ish) thing I encountered is;
It changes roll/pitch angle rapidly when I switched off angle mode (in old name, when I swithced of from stable to acro).
So if hexa going forward it rapidly pitches back when I switched off ACC. It stays stable if hexa is level when I switch.

Posted: **Tue Nov 19, 2013 2:19 am**

Varvar’s line change gave me back my OLED_128_64. (in pre2.3 & 2.3 I could have i2c GPS OR OLED, just not both at the same time)
Thank You
Paris V4r3, Tri, MPU6050, 400kHz, BMP085, HMC5883, RCAUXPIN8, i2C_GPS, and now OLED.

Posted: **Wed Nov 27, 2013 8:36 am**

Hi, I posted this in the flight characteristics thread a little while ago (no replies), so expanding on issue here...

With 2.3, my quadX with HK Multiwii Pro board seems to 'forget' it's level mode calibration if I make it go fast forward or fast backward for a while then release the sticks. Instead of just sliding back to being level, it actually reverses direction and starts flying back the way it had just come at an almost equal but opposite angle, resisting any input from me to level it out. Eventually I can input enough correction to level it out, after which it settles back down and will stay reasonably level again. This did not happen with 2.2.

Tested with throttle_angle_correction ON & OFF - no change.
GPS hold or RTH modes are OFF.

It also seems to roll left or right after each battery change, even if I'd calibrated it previously and not changed CG or trims.

Any ideas?

Posted: **Wed Nov 27, 2013 1:12 pm**

ZaksterBlue that effect is most likely caused by a different set of PID values from 2.2 to 2.3. Increase I term if you dont want it to brake.
I did also note in 2.3 the gyro calib is somehow twitchy. No idea why. I often do stick calib it before flight, stick calib always works fine but startup calib is often messed up.

On my geared motors mini quad i do use a transmitter pot to adjust PID values. Those big-prop geared motor combos are very sensible to wrong PID values and start to wobble and shake easily. System input is an aux channel and output is the realtime calculated PID values for pitch/roll or then level. This allows in flight comparison of different PID settings. I can also switch from alexk into oldskool in flight. Fascinating intuitive results. I can set it up as a lame duck and then change to twitchy acro machine with a side pot on the Devo12s

Posted: **Wed Nov 27, 2013 3:57 pm**

Try

#define GYROCALIBRATIONFAILSAFE

to solve the problem at first gyro calibration .... works for a lot of guys ....

Posted: **Wed Nov 27, 2013 5:07 pm**

#define GYROCALIBRATIONFAILSAFE

Is a cure but not the cause that calibration was perfectly OK in 2.2 and is NOT OK in 2.3. Someone finds out what is the cause?

Also GYROCALIBRATIONFAILSAFE allows the angles to be off by 32 (carrots or what is the unit ?) which may be OK for most.

Code: Select all

if(abs(imu.gyroADC[axis] - previousGyroADC[axis]) > 32) tilt=1;

But if you fly HeadHold or HeadFree without MAG like baseflight or my pocketquad does 32 may not be good enough.

Posted: **Fri Nov 29, 2013 5:42 pm**

I just loaded 2.3 into my NanoWii control board (formerly using 2.1). It appears my 'stick commands' aren't working right. I can arm and disarm with no problem. I can't get it to do the Gyro Calibration nor ACC Trim. I don't know if I'm doing something wrong or if something has changed in 2.3 in how to do stick commands. Any ideas???

Posted: **Fri Nov 29, 2013 6:36 pm**

Yes .... erase EEPROM before loading 2.2/2.3 ....

Posted: **Fri Nov 29, 2013 6:43 pm**

Ah...thank you. I didn't do that part...totally forgot about it. Thank you.

edit: Nope. That didn't work either. Maybe I'll just back down to 2.1 again?

edit-edit: I just loaded 2.1 back into my FC (erased, then reload) and my stick configuration works fine. So maybe something I did wrong with the erase, load of 2.3 that doesn't allow me to do stick config other than arm and disarm?

Posted: **Fri Nov 29, 2013 11:43 pm**

I think I had to bump my throttle high end point up a few notches in my TX to get all stick commands working with both the 2.2dev and 2.3. I previously had throttle high set for 1900 but stick commands work more consistently if you push this up to 1910+.

Posted: **Sat Nov 30, 2013 7:29 am**

Thanks. Higher throttle setting shouldn't make a difference for Gyro Calibration...where down throttle is used, but I'll certainly check all the EPAs. Perhaps it is just insufficient throws causing the problem. I hope to get it figured out. I liked the feel of the Horizon flight mode; I just couldn't 'trim' the ACCs without the stick commands to tweak it for exact level resonse.

Posted: **Sat Nov 30, 2013 2:42 pm**

When you want stick commands to work, you must hold for example: roll stikc for almost two seconds and then it'll work.

Posted: **Sat Nov 30, 2013 5:42 pm**

Thanks all. I got my stick commands working. It turned out it was a Tx end point issue. I had my Tx AIl and Ele at 90%, which worked for fw 2.1 but not 2.3. Once I bumped all the EPAs to 100% the stick commands starting working again. Thanks for the help.

Posted: **Sat Nov 30, 2013 7:26 pm**

If i am using the serial command MSP_SET_RAW_RC do i need to arm the motors ? Or I just need to send this command and the quad will start flying? I have a Raspberry pi program which is taking input from the android. RPi is connected to the MW FC. The android seekbar goes up meaning throttle up. The msg is sent to RPi. Rpi injects the MSP_SET_RAW_RC. Also I know its kinda out of the context but do I need to give values between 1000 and 2000 can i just give 0 to the variables I am not using as in when i just want to up the throttle just increase the throttle value of do i need to send pitch roll and yaw value as 1000 too? just want to confirm :S

MultiWii

2.3 is finally here :)

2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)

Re: 2.3 is finally here :)