MultiWii_dev_20111008 Testing

[jevermeister]

Ok Alex,

I flew the new version twive now:
1. Test indoor: I noticed a constant drift to front right. After I did a lot f calibration via stick input it was back after a few moments. Still front right. It might be the ground effect though.
2. Test outdoor (sorry very windy conditions right now) I think the same drift I noticed indoors. :-/

Another finding: If I tilt about 30° and more the compass seems to have problems, I do not know if it a problem of my reversed compass or code it corrects the heading by yawing quite a bit whyle I tilt.

[PatrikE]

I tested V1107.
All tendens to flipp id gone now..
Flies nearly perfect.

Loaded V1108.
The gyro is less sensitive. Reqire much higher PIDvalues.
No more daylight.
No more testing to day.

[kataventos]

Hi to all,
I´m testing this dev and found that the accumulative drift is gone, the indecision on leveling still there, odd is that on gui with the acc on or off, I get some strange readings, some peaks on the lines (acc values jumping around) with the copter stactic on the table.

My setup is Paris V4 with Original´s WMP and NK, 18A Hobbywing Fly Fun (Pentium) ESC´s
Can some tell what´s hapenning or someone have the same "bug"?

Cheers,
Henrique

[dramida]

I have an octocopter with atmega 1280, ADXL345, ITG3205, BMP085, GPS Mediatek, HMC5883.
I've uploaded 20011008 dev version and all works fine inside the room.
I've done some tests in GUI with GPS functions using remzibi OSD's gps emulator software and the heading and distance are working well. Today i'll try OpenLRS transparent serial Link between GUI and the Octocopter.

When the rain stops, i'll fly it outside and report back, hopefully with a video.

[dramida]

Video:

http://www.youtube.com/watch?v=7BUfaCCdxtg


The level mode works fine on octocopter flat X but i saw some isues:

YAW authority is not good, it tends to yaw steadily in a direction and when applying corrections, it jumps.
On full right yaw, the rear right engine acts wired. Analysis of the octo flat X code required.

[dramida]

I made a short test with stunning results.

The motors are mixed in octo flatX config very primitively.

Example:

Let's suppose we connect only the rear -middle- right engine of an octo flat X configuration. When moving the roll/pitch stick from right-down to right-up position, the engine doesn't change the thrust (theoretically the thrust would vary proportionally with the cosine of the angle between engine position and stick orientation).

Obviously the mixing table can be improved for octo. The benefits would be a better stability and better redundancy on engine failure. Don't budget timing on the wrong end of the algorithm.

[Alexinparis]

I made a short test with stunning results.

The motors are mixed in octo flatX config very primitively.

Example:

Let's suppose we connect only the rear -middle- right engine of an octo flat X configuration. When moving the roll/pitch stick from right-down to right-up position, the engine doesn't change the thrust (theoretically the thrust would vary proportionally with the cosine of the angle between engine position and stick orientation).

Obviously the mixing table can be improved for octo. The benefits would be a better stability and better redundancy on engine failure. Don't budget timing on the wrong end of the algorithm.

Hi,
The only code to understand is:

Code: Select all

  #ifdef OCTOFLATX
    motor[0] = PIDMIX(+1  ,-1/2,+1); //MIDFRONT_L
    motor[1] = PIDMIX(-1/2,-1  ,+1); //FRONT_R
    motor[2] = PIDMIX(-1  ,+1/2,+1); //MIDREAR_R
    motor[3] = PIDMIX(+1/2,+1  ,+1); //REAR_L
    motor[4] = PIDMIX(+1/2,-1  ,-1); //FRONT_L
    motor[5] = PIDMIX(-1  ,-1/2,-1); //MIDFRONT_R
    motor[6] = PIDMIX(-1/2,+1  ,-1); //REAR_R
    motor[7] = PIDMIX(+1  ,+1/2,-1); //MIDREAR_L 
  #endif

where you can tune precisely the motor weight: PIDMIX(ROLL,PITCH,YAW)

[Alexinparis]

So, still one question about the LEVEL mode:
in this version:
- is there some remaining drift that can been seen in the previous 1.8 patch 2 ?
- how does it compare to 1.7 LEVEL mode ? (which can still be activated vie a #define STAB_OLD_17)

[kataventos]

So, still one question about the LEVEL mode:
in this version:
- is there some remaining drift that can been seen in the previous 1.8 patch 2 ?
- how does it compare to 1.7 LEVEL mode ? (which can still be activated vie a #define STAB_OLD_17)

Hi Alex, I will do precision tests when I receive new propellers, I want to give the best feedback on this, and new precisely balanced props is the most important for accuracy, think that on tuesday they are on my hands.

Can you please answer to my last post about the acc values on gui? this does not happen on 1.8 P2

Cheers,
Henrique

[dramida]

http://www.youtube.com/watch?v=wEHKnFBhXHw

Test between 1.8patch2 tricopter and octocopter dev 20111008 mwc software.
Tricopter tends to drift, the octocopter responds well. Tomorow i'll load v1.7 MWC soft and make some comparison.

[dramida]

I've made a test with my tricopter with 20111008 dev MWC software. Without changing any PID, i added this line:

Code: Select all

#define STAB_OLD_17

The flight chacarteristics were the same.

I used the absolute default PID with P roll and P pitch increased to 6.5 instead of 4

I used itg3205 and nunchuk as accelerometer on a 328 platform.

[mahowik]

So, still one question about the LEVEL mode:
in this version:
- is there some remaining drift that can been seen in the previous 1.8 patch 2 ?
- how does it compare to 1.7 LEVEL mode ? (which can still be activated vie a #define STAB_OLD_17)

Hi all,

I have done couple of tests on this weekends with patch2 and STAB_OLD_17.
And it seems stab old 1.7 more stable in any case Where with patch2 my quadro drifts in spite of trims and any calibrations. I also tried to apply advanced LPF filter to ACC to make it possible to know the cut frequency:
viewtopic.php?f=8&t=671&start=60#p4349
and played with 5-20Hz cut frequency. Also I tried to use the filtered gyroData inside of the IMU calculation instead of "clean" gyroADC values. Nothing helps to avoid the drift. I think the drift goes from ACC because when i tried to decrease the GYR_CMPF_FACTOR it has more drifts...
Also i have looked through the MultiWii_dev_20111008 and it seems there are no any principal changaes in IMU and PID regulator in diff with patch2. So Alex why do you think that drift issue will be fixed here?

my config: 3205 + bma020

thx-
Alex

[mahowik]

I've made a test with my tricopter with 20111008 dev MWC software. Without changing any PID, i added this line:

Code: Select all

#define STAB_OLD_17

The flight chacarteristics were the same.

I used the absolute default PID with P roll and P pitch increased to 6.5 instead of 4

I used itg3205 and nunchuk as accelerometer on a 328 platform.

Sorry to ask, it means that drift is still there or it's stable?
Have you done this test with your tricopter what was not stable (drifted) with patch2?

[KeesvR]

I have tested the Dev20111008 only inside, because the wind outside is to high the last days.
I'm very pleased with the latest dev version because my drift problem with patch2 is gone.
I've tested it with a T-copter with:
WM+ original
BMA020
HMC5883
BMP085

I was testing a Quad from my brother in law with WM+ and Nunchuck both originals.
This one is flying great with patch2, no ACC drift problem.
But this one has not so much vibrations as mine.

[mahowik]

Reading this thread I see the rule. That guys that have bma020, has the drift issue...
Probably it's related to not "clear" bma020 values. It should has symmetric values for all axis.
Try to do a simple test: rotate and write the max values for all axis. For bma020 it should be -255/+255 for all axis.

My values after the ACC calibration:
ROLL: -250/+255
PITCH: -242/+260
Z: -290/+255

P.s. I supposed before that bma020 more clean ACC. Probably the reason is here...

[Alexinparis]

Also i have looked through the MultiWii_dev_20111008 and it seems there are no any principal changaes in IMU and PID regulator in diff with patch2. So Alex why do you think that drift issue will be fixed here?

Because the way the ACC vector is rotated is different in this version.

[Alexinparis]

Can you please answer to my last post about the acc values on gui? this does not happen on 1.8 P2

I really don't know.
The cycle time is a little bit optimized (around 10% less).
That might explain the new spikes you see because this change can impact the delay between 2 sensor pooling.

[avazdo]

Hi. Today I was trying this version and I watched a bad behavior about barometer datas. It worked jumping.
I think I found the bug. BaroAlt and BaroHold variables have been declared integers instead floats like 1.8p2 version. After change, it worked smoother.
I will continue trying this version and tuning PID becouse the same PID's do not work fine for my quad. I'll also try stable drift becouse I think I have a big temperature drift accelerometer problem.

Best regards

[mahowik]

Because the way the ACC vector is rotated is different in this version.

Oh sorry. I thought that is just code movement to rotateV() function...

Do you know what is the cut frequency for this LPF with e.g. cycle time 2300?

Code: Select all

accSmooth[axis] =(accSmooth[axis]*7+accADC[axis]+4)>>3;

Because for example bma020 has 25Hz as low, but it's good to have 8-10Hz as max for ACC to reduce the noise.

Does it make sense to use the little bit advanced LPF to know the cut frequency?

Code: Select all

/* Set the Low Pass Filter cut frequency for derivative calculation. */
/* It's discrete LPF, cuts out the high frequency noise that can drive the controller crazy and produce a drift. */
/* Pls. see http://en.wikipedia.org/wiki/Low-pass_filter. */
/* Decreasing the cut frequency would reduce ACC noise (visible in GUI), but would increase ACC lag time */
/* Preferably it should be less 25 Hz because anything over that is probably noise for ACC. */
#define ACC_LPF_CUT_FREQ 10

...........................

  uint16_t currentT  = micros();
  uint16_t dt = currentT - previousT; 
  previousT = currentT;

...........................

      /// accurate version: with float calculation
      /*
        float delta_time   = (float)dt / (1000.0 * 1000.0); // get time in seconds
        float RC = 1 / (2 * M_PI * ACC_LPF_CUT_FREQ);
        accSmooth[axis] = accSmooth[axis] + (delta_time / (RC + delta_time)) * (accADC[axis] - accSmooth[axis]);
      */

      /// simplified version: add more performance in diff with accurate version (i.e. without float calculation)
      /// RC(IN_MICROSECONDS) = 1000000 * / (2 * M_PI * ACC_LPF_CUT_FREQ) = 159154.94309189533576888378278968 / ACC_LPF_CUT_FREQ ~= 159155 / ACC_LPF_CUT_FREQ
      accSmooth[axis] = accSmooth[axis] + ((int32_t)dt * (accADC[axis] - accSmooth[axis])) / ((159155 / ACC_LPF_CUT_FREQ) + dt);

Here is more details: viewtopic.php?f=8&t=671&start=60#p4349

[mahowik]

I have tested new IMU on MultiWii_dev_20111008.
It has the same LEVEL drift issue (

My PIDs:
- acro 5.0-0.030-40 (it helps for smooth flying like a submarine)
- level 7.0-(0.000-0.045)

So as for now it works only with STAB_OLD_17 (1.7 IMU) option.

Probably I should try to reduce the vibrations for my ACC?!

[flyman777]

Hi All,

I just tested DEV_20111008 with FCWii board + WM+ genuine + BMA180.

I changed ACC_LPF_FACTOR to 64 and GYR_CMPF_FACTOR to 330.0f.

I always take the modif in IMU.pde:

...
#if defined(ACC_LPF_FACTOR)
accSmooth[axis] = (accSmooth[axis] * (ACC_LPF_FACTOR - 1) + accADC[axis]) / ACC_LPF_FACTOR; // LPF for ACC values ---> uncommented
//accSmooth[axis] =(accSmooth[axis]*7+accADC[axis]+4)>>3; //----> commented

And it is the first time that my tri flies in Stable MODE without drifts and/or flips to death.
I made 2 flights with this config with no problems. The control was good and no overshooting ( Plevel=8, I=0).
When I'm banking the tri in roll or pitch and release the sticks, it will resume instantanely his level.
The trace of the ACC in the GUI is a lot smoother.
By the way, increasing ACC_LPF_FACTOR to 128 will bring the ACC to oscillate (sawtooth on the GUI) !!

For the moment I wil remain this config.

cheers
Claude
Flyman777

[mahowik]

Hi All,

I just tested DEV_20111008 with FCWii board + WM+ genuine + BMA180.

I changed ACC_LPF_FACTOR to 64 and GYR_CMPF_FACTOR to 330.0f.

I always take the modif in IMU.pde:

...
#if defined(ACC_LPF_FACTOR)
accSmooth[axis] = (accSmooth[axis] * (ACC_LPF_FACTOR - 1) + accADC[axis]) / ACC_LPF_FACTOR; // LPF for ACC values ---> uncommented
//accSmooth[axis] =(accSmooth[axis]*7+accADC[axis]+4)>>3; //----> commented

And it is the first time that my tri flies in Stable MODE without drifts and/or flips to death.
I made 2 flights with this config with no problems. The control was good and no overshooting ( Plevel=8, I=0).
When I'm banking the tri in roll or pitch and release the sticks, it will resume instantanely his level.
The trace of the ACC in the GUI is a lot smoother.
By the way, increasing ACC_LPF_FACTOR to 128 will bring the ACC to oscillate (sawtooth on the GUI) !!

For the moment I wil remain this config.

cheers
Claude
Flyman777

Hi Flyman777!!!

Thanks for the post. I will also try to increase the ACC_LPF_FACTOR...

Also you can't use the 128 value because the there is overflow occured...
You need to use the int32_t if you want to try so big ACC_LPF_FACTOR...

Code: Select all

accSmooth[axis] = ((int32_t)accSmooth[axis] * (ACC_LPF_FACTOR - 1) + accADC[axis]) / ACC_LPF_FACTOR; // LPF for ACC values

[kataventos]

Hi to all,

I am testing this dev for a few days after my new propellers arrived. After fly with P1 and P2 this dev is better regarding the accumulative drif, it still have but after some more time. At this time I was wondering if my NK was faulty, I´ve got two flips to death (luckly without any consequences), activated the 1.7 stab and found that everything was the same. I went home and found my ACC values were 0/0/200 and upside down 0/0/240, I read here that they must be the same, is that true? After this I thought that if no one had problems with the 1.7 code why not try it? Again found that 1.7 flips to death to if I push it to hard!!No accumulative drift though. (does this means a ACC problem?) Today I saw Claude (flyman777) changes to IMU and tryed them exactly like he mencioned.

My config:

-Quad X
-Original WMP & Nunchuk on a Paris V4 and Hobby wing Fly Fun (Pentium) 18A ESC´s
-Original PID´s for everything less Level-----P=8 / I=0.

I found that even if my config differs, (because Claude have a BMA180), it flys in stable (inside for today) like never and I can assure that no more flips to death! Tomorrow I will fly outside see how it behaves and do a final update. Until the next dev I think that I´m going to maintain this config.

Cheers,
Henrique

PS: my Acc values on power up are 0/0/140 and up side down 0/0/220 after a few turns and about 7 min it is 0/0/170 and up side down 0/0/190 and in a few seconds it jumps to 140 and usdown 190 and this gets stable in this values, is this ok? should I make some change to ACC 1G= ?

[mahowik]

Again found that 1.7 flips to death to if I push it to hard!!No accumulative drift though.

Do you mean that copter tries to turn over/flip when you inclinate the roll/pitch sticks to the max values?
If yes I found a workaround to fix this:

Go to the MultiWii_dev_20111008.pde and change this line

Code: Select all

errorAngle = constrain(2*rcCommand[axis],-700,+700) - angle[axis] + accTrim[axis]; //16 bits is ok here

with this one:

Code: Select all

errorAngle = constrain(2*rcCommand[axis],-250,+250) - angle[axis] + accTrim[axis]; //16 bits is ok here

where 700 is angle*10, i.e. 70 degrees... I have decreased it to 250 in for my config and now it tries to keep inclination no more than 25 degrees...

[kataventos]

Hi Mahowik,

Thanks, yes, that and when I fly on windy day the copter sometimes tends to hovershoot to the oposite direction, I will try your suggestion on 1.7 code just to see if that will avoid the "flips to death" , because I think that the changes that Claude suggested are quite OK for my quad without more coding, this flips stoped with only this changes. Tomorrow I will fly outdoor and update.

Regarding my ACC questions, do you know if my readings are normal, does ACC have a problem?

Cheers,
Henrique

[mahowik]

Regarding my ACC questions, do you know if my readings are normal, does ACC have a problem?

I think asymmetric values it's normal for ACC. See the "Accelerometer test for MultiWii.pdf" from http://www.rcgroups.com/forums/attachme ... id=3884788

[marbalon]

Hi,
I also changed this values to
ACC_LPF_FACTOR 32 and GYR_CMPF_FACTOR to 320.0f
Before thus I have a problem with oscilations but now it is almost perfect. I can increase P for level so it is more responsive in fly. My acc is adxl345.

Thanks for this suggestion.
Regards,
Marcin.

[kataventos]

Hi to all,


still the same... Fliping out in stable... I will forget this until I by a new ACC because I dont know what to do anymore, at this time probably I´m the only one with this problem.
I think that GUI is saying that the acc is not ok, when I uploaded this dev with no changes to the IMU was having spikes from the acc lines, Alex told me that probably had to do with the cycle time that was optimized in 10% less, but with all the problems I´m having, I think that my Nunchuk was faulty in the first moment. I tryed 1.8P1, P2, this dev, 1.7 and they all flip my copter in some moment, sooner or later depending on the code I use / type of fligh.

Cheers,
Henrique

*Mahowik* I decreased the error angle to 250, it keeps a good 25º angle for stable, but do not resolve my problem.

[Noctaro]

hey,
i uploaded the new dev to my quadrocopter.
I tested it in flight and have to say that acro mode seemed to be more unstable. Maybe it was just based on the windgusts these days.
Whats about the ACC trim, do we need now less clicks to have influence on level?
At the moment i am note sure if it was the accdrift or the trim that caused my quad to drift in stable mode. Or maybe strange readings of gyro. Can´t say right now. I will keep on testing and add an onboard video here. Maybe that helps to get an impression of my problem.

greetz,
Noc

Update:
Did some flight tests and got new results. I will upload a video later night.
I got drift in stable mode since first flights. (V1.7)

If i start a flight.
Take off, trim acro mode to keep angle.
Switch on level mode. (A drift to right front is usual)

Trim around 13 clicks to the left.
Around 5 backwards.

Take off! There we go, a stable copter.
But wait, it starts to drift right again.

Trim again around 5 clicks left.

...a stable copter.
(10 secs later)
It starts to drift right again.

so i can do this all flight long.

since dev_20111008 i am gettin a drift also in acro mode...

or may this be based on temperature drift of gyro? is there any?

since its getting cold these days.
I used to power up at around 22°C and took off at around 7°C

btw. i did not touch GYR or ACC rate in this version, using standard PID settings.

greetz
Noc

[Lalitha]

Hi All,

Can someone tell me how much delay is introduced in the accelerometer data when we change the ACC_LPF_FACTOR value?

Regards
Lalitha