MultiWii_dev_20111017
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
MultiWii_dev_20111017
Hi,
In this release:
- I tried to reproduced the level mode of 1.7 in the 1.8 algorithm:
when ACC values on X Y are small enough, I consider ACC_Z = acc1G
I think this should help to solve the remaining drifting problems.
- the LPF of ACC is increased to 16 (8 before)
- the angle limit is decreased to 50 degrees (70 before)
In this release:
- I tried to reproduced the level mode of 1.7 in the 1.8 algorithm:
when ACC values on X Y are small enough, I consider ACC_Z = acc1G
I think this should help to solve the remaining drifting problems.
- the LPF of ACC is increased to 16 (8 before)
- the angle limit is decreased to 50 degrees (70 before)
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: MultiWii_dev_20111017
Great Job Alex, I was just looking at this segment of the 1.7 code today and note something very interesting.
errorAngle = rcCommand[axis]/2 - angle[axis]/2;
Going to make a screen video of the behavior, the motors will going out of balance but this will correct itself with the first stick movement. It is as if some value is not resetting correctly.
I have always flown with the ACC on so I have never switch the ACC on and off during flight but was doing some testing today with the new radio and noticed this behavior.
errorAngle = rcCommand[axis]/2 - angle[axis]/2;
Going to make a screen video of the behavior, the motors will going out of balance but this will correct itself with the first stick movement. It is as if some value is not resetting correctly.
I have always flown with the ACC on so I have never switch the ACC on and off during flight but was doing some testing today with the new radio and noticed this behavior.
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: MultiWii_dev_20111017
Help me to understand here, I thought the Angle[x] was Angular measurement in degrees in 1.7 and radius in 1.8, is this correct?
Re: MultiWii_dev_20111017
Hi Alex,
It is quite erratic to Yaw.
Try to roll left and apply left Yaw simutaniously.
But what we trying to archive by this? If we want to increase range of "trusted" acc values, would it be easier to increase range of trustred ACC values?
Let's say 0.2 - 3g.
Or just remove this check completelly.
If we want to reconstruct Z value, we probably can't as we do not have enough information. To simulate 1.7 behavior, we can do something like this:
And if we planning use angles ONLY for level mode, we can just have it like this always:
Would be just little bit too aggressive in angles higher than 25 deg.
I think, this would satify everyone
regards,
ziss_dm
It is quite erratic to Yaw.

But what we trying to archive by this? If we want to increase range of "trusted" acc values, would it be easier to increase range of trustred ACC values?

Or just remove this check completelly.

If we want to reconstruct Z value, we probably can't as we do not have enough information. To simulate 1.7 behavior, we can do something like this:
Code: Select all
if ( abs(EstG.V.X)<acc_25deg && abs(EstG.V.Y)<acc_25deg && EstG.V.Z>0) {
angle[ROLL] = EstG.V.X / acc_1G * 10.0;
angle[PITCH] = EstG.V.Y / acc_1G * 10.0;
} else {
angle[ROLL] = _atan2(EstG.V.X , EstG.V.Z) ;
angle[PITCH] = _atan2(EstG.V.Y , EstG.V.Z) ;
}
And if we planning use angles ONLY for level mode, we can just have it like this always:

Code: Select all
angle[ROLL] = EstG.V.X / acc_1G * 10.0;
angle[PITCH] = EstG.V.Y / acc_1G * 10.0;
Would be just little bit too aggressive in angles higher than 25 deg.
I think, this would satify everyone

