2.3 is finally here :)

David J · Post by **David J** » 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).

varvar · Post by **varvar** » 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

Alexinparis · Post by **Alexinparis** » 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.

varvar · Post by **varvar** » 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!

David J · Post by **David J** » 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.

Greg Covey · Post by **Greg Covey** » 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]

mahomedia · Post by **mahomedia** » 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.

Wayne · Post by **Wayne** » 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.

ZaksterBlue · Post by **ZaksterBlue** » 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?

Plüschi · Post by **Plüschi** » 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

-ralf- · Post by **-ralf-** » Wed Nov 27, 2013 3:57 pm

Try

#define GYROCALIBRATIONFAILSAFE

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

Plüschi · Post by **Plüschi** » 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.

Vantasstic · Post by **Vantasstic** » 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???

-ralf- · Post by **-ralf-** » Fri Nov 29, 2013 6:36 pm

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

Vantasstic · Post by **Vantasstic** » 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?

ZaksterBlue · Post by **ZaksterBlue** » 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+.

Vantasstic · Post by **Vantasstic** » 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.

scrat · Post by **scrat** » 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.

Vantasstic · Post by **Vantasstic** » 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.

linkstatic · Post by **linkstatic** » 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

prodrone · Post by **prodrone** » Sat Dec 07, 2013 1:43 pm

Alexinparis wrote: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

QUESTION: What does it mean compared to the Yaw rate use in MultiWii 2.1 (i used up to now) ? Stick scaling ? Does that the same as RC rate ? I dont know what to expect, so where can i read more please.

Alexinparis · Post by **Alexinparis** » Sun Dec 08, 2013 12:58 am

Hi,

stick scaling: before the stick rate was an expo factor, now it acts as a proportional factor on the whole range like rc rate. => more response at center now

Steeze McQueen · Post by **Steeze McQueen** » Thu Dec 12, 2013 2:46 am

Hi all - having an issue with 2.3

In 2.2, my GY-80 IMU works fine. In 2.3, regardless of how many config settings I try, I am getting constant I2C errors in MultiWiiConf and none of the sensors report any movement. In 2.2 I can uncomment the GY_80 define in config.h and it is recognized straightaway, but no such luck with 2.3. I've tried mucking with the internal pullups, changing the address of the ACC, but still nothing but I2C errors.

Rust · Post by **Rust** » Mon Dec 16, 2013 10:46 am

Didn't manage to make the Motor Balancing feature to work for me.
Problem is stated here by another man. It's exactly the same for me. viewtopic.php?f=8&t=4285
Trying to bring the question here where more people are looking.

cbap wrote:I am having the same problem.

Set up for X quad.

Enable Dynamic balance and get the motor control tab in the control panel.

Clicking the motors doesn't seem to control them.

Then they two just seem to spin up randomly.

I've reset eeprom and tried it on more than one controller. Same issues.

Anyone know what is going on?

32 bit interface on 64 bit win 7.

Can't get the 64 bit one to work.

Cheers,

Carl

Gartenflieger · Post by **Gartenflieger** » Mon Dec 16, 2013 8:42 pm

Is it possible the 2.3 takes a little longer to initialize the Motor outputs than the old versions? Every other time I connect the battery on my Quad, the motors won't beep as usual. In those cases the ESCs don't arm and neither does the quad.

cofl1001 · Post by **cofl1001** » Tue Dec 31, 2013 3:19 am

Hello All,
I dont want to double post but I appreciate if any of you can help with this issue I have here
http://www.multiwii.com/forum/viewtopic.php?f=18&t=4454&p=44860#p44860

Ackroyd · Post by **Ackroyd** » Sat Feb 01, 2014 9:01 pm

Hello...I have the strange problem...I have the ultraPWM ESC. But with multiwii 2.1 it wasnt problem. All i had to do was to change MINTHROTTLE, MAXTHROTTLE, and MINCOMMAND but...this solution doesnt work with multiwii 2.3. i used the same numbers. Before i uploaded it i cleared eeprom.. But ESCs still behave like they are receiving original PWM signals...Can somebody tell me what changes where made in newest version with this?

Ackroyd · Post by **Ackroyd** » Sun Feb 02, 2014 9:39 am

I have localised the problem better...but have no idea how to solve it. Problem is propably with GUI. When i connect it tu gui, in settings tab there is no option to set MINTHROTTLE to lower value than 1000...i need aprox. 200, other parameters can be setted as i want ...but not MINTHTOTTLE. IT worked in multiwii 2.1 (wasnt setted in gui,but arduino only) I would really like to use 2.3 but i have no idea how to solve this, because gui always overwrite me the value a setted in adruino. Thanks for help

Greg Covey · Post by **Greg Covey** » Wed Feb 05, 2014 6:36 pm

Hi,

