MultiWii_dev_20111029
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
MultiWii_dev_20111029
Hi,
In this version:
- There is the new init function for BMP180. It apparently solve the ACCZ stability.
- Anyway, as this is not the only ACC, I introduced a switch //#define TRUSTED_ACCZ to trust or not trust the ACCZ values in small inclination condition.
By default: not trusted.
- A small LCD bug correction
- IMU attitude code should be more accurate due to the replacement of the previous ACC LPF
I plan to release the 1.9 soon based on this version.
In this version:
- There is the new init function for BMP180. It apparently solve the ACCZ stability.
- Anyway, as this is not the only ACC, I introduced a switch //#define TRUSTED_ACCZ to trust or not trust the ACCZ values in small inclination condition.
By default: not trusted.
- A small LCD bug correction
- IMU attitude code should be more accurate due to the replacement of the previous ACC LPF
I plan to release the 1.9 soon based on this version.
Last edited by Alexinparis on Sat Oct 29, 2011 10:03 am, edited 1 time in total.
Re: MultiWii_dev_20111029
Sounds very nice. Thank you!
- 9DOF + Baro user.
- 9DOF + Baro user.
Re: MultiWii_dev_20111029
Hi,
When i use bmp180 i have to use the trusted_accz?
Kayle
When i use bmp180 i have to use the trusted_accz?
Kayle
Re: MultiWii_dev_20111029
just fired up the old tri in the lounge with the new dev and it works really well. both acro and stable mode look promising. its really windy outside so i cant test fully but the next time its fine ill try some aggressive and fast flying to see if it holds up.
Re: MultiWii_dev_20111029
Requesting configurable gyro dps that's not 2000 and not tied into the rest of the code? pretty-please?
Re: MultiWii_dev_20111029
Hmm.. I merged the changes, and something is messed up in accSmooth, pitch/roll values are all over the place (jumping between -1000/1000 type thing... So I went through line by line and didn't see any merge fail... Finally I thought "hey let's calibrate ACC". Hit that button and now all is OK. Yay.
Re: MultiWii_dev_20111029
I think something went wrong with the yaw on a Tri....
Seems like the gain is like 100x more sensitive.... If I push the stick just slightly from neutral, the yaw servo goes full stroke...
Doesn't help to calibrate ACC, nor reducing the yaw gain (even at yaw P=0.1, it still goes crazy if I move the yaw stick just slightly).
EDIT:
I think I found the problem here on my side.....
I accidently put #define YAW_DIRECTION -11 (minus ELEVEN).... So not a 100x but just a 11x.....
Seems like the gain is like 100x more sensitive.... If I push the stick just slightly from neutral, the yaw servo goes full stroke...
Doesn't help to calibrate ACC, nor reducing the yaw gain (even at yaw P=0.1, it still goes crazy if I move the yaw stick just slightly).
EDIT:
I think I found the problem here on my side.....
I accidently put #define YAW_DIRECTION -11 (minus ELEVEN).... So not a 100x but just a 11x.....
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii_dev_20111029
Kayle wrote:Hi,
When i use bmp180 i have to use the trusted_accz?
Kayle
Hi,
With BMA180, the ACCZ should be trusted with the new init function.
But in case of doubt, think about this option latter.
Anyway, it's easy to see if you can trust or not accz:
Hold the multi and put some thottle while looking at the GUI, the ACCZ line should not decrease.
If it's not the case, leave this option commented.
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii_dev_20111029
dongs wrote:Requesting configurable gyro dps that's not 2000 and not tied into the rest of the code? pretty-please?
Currently for an ITG3200 , this value is defined in IMU.pde here:
Code: Select all
#define GYRO_SCALE ((2380 * PI)/((32767.0f / 4.0f ) * 180.0f * 1000000.0f)) //should be 2279.44 but 2380 gives better result
Code: Select all
GYRO_ORIENTATION( + ( ((rawADC[2]<<8) | rawADC[3])/4) ,
- ( ((rawADC[0]<<8) | rawADC[1])/4 ) ,
- ( ((rawADC[4]<<8) | rawADC[5])/4 ) );
So this 2 things are very dependent and would be different for another gyro. (like WMP or analogical IDG).
So extracting the current 2380 in the conf.h wouldn't be so useful, no ? What is your suggestion ?
Re: MultiWii_dev_20111029
Well, I thought you said auto-level code depended on 2000dps as well at some point. Is this not the case anymore?
i.e. if I change to 500dps gyro and adjust things appropriately, nothing else needs to be changed?
i.e. if I change to 500dps gyro and adjust things appropriately, nothing else needs to be changed?
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: MultiWii_dev_20111029
Hi Alex,
good news, I am looking forward to 1.9 hopefully the devs of the android tools can keep up, those tools are pure luxury for conficuration in the field.
My question is: Do you have a clue why the ACCZ is behaving like this? Is it a problem with the sensors (defective hardware) or is there something wrong with the software?
You once noticed that my accz is doing this in one of my videos (1.7Stab Mode is not referring to accz?)
May it be possible to think about including the sensitivity of the mag into the code, so that we might edit it if we have problems with fluctuating data? The standard sensitivity of the HMC5883L is way to high?
Cheers and keep on the great work - we all appreciate it a lot!!!
Nils
good news, I am looking forward to 1.9 hopefully the devs of the android tools can keep up, those tools are pure luxury for conficuration in the field.
My question is: Do you have a clue why the ACCZ is behaving like this? Is it a problem with the sensors (defective hardware) or is there something wrong with the software?
You once noticed that my accz is doing this in one of my videos (1.7Stab Mode is not referring to accz?)
May it be possible to think about including the sensitivity of the mag into the code, so that we might edit it if we have problems with fluctuating data? The standard sensitivity of the HMC5883L is way to high?
Cheers and keep on the great work - we all appreciate it a lot!!!
Nils
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii_dev_20111029
dongs wrote:Well, I thought you said auto-level code depended on 2000dps as well at some point. Is this not the case anymore?
i.e. if I change to 500dps gyro and adjust things appropriately, nothing else needs to be changed?
Hi,
basically, gyro data coming from sensors.pde code is used:
- by acro and level mode in multiwii.pde
- by attitude estimation in IMU.pde to produce angles
- the data from ITG is divided by 4 to produce a limited output -8192;+8192 => 8192 units after the sensor calculation = 2279.44 deg/s (see here: viewtopic.php?f=8&t=809)
gyro scale is used:
- only by attitude estimation. the number "2000" is used only in this part: which in fact should be theoretically 2279, and which is 2380 currently
So regarding the real scale value used in the attitude estimation function, it it 2380/4
#define GYRO_SCALE ((2380 * PI)/((32767.0f / 4.0f ) * 180.0f * 1000000.0f))
regarding your 500dps gyro, if you want to reproduce the same sensibility: you have to find a way to reproduce the same proportion in the sensor calculation function: 8192 units = 2279.44 deg/s and everything else should be fine.
Re: MultiWii_dev_20111029
OK, thanks for explanation. That's basically what I'm doing, and it seems to work. ( = rescaling gyro outputs)
500 dps was just an example anyway. Still haven't fly-tested this dev, but it seems to be working OK on the desk.
500 dps was just an example anyway. Still haven't fly-tested this dev, but it seems to be working OK on the desk.
Re: MultiWii_dev_20111029
I tried this dev version and immediately noticed how stable the copter was in level mode. Really smooth!
But when I started flying around more quickly, the tricopter all of a sudden tilted backwards/left about 10 degrees. I corrected this by using the stick, but was not able to get into stable hover. After landing however, I could again reach the same stable hover.
I used the new "do not trust acc" function when this happened. BMA180 accelerometer.
And yes, my props are balanced. But not the motors.
-
- Posts: 702
- Joined: Sun Aug 28, 2011 8:14 pm
- Contact:
Re: MultiWii_dev_20111029
Hi Alex and Ziss_dm,
In the last week I have been followed your work in (google project) and the post´s from one to another! let me say that both of you are geniouses!
For the first time I have my Quad working in perfect conditions. The drift and flip issues are forever gone! The PID´s are perfect (on my config).
I just changed the code on to things: level mode error from 500 to 250 / 25ºmax ( when I use the level mode it´s because I need to be leveled not to fly around fast) and the trust ACC Z Value ( with my motors running my ACC Z Value is almost the same as stoped!).
So... keep going with the good work!
A litle video to show that all works just fine!
http://www.youtube.com/watch?v=OazH4GOQFso
Cheers,
Henrique
In the last week I have been followed your work in (google project) and the post´s from one to another! let me say that both of you are geniouses!
For the first time I have my Quad working in perfect conditions. The drift and flip issues are forever gone! The PID´s are perfect (on my config).
I just changed the code on to things: level mode error from 500 to 250 / 25ºmax ( when I use the level mode it´s because I need to be leveled not to fly around fast) and the trust ACC Z Value ( with my motors running my ACC Z Value is almost the same as stoped!).
So... keep going with the good work!
A litle video to show that all works just fine!
http://www.youtube.com/watch?v=OazH4GOQFso
Cheers,
Henrique
Last edited by kataventos on Wed Nov 02, 2011 10:10 pm, edited 1 time in total.
Re: MultiWii_dev_20111029
this dev looks really good. got out for some aggressive flying in no wind this afternoon. My pids are a little off so it was twitching but the drift issue seems to be all but solved. it only drifted off twice and they were only small drifts that were very manageable. i think after i replace the bearings in one of my motors and refine the balance of the props well be all good.
cant wait for 1.9 thanx Alex
cant wait for 1.9 thanx Alex
Re: MultiWii_dev_20111029
@Henrique
Will you please be so kind and post a screenshot of your config Window, to see all the PID values.
I am still fighting horizontal moves in stable mode.
My PID values can be seen in the attached screenshot.
Regards, Rudolf
Will you please be so kind and post a screenshot of your config Window, to see all the PID values.
I am still fighting horizontal moves in stable mode.
My PID values can be seen in the attached screenshot.
Regards, Rudolf
Re: MultiWii_dev_20111029
Hello,
I wanted to show more actual and real life "config" screenshots:
Setup: ITG3200, BMA020, BMP085, HMC5883, Motor 2213N, Prop 9x5" balanced
1. armed with 1200 us
2. holding with centered gas, about 1500 us
I have activated:
#define TRUSTED_ACCZ
Is that behavior OK?
Regards, Rudolf
I wanted to show more actual and real life "config" screenshots:
Setup: ITG3200, BMA020, BMP085, HMC5883, Motor 2213N, Prop 9x5" balanced
1. armed with 1200 us
2. holding with centered gas, about 1500 us
I have activated:
#define TRUSTED_ACCZ
Is that behavior OK?
Regards, Rudolf
Re: MultiWii_dev_20111029
Hi rudi,
Alex wrote that #define trusted accz is use only for bma180. It has no effect with bma020.
Greetings Kayle
Alex wrote that #define trusted accz is use only for bma180. It has no effect with bma020.
Greetings Kayle
Re: MultiWii_dev_20111029
Hi Kayle,
You are wrong,
#trusted_accz must be defined if your acc Z value changes significantly when you apply throttle, so you cannot trust it's 1G value. (It's used in the IMU part, so applied to all acc calculations)
Regards,
Bandi
You are wrong,
#trusted_accz must be defined if your acc Z value changes significantly when you apply throttle, so you cannot trust it's 1G value. (It's used in the IMU part, so applied to all acc calculations)
Regards,
Bandi
Re: MultiWii_dev_20111029
Hi,
Thanks. I only find this from alex:
"As you don't have a BMA180, it is useless to test it with trusted acc."
Greetings Kayle
Thanks. I only find this from alex:
"As you don't have a BMA180, it is useless to test it with trusted acc."
Greetings Kayle
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: MultiWii_dev_20111029
EOSBandi wrote:Hi Kayle,
You are wrong,
#trusted_accz must be defined if your acc Z value changes significantly when you apply throttle, so you cannot trust it's 1G value. (It's used in the IMU part, so applied to all acc calculations)
Regards,
Bandi
Hi,
in fact it's the opposite
trusted_accz commented (//#define trusted_accz) means accz is not taken into account
trusted_accz not commented (#define trusted_accz) means it is taken into account for calculation
if acc Z value changes significantly when you apply throttle => it must be commented
Re: MultiWii_dev_20111029
I know I might be asking too much, but I've got a few code readability improvement requests.
Things like LEDPIN_SWITCH, etc macros do not have a terminating semicolon after them.
Yes, I realize it's in the config.h file, but it still makes it more difficult to read (and indent) the code.
So instead of if (foo) LEDPIN_SWITCH else LEDPIN_ON or something can it be made to
if (foo)
LEDPIN_SWITCH;
else
LEDPIN_ON;
There are a few places in the code where one has to look twice to determine the nesting/order of nested ifs and if elses. I think it might be a good idea to put { } where appropriate to avoid confusion. The code is already much, much cleaner than "other" arduino-based projects but it would be nice if these requests were implemented.
Another request, is try to minimize C++isms in the code when possible
in void rotateV(...), fp_vector v_tmp doesn't work when code is compiled as C. So it should be 'struct fp_vector v_tmp = ...', should also build in C++ mode as well.
also fp_is_neg kinda depends on CPU endinanness, so perhaps a comment there about that is in order.
I posted about the byte->uint8_t cleanup in the spektrum thread but that's also something that would be nice to have so that all the used types are consistent.
Sorry, these are mostly nitpicks, because I don't have much else to nitpick on, the code is very well organized so far.
Things like LEDPIN_SWITCH, etc macros do not have a terminating semicolon after them.
Yes, I realize it's in the config.h file, but it still makes it more difficult to read (and indent) the code.
So instead of if (foo) LEDPIN_SWITCH else LEDPIN_ON or something can it be made to
if (foo)
LEDPIN_SWITCH;
else
LEDPIN_ON;
There are a few places in the code where one has to look twice to determine the nesting/order of nested ifs and if elses. I think it might be a good idea to put { } where appropriate to avoid confusion. The code is already much, much cleaner than "other" arduino-based projects but it would be nice if these requests were implemented.
Another request, is try to minimize C++isms in the code when possible
in void rotateV(...), fp_vector v_tmp doesn't work when code is compiled as C. So it should be 'struct fp_vector v_tmp = ...', should also build in C++ mode as well.
also fp_is_neg kinda depends on CPU endinanness, so perhaps a comment there about that is in order.
I posted about the byte->uint8_t cleanup in the spektrum thread but that's also something that would be nice to have so that all the used types are consistent.
Sorry, these are mostly nitpicks, because I don't have much else to nitpick on, the code is very well organized so far.
Re: MultiWii_dev_20111029
I was unable to fly with this dev build.
When it was 1.8p2, everything is OK. But if I was using 20111029, it's very unstable and drifted a lot when it leaves the floor. I was using the same parameters (PIDs, RC curve). Surely the mag/acc calibration was done. I had done back and forth several times and got the same result.
The customization work I do in code (both to 1.8p2 and this dev build) was:
1. Choosing QUADRINO - I have a 9DOF + BARO
2. Change I2C speed to fast
I'm using a 500mm sized, 950g weighted Quad X.
Did I miss something and caused this big problem?
When it was 1.8p2, everything is OK. But if I was using 20111029, it's very unstable and drifted a lot when it leaves the floor. I was using the same parameters (PIDs, RC curve). Surely the mag/acc calibration was done. I had done back and forth several times and got the same result.
The customization work I do in code (both to 1.8p2 and this dev build) was:
1. Choosing QUADRINO - I have a 9DOF + BARO
2. Change I2C speed to fast
I'm using a 500mm sized, 950g weighted Quad X.
Did I miss something and caused this big problem?
Re: MultiWii_dev_20111029
I would like to see the code added to initialize the magnetic compass via stick commands. I almost tore my board up trying to rotate it connected to USB. Rcflyrodeo posted the code changes and it worked great. http://www.multiwii.com/forum/viewtopic.php?f=8&t=775&p=4580&hilit=compass#p4440
- captaingeek
- Posts: 228
- Joined: Fri Jan 28, 2011 6:42 pm
Re: MultiWii_dev_20111029
darn didnt realize this was released was fighting the atmel i1 acc all weekend trying to get it working with 1.8p2. havnt been able to get stable mode working right with that board no matter what ive tried.
-
- Posts: 702
- Joined: Sun Aug 28, 2011 8:14 pm
- Contact:
Re: MultiWii_dev_20111029
Rudi48 wrote:@Henrique
Will you please be so kind and post a screenshot of your config Window, to see all the PID values.
I am still fighting horizontal moves in stable mode.
My PID values can be seen in the attached screenshot.
Regards, Rudolf
@Rudolf
Hi, of course no problem with that, tomorrow afternoon I will update with my GUI pictures to show ACC values with and without the motors running not forgetting the 10º inclination, the PID´S are the original from this dev and they work just fine on my config.
Cheers,
Henrique
Re: MultiWii_dev_20111029
Had some time to port this new code and try it out.
Flies as good as ever, and I don't notice any issues with autolevel.
Flies as good as ever, and I don't notice any issues with autolevel.
Re: MultiWii_dev_20111029
Hey everyone, been closely watching the progress of this wonderful project.
FPVd my tricopter today and it was perfect! Very very stable with this dev firmware
Quick overview of tri:
AUW 1500g
1000mm diameter
11x4.7 props
multiwii : wii gyros+ bma020 + HMC5883L mag
---------------------
Vid: http://www.youtube.com/watch?v=MLWyLV0yS_o
FPVd my tricopter today and it was perfect! Very very stable with this dev firmware
Quick overview of tri:
AUW 1500g
1000mm diameter
11x4.7 props
multiwii : wii gyros+ bma020 + HMC5883L mag
---------------------
Vid: http://www.youtube.com/watch?v=MLWyLV0yS_o
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: MultiWii_dev_20111029
Same for me here.
I did some FPV too and was pretty happy with the nodrift situation.
I am one of those who suffer from the BMA0202 ACCZ Problem...
I did some FPV too and was pretty happy with the nodrift situation.
I am one of those who suffer from the BMA0202 ACCZ Problem...
Re: MultiWii_dev_20111029
I am not sure what is wrong in my setup - I'm using the allinone board from CSG_EU, using X4 configuration - acro flying is super, but once I activate level it starts to roll left and back (fast!), I was able to trim it using the sticks (acc trim) and it started being oversensitive. I had the same results on different copter with the same sensors, so either the error is in the acc (but it behaves well in GUI) or in code (this dev version, previous dev version, 1.8p2...).
Is old stable mode (1.7) still present? Will try that, and after that I don't know what else to try...
Is old stable mode (1.7) still present? Will try that, and after that I don't know what else to try...
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: MultiWii_dev_20111029
Remember my bench test!? Try it for yourself and watch the gauges and especially AccZ, Alex implemented a feature to turn of unwanted readings in the grapics.
Just be very very very VERY V-E-R-Y careful with the props!!!!
Nils
Just be very very very VERY V-E-R-Y careful with the props!!!!
Nils
Re: MultiWii_dev_20111029
jevermeister wrote:Remember my bench test!? Try it for yourself and watch the gauges and especially AccZ, Alex implemented a feature to turn of unwanted readings in the grapics.
Just be very very very VERY V-E-R-Y careful with the props!!!!
Nils
aargh... I thought I had trusted ACCZ disabled.. my bad... will try again tomorrow :/ I'm not sure if I uncommented that during the last test or if it was enabled the entire time
anyway - is it known why measurement on Z is way of with motors running? Is it vibration or a bad batch?
I don't have a BMA020 but BMA180. I also have some vibration problems (chaning whole frame didn't fix that, maybe I'm doing something systematicaly wrong?) so it may very well be related. Right now it is set to mode 2 (ultra low noise), but I'll try messing with the filters on it and see if it changes anything...
I'd like to have mag and baro working apart from autolevel...
Re: MultiWii_dev_20111029
Hello!
Today I tried 1.9pre. It definitely has a drift issue in level mode.
Drifts to one side and you have to pull against it until the stick is at outer stop.
In the GUI I can see the lines of the ACC constantly moving a little bit even if the Quad is laying on the table.
That's not happening with 1.8.2
Quad X 480mm
my own frame and shield
Mystery Blue 12A
EMAX CF2822
Propeller 10" x 4,5"
Arduino Mini
Original WMP + NC
Today I tried 1.9pre. It definitely has a drift issue in level mode.
Drifts to one side and you have to pull against it until the stick is at outer stop.
In the GUI I can see the lines of the ACC constantly moving a little bit even if the Quad is laying on the table.
That's not happening with 1.8.2
Quad X 480mm
my own frame and shield
Mystery Blue 12A
EMAX CF2822
Propeller 10" x 4,5"
Arduino Mini
Original WMP + NC
Re: MultiWii_dev_20111029
Dev.20111029 GUI shows strange spikes, in Dev. 20111008 to. V18p2 is OK.
You can see images on http://www.rcgroups.com/forums/showthread.php?t=1534905
Thanks
Tom
You can see images on http://www.rcgroups.com/forums/showthread.php?t=1534905
Thanks
Tom