Code: Select all
#if ALWAYS_TRUST_ACC
if ( ( 36 < accMag && accMag < 196 ))
#endif
for (axis = 0; axis < 3; axis++)
EstG.A[axis] = (EstG.A[axis] * GYR_CMPF_FACTOR + ACC_VALUE) * INV_GYR_CMPF_FACTOR;
...
#if SIMULATE_17_LEVEL
angle[ROLL] = EstG.V.X / acc_1G * 10.0;
angle[PITCH] = EstG.V.Y / acc_1G * 10.0;
#else
angle[ROLL] = _atan2(EstG.V.X , EstG.V.Z) ;
angle[PITCH] = _atan2(EstG.V.Y , EstG.V.Z) ;
#endif
regards,
ziss_dm
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii_dev_20111017
Hi,
The purpose here is not to increase the range of trusted ACC, but effectively to reconstruct an hypothetic ACC_Z under small inclination situation.
After seeing many issues about the decrease of ACC_Z values with a throttle input, I tried to simulate a constant wrong value (acc_1G/2), and I managed to reproduce the drift issue.
This leads me to think the drift issue is tied to this.
Doing this would not smooth the angle change at the acc_25deg limit.
And I remember what you said about the loop delay variation regarding the PID adjustment. It’s better to have a quite constant calculation time whatever the angle, that’s why I thought it was better to modify directly EstG.V.Z.
This way, we can still have the LPF to smooth the vector.
I didn’t think about the yaw side effect. It is really annoying ?
For a “level only” mode where keeping the horizon is the only aim, this is probably the most efficient way, but the angle won’t be true after 25 deg.
@copterrichie , angle[] unit is still the same: 1 degree = 10 units
The purpose here is not to increase the range of trusted ACC, but effectively to reconstruct an hypothetic ACC_Z under small inclination situation.
After seeing many issues about the decrease of ACC_Z values with a throttle input, I tried to simulate a constant wrong value (acc_1G/2), and I managed to reproduce the drift issue.
This leads me to think the drift issue is tied to this.
Doing this would not smooth the angle change at the acc_25deg limit.
Code: Select all
if ( abs(EstG.V.X)<acc_25deg && abs(EstG.V.Y)<acc_25deg && EstG.V.Z>0) {
angle[ROLL] = EstG.V.X / acc_1G * 10.0;
angle[PITCH] = EstG.V.Y / acc_1G * 10.0;
} else {
angle[ROLL] = _atan2(EstG.V.X , EstG.V.Z) ;
angle[PITCH] = _atan2(EstG.V.Y , EstG.V.Z) ;
}
And I remember what you said about the loop delay variation regarding the PID adjustment. It’s better to have a quite constant calculation time whatever the angle, that’s why I thought it was better to modify directly EstG.V.Z.
This way, we can still have the LPF to smooth the vector.
I didn’t think about the yaw side effect. It is really annoying ?
For a “level only” mode where keeping the horizon is the only aim, this is probably the most efficient way, but the angle won’t be true after 25 deg.
Code: Select all
angle[ROLL] = EstG.V.X / acc_1G * 10.0;
angle[PITCH] = EstG.V.Y / acc_1G * 10.0;
@copterrichie , angle[] unit is still the same: 1 degree = 10 units
Re: MultiWii_dev_20111017
Hi Alex,
But other people decreasing cut-off of ACC_LPF and increasing Gyro factor and claiming this is solves issue.
Yes, but in case ACC has accuracy less than 50% this does not matter.
My point was:
- we cannot reconstruct correct ACC values, just because there not enough information
- we only can assume that everything level and steady and this leads us to the:
- we should admit that this is just workaround to the unknown problem, not a solution
And keep it simple and optional as it is temporary.
regards,
ziss_dm
After seeing many issues about the decrease of ACC_Z values with a throttle input, I tried to simulate a constant wrong value (acc_1G/2), and I managed to reproduce the drift issue.This leads me to think the drift issue is tied to this.
But other people decreasing cut-off of ACC_LPF and increasing Gyro factor and claiming this is solves issue.

For a “level only” mode where keeping the horizon is the only aim, this is probably the most efficient way, but the angle won’t be true after 25 deg.
Yes, but in case ACC has accuracy less than 50% this does not matter.

My point was:
- we cannot reconstruct correct ACC values, just because there not enough information
- we only can assume that everything level and steady and this leads us to the:
Code: Select all
angle[ROLL] = constrain(EstG.V.X / acc_1G * 570.29577951, -200, 200);
angle[PITCH] = constrain(EstG.V.Y / acc_1G * 570.29577951, -200, 200);
- we should admit that this is just workaround to the unknown problem, not a solution