I have been disabling the BARO on Multiwii when flying in cold weather due to undesired performance when taking the MRC outside to my backyard to fly.

On Arducopter, the BARO readings are reset apon arming so it works fine in cold weather if you let the MRC sit powered on for at least 5 to 10 minutes.

Is this operation the same for Multiwii? Does Multiwii reset the BARO readings when arming?

Thank you.

Crashpilot1000 · Post by **Crashpilot1000** » Wed Feb 05, 2014 7:00 pm

Basically the absolute hight upon engaging althold is irrelevant, so setting it to zero (with an offset) on the ground is just necessary if you want to do an RTL with a predefined hight. The baroreadings are affected (next to unclean powersupply, missing cover and sunlight) by TEMPERATURE. So the heating up of the surrounding chips will affect the calculated hight. You can observe that on hardwaredesigns that didn't/couldn't take that into account like Naze4 (i measured it against fabios freeimu 0.3.5MS- that did much better - no offense, just observation and measured data).
But in your special case I think you use stock mwii 2.3 - and there was a softwarebug found in baro temp compensation, that is fixed in the dev trunc see (http://code.google.com/p/multiwii/source/detail?r=1649).
Cheers
Rob

Greg Covey · Post by **Greg Covey** » Thu Feb 06, 2014 6:42 pm

Rob,

Thanks for the information. I agree with your assessment on r1649. I haven't gone back to dev trunc since 2.3 was released and winter arrived. It seems that my BARO disable works for now but I will try an upgrade in the spring.

The effect seen on 2.3 when bringing a warm proven MRC into a cold backyard was unusual height changes when BARO was enabled. When just using Horizon Mode, all was well.

Regards.

Batam · Post by **Batam** » Sat Feb 08, 2014 5:39 pm

Hi,

I have just managed to load Multiwii 2.3 into my Arduino Pro Mini.
BUT, when I try to config, nothing is working.

I do get the 2 lines for my WMP and Nunchuk running, but no movement, everything stay flat and my blue led is Blinking.
I can't calibrate ACC, as when I push the button on MultiwiiConfig, nothing happens.
It's like there was no Gyro and Acc data.
I have no beep when I power up the board either (It did on 1.7)

Everything is working on 1.7 though.

Any Ideas ?

Hamburger · Post by **Hamburger** » Sat Feb 08, 2014 8:11 pm

5V power for sensors on pin12 (?) is off by default in config.h now

Batam · Post by **Batam** » Sat Feb 08, 2014 10:33 pm

Thanks for you advice.
It was not the power pin.

It was just the INTERNAL_I2C_PULLUPS that was disabled. Once enabled it's working fine.

Now I have to mount the FC on my T-Copter and test it.

busta · Post by **busta** » Sat Feb 08, 2014 11:41 pm

Hey guys, awesome software !

A few questions: MultiWiiConf is a bit buggy in my setup. Im using a bluetooth module connected to crius aio v2. Running Linux and Oracle JRE7.

Often i have to connect like 6-7 times before it works.
Sometimes the "stop" button does not work.
And sometimes i cannot click the boxes to configure ANGLE/BARO etc etc, i have to click several times for it to work.

Are these know issues or should i check my setup?

Which version of the JRE do you develop the GUI in?

Again, awesome software, i really like it.

Crashpilot1000 · Post by **Crashpilot1000** » Sun Feb 16, 2014 1:22 pm

Don't want to spam another thread.

Concerning the Auxchannel readout this might be also a way:

Code: Select all

    uint16_t auxState = 0;
    int8_t auxShift = -1;
    for(i = 0; i < 4; i++)
    {
        auxState |= (rcData[AUX1+i] < 1300) << ++auxShift;
        auxState |= (1300 < rcData[AUX1+i] && rcData[AUX1+i] < 1700) << ++auxShift;
        auxState |= (rcData[AUX1+i] > 1700) << ++auxShift;
    }

I checked it with the old and rusty arduino IDE and it compiles to 2 bytes less. Maybe it's faster than the version with multiplication - depending on compiler I guess.
(Referrer: http://code.google.com/p/multiwii/sourc ... ii.cpp#957)
Cheers
Rob

timecop · Post by **timecop** » Sun Feb 16, 2014 1:45 pm

We don't have enough people asking what does "<<" and ">>" mean yet?

Johnnynunes · Post by **Johnnynunes** » Thu Feb 20, 2014 10:55 pm

Can't get cam stab to work properly on 2.3. defined servo_tilt, works ok but in the wrong direction, if defined servo_mix_tilt works fine, but I wanted to chagr the mid pitch vallue to a bigger one and cant find the option...

Johnnynunes · Post by **Johnnynunes** » Thu Feb 20, 2014 10:55 pm

Can't get cam stab to work properly on 2.3. defined servo_tilt, works ok but in the wrong direction, if defined servo_mix_tilt works fine, but I wanted to chagr the mid pitch vallue to a bigger one and cant find the option...

Batam · Post by **Batam** » Sat Feb 22, 2014 12:33 am

Hi,

me again.
I tried my TCopter this evening and can't take off.

2 problems :
- Seems that Gyro is not well calibrated. On a flat surface, left motor tends to accelerate more than right motor. I can't find how to calibrate Gyro.
- Yaw is turning full right when I push throttle a bit. It doesn't stay in place.

--> The TCopter won't take off. My YAW PID is 6.4 / 0.045 / 0
--> I have a bit of slop with my corona digital servo, could it be the problem ? Could it be my Flight controller shield ?

I am having this problem since v1.8 and stuck with 1.7 but now it is really obsolete so... I would like to use the latest software.

Thanks for your advices.

Batam · Post by **Batam** » Sun Feb 23, 2014 11:47 pm

Ok, answering myself :
In 2.3, yaw reverse direction is not working. So the corrections on Yaw were wrong on my copter.
If anyone knows how to reverse Yaw direction with 2.3 I would be glad to try.

Returned to 2.2 for now and it's OK.

Now I struggle getting rid of the wobbles.
I'm almost at p=2.0 on roll and reactions are not as sharp as it should, plus drifting quite a bit.

Batam · Post by **Batam** » Tue Mar 04, 2014 9:16 pm

OK,

so after a week of daily trial, I found a direction for my PID tuning.
Increasing D to 35-40 helped increasing P to get it stable.
Then decrease I to reduce wobble.

Now it still drifts a little on Roll and Pitch, but it's way more stable and doesn't wobble too much except in windy condition.

I've managed to film with the Gopro and the results are very good, very subtle vibration.

Gallaway500 · Post by **Gallaway500** » Thu Mar 06, 2014 5:12 am

I pulled a tri off a dusty shelf and loaded in 2.3. As Batam noted is there anyway too change the direction of the Yaw servo for a tri. The sketch change didn't work. I tried it in the gui but each time I went to write it. The direction would just change back to what it was reading before. :-(

Running a Crius SE V.02 board if that is a factor.

adilson · Post by **adilson** » Fri Mar 07, 2014 3:39 am

Hi there

I wonder if RTH for airplane mode is incorporated on 2.3. I did try just the stabilizartion on horizon mode and worked fine BTW.

TIA

turdsurfer · Post by **turdsurfer** » Sat Mar 08, 2014 5:28 pm

Is it possible that the firmware (MultiWii 2.3) sometimes and somehow forgets what's level?

I have my ACC calibrated, and my quadcopter with nanowii flies nice and level in horizon mode for 1 or 2 flights. Then the next flight all of a sudden it wants to fly sideways. Sometimes it also doesn't want to arm, but just beeps instead, possibly because it thinks it's not laying flat on the ground where in reality it is, due to the decalibrated ACC.

It also makes me wonder if the the TX stick combos for trimming the ACC calibration are unintentionally active while armed and flying, e.g.
http://www.multiwii.com/wiki/index.php?title=Calibration_Accelerometer
INFLIGHT_ACC_CALIBRATION is not defined in config.h, so that's not it.

Then when I come home, lay my quadcopter flat on the ground and connect to it with the GUI, the artificial horizon is banked. So that means that the 'forgotten' ACC calibration isn't temporary.

LVNeptune · Post by **LVNeptune** » Sat Mar 08, 2014 5:34 pm

Are you plugging the battery in when it is level? It calibrates the GYRO every time it is powered up. Sounds like you are angling it when applying power.

-ralf- · Post by **-ralf-** » Sat Mar 08, 2014 5:59 pm

Maybe the EEPROM is corrupted. Load EEPROM_CLEAR to the FC, let it run, then reflash
MWii and calibrate the ACC.

olaf45 · Post by **olaf45** » Fri Mar 28, 2014 10:01 pm

Hi,

I have just managed to load Multiwii 2.3 into my Arduino Pro Mini but the blue led is always blinking( I2C problem ? ) . On multiconf, some datas are wrong and blocked like ROLL.
When I flashed the Multiwii2.2 , everything is OK . I didn't find any difference in I2C protocol. I only have GY85 IMU ( No GPS) .
Do you have an idea ? By comparing the two codes, I didn't find any difference that can explain the problem.

Thanks

Crashpilot1000 · Post by **Crashpilot1000** » Wed Apr 30, 2014 7:46 am

Just a thought on the mixer and handling pwm values overshooting the esc pwm range. I am referring to http://code.google.com/p/multiwii/sourc ... t.cpp#1537.

What I think is happening here is when an overshoot of pwm is detected the difference is calculated and all motorvalues are reduced by that value. That is a very good idea, however i think there could be something done in situations where the overshoot is too severe.
Of course we are always in trouble in those saturation situations but I think the handling could be improved by limiting the motors and the overshoot to a margin of where is 10-15% left for keeping yaw etc.
I tested another approach with acually taking the pwm range demanded by the regulation (min and max) and scaled it down to the possible pwm range that seems to be even better.
Anyway I ported back the first approach to the current mwii mixing - note that it is not tested in this posted form and I hope I got it right..

Code: Select all

/****************                normalize the Motors values                ******************/
#define Limit85 MAXTHROTTLE + ((MAXTHROTTLE - conf.minthrottle) * 85) / 100 // Note this is a constant in MWII
int16_t overshoot;

maxMotor = 0;
for(i = 0; i < NUMBER_MOTOR; i++)
{
    motor[i] = min(motor[i], Limit85);
    if (motor[i] > maxMotor) maxMotor = motor[i];    
}

if (maxMotor > MAXTHROTTLE) overshoot = maxMotor - MAXTHROTTLE;
else overshoot = 0;
    
for(i = 0; i < NUMBER_MOTOR; i++)
{
    motor[i] = constrain(motor[i] - overshoot, conf.minthrottle, MAXTHROTTLE);
    if ((rcData[THROTTLE] < MINCHECK) && !f.BARO_MODE)
#ifndef MOTOR_STOP
        motor[i] = conf.minthrottle;
#else
        motor[i] = MINCOMMAND;
#endif
    if (!f.ARMED)
        motor[i] = MINCOMMAND;
}

Cheers Rob

Crashpilot1000 · Post by **Crashpilot1000** » Fri May 16, 2014 7:22 pm

Hi!

The aeroquad version of the QuakeIII InvSqrt multiwii is using (https://code.google.com/p/multiwii/sour ... MU.cpp#153)

Code: Select all

float InvSqrt (float x){
  union{  
    int32_t i;  
    float   f;
  } conv;
  conv.f = x;
  conv.i = 0x5f3759df - (conv.i >> 1);
  return 0.5f * (conv.f * (3.0f - x * conv.f * conv.f));
}

can be improved in accuracy with no extra cpu cost according to this: http://rrrola.wz.cz/inv_sqrt.html

So the proposed more accurate function with different "magic numbers" would be that:

Code: Select all

float InvSqrt(float x){
    union
    {
        float f;
        uint32_t u;
    } y = {x};
    y.u = 0x5F1FFFF9 - (y.u >> 1);
    return 0.703952253f * y.f * (2.38924456f - x * y.f * y.f);
}

The link states the following maximal errors:
QuakeIII Method: 0,00175233867
Alternative Method: 0,000650196699
Maybe something worth to check out since 2,7 times more accuracy for free isn't bad.
Cheers
Rob

EDIT:
Did some testruns with 199 values (damn, forgot one ...), the absolute error is >2,6 fold better (less).
Concerning the speed I found that the union-free version proposed here http://pizer.wordpress.com/2008/10/12/f ... uare-root/ is 2,6% faster (tested on stm cpu).
Putting both sources together I end up with that code:

Code: Select all

float InvSqrt(float x)
{
   uint32_t i = 0x5F1FFFF9 - (*(uint32_t*)&x >> 1);
   float  tmp = *(float*)&i;
   return tmp * (1.68191409f - 0.703952253f * x * tmp * tmp);
}

Timechart on STM F3 (Test with 1000000 cycles run Note: GCC compiler, not keil):
No optimization = 100%
"Union" Version = 54,1%
"No Union" Version = 51,5% (So thats a little closer to "double" speed)

Avg Error (rounded, based on absolute error, based on 199 values 1-199 in integer "1" steps)
Old: +- 0,00013
New: +- 0,00005
Looks like my errorcalculation is off by a magnitude of 10 but the proportion is still correct, the new magic numbers increase accuracy 2.6 times.
I will not look into that "off by a magnitude" stuff because it's just testcode to verify the increased accuracy - and I consider it as *done* - *myth busted* - whatever.

Note: I've read that sqrtf alone takes 44us (https://github.com/diydrones/ardupilot/ ... M.cpp#L183) on 8bit arduino. What I measured on my platfrom with float devision 1.0f/sqrtf(x) and an float addition and the "for" loop was 11.6us total (averaged 1mio runs). So it can be assumed that the sqrtf alone on F3 takes less than 10us, so 1/sqrtf optimization doesn't seem to be reasonable there, unless you do plenty of them...
Note: I use opensource gcc compiler.
Note: Don't feed InvSqrt with zero. The unoptimized version will produce an devision by zero exception of course, the "hacked" version will produce a bogus value. I don't know if any of the mwii devs will read this but, insert a check in your IMU part. It sounds unlikely but it will happen and result in a short spike of crazy attitude, it will not ground the copter but is not nice.
So from my perspective the mwii project could have a faster and more accurate algo - just my 2cents.
Cheers Rob