2.3 is finally here :)

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
prodrone
Posts: 7
Joined: Sun Nov 04, 2012 3:30 pm

Re: 2.3 is finally here :)

Post by prodrone »

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
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: 2.3 is finally here :)

Post by Alexinparis »

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
Posts: 4
Joined: Fri Jan 27, 2012 10:09 pm

Re: 2.3 is finally here :)

Post by Steeze McQueen »

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
Posts: 36
Joined: Wed Nov 20, 2013 8:39 am

Re: 2.3 is finally here :)

Post by Rust »

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

User avatar
Gartenflieger
Posts: 65
Joined: Sat Oct 01, 2011 10:07 pm
Location: Dortmund, Germany

Re: 2.3 is finally here :)

Post by Gartenflieger »

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
Posts: 16
Joined: Sun Dec 29, 2013 3:31 pm

Re: 2.3 is finally here :)

Post by cofl1001 »

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
Posts: 2
Joined: Fri Feb 08, 2013 11:46 am

Re: 2.3 is finally here :)

Post by Ackroyd »

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
Posts: 2
Joined: Fri Feb 08, 2013 11:46 am

Re: 2.3 is finally here :)

Post by Ackroyd »

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
Posts: 11
Joined: Tue Feb 05, 2013 11:20 pm
Location: Rochester, NY USA
Contact:

BARO Reset when Arming?

Post by Greg Covey »

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.

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: 2.3 is finally here :)

Post by Crashpilot1000 »

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
Posts: 11
Joined: Tue Feb 05, 2013 11:20 pm
Location: Rochester, NY USA
Contact:

Re: 2.3 is finally here :)

Post by Greg Covey »

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
Posts: 7
Joined: Wed Oct 26, 2011 4:43 pm

Re: 2.3 is finally here :)

Post by Batam »

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 ?

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: 2.3 is finally here :)

Post by Hamburger »

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

Batam
Posts: 7
Joined: Wed Oct 26, 2011 4:43 pm

Re: 2.3 is finally here :)

Post by Batam »

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
Posts: 12
Joined: Tue Jan 28, 2014 7:52 pm
Location: Barcelona

Re: 2.3 is finally here :)

Post by busta »

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.

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: 2.3 is finally here :)

Post by Crashpilot1000 »

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
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: 2.3 is finally here :)

Post by timecop »

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

Johnnynunes
Posts: 35
Joined: Wed Aug 28, 2013 2:38 pm

2.3 is finally here :)

Post by Johnnynunes »

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
Posts: 35
Joined: Wed Aug 28, 2013 2:38 pm

2.3 is finally here :)

Post by Johnnynunes »

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
Posts: 7
Joined: Wed Oct 26, 2011 4:43 pm

Re: 2.3 is finally here :)

Post by Batam »

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
Posts: 7
Joined: Wed Oct 26, 2011 4:43 pm

Re: 2.3 is finally here :)

Post by Batam »

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
Posts: 7
Joined: Wed Oct 26, 2011 4:43 pm

Re: 2.3 is finally here :)

Post by Batam »

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
Posts: 1
Joined: Sat Feb 22, 2014 4:56 pm

Re: 2.3 is finally here :)

Post by Gallaway500 »

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
Posts: 7
Joined: Mon Jun 03, 2013 6:55 pm

Re: 2.3 is finally here :)

Post by adilson »

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
Posts: 6
Joined: Sat Mar 08, 2014 4:52 pm

Re: 2.3 is finally here :)

Post by turdsurfer »

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
Posts: 19
Joined: Mon Jan 20, 2014 10:54 pm

Re: 2.3 is finally here :)

Post by LVNeptune »

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-
Posts: 215
Joined: Mon Dec 03, 2012 7:08 pm

Re: 2.3 is finally here :)

Post by -ralf- »

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

olaf45
Posts: 24
Joined: Sun Nov 25, 2012 11:38 am
Location: France

Re: 2.3 is finally here :)

Post by olaf45 »

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

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: 2.3 is finally here :)

Post by Crashpilot1000 »

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

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: 2.3 is finally here :)

Post by Crashpilot1000 »

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
Last edited by Crashpilot1000 on Sat May 17, 2014 9:24 pm, edited 4 times in total.

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: 2.3 is finally here :)

Post by Crashpilot1000 »

2 posts just self talk, thought to contribute back to multiwii but it seems I am too low-brow for that - sorry dudes!

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: 2.3 is finally here :)

Post by Hamburger »

Just keep on - we see you.
I personally am not at the moment in a position to experiment easily.

MHefny
Posts: 18
Joined: Sun Jan 05, 2014 4:27 pm
Location: Cairo, Egypt
Contact:

Re: 2.3 is finally here :) (ARDUINO_DUE)

Post by MHefny »

Hi,

I could add the capability to compile -some of the firmware features [quad,tri]- on Arduino DUE.
Can we consider adding this to the original multiwii code, or this is out of the road map.

kindly chk here viewtopic.php?f=22&t=5125

Best Regards

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: 2.3 is finally here :)

Post by Crashpilot1000 »

MHefny: You did an outstanding job!

Hamburger: Thx!
I revived my old mwii and did some testing, the proposed invsqrt compiles to less bytes and works good.
However I think the mwii _atan2 https://code.google.com/p/multiwii/sour ... MU.cpp#134 has some hickups at 90deg.
I looked around and found this: http://www.dspguru.com/dsp/tricks/fixed ... malization.
Based on that info and knowing that mwii needs the atan output in degree*10 and 8bit hates floatpoints I did a floatpoint free version:

Code: Select all

int16_t _atan2(int32_t y, int32_t x)
{
    int32_t abs_y = abs(y), tmp;
    int16_t angle = 0;
    if (x >= 0)
    {
        tmp = x + abs_y;
        if(tmp) angle = 450 - ((450 * (x - abs_y)) / tmp);
    }
    else
    {
        tmp = abs_y - x;
        if(tmp) angle = 1350 - ((450 * (x + abs_y)) / tmp);
    }
    if (y < 0) return(-angle);
    else return(angle);
}

I did not do an accuracy bench this time because it is probably worse, but the behaviour at 90 is better and it's faster and shorter. On the bench the accuracy looks good but I can't flighttest orig mwii.
Both suggested changes (invsqrt and atan) reduce the compilesize by 180byte.
Cheers Rob

EDIT: Forget that atan2 idea the error in this integer only version is not acceptable (max 4 deg!!!). I've seen errors up to 10 times higher than mwii atan. So my approach is much worse, but maybe someone wants to "float" it up and get better accuracy and still be faster. The original dspguru quoted accuracy is about 0.6 degree..


EDIT EDIT:
Now did an integer only version with an maximal error of 0.6 degree (mwii version 0.4 degree max error)

Code: Select all

int16_t _atan2(int32_t y, int32_t x)
{
    int32_t abs_y = abs(y), tmp;
    int16_t angle = 0, tmp1 = 0;
    if (x >= 0)
    {
        tmp = x + abs_y;
        if(tmp)
        {
            tmp   = ((x - abs_y) << 10) / tmp;
            tmp1  = 4096;
        }
    }
    else
    {
        tmp = abs_y - x;
        if(tmp)
        {
            tmp   = ((x + abs_y) << 10) / tmp;
            tmp1  = 12288;
        }
    }
    if(tmp1) angle = (450 * (((tmp * tmp * tmp) >> 20) - 5 * tmp + tmp1)) >> 12;
    if (y < 0) return(-angle);
    else return(angle);
}


EDIT EDIT EDIT

Took the original multiwii and eliminated the float operations. The result is a better(!) accuracy. The maximal error I have seen is 0.3 degree compared to the original with maximal error of 0,4 degree. But it runs slower on arduino !!!
Fast atan2 case closed for me - the current mwii implementation is probably the best for 8 bit IF IT HAD A DIV BY ZERO PROTECTION.

Code: Select all

int16_t _atan2(int32_t y, int32_t x)
{
    int32_t z;
    int16_t a;
    uint8_t c;
    c = abs(y) < abs(x);
    if (c)
    {
        if(x) z = (y << 10) / x;
        else return 0;
    }
    else
    {
        if(y) z = (x << 10) / y;
        else return 0;
    }
    a = (523886 * z) / (936221 + ((z * z) >> 2));
    if (c)
    {
        if (x < 0)
        {
            if (y < 0) a -= 1800;
            else       a += 1800;
        }
    }
    else
    {
        a = 900 - a;
        if (y < 0) a -= 1800;
    }
    return a;
}



EDIT EDIT EDIT EDIT:
Rechecked the runtime of the previous fast atan. Acutally it isn't slower, it has a more sustained speed and lower spikes. Those 10 Bit shifts on 8Bit Arduino are slow, especially when using signed values. Here is an unreasonably long version that is a little faster by circumventing some shifts with byteswaps. Just for the hell of it:

Code: Select all