regards,
ziss_dm
Re: MultiWii_dev_20111017
acc-Z zero-point not stable!
to be precise , I experiment with r312 which should be most similar regarding flight characteristics.
copter is with wmp+bma020.
sequece on level ground:
1. power up
2. calibrate acc
3. acc values normal
4. 5 second flight - wobbly
5. disarm
5. acc z-value is beyond scope in telemetry (off by more than 30 from acc_1G)
One copter frame broken, now upon diagnosis another frame stressed, I leave it to more experienced coders/flyers to sort this out.
to be precise , I experiment with r312 which should be most similar regarding flight characteristics.
copter is with wmp+bma020.
sequece on level ground:
1. power up
2. calibrate acc
3. acc values normal
4. 5 second flight - wobbly
5. disarm
5. acc z-value is beyond scope in telemetry (off by more than 30 from acc_1G)
One copter frame broken, now upon diagnosis another frame stressed, I leave it to more experienced coders/flyers to sort this out.
Re: MultiWii_dev_20111017
I've tested this version, and i have no problems with it.
No ACC drift at all.
Very stable.
Baro not tested enough.
My setup: WM+, BMA020, BMP085 and HMC5883.
No ACC drift at all.
Very stable.
Baro not tested enough.
My setup: WM+, BMA020, BMP085 and HMC5883.
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: MultiWii_dev_20111017
Hi Alex.
I did some testflying today.
I am not very happy with the results. Tere is still a constant drift.
It was alittle windy though but the drift is there. It is not connected to the wind.
I have some vibrations in one motor so I will try again tomorrow.
Nils
I did some testflying today.
I am not very happy with the results. Tere is still a constant drift.
It was alittle windy though but the drift is there. It is not connected to the wind.
I have some vibrations in one motor so I will try again tomorrow.
Nils
-
- Posts: 2261
- Joined: Sat Feb 19, 2011 8:30 pm
Re: MultiWii_dev_20111017
jevermeister wrote:Hi Alex.
I did some testflying today.
I am not very happy with the results. Tere is still a constant drift.
It was alittle windy though but the drift is there. It is not connected to the wind.
I have some vibrations in one motor so I will try again tomorrow.
Nils
Have you tried trimming the Angle (ACC)?
http://www.multiwii.com/forum/viewtopic.php?f=15&t=805
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii_dev_20111017
jevermeister wrote:Hi Alex.
I did some testflying today.
I am not very happy with the results. Tere is still a constant drift.
It was alittle windy though but the drift is there. It is not connected to the wind.
I have some vibrations in one motor so I will try again tomorrow.
Nils
Hi
How can you really evaluate a drift in the wind ? (except if it it really important like at least 3/4 deg inclination)
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: MultiWii_dev_20111017
Hi Alex, hi richie,
sorry for my last post.
I calibrated and trimmed the acc but the problem persists.
BUT:
I flew with 1.7 Code activated today and have the same drift. So I think the problem is with my setup.
That is very weird since the copter seems to be level when lying on my table - I need some inflight data for finding this - any Idea?
I have bluetooth and two Android devices at hand.
Nils
sorry for my last post.
I calibrated and trimmed the acc but the problem persists.
BUT:
I flew with 1.7 Code activated today and have the same drift. So I think the problem is with my setup.
That is very weird since the copter seems to be level when lying on my table - I need some inflight data for finding this - any Idea?
I have bluetooth and two Android devices at hand.
Nils
Re: MultiWii_dev_20111017
Hi Alex,
I noticed, in the latest dev, the powermeter does not work anymore.
The alarm value for the powermeter is not saved properly to eprom upon write it seems....
Wilco
I noticed, in the latest dev, the powermeter does not work anymore.
The alarm value for the powermeter is not saved properly to eprom upon write it seems....
Wilco
Re: MultiWii_dev_20111017
Hi all,
I tested the dev_201111017 and I'm pretty happy with it. No drift, stable mode very ... stable!
Windy conditions today test ... passed !
I've not tested ALT_HOLD or MAG yet.
GPS is working. Just awaiting the RTH code implementation.
Thanks
I tested the dev_201111017 and I'm pretty happy with it. No drift, stable mode very ... stable!
Windy conditions today test ... passed !
I've not tested ALT_HOLD or MAG yet.
GPS is working. Just awaiting the RTH code implementation.
Thanks
Re: MultiWii_dev_20111017
Nils,
you could try and get the link to the gui on PC via bt and monitor sensor values in gui while flying.
with latest dev versions I have non stable acc-z value - described more explicit in another thread here.
jevermeister wrote:I need some inflight data for finding this - any Idea?
I have bluetooth and two Android devices at hand.
you could try and get the link to the gui on PC via bt and monitor sensor values in gui while flying.
with latest dev versions I have non stable acc-z value - described more explicit in another thread here.
Re: MultiWii_dev_20111017
wilco1967 wrote:I noticed, in the latest dev, the powermeter does not work anymore.
The alarm value for the powermeter is not saved properly to eprom upon write it seems....
Wilco
yes, thank you.
This is a known bug. Alex has found the code at error and fixed this - we are awaiting integration in the dev version.
So it is safe to asume you are using the powermeter feature? May I ask whether you use the software version or run it with a hardware current sensor?
How exact is it for you, please?
Re: MultiWii_dev_20111017
Hi guys,
I'm so happy with the last MultiWii_dev_20111017. This is the first time when I can fly in stable mode! Thanks to Alex!
A little drift is still there but it's probably the issue of my quadr, because i'm flying with cheap props from HK. The props are balanced but it's not so good in any case.
My config: 3205+bma020
thx-
Alex
I'm so happy with the last MultiWii_dev_20111017. This is the first time when I can fly in stable mode! Thanks to Alex!
A little drift is still there but it's probably the issue of my quadr, because i'm flying with cheap props from HK. The props are balanced but it's not so good in any case.
My config: 3205+bma020
thx-
Alex
Re: MultiWii_dev_20111017
Hi,
I also tested this dev, these days. Drift is still there but less agressive i would say.
In Dev20111008 i had a constant drift to right front, wich got stronger and stronger and would lead to a crash if not corrected.
Beat me if i am wrong, but this dev seems to be the first one, where i am able to create a constant drift to the left by trimming acc. Ok not really constant, it will again drift to the right, but i got around 10minutes of time where i can maintain drift to the left.
I have a cam onboard and a crappy inet connection. I promised to upload a vid of last dev, instead i ll do it for this one.
Right now i can not see any kind of vibration in the footage, so my props really seem to be well balanced.
I ll keep on testing.
greetz,
Noc
I also tested this dev, these days. Drift is still there but less agressive i would say.
In Dev20111008 i had a constant drift to right front, wich got stronger and stronger and would lead to a crash if not corrected.
Beat me if i am wrong, but this dev seems to be the first one, where i am able to create a constant drift to the left by trimming acc. Ok not really constant, it will again drift to the right, but i got around 10minutes of time where i can maintain drift to the left.
I have a cam onboard and a crappy inet connection. I promised to upload a vid of last dev, instead i ll do it for this one.
Right now i can not see any kind of vibration in the footage, so my props really seem to be well balanced.
I ll keep on testing.
greetz,
Noc
Re: MultiWii_dev_20111017
Hamburger wrote:wilco1967 wrote:I noticed, in the latest dev, the powermeter does not work anymore.
The alarm value for the powermeter is not saved properly to eprom upon write it seems....
Wilco
yes, thank you.
This is a known bug. Alex has found the code at error and fixed this - we are awaiting integration in the dev version.
So it is safe to asume you are using the powermeter feature? May I ask whether you use the software version or run it with a hardware current sensor?
How exact is it for you, please?
Hi Hamburger,
Yes, I'm trying to use it..... Just managed yesterday to get a working led strip driver... The one from my flydusense board did not work properly. It only was able to drive a small led (which was almost impossible to see in flight). Now it is working properly with a different transistor (not flown with it yet).
From the few flight I made with it, the power meter seems pretty accurate.... MUCH better then waiting for the low voltage alarm.... I'm using the software version.
Some of my lipo's get very tired, so the low bat alarm comes on almost immediately. If you pull them down till the low voltage alarm, it's kind of late..... Also a high throttle burst will raise the low voltage alarm way before the lipo is 80% depleted, so it's good for a warning, but no accurate measure for used mAh. Your powermeter routine does a much better job at that !
One feature that would be nice, is different alarms (different blink patterns), based on various powermeter alarm levels. I fly different batteries, so need other settings for each battery....
The multiwii with lights code made by Mariano (mgros) is a nice start for what I have in mind.... I've tried it earlier, and it can create all kinds of patterns.... very nice.... I don't mind for stable mode on/off, but various powermeter settings would be perfect.... like one setting for a 1600 battery, one for a 2200, and one for a 3300.... you get the idea.
I've tried some small code modifications for this, but I'll need some practice... Long time ago since I did some programming.... Somewhere back in the 80's on a commodore 64 I think

