2.3 is finally here :)
Re: 2.3 is finally here :)
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.
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.
Re: 2.3 is finally here :)
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.
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.
-
- Posts: 1
- Joined: Sat Feb 22, 2014 4:56 pm
Re: 2.3 is finally here :)
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.
Running a Crius SE V.02 board if that is a factor.
Re: 2.3 is finally here :)
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
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
-
- Posts: 6
- Joined: Sat Mar 08, 2014 4:52 pm
Re: 2.3 is finally here :)
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.
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.
Re: 2.3 is finally here :)
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.
Re: 2.3 is finally here :)
Maybe the EEPROM is corrupted. Load EEPROM_CLEAR to the FC, let it run, then reflash
MWii and calibrate the ACC.
MWii and calibrate the ACC.
Re: 2.3 is finally here :)
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
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
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: 2.3 is finally here :)
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..
Cheers Rob
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
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: 2.3 is finally here :)
Hi!
The aeroquad version of the QuakeIII InvSqrt multiwii is using (https://code.google.com/p/multiwii/sour ... MU.cpp#153)
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:
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:
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
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.
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: 2.3 is finally here :)
2 posts just self talk, thought to contribute back to multiwii but it seems I am too low-brow for that - sorry dudes!
Re: 2.3 is finally here :)
Just keep on - we see you.
I personally am not at the moment in a position to experiment easily.
I personally am not at the moment in a position to experiment easily.
Re: 2.3 is finally here :) (ARDUINO_DUE)
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
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
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: 2.3 is finally here :)
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:
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)
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.
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:
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.
Re: 2.3 is finally here :)
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
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
Re: 2.3 is finally here :)
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
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
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: 2.3 is finally here :)
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);
}
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: 2.3 is finally here :)
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
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: 2.3 is finally here :)
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
- Crashpilot1000
- Posts: 631
- Joined: Tue Apr 03, 2012 7:38 pm
Re: 2.3 is finally here :)
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):
And a version that is only a little shorter (4byte) and just a little faster (in the 10us area, if I remember right).
Cheers Rob.
Edit: You can even have the Invsqrt 8 bytes shorter (than current mwii) with the "new magic" numbers:
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.
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.
Re: 2.3 is finally here :)
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
Any help would be fantastic,
Jeff
Re: 2.3 is finally here :)
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
Re: 2.3 is finally here :)
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
Jeff
Re: 2.3 is finally here :)
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
Jeff
-
- Posts: 97
- Joined: Mon Sep 08, 2014 12:25 am
Re: 2.3 is finally here :)
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..
does anyone think i will be able to run missions with this processor / flight controller... just curious. ?
please advise...
thank you Al..
Re: 2.3 is finally here :)
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.
Re: 2.3 is finally here :)
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
-
- Posts: 3
- Joined: Wed Mar 12, 2014 2:32 pm
Re: 2.3 is finally here :)
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