// max error 0.3 Degree!
// Bitshifts resolved for 8 bit arduino
int16_t _atan2(int32_t y, int32_t x)
{
    union
    {
        uint32_t i;
        uint8_t  b[4];
    } lsl8;
    uint32_t z, absX, absY;
    int16_t a;
    uint8_t c, sign;

    if(x < 0)
    {
        absX = -x;
        sign = 1;
    }
    else
    {
        absX = x;
        sign = 0;
    }

    if(y < 0)
    {
        absY  = -y;
        sign ^= 1;
    }
    else absY = y;

    c = absY < absX;

    if (c)
    {
        if(absX)
        {
            lsl8.i    = absY;
            lsl8.b[3] = lsl8.b[2];
            lsl8.b[2] = lsl8.b[1];
            lsl8.b[1] = lsl8.b[0];
            lsl8.b[0] = 0;
            z = (lsl8.i << 2) / absX;
        }
        else return 0;
    }
    else
    {
        if(absY)
        {
            lsl8.i    = absX;
            lsl8.b[3] = lsl8.b[2];
            lsl8.b[2] = lsl8.b[1];
            lsl8.b[1] = lsl8.b[0];
            lsl8.b[0] = 0;
            z = (lsl8.i << 2) / absY;
        }
        else return 0;
    }
    a = (523886 * z) / (936221 + ((z * z) >> 2));
    if(sign) a = -a;
    if (c)
    {
        if (x < 0)
        {
            if (y < 0) a -= 1800;
            else       a += 1800;
        }
    }
    else
    {
        a = 900 - a;
        if (y < 0) a -= 1800;
    }
    return a;
}
Last edited by Crashpilot1000 on Tue May 27, 2014 8:33 pm, edited 11 times in total.

Vertigo
Posts: 41
Joined: Mon Jul 08, 2013 6:58 pm

Re: 2.3 is finally here :)

Post by Vertigo »

There seems to be a problem in airplane mode. No matter what I try, the rudder/yaw control seems to be in heading lock mode. With sticks centered, the rudder will not return to center unless the plane is flying at the original heading again (when I last moved the rudder stick). This makes flying pretty awkward, every turn you make, the rudder will try to counter act the (completely normal) heading change and your turn becomes a knife edge. This is without any flight modes enabled.

Ive been given the advice of setting yaw PIDs to zero, which is not a real solution as then you lose all stabilization, and I specifically installed this multiwii to help me out on take off from narrow runways, to better maintain its track.

I reverted to multiwii 2.2, and there it works as expected. If it matters, Im using a Crius SE V2.0

Magik30
Posts: 30
Joined: Sun Sep 29, 2013 4:19 pm

Re: 2.3 is finally here :)

Post by Magik30 »

My tricopter board rctimer AIOP v2 fly better when I start-up facing north.
but when I start-up the south, poshold = no good and return hone = no good
even with 8 satellite
Version MultiWii dev r1648
ok well calibrated compass

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: 2.3 is finally here :)

Post by Crashpilot1000 »

I think this https://code.google.com/p/multiwii/sour ... rs.cpp#697 can be done faster and shorter:

Code: Select all

void i2c_MS561101BA_Calculate()
{
    int32_t delt;
    union
    {
        uint32_t i;
        uint16_t w[2];
    } lsl16;
    lsl16.w[0] = 0;
    float dT   = (int32_t)ms561101ba_ctx.ut.val - (int32_t)((uint32_t)ms561101ba_ctx.c[5] << 8);
    lsl16.w[1] = ms561101ba_ctx.c[2];
    float off  = lsl16.i + ((dT * ms561101ba_ctx.c[4]) / ((uint32_t)1 << 7));
    lsl16.w[1] = ms561101ba_ctx.c[1];
    float sens = (uint32_t)(lsl16.i >> 1) + ((dT * ms561101ba_ctx.c[3]) /((uint32_t)1<<8));
    baroTemperature  = (dT * ms561101ba_ctx.c[6]) / ((uint32_t)1 << 23);
    if (baroTemperature < 0)   // temperature lower than 20st.C
    {
        delt  = baroTemperature;
        delt  = 5 * delt * delt;
        off  -= delt >> 1;
        sens -= delt >> 2;
    }
    baroTemperature += 2000;
    baroPressure     = (((ms561101ba_ctx.up.val * sens) / ((uint32_t)1 << 21)) - off) / ((uint32_t)1 << 15);
}



Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: 2.3 is finally here :)

Post by Alexinparis »

Crashpilot1000 wrote:I think this https://code.google.com/p/multiwii/sour ... rs.cpp#697 can be done faster and shorter:

Code: Select all

void i2c_MS561101BA_Calculate()
{
    int32_t delt;
    union
    {
        uint32_t i;
        uint16_t w[2];
    } lsl16;
    lsl16.w[0] = 0;
    float dT   = (int32_t)ms561101ba_ctx.ut.val - (int32_t)((uint32_t)ms561101ba_ctx.c[5] << 8);
    lsl16.w[1] = ms561101ba_ctx.c[2];
    float off  = lsl16.i + ((dT * ms561101ba_ctx.c[4]) / ((uint32_t)1 << 7));
    lsl16.w[1] = ms561101ba_ctx.c[1];
    float sens = (uint32_t)(lsl16.i >> 1) + ((dT * ms561101ba_ctx.c[3]) /((uint32_t)1<<8));
    baroTemperature  = (dT * ms561101ba_ctx.c[6]) / ((uint32_t)1 << 23);
    if (baroTemperature < 0)   // temperature lower than 20st.C
    {
        delt  = baroTemperature;
        delt  = 5 * delt * delt;
        off  -= delt >> 1;
        sens -= delt >> 2;
    }
    baroTemperature += 2000;
    baroPressure     = (((ms561101ba_ctx.up.val * sens) / ((uint32_t)1 << 21)) - off) / ((uint32_t)1 << 15);
}




Hi,

I think this code can still be optimized for sure.
float version is much shorter than the previous int64 version.

However, the code you submit takes 10 bytes more with windows arduino IDE. so not sure about the gain

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: 2.3 is finally here :)

Post by Alexinparis »

Crashpilot1000 wrote:Hi!

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



I agree about new coef choice. it's wise and cost nothing to change.
But this code (without union) takes 26 bytes more in comparison with original on windows arduino ide

User avatar
Crashpilot1000
Posts: 631
Joined: Tue Apr 03, 2012 7:38 pm

Re: 2.3 is finally here :)

Post by Crashpilot1000 »

Hi, Alexinparis!
Thx for checking it out!
Yep, I just checked the Invsqrt thing on stm environment but I didn't expect the union version to be shorter on arduino!
Concerning the baro calculation you are right, it compiles to 10 bytes more, I checked with an altered 2.3 so *somehow* got other results or mixed the numbers up.. anyhow, you are right - it can be done shorter:

Just shorter (14byte):

Code: Select all

// use float approximation instead of int64_t intermediate values
// does not use 2nd order compensation under -15 deg
void i2c_MS561101BA_Calculate() {
  int32_t delt;

  float dT        = (int32_t)ms561101ba_ctx.ut.val - (int32_t)((uint32_t)ms561101ba_ctx.c[5] << 8);
  float off       = ((uint32_t)ms561101ba_ctx.c[2] <<16) + ((dT * ms561101ba_ctx.c[4]) /((uint32_t)1<<7));
  float sens      = ((uint32_t)ms561101ba_ctx.c[1] <<15) + ((dT * ms561101ba_ctx.c[3]) /((uint32_t)1<<8));
  delt            = (dT * ms561101ba_ctx.c[6])/((uint32_t)1<<23);
  baroTemperature = delt + 2000;
  if (delt < 0) { // temperature lower than 20st.C
    delt *= 5 * delt;
    off  -= delt>>1;
    sens -= delt>>2;
  }
  baroPressure = (( (ms561101ba_ctx.up.val * sens ) /((uint32_t)1<<21)) - off)/((uint32_t)1<<15);
}


And a version that is only a little shorter (4byte) and just a little faster (in the 10us area, if I remember right).

Code: Select all

// use float approximation instead of int64_t intermediate values
// does not use 2nd order compensation under -15 deg
void i2c_MS561101BA_Calculate()
{
    int32_t delt;
    union
    {
        uint32_t i;
        uint16_t w[2];
    } lsl16;
    lsl16.w[0] = 0;
    float dT   = (int32_t)ms561101ba_ctx.ut.val - (int32_t)((uint32_t)ms561101ba_ctx.c[5] << 8);
    lsl16.w[1] = (uint32_t)ms561101ba_ctx.c[2];
    float off  = (uint32_t)lsl16.i + ((dT * ms561101ba_ctx.c[4]) / ((uint32_t)1 << 7));
    lsl16.w[1] = (uint32_t)ms561101ba_ctx.c[1];
    float sens = (uint32_t)(lsl16.i >> 1) + ((dT * ms561101ba_ctx.c[3]) /((uint32_t)1<<8));
    delt       = (dT * ms561101ba_ctx.c[6]) / ((uint32_t)1 << 23);
    baroTemperature = delt + 2000;
    if (delt < 0)   // temperature lower than 20st.C
    {
        delt *= 5 * delt;
        off  -= delt >> 1;
        sens -= delt >> 2;
    }
    baroPressure = (((ms561101ba_ctx.up.val * sens) / ((uint32_t)1 << 21)) - off) / ((uint32_t)1 << 15);
}


Cheers Rob.

Edit: You can even have the Invsqrt 8 bytes shorter (than current mwii) with the "new magic" numbers:

Code: Select all

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


Edit Edit:
Note: an integer fastatan will increase compilesize by 60-100 bytes (depending on version) but will noticeably smooth out the cycletime (ca 100us spikereduction) and reduce the average cycletime with at least even accuracy - just saying, to show the pros/cons.

Drezed
Posts: 4
Joined: Wed Feb 18, 2015 4:35 pm

Re: 2.3 is finally here :)

Post by Drezed »

Is it safe to say "DYNBALANCE" is not working in 2.3? I have a crius AIOPv2 clone board, and am unable to get any response to motors through Multiwiiconf. I can see the "motor" tab, and the select/deselect boxes, but no "arm" button and no response. Is this somehow related to the deletion of "RCSerial"?

Any help would be fantastic,
Jeff

LutzB
Posts: 67
Joined: Sun Feb 08, 2015 4:01 pm
Location: Germany

Re: 2.3 is finally here :)

Post by LutzB »

Drezed wrote:Is it safe to say "DYNBALANCE" is not working in 2.3? I have a crius AIOPv2 clone board, and am unable to get any response to motors through Multiwiiconf. I can see the "motor" tab, and the select/deselect boxes, but no "arm" button and no response. Is this somehow related to the deletion of "RCSerial"?

I did use this feature with the current 2.4 dev release and it did what I expected. So I think it should work with 2.3 as well. However the description is not up to date.
Go to the motors tab, then select the boxes of the motors you want to spin. Now you can adjust the slider right above the motor boxes to the desired output rate and the selected motors will follow.

Regards,
Lutz

Drezed
Posts: 4
Joined: Wed Feb 18, 2015 4:35 pm

Re: 2.3 is finally here :)

Post by Drezed »

Odd, I've tried all combinations of boxes highlighted/un-highlighted, all sliders, Tx on/off and never got a response. Did your GUI have an "ARM" button? Did you have to make any changes in config.h(other than DYNBALANCE)?

Jeff

Drezed
Posts: 4
Joined: Wed Feb 18, 2015 4:35 pm

Re: 2.3 is finally here :)

Post by Drezed »

UPDATE. My issues with DYNBALANCE were entirely my own ignorance. I didn't recognize the additional slider bar near top-center of the screen. I assumed this was a display of my "MINCOMMAND" setting, and not a slider. In the end everything appears to be working now. :-)

Jeff

handsomejackuk
Posts: 97
Joined: Mon Sep 08, 2014 12:25 am

Re: 2.3 is finally here :)

Post by handsomejackuk »

just installed version 2.3 in my home built arduino pro mini 3.0 flight controller has gps on it, and various sensors.... i have had trouble with it on the past installing as it seems to big to install on atmega 328p processor. anyway seems to have gone ok, and all sensors behave as expected... also seems to work on wingui too...

does anyone think i will be able to run missions with this processor / flight controller... just curious. ?

please advise...

thank you Al..

User avatar
Leo
Posts: 372
Joined: Wed Sep 17, 2014 7:01 am
Location: Germany
Contact:

Re: 2.3 is finally here :)

Post by Leo »

handsomejackuk wrote:...

does anyone think i will be able to run missions with this processor / flight controller... just curious. ?

please advise...

thank you Al..


No, it won't. That is why I switched to a 2560 mega FC. I would recommend you do the same.

dzakarya
Posts: 2
Joined: Thu Mar 12, 2015 5:07 am

Re: 2.3 is finally here :)

Post by dzakarya »

i have problem. why my motor start spinning when my tx first arming.. what i should change with the code?? i use HK multiwii se v2.5. please help me master

homeslice976
Posts: 3
Joined: Wed Mar 12, 2014 2:32 pm

Re: 2.3 is finally here :)

Post by homeslice976 »

dzakarya wrote:i have problem. why my motor start spinning when my tx first arming.. what i should change with the code?? i use HK multiwii se v2.5. please help me master

Uncomment the following in config.h and motors won't spin when armed with the throttle in the low position:

//define MOTOR_STOP

Post Reply