No need to implement in the GUI... just hardcoded would do fine for me... Download takes only a few seconds, and once set, will not change anymore.
Re: MultiWii_dev_20111017
thanks for the feedback. I am glad powermeter works for you.
You can set the alarm level via the LCD. In my case that is 'attached' wirelessly with bluettooth, it is easy to change the alarm level 'on the fly' while copter is disarmed. Having an LCD is a very useful addon, imho.
Does that help?
One feature that would be nice, is different alarms (different blink patterns), based on various powermeter alarm levels. I fly different batteries, so need other settings for each battery....
You can set the alarm level via the LCD. In my case that is 'attached' wirelessly with bluettooth, it is easy to change the alarm level 'on the fly' while copter is disarmed. Having an LCD is a very useful addon, imho.
Does that help?
Re: MultiWii_dev_20111017
Hey guys,
the new software is great! After a little trimming it flys much better!
Now my problem:
After disconnecting and new connecting my battery, the trimming is gone and i have to start trimming again.
What can i do?
the new software is great! After a little trimming it flys much better!
Now my problem:
After disconnecting and new connecting my battery, the trimming is gone and i have to start trimming again.
What can i do?
Re: MultiWii_dev_20111017
the trim is relitve to gravity, and thus level ground. I had the idea of putting the level out of a cheap spirit level on each of the booms. so i knw my copter is sitting dead level when i power it on and know my trims will be pretty dam close to perfect every time.
Re: MultiWii_dev_20111017
Hi people,
I can not config through the LCD. The second line appears at the top and the first ever. Please advice. Thank you.
I can not config through the LCD. The second line appears at the top and the first ever. Please advice. Thank you.
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii_dev_20111017
Stalk wrote:Hi people,
I can not config through the LCD. The second line appears at the top and the first ever. Please advice. Thank you.
Hi,
there was a small bug with LCD, which was just corrected in the last dev from today.
Re: MultiWii_dev_20111017
Hi Alex,
Thank you for your quick help.
Thank you for your quick help.