MultiWii 1.9

UndCon · Post by **UndCon** » Wed Nov 09, 2011 1:10 pm

shikra wrote:Running 1.9 (downloaded just prior to the arming fix)
Seeing this on two Tri's - one using WMP/NK and the other ITG3200 and ADXL345

This may be same with other versions too, but I noticed it yesterday because I used GUI to set up rather than LCD and tx sticks like usual.

So calibrate with the Tri level. Looks good in the gui. pitch/roll indicators appear perfect.
These days I set up my Tri by hand feel now before flying. Can get it nearly right.

So hold it up in the air and turn motors on until it reaches hover point then I start to adjust gyro PID until it feels about right.

Now I move to acc autolevel.
Again holding the tri get it to about hover point, then engage autolevel.
It levels out at about 20-25 deg tilt. Seems a little far out as calibrated with it perfect level on bench. mmmmm
Tried a few times - same result. Calibrating from sticks or GUI

At this point I notice first odd thing. When it's hovering and gets to level, the GUI pitch/ roll is indicating perfectly the angle of the copter. Which is nowhere near level... 20- 25 degrees
So the copter thinks its level - but the gui indicates it's true angle very well.

And then the second odd thing I did not expect...
So I looked at my settings and my Autolevel I value was very low compared to default.
I changed I value - and the angle at which the copter stayed for level changed. By changing it I could get it to near level......
I was not expecting that.

Is this related to the fix last night or normal??
I wouldn't normally notice because I usually use LCD and the fine tx calibration to set up..... My feeling is I have experienced with previous versions too, but just trimmed it out with sticks until it was Level like I wanted.

I think this sums up all my experiences as well.
When new code is calibrated - acro and level, the level mode seems to be far off by default (I experience ~25 degrees as well)- I did not try the trimming like you did... and I will try a few things when I get home

mr.rc-cam · Post by **mr.rc-cam** » Wed Nov 09, 2011 6:05 pm

Running 1.9 (downloaded just prior to the arming fix)
Seeing this on two Tri's - one using WMP/NK and the other ITG3200 and ADXL345

Be sure to use the latest V1.9 that has the arming patch. The arming fix corrects other problems with WMP/NK's ACC functions.

When new code is calibrated - acro and level, the level mode seems to be far off by default (I experience ~25 degrees as well)

Hmm, this sort of thing sounds like it could be a bug related to the new TRUSTED_ACCZ define. Repeat your GUI tests both ways (TRUSTED_ACCZ enabled & disabled) and report your observations; That may help ID the issue.

BTW, I think TRUSTED_ACCZ is only valid for BMA180 users at this point. Regardless, the published ACC Z test will tell you if you should attempt to use it.

shikra · Post by **shikra** » Wed Nov 09, 2011 7:06 pm

OK, just downloaded the latest 1.9 posted by alex and...

wmp/nk setup
Arms on sticks OK now..

With Autolevel I of 0.05, after calibrating, it is approx level in hover. And the GUI shows level

With Autolevel I of 0.006 it "levels at an angle of approx 20-25 degrees. And the GUI shows that angle.
BUT - only the roll is at an angle. The Pitch is fine....

!! Hope that helps

EDIT: tried with without #Trusted... no change - but it is WMP/NK

mgros · Post by **mgros** » Wed Nov 09, 2011 9:04 pm

Hello.
I have a miniquad with WMP and BMA180, it fly with 1.8pre2 fantastic, now i'm testing 1.9 but i have detected a small problem.
Flying i have detectes some spurious peaks in gyro reading that convert to a quick oscillation in quad.
I have this peaks with engines on when i move the quad via radio N-S or W-E without any repetitive frecuency, but if i hold the quad in my hand without moving the radio sticks i have not peaks.
It seems is related to timing, but any idea where.
With 1.8 pre2 or older version never have this peaks.
Any other has noticed this symptom?. Any idea?
Thanks, perhaps there is a new bug in code.

mr.rc-cam · Post by **mr.rc-cam** » Wed Nov 09, 2011 11:06 pm

With Autolevel I of 0.05, after calibrating, it is approx level in hover. And the GUI shows level
With Autolevel I of 0.006 it "levels at an angle of approx 20-25 degrees. And the GUI shows that angle.
BUT - only the roll is at an angle. The Pitch is fine....

I cannot duplicated it with my BMA180 and I don't have a WMP/NK to investigate it further. So it might be best to gather some data for Alex. If you don't mind, open serial.pde and find this code sequence (may be different if you have previously edited the serial.pde):

Code: Select all

      serialize16(BaroAlt/10); // 4 variables are here for general monitoring purpose
      serialize16(0);              // debug2
      serialize16(0);              // debug3
      serialize16(0);              // debug4

and replace it with:

Code: Select all

      serialize16(BaroAlt/10); // 4 variables are here for general monitoring purpose
      serialize16(accZero[ROLL]);              // debug2
      serialize16(accZero[PITCH]);              // debug3
      serialize16(I8[PIDLEVEL]);              // debug4

Do this to both V1.9 and a working prior version (V1.8p2 or later dev). Perform a ACC Cal (do this whenever a different firmware version is loaded), then repeat your AutoLevel I-value tests (0.05, 0.006) for both firmware versions. Post the screenshots for the two I-values on both firmware versions (will be 4 screenshots total). Maybe there will be something useful reported in the GUI debug windows that will help determine the problem.

- Thomas

mr.rc-cam · Post by **mr.rc-cam** » Wed Nov 09, 2011 11:41 pm

Flying i have detectes some spurious peaks in gyro reading that convert to a quick oscillation in quad.

If you are using the 400KHz I2C_SPEED then try 100KHz. If the slower I2C clock changes the pattern of the intermittent spurious peaks then that would be useful information. Also check to see that the INTERNAL_I2C_PULLUPS is correctly configured to your board's requirements. These two things are in config.h

mgros · Post by **mgros** » Thu Nov 10, 2011 12:06 am

mr.rc-cam wrote:
Flying i have detectes some spurious peaks in gyro reading that convert to a quick oscillation in quad.

If you are using the 400KHz I2C_SPEED then try 100KHz. If the slower I2C clock changes the pattern of the intermittent spurious peaks then that would be useful information. Also check to see that the INTERNAL_I2C_PULLUPS is correctly configured to your board's requirements. These two things are in config.h

I'm working with 100Khz and with LLC and INTERNAL_I2C_PULLUPS enabled. I tested ther others configurations with same results.
Notced that with 1.8p2 works fine.

UndCon · Post by **UndCon** » Thu Nov 10, 2011 12:12 am

I tested the 1.9 version (latest fixx) with all of my boards. Jussi 1.3 board and 2 Paris v4 boards - both with genuine sensors WM+ and NK

Compiled OK and uploaded to Arduino
Start connecting GUI
Calibrating Acro Gyro - OK
Calibrating Stable Acc - OK but takes very long time compared to earlier versions
Test to engage motors (maximum warp speed)
Acro mode shows no special signs
Level mode now seems to work and is stable with no jitter at all but drifts to the right (left motors increasing)

I also added the code to my trusted Quad and a Tricopter ready for maiden flight
looks much better than previous version so far
//UndCon

cob · Post by **cob** » Thu Nov 10, 2011 12:51 am

Hello all,
I've found a small mistake in the very last 1.9 version in IMU.PDE on line 100

Code: Select all

    if (accSmooth[ROLL]<acc_25deg && accSmooth[ROLL]>-acc_25deg && accSmooth[PITCH]<acc_25deg && accth[PITCH]>-acc_25deg) {

while it was

Code: Select all

    if (accSmooth[ROLL]<acc_25deg && accSmooth[ROLL]>-acc_25deg && accSmooth[PITCH]<acc_25deg && accSmooth[PITCH]>-acc_25deg) {

looks like Alex's fingers went very fast on that one ;-)

I'm using a text compare app each time a new version comes out as I modded the code for my needs and don't want to change everything. So I saw it.

Regards

mr.rc-cam · Post by **mr.rc-cam** » Thu Nov 10, 2011 2:01 am

Flying i have detectes some spurious peaks in gyro reading that convert to a quick oscillation in quad. {snip}
I'm working with 100Khz and with LLC and INTERNAL_I2C_PULLUPS enabled. I tested ther others configurations with same results.
Notced that with 1.8p2 works fine.

Strangely enough, I had the opposite experience. My ITG3200 gyro had an occasional (3-6 times per minute) GUI data jump with the V1.8 - V1.8p2 releases. But it was not seen with V1.9. So this stuff works in mysterious ways.

I suspect the problem was still occurring in V1.9 but for some reason was not as noticeable. But I believe I found the root cause to it, at least on my board. The I2C clock's rise time was too slow and so some I2C R/W's were failing. I reduced the SCL pullup resistor's value and changed to the 100KHz clock; the intermittent data failures were solved.

If you have a buzzer installed on your board then I have some debug code that can could be used to confirm the problem. The debug code chirps the buzzer whenever the CPU fails to see the I2C TWINT flag, which occurred on my board's bad I2C transmissions. Let me know if you want to try it on yours.

UndCon · Post by **UndCon** » Thu Nov 10, 2011 8:14 am

mr.rc-cam wrote:
If you have a buzzer installed on your board then I have some debug code that can could be used to confirm the problem. The debug code chirps the buzzer whenever the CPU fails to see the I2C TWINT flag, which occurred on my board's bad I2C transmissions. Let me know if you want to try it on yours.

Sounds like a cool thing - I have to install a buzzer.

please provide the code for "ThaBeep"

//UndCon

shikra · Post by **shikra** » Thu Nov 10, 2011 10:05 am

Good catch cob. I'll try that code change tonight

tryss · Post by **tryss** » Thu Nov 10, 2011 1:47 pm

Hi people !!!!

I succefully test the 1.9 code this morning with my Y6. (thanks Alex)

Thanks to all of you who contribuate to this. Now i can compare both project APM and MultiWii (it was my goal)

tryss · Post by **tryss** » Thu Nov 10, 2011 2:03 pm

http://www.facebook.com/v/2551455274150 here is a video of the Y6 flying with 1.9

Code: Select all

<object width="400" height="224" ><param name="allowfullscreen" value="true" /><param name="movie" value="http://www.facebook.com/v/2551455274150" /><embed src="http://www.facebook.com/v/2551455274150" type="application/x-shockwave-flash" allowfullscreen="true" width="400" height="224"></embed></object>

mr.rc-cam · Post by **mr.rc-cam** » Thu Nov 10, 2011 9:50 pm

UndCon wrote:
mr.rc-cam wrote:
If you have a buzzer installed on your board then I have some debug code that can could be used to confirm the problem. The debug code chirps the buzzer whenever the CPU fails to see the I2C TWINT flag, which occurred on my board's bad I2C transmissions. Let me know if you want to try it on yours.

Sounds like a cool thing - I have to install a buzzer.
please provide the code for "ThaBeep"

Rather than take this thread off topic, I posted a new discussion for the I2C testing code. It is here:
viewtopic.php?f=8&t=884&p=5404

If you don't have a buzzer then you can use the GUI debug window instead to see the I2C errors. Details are posted in the linked discussion.

- Thomas

shikra · Post by **shikra** » Thu Nov 10, 2011 9:51 pm

Recap:
wmp/nk setup latest code downloaded.
Arms on sticks OK now..

With Autolevel I of 0.05, after calibrating, it is approx level in hover. And the GUI shows level
With Autolevel I of 0.006 it "levels at an angle of approx 20-25 degrees. And the GUI shows that angle.
BUT - only the roll is at an angle. The Pitch is fine....

Tried with without #Trusted... no change - but it is WMP/NK
Tried with the amended code pointed out by cob - accth to accsmooth. No change

Extra info...
My Autolevel P is low at 3. I like this because it is very flyable and I don't need asharp return to level. Dafault is way to strong on mine.
If I raise P to default, there is still a tilt, but it is only little.
It seems to be worse as throttle increase.

So try to replicate with P and I autolevel very low...
The Tri tilts at quite an angle when it thinks it is level. Here is screenshot of what it looks like when it is in level hover after calibration on level. Notice the roll angle....

Maybe its right, but seems odd to me the the gui is correct.
Am sure its indicator or somewhere the code can be improved a little.

adult image hosting

mr.rc-cam · Post by **mr.rc-cam** » Thu Nov 10, 2011 11:59 pm

So try to replicate with P and I autolevel very low...
The Tri tilts at quite an angle when it thinks it is level.

I tried your LEVEL PID values again and still cannot reproduce the problem. I also recompiled my QUAD-X sketch as a TRI and couldn't duplicate it. But I certainly couldn't fly my Quad as a TRI, so maybe that is why I don't see it. Or perhaps it is sensor type related (the data ranges vary greatly on them).

There are several code cleanup changes to the Pitch/Roll/Yaw PID in V1.9. I think it would be interesting to revert a small section back to the V1.8 era code to see if the problem lies within it. Here is what I have in mind:

Find this code section in MultiWii_1_9.pde:

Code: Select all

    if (accMode == 1 && axis<2 ) { //LEVEL MODE
      // 50 degrees max inclination
      errorAngle = constrain(2*rcCommand[axis],-500,+500) - angle[axis] + accTrim[axis]; //16 bits is ok here
      #ifdef LEVEL_PDF
        PTerm      = -(int32_t)angle[axis]*P8[PIDLEVEL]/100 ;
      #else  
        PTerm      = (int32_t)errorAngle*P8[PIDLEVEL]/100 ;                          //32 bits is needed for calculation: errorAngle*P8[PIDLEVEL] could exceed 32768   16 bits is ok for result
      #endif

      errorAngleI[axis]  = constrain(errorAngleI[axis]+errorAngle,-10000,+10000);    //WindUp     //16 bits is ok here
      ITerm              = ((int32_t)errorAngleI[axis]*I8[PIDLEVEL])>>12;            //32 bits is needed for calculation:10000*I8 could exceed 32768   16 bits is ok for result
    } else { //ACRO MODE or YAW axis
      if (abs(rcCommand[axis])<350) error =          rcCommand[axis]*10*8/P8[axis] ; //16 bits is needed for calculation: 350*10*8 = 28000      16 bits is ok for result if P8>2 (P>0.2)
                               else error = (int32_t)rcCommand[axis]*10*8/P8[axis] ; //32 bits is needed for calculation: 500*5*10*8 = 200000   16 bits is ok for result if P8>2 (P>0.2)
      error -= gyroData[axis];

      PTerm = rcCommand[axis];
      
      errorGyroI[axis]  = constrain(errorGyroI[axis]+error,-16000,+16000);          //WindUp //16 bits is ok here
      if (abs(gyroData[axis])>640) errorGyroI[axis] = 0;
      ITerm = (errorGyroI[axis]/125*I8[axis])>>6;                                   //16 bits is ok here 16000/125 = 128 ; 128*250 = 32000
    }
    if (abs(gyroData[axis])<160) PTerm -=          gyroData[axis]*dynP8[axis]/10/8; //16 bits is needed for calculation   160*200 = 32000         16 bits is ok for result
                            else PTerm -= (int32_t)gyroData[axis]*dynP8[axis]/10/8; //32 bits is needed for calculation

Temporarily replace it ALL with:

Code: Select all

    if (accMode == 1 && axis<2 ) { //LEVEL MODE
      errorAngle = constrain(2*rcCommand[axis],-700,+700) - angle[axis] + accTrim[axis]; //16 bits is ok here
      #ifdef LEVEL_PDF
        PTerm      = -(int32_t)angle[axis]*P8[PIDLEVEL]/100 ;
      #else  
        PTerm      = (int32_t)errorAngle*P8[PIDLEVEL]/100 ;                         //32 bits is needed for calculation: errorAngle*P8[PIDLEVEL] could exceed 32768   16 bits is ok for result
      #endif

      errorAngleI[axis] += errorAngle;                                              //16 bits is ok here
      errorAngleI[axis]  = constrain(errorAngleI[axis],-10000,+10000); //WindUp     //16 bits is ok here
      ITerm              = (int32_t)errorAngleI[axis]*I8[PIDLEVEL]/4000;            //32 bits is needed for calculation:10000*I8 could exceed 32768   16 bits is ok for result
    } else { //ACRO MODE or YAW axis
      error = (int32_t)rcCommand[axis]*10*8/P8[axis] - gyroData[axis];              //32 bits is needed for calculation: 500*5*10*8 = 200000   16 bits is ok for result if P8>2 (P>0.2)
      PTerm = rcCommand[axis];

      errorGyroI[axis] += error;                                                    //16 bits is ok here
      errorGyroI[axis]  = constrain(errorGyroI[axis],-16000,+16000); //WindUp       //16 bits is ok here
      if (abs(gyroData[axis])>640) errorGyroI[axis] = 0;
      ITerm = (int32_t)errorGyroI[axis]*I8[axis]/1000/8;                            //32 bits is needed for calculation: 16000*I8  16 bits is ok for result
    }
    PTerm         -= (int32_t)gyroData[axis]*dynP8[axis]/10/8;                      //32 bits is needed for calculation            16 bits is ok for result

I've done this code substitution and confirmed it is flyable, so no unexpected surprises should come from it. If it solves your problem then we will know where the issue is. If it does not help then we will know what isn't the problem. Either way something will be learned.

- Thomas

ziss_dm · Post by **ziss_dm** » Fri Nov 11, 2011 7:22 am

Hi shikra,

With Autolevel I of 0.05, after calibrating, it is approx level in hover. And the GUI shows level
With Autolevel I of 0.006 it "levels at an angle of approx 20-25 degrees. And the GUI shows that angle.
BUT - only the roll is at an angle. The Pitch is fine....

Am I understanding you correctly?
The GUI shows true angle, but it is not leveling? Or vice-versa?

regards,
ziss_dm

shikra · Post by **shikra** » Fri Nov 11, 2011 10:37 am

Yes - you got it.

First I put tri level and calibrated. Have used GUI and sticks. The pitch/roll indicators are perfect on gui and match the Tri when you move it around or it is level.

Then put into acro mode and take up to hover point.
Activate stable mode. It then tilts left considerably until it reaches the point at which it "thinks" it is stable. It stayas this. I can force it away in any direction and it always returns to that same point

On the screenshot, that is taken with motors running and at hover point. And stable on. It is in steady "stable" position. The angl eon the GUI matches very well the angle I see on the Tri. I am very lightly touching it to stop it flying off of course.

This Tri/board combo is a good flyer and well balanced. As you can see from the GUI, the vibes are minimal considering this is running at hover.

STrange how its the roll only though. Going to a little more testing with prev code etc.
Intersting eh?

shikra · Post by **shikra** » Fri Nov 11, 2011 11:16 am

Update - just tried 1.5
Although there is no Autolevel I, dropped Autolevel P right down very low. Perfect - no tilt at all

Update - tried rc-cams amendement - the tilt is still there.

I am almost glad 1.5 was good. I think it does rule out an issue with my setup?
One thing I do notice is that on 1.9&1.5, the gyros report perfect 0 on vlaueswhen idle, but with the acc the fluctuate a little on 1.9 (+/- 1 or 2) whereas on 1.5 they are steady. Not sure if that is an indicator

I also get the same tilt with my non wii adxl/ITG discrete board. A few times with this though it moves around a bit i.e. doesn't keep to teh tilt 100% of time

xerbar · Post by **xerbar** » Fri Nov 11, 2011 11:51 am

Hi I put my hexacopter the 1.9 but I have a problem in the GUI do not work GYRO and ACC graphs are flat. I've tried a thousand ways and does not work. However with the 1.8 all is perfect. Any ideas please?.

shikra · Post by **shikra** » Fri Nov 11, 2011 11:58 am

Which board / chips used? xerbar

xerbar · Post by **xerbar** » Fri Nov 11, 2011 1:36 pm

shikra wrote:Which board / chips used? xerbar

Seduino Mega, BMA020, HMC5883 and WMP thanks.

shikra · Post by **shikra** » Fri Nov 11, 2011 4:46 pm

Can't help you with the mega - have no experience there.
Most probable is wrong sensor definitions / and or addresses

But I would start with all the sensors/boards undefined. WMP only at 100k
At least to see if can get the gyro data working.

mr.rc-cam · Post by **mr.rc-cam** » Fri Nov 11, 2011 6:09 pm

Update - tried rc-cams amendement - the tilt is still there.

Good to know; The problem is not in the latest PID. (EDIT: Assuming you had success with V1.8p2.)

Then put into acro mode and take up to hover point.
Activate stable mode. It then tilts left considerably until it reaches the point at which it "thinks" it is stable. It stayas this. I can force it away in any direction and it always returns to that same point

If you use the Level Trim feature to adjust the attitude offset during Stable mode does it fix the problem? If that feature does not help then something very odd is going on. I'm not saying it is the final fix for you, but knowing it successfully corrects the offset may be helpful information.

jevermeister · Post by **jevermeister** » Fri Nov 11, 2011 6:19 pm

Sorry for the return with my problem:

does noone have these twitches while in acc mode??

Nils

mr.rc-cam · Post by **mr.rc-cam** » Fri Nov 11, 2011 6:56 pm

jevermeister wrote:Sorry for the return with my problem:
does no one have these twitches while in acc mode??

You should consider performing the I2C chirp test discussed here:
viewtopic.php?f=8&t=884&p=5433

cardboard · Post by **cardboard** » Sat Nov 12, 2011 5:53 am

Some video of 1.9 for those that haven't seen it in action yet.
Small-med sized copter (10amp plush escs) with pro mini and original NK and WM+
Aggressive flight mainly in level mode to test the new code and it looks good with this setup.

http://vimeo.com/31985786

xerbar · Post by **xerbar** » Sat Nov 12, 2011 11:53 am

shikra wrote:Can't help you with the mega - have no experience there.
Most probable is wrong sensor definitions / and or addresses

But I would start with all the sensors/boards undefined. WMP only at 100k
At least to see if can get the gyro data working.

thanks, not what is happening is very rare, the fact is that I'm back to 1.8 and everything perfect.

Tifani · Post by **Tifani** » Sat Nov 12, 2011 5:44 pm

Hi Alex !
Uploaded New1.9
With NK (level) on I have spikes like before.
Can NOT arm with stick.
Back to 1.8p2
All normal (OK)
Thanks for Your work
Pictures @ http://www.rcgroups.com/forums/showpost.php?p=19855263&postcount=21679
Regards
Tom
P.S
I will try to set up new board with new set of sensors.
P.S 2
How to attach pictures to post

shikra · Post by **shikra** » Sat Nov 12, 2011 8:50 pm

mr.rc-cam wrote:If you use the Level Trim feature to adjust the attitude offset during Stable mode does it fix the problem? If that feature does not help then something very odd is going on. I'm not saying it is the final fix for you, but knowing it successfully corrects the offset may be helpful information.

Oh yes for sure I should have added that. It takes quite a lot of trimming, but absoloutely corrects it.

I just can't figure out why the low value of Pand I autolevel would affect the tilt angle for a calibrated acc. And only in roll axis.

I'm convinced its and indicator of something that isn't quite right. Especially as I don't see this with 1.5 and the Tri flies like a dream in all other respects.

1.9 is great for me so far, but not had much air time. I see same effect with 1.8 too so don't want this to detract from all positive comments. Actually going back to 1.5 makes you realise how mature this is becoming!

Nice one Alex!

Alexinparis · Post by **Alexinparis** » Sat Nov 12, 2011 9:25 pm

shikra wrote:Recap:
wmp/nk setup latest code downloaded.
Arms on sticks OK now..

With Autolevel I of 0.05, after calibrating, it is approx level in hover. And the GUI shows level
With Autolevel I of 0.006 it "levels at an angle of approx 20-25 degrees. And the GUI shows that angle.
BUT - only the roll is at an angle. The Pitch is fine....

Tried with without #Trusted... no change - but it is WMP/NK
Tried with the amended code pointed out by cob - accth to accsmooth. No change

Extra info...
My Autolevel P is low at 3. I like this because it is very flyable and I don't need asharp return to level. Dafault is way to strong on mine.
If I raise P to default, there is still a tilt, but it is only little.
It seems to be worse as throttle increase.

So try to replicate with P and I autolevel very low...
The Tri tilts at quite an angle when it thinks it is level. Here is screenshot of what it looks like when it is in level hover after calibration on level. Notice the roll angle....

Maybe its right, but seems odd to me the the gui is correct.
Am sure its indicator or somewhere the code can be improved a little.

adult image hosting

Hi,
According to your graph, there is a gyro ROLL of 4.
Is it an average value you can see when the multi is not moving ?
If yes, it could explain a constant angle, especially for low PID LEVEL

shikra · Post by **shikra** » Sat Nov 12, 2011 10:50 pm

gyros show a perfect 0 when no throttle.

There is a bit of fluctuation on acc.
There is no acc fluctation in 1.5 - shows perfect zeros - and the issue doesn't show with 1.5

Give it a try to see if you see the same. I have same with 2 controllers

copterrichie · Post by **copterrichie** » Sat Nov 12, 2011 11:10 pm

I just made a discovery, we really need to take a good look at which Gyros and Accelerometers report their data as 2's Complement. I had a major problem getting my MMA7455 accelerometers to work with 1.9 that worked flawlessly in 1.7. I changed the following and now my MMA7455 is working great in 1.9 however I have not done any flight testing.

Code: Select all

int8_t rawADC[6];
.
.
.

int8_t i2c_readAck() {
.
.
.

int8_t i2c_readNak(void) {
.
.
.

copterrichie · Post by **copterrichie** » Sat Nov 12, 2011 11:55 pm

P.S. I used the following and in the GUI, everything appears to be rock solid.

Code: Select all

/* This option is here if you want to use the old level code from the verison 1.7
   It's just to have some feedback. This will be removed in the future */
#define STAB_OLD_17

Being the MMA7455 when configured at 2G has an 8 bit resolution, I made the following change and restored the above variables.

Code: Select all

ACC_ORIENTATION (   int8_t(rawADC[2]) ,
                     int8_t(rawADC[0]) ,
                     int8_t(rawADC[4]) );
  ACC_Common();

spagoziak · Post by **spagoziak** » Sun Nov 13, 2011 1:55 am

I upgraded from 1.8p2 to 1.9 and found that my gyro lines in the GUI all remained at 0 no matter what was done to the copter. The acc lines/values showed proper operation. The LED on the ard was lit solid green--nothing would alter its behavior, so arming wasn't possible. However, the GUI would allow me to change and write PID values, so I suspect the ard wasn't hung. Resetting the MWC didn't change it, either.

Once I pushed 1.8p2 back to the chip all was well and I was in the air moments later.

Do I have to uncomment the WMP now, in 1.9?

Hardware:
ProMini
WMP
BMA020
BMP025

mr.rc-cam · Post by **mr.rc-cam** » Sun Nov 13, 2011 4:12 am

Do I have to uncomment the WMP now, in 1.9?

Same as before, the WMP will be automatically chosen if you have not defined the other two gyros choices (ITG3200 or L3G4200D) in config.h.

Things to do/check (all things you probably already know, but it is good to check them all again).
1. Visit config.h to see if all the #define choices are correct. Look again, maybe you missed something in the last review.
2. Set I2C_SPEED to 100KHz. Once things are working you can try 400KHz if you want to use it instead.
3. Use the LATEST (a few hours old) V1.9. In the GUI confirm that debug2 value remains zero. If >0 then I2C communication is in trouble.

There is a chance you do not have the latest V1.9, or perhaps the new I2C Stop method (that was introduced in yesterday's V1.9) in sensors.pde is involved in your problem. To help Alex track the problem it might be best to post the time/date of the V1.9 zip file set you are using.

spagoziak · Post by **spagoziak** » Sun Nov 13, 2011 6:30 am

mr.rc-cam wrote:
Do I have to uncomment the WMP now, in 1.9?

Same as before, the WMP will be automatically chosen if you have not defined the other two gyros choices (ITG3200 or L3G4200D) in config.h.

Things to do/check (all things you probably already know, but it is good to check them all again).
1. Visit config.h to see if all the #define choices are correct. Look again, maybe you missed something in the last review.
2. Set I2C_SPEED to 100KHz. Once things are working you can try 400KHz if you want to use it instead.
3. Use the LATEST (a few hours old) V1.9. In the GUI confirm that debug2 value remains zero. If >0 then I2C communication is in trouble.

There is a chance you do not have the latest V1.9, or perhaps the new I2C Stop method (that was introduced in yesterday's V1.9) in sensors.pde is involved in your problem. To help Alex track the problem it might be best to post the time/date of the V1.9 zip file set you are using.

Great advice! 1 & 2 had already been checked, so here's hoping 3 is the winner

I downloaded my 1.9 from this link, and all of the dates reflect when the file was created on my computer; today 11/12 at ~11am CST.

Here's a snip of I2C device defines from my 1.9 config.h, too:

Code: Select all

/* if you use a specific sensor board:
   please submit any correction to this list.
     Note from Alex: I only own some boards
                     for other boards, I'm not sure, the info was gathered via rc forums, be cautious */
//#define FFIMUv1         // first 9DOF+baro board from Jussi, with HMC5843                   <- confirmed by Alex
//#define FFIMUv2         // second version of 9DOF+baro board from Jussi, with HMC5883       <- confirmed by Alex
//#define FREEIMUv1       // v0.1 & v0.2 & v0.3 version of 9DOF board from Fabio
//#define FREEIMUv03      // FreeIMU v0.3 and v0.3.1
//#define FREEIMUv035     // FreeIMU v0.3.5 no baro
//#define FREEIMUv035_MS  // FreeIMU v0.3.5_MS                                                <- confirmed by Alex
//#define FREEIMUv035_BMP // FreeIMU v0.3.5_BMP
//#define PIPO            // 9DOF board from erazz
//#define QUADRINO        // full FC board 9DOF+baro board from witespy  with BMP085 baro     <- confirmed by Alex
//#define QUADRINO_ZOOM   // full FC board 9DOF+baro board from witespy  second edition       <- confirmed by Alex
//#define ALLINONE        // full FC board or standalone 9DOF+baro board from CSG_EU
//#define AEROQUADSHIELDv2
//#define ATAVRSBIN1      // Atmel 9DOF (Contribution by EOSBandi). requires 3.3V power.
//#define SIRIUS          // Sirius Navigator IMU                                             <- confirmed by Alex
//#define SIRIUS600       // Sirius Navigator IMU  using the WMP for the gyro
//#define MINIWII         // Jussi's MiniWii Flight Controller
//#define CITRUSv1_0      // CITRUSv1 from qcrc.ca
//#define DROTEK_IMU10DOF


//if you use independent sensors
//leave it commented it you already checked a specific board above
/* I2C gyroscope */
//#define ITG3200
//#define L3G4200D

/* I2C accelerometer */
//#define ADXL345
#define BMA020
//#define BMA180
//#define NUNCHACK  // if you want to use the nunckuk as a standalone I2C ACC without WMP
//#define LIS3LV02
//#define LSM303DLx_ACC

/* I2C barometer */
#define BMP085
//#define MS561101BA

/* I2C magnetometer */
//#define HMC5843
//#define HMC5883
//#define AK8975

/* ADC accelerometer */ // for 5DOF from sparkfun, uses analog PIN A1/A2/A3
//#define ADCACC

Dehas · Post by **Dehas** » Sun Nov 13, 2011 11:52 am

I tried multiwii version 1.9 (the latest version)
Can not fly properly.
- Very violent upheavals.
- Changes in violent
Even sitting in the coefficients I use 1.8p2 ...
Then lowering the P.
In the GUI debug 2 is a 5000.

I return to the 1.8 patch2

personal Board
with WMP and MMA7455

jalves · Post by **jalves** » Sun Nov 13, 2011 12:27 pm

Something is wrong with your hardware.

I am using latest 1.9 fw with wmp+nk and so far it is MUCH more stable and flyable than 1.8patch2 (and debug2=0).

Well done Alex and folks!

Th0rsten · Post by **Th0rsten** » Sun Nov 13, 2011 1:09 pm

Hello!

I'm just coming back from flying latest 1.9
First takeoff and it's really nice to fly. Absolutely stable in ACC-mode (WII+NC).
Then I accidentally hit the ground (not very hard) and continued flying.
The quad began to drift away to one side. Had to compensate it with the sticks but it was getting worse.
Landed an cut the power.
Attached power again and it flew very stable like the first time I took off.

IMHO the is something remembering hard crushes to the copter.

Thorsten

KeesvR · Post by **KeesvR** » Sun Nov 13, 2011 1:54 pm

Its always better when you crash or land hard to calibrate the sensors again.

Stalk · Post by **Stalk** » Sun Nov 13, 2011 3:22 pm

Hi all,
In version 1.9 I have no response from WMP (original) in the GUI. BMA020 shows movement. With ITG3200 BMA020 the response from both.
In previous versions, everything was OK.
Thank you for your help.

spagoziak · Post by **spagoziak** » Sun Nov 13, 2011 4:39 pm

Stalk wrote:Hi all,
In version 1.9 I have no response from WMP (original) in the GUI. BMA020 shows movement. With ITG3200 BMA020 the response from both.
In previous versions, everything was OK.
Thank you for your help.

I have the exact same issue! Not sure what to do about it except return to 1.8p2

mr.rc-cam · Post by **mr.rc-cam** » Sun Nov 13, 2011 6:55 pm

I downloaded my 1.9 from this link, and all of the dates reflect when the file was created on my computer; today 11/12 at ~11am CST.

That time stamp reflects latest files to date. Perhaps your WMP does not like the new I2C stop code in sensors.pde. More importantly, in prior releases there was a check to see if the WMP had stopped responding. If it had locked up a hard power reset was performed to wake it back up. That is no longer done because the new I2C stop code was suppose to cure the WMP lockups.

In your new V1.9 release the debug2 window now shows the I2C error count. You haven't said if yours has any errors being reported. What number do you see?

I tried multiwii version 1.9 (the latest version)
Can not fly properly.
In the GUI debug 2 is a 5000.

Debug2 is reporting that you have significant I2C problems. If the V1.8 - V1.8p2 code worked for you then use it with the I2C test code discussed in the following link to see if it has hidden I2C problems too:
viewtopic.php?f=8&t=884

In version 1.9 I have no response from WMP (original) in the GUI. BMA020 shows movement. With ITG3200 BMA020 the response from both.

See comments above.

KeesvR · Post by **KeesvR** » Sun Nov 13, 2011 7:03 pm

This latest version is very good, excellent work Alex.
The one before i had allot of I2C counts, now it stays at zero.

Stalk · Post by **Stalk** » Sun Nov 13, 2011 7:23 pm

In your new V1.9 release the debug2 window now shows the I2C error count. You haven't said if yours has any errors being reported. What number do you see?

The number is constantly and rapidly increasing with WMP. With ITG3200 is 0.

mgros · Post by **mgros** » Sun Nov 13, 2011 8:47 pm

Stalk wrote:
In your new V1.9 release the debug2 window now shows the I2C error count. You haven't said if yours has any errors being reported. What number do you see?

The number is constantly and rapidly increasing with WMP. With ITG3200 is 0.

Check if you are working with 400 KHZ ot 100 KHz I2c frecuency in config.h try it using 100 Khz.

Stalk · Post by **Stalk** » Sun Nov 13, 2011 9:11 pm

I work at 100kHz with WMP

mgros · Post by **mgros** » Mon Nov 14, 2011 12:10 am

Stalk wrote:I work at 100kHz with WMP

Try changing Pull-ups configuration.