MultiWii 2.0 bug report

Joachim08 · Post by **Joachim08** » Mon Apr 16, 2012 5:10 pm

Ok once more about tbe:

in the German FPV-Forum there is a 7-page thread about this issue:

http://fpv-community.de/showthread.php? ... table-Mode

Maybe google can help you with translation.

The last report is as follows:

User rc-action_de has three copter, all more or less unflyable in acc mode with 2.0:

"TBE is the same with me at 3 Coptern.

Crius the Quadro board
Paris 4.0 with 6 DOF IMU Robo Bee in the Quadro
Mega Flyduino with Sirius in the Navigator Hexacopter

All boards previously had the 1.9 software and were flashed on the 2.0.

All copter fly (without ACC) are extremely stable, but with almost unflyable ACC.

The hexa example flew with the 1.9 and very high P-values are very stable...."

How can we help to identify the problem ? It takes me wonder that nobody else reports this problem as up to now quite a
few people are reporting tbe in the fpv-forum....

regards

Joachim

matbogdan · Post by **matbogdan** » Tue Apr 17, 2012 6:20 am

Yesterday i tried the stable mode fly with MONGOSE board. A very bad experience. The copter do not want to stay level no mater of the acc trim, pid level adjusts.Sometimes it goes to the left with accumulative drift or sometimes go to front, than right than left than .... I am more and more disappointed by the multiwii way of doing things.
I think is time to try something else ... maybe fuzzy logic ? Maybe it will be easier to understand and adjust the parameters than PID's.
My opinion is that we are interpreting in a wrong way the acc sensor data.

mlebret · Post by **mlebret** » Tue Apr 17, 2012 10:07 am

To contribute with Joachim Stable mode (Acc) problems.

I'm using MultiWii v2 on two boards.

First on my Vtail small quad (700g) Paris v4, Sirius
Second on my Vtail medium quad (1050g), Paris V4, FreeIMU 4.3

Here is a video of the small one in Stable (Acc) flight with Z hold/Heading hold.

There are no glitches with my setup and PID settings.

Marc

http://vimeo.com/40504035

Joachim08 · Post by **Joachim08** » Tue Apr 17, 2012 4:01 pm

Marc,

i cant see how your video contributes to my problem. It shows a Multiwiicopter which is flying wihout
any glitches in stable mode... I think most of the users have have this sort of behaviour...

In the meantime I know several people with the toilet bowl effect problem and as our copter does not
fly stable we cannot shot a video without risking a crash..

mlebret · Post by **mlebret** » Tue Apr 17, 2012 5:50 pm

Hallo Joachim,

My video is to show it can work.

Default pid settings are for a light quad. With heavier configuration I have around 50% more P (Acro and Level). I also have lower I for Level (0.010). It helped a lot with 1.9 version and I stick to it (no bad drift).

Toilet bowl tell me "increase P".

I experienced diagonal oscillation: it was due to slipping shaft. I also had some free magnets after a crash. Not good for a nice flight.

Enjoy your quad,

Marc

warthox · Post by **warthox** » Tue Apr 17, 2012 6:43 pm

jevermeister wrote:Okay, I don't know if it is a bug with 2.0 because I flew some lipos without this problem:

My copter stutters and drops a few centimeters and banks to left to right and front and back randomly and this lead to a crash two times.

I was lucky that I was fas flying low at the first crash in FVP.

Here is a video ( do not laugh because of the missing front legs, they got killed in the first crash :-/)

All these small glitches are not me...
http://youtu.be/6nFd-ZBJeNE

Is this a Software problem or do I have some loose wires? I swapped the batteries of my TX but this did not help, even a new LIPO does not help...

Nils

ps.: I will post this into RCgroups too, so please do not object.

the up and down looks like the behavior when baro is activated.
which imu/sensors do u use?

jevermeister · Post by **jevermeister** » Tue Apr 17, 2012 6:48 pm

warthox wrote:
jevermeister wrote:Okay, I don't know if it is a bug with 2.0 because I flew some lipos without this problem:

My copter stutters and drops a few centimeters and banks to left to right and front and back randomly and this lead to a crash two times.

I was lucky that I was fas flying low at the first crash in FVP.

Here is a video ( do not laugh because of the missing front legs, they got killed in the first crash :-/)

All these small glitches are not me...
http://youtu.be/6nFd-ZBJeNE

Is this a Software problem or do I have some loose wires? I swapped the batteries of my TX but this did not help, even a new LIPO does not help...

Nils

ps.: I will post this into RCgroups too, so please do not object.

the up and down looks like the behavior when baro is activated.
which imu/sensors do u use?

Hi Warthox,
Baro is deactivated here, bigger problem is the sudden tilt forwad ;-)

I just flew a lipo a few moments ago but have no problems. Very strange, I think I have some loose parts here.

I have no IMU I fly single Bobs: WMP, BMA020, BMP085, HMC5883L.
Never had this behavior before :-/

Thank you for looking into my issue ;-)

Nils

warthox · Post by **warthox** » Tue Apr 17, 2012 6:55 pm

i think i found another bug.

i built 3 quads. all with promini and mpu6050 from flyduino.
all with totally different setup.
flydumini + tiger 10A + tiger 1306 // dji clone frame + suppo30A + mt2212 980kv // grasshopper frame + hobbywing 10A + mt2208 1100kv

all have the same behavior. they dont take throttle directly, very laggy, dont fly smooth.
its like with a copter with an itg3200 with no lpf and much vibrations.

i also swapped the board to another frame which i fly a long time without problem. same behavior here.

so i tried the mpu6050 lpf down to 20hz but no difference.
i also tried different fw versions from 2.0 pre over 2.0 and latest the 2.0 dev.

the dji clone quad flies smooth with a mwc board with itg3200 gyro and the grasshopper quad also flies good with an ff board with ported mwc fw.

it seems that the lpf for the mpu6050 has not a bit of effect.

Alexinparis · Post by **Alexinparis** » Tue Apr 17, 2012 9:08 pm

Joachim08 wrote:Ok once more about tbe:

in the German FPV-Forum there is a 7-page thread about this issue:

http://fpv-community.de/showthread.php? ... table-Mode

Maybe google can help you with translation.

The last report is as follows:

User rc-action_de has three copter, all more or less unflyable in acc mode with 2.0:

"TBE is the same with me at 3 Coptern.

Crius the Quadro board
Paris 4.0 with 6 DOF IMU Robo Bee in the Quadro
Mega Flyduino with Sirius in the Navigator Hexacopter

All boards previously had the 1.9 software and were flashed on the 2.0.

All copter fly (without ACC) are extremely stable, but with almost unflyable ACC.

The hexa example flew with the 1.9 and very high P-values are very stable...."

How can we help to identify the problem ? It takes me wonder that nobody else reports this problem as up to now quite a
few people are reporting tbe in the fpv-forum....

regards

Joachim

Hi,
can you try to remove this line in multiwii.ino (from 2.0):

Code: Select all

      PTerm = constrain(PTerm,-D8[PIDLEVEL]*5,+D8[PIDLEVEL]*5);

With this, you should have exactly the same behavior of 1.9 stable mode.

can you ensure also that when the multi is reverted, Z ACC is negative and equal in absolute to the value it has when the multi is flat and not reverted ?

Alexinparis · Post by **Alexinparis** » Tue Apr 17, 2012 9:09 pm

warthox wrote:it seems that the lpf for the mpu6050 has not a bit of effect.

Hi,
It's possible as I never used a LPF setting on my multis.
I will check, it's maybe a problem of register setting order.

Hamburger · Post by **Hamburger** » Tue Apr 17, 2012 9:34 pm

for OCTOFLATP I did receive the following bug report via email from Michael Geuer:

#define OCTOFLATP ausgewählt. Aber im Config ist Roll und Pitch falsch und es steht auch noch OctoX im Tool

which imho boils down to:
for OCTOFLATP, the GUI displays OctoX instead and roll and pitch are wrong (switched?)

Hope it makes sense to someone - I have nothing bigger than TRIs.

ronco · Post by **ronco** » Tue Apr 17, 2012 9:47 pm

hi,

he wrote me this email too .. and i looked at the mix tables.. it seems that there is everything right. i told him that it may be because of an incorrect sensor orientation.. or a not corrrected one.

regards

felix

jevermeister · Post by **jevermeister** » Tue Apr 17, 2012 9:50 pm

ronco wrote:hi,

he wrote me this email too .. and i looked at the mix tables.. it seems that there is everything right. i told him that it may be because of an incorrect sensor orientation.. or a not corrrected one.

regards

felix

same here

warthox · Post by **warthox** » Tue Apr 17, 2012 10:32 pm

Alexinparis wrote:
warthox wrote:it seems that the lpf for the mpu6050 has not a bit of effect.

Hi,
It's possible as I never used a LPF setting on my multis.
I will check, it's maybe a problem of register setting order.

thanks alex

Joachim08 · Post by **Joachim08** » Sat Apr 21, 2012 1:02 pm

Alexinparis wrote:
Hi,
can you try to remove this line in multiwii.ino (from 2.0):
Code: Select all
      PTerm = constrain(PTerm,-D8[PIDLEVEL]*5,+D8[PIDLEVEL]*5);
With this, you should have exactly the same behavior of 1.9 stable mode.

can you ensure also that when the multi is reverted, Z ACC is negative and equal in absolute to the value it has when the multi is flat and not reverted ?

Alex,

regarding the tbe i have just downloaded 2.0dev of 14. April. It looks like you have changed the line in multiwii.ino already.
The Z ACC is around 512 when it is flat on the ground and - (minus) 524 when it is reverted.

Is that ok so far ?

When i start the copter in my hands it looks much better now, but i cannot fly because of windy weather outside, maybe
i can give it a try later this evening.

Is there any reason why you have not included the code for the new Drotek IMU 10DOF with MP6050 in the sketch ?

Hamburger · Post by **Hamburger** » Sat Apr 21, 2012 5:36 pm

when compiling latest code r700 out of MultiWii_shared, I get the following warnings:

Serial.pde: In function 'uint32_t read32()':
Serial.pde:47: warning: left shift count >= width of type
Serial.pde:48: warning: left shift count >= width of type

Code in question is

Code: Select all

static uint8_t checksum,stateMSP,indRX,inBuf[64];

uint32_t read32() {
  uint32_t t = inBuf[indRX++];
  t+= inBuf[indRX++]<<8;
  t+= inBuf[indRX++]<<16;
  t+= inBuf[indRX++]<<24;
  return t;
}

Could not this be rewritten in a compiler-clean way?

pm1 · Post by **pm1** » Sat Apr 21, 2012 9:01 pm

Hamburger wrote:when compiling latest code r700 out of MultiWii_shared, I get the following warnings:
Code: Select all
..
  t+= inBuf[indRX++]<<8;
Could not this be rewritten in a compiler-clean way?

Should be like this (sry, not tested...):
t+= ((uint16_t)inBuf[indRX++])<<8;
t+= ((uint32_t)inBuf[indRX++])<<16;
t+= ((uint32_t)inBuf[indRX++])<<24;
...

Hamburger · Post by **Hamburger** » Sat Apr 21, 2012 10:44 pm

yes, thanks. It eliminates the warnings.

Hamburger · Post by **Hamburger** » Sat Apr 21, 2012 10:51 pm

cannot calb ACC with latest r700 MWii_shared.
What I did:
zeroed out eeprom,
then uploaded freshly compiled MWii to crius lite board.
Then run freshly compiled GUI. Sensor graphs are all over the window - because acc values go crazy.
Pressing the 'Calib ACC' does nothing to this.

Loading older r660 with corresponding GUI allows to calib Acc. If I now again load r700, then the graphs look good but
pressing 'calib ACC' does not give the typical notch in the acc graph. So I presume that with r700 the GUI never makes the board enter the Acc calib.

Hamburger · Post by **Hamburger** » Sat Apr 21, 2012 11:06 pm

also, the GUI Reset Button does nothing for me.

mbrak · Post by **mbrak** » Sun Apr 22, 2012 4:29 pm

Alexinparis wrote:
warthox wrote:it seems that the lpf for the mpu6050 has not a bit of effect.

Hi,
It's possible as I never used a LPF setting on my multis.
I will check, it's maybe a problem of register setting order.

hi

is there any solution for this problem?
my quad with flydiuno MPU6050 has the same problem as wartho described before.
would be great if anyone could solve the problem.

br michael

Alexinparis · Post by **Alexinparis** » Sun Apr 22, 2012 4:35 pm

Hamburger wrote:for OCTOFLATP I did receive the following bug report via email from Michael Geuer:
#define OCTOFLATP ausgewählt. Aber im Config ist Roll und Pitch falsch und es steht auch noch OctoX im Tool

which imho boils down to:
for OCTOFLATP, the GUI displays OctoX instead and roll and pitch are wrong (switched?)

Hope it makes sense to someone - I have nothing bigger than TRIs.

It's just the GUI which is generic for all octo configs and display OCTOCOPTER X8 for all configs.
I will switch it to the generic term "OCTOCOPTER"

Alexinparis · Post by **Alexinparis** » Sun Apr 22, 2012 4:39 pm

Joachim08 wrote:
Alexinparis wrote:
Hi,
can you try to remove this line in multiwii.ino (from 2.0):
Code: Select all
      PTerm = constrain(PTerm,-D8[PIDLEVEL]*5,+D8[PIDLEVEL]*5);
With this, you should have exactly the same behavior of 1.9 stable mode.

can you ensure also that when the multi is reverted, Z ACC is negative and equal in absolute to the value it has when the multi is flat and not reverted ?
Alex,

regarding the tbe i have just downloaded 2.0dev of 14. April. It looks like you have changed the line in multiwii.ino already.
The Z ACC is around 512 when it is flat on the ground and - (minus) 524 when it is reverted.

Is that ok so far ?

When i start the copter in my hands it looks much better now, but i cannot fly because of windy weather outside, maybe
i can give it a try later this evening.

Is there any reason why you have not included the code for the new Drotek IMU 10DOF with MP6050 in the sketch ?

Your ACC value seems to be correct.
Please look better. The line I suggested to remove is still present in the current dev version... and nothing changed regarding the ACC stability.

jhoexp · Post by **jhoexp** » Mon Apr 23, 2012 8:10 am

mbrak wrote:is there any solution for this problem?
my quad with flydiuno MPU6050 has the same problem as wartho described before.
would be great if anyone could solve the problem.

br michael

Same problem here, tried a friend's quad with atmega-328 and mpu-6050 after a good 20minutes bench tuning. It was barely flyable with very low P and high D, and only in hovering/slow manouvers.
Gyro were too sensible and seem to resonate at some frequency, making it impossible to sustain heigh and very hard to tune.
LPF filter has no effect.

Please check the full-range scale too. We really don't need the 2000 °/sec, 1000 or 500°/s should be better. (I think that is the "problem" with itg32XX too, it's just too sensitive, while old good wmp's idg600 gives a better feeling in slow flying and for AP purposes)

warthox · Post by **warthox** » Mon Apr 23, 2012 10:19 am

jhoexp wrote:Please check the full-range scale too. We really don't need the 2000 °/sec, 1000 or 500°/s should be better. (I think that is the "problem" with itg32XX too, it's just too sensitive, while old good wmp's idg600 gives a better feeling in slow flying and for AP purposes)

are u sure that we dont need the full scale?

maybe u dont need it but some others need it.
so the best solution would be a define for it to select the scale depending on your flying style.

@ alex - did u already had the time to take a look onto the mpu lpf?

jhoexp · Post by **jhoexp** » Mon Apr 23, 2012 1:18 pm

warthox wrote:are u sure that we dont need the full scale?

Of course you can set it to what you want, but you don't need 2000°/s, expecially for AP purposes.
Anyway, setting the full range scale to 500°/sec doesn't prevent you to flip it even much faster, prroves is that you can do that with wmp's idg500 and they are just 500°/s.

mbrak · Post by **mbrak** » Mon Apr 23, 2012 6:58 pm

hi

about the problem with the mpu6050 (not very stable, laggy,etc.).....

try out with p=9.0/I=0.04/D=23

just came in from testflight with these settings. very very stable. just wobbling just a tiny bit.

wow. and this with the promini without 11bit pwm.... i am impressed!

the values are from rosewhite. 10 minutes bevore i couldnt believe that they are real... now i know that they are!

Kayle · Post by **Kayle** » Mon Apr 23, 2012 9:38 pm

Hi,

try out with p=9.0/I=0.04/D=23

Auf welchen Achsen ? Allen drei ?

Gruß Kayle

fax8 · Post by **fax8** » Mon Apr 23, 2012 10:57 pm

jhoexp wrote:LPF filter has no effect.

While troubleshooting the same quad jhoexp is referring above (we are common friends) we discovered that with current code, it seems that DLPF settings are not stored in the sensor memory thus never actually used by the sensor and completely useless. More details, including working code, at viewtopic.php?f=8&t=1591

Fabio Varesano

bitman · Post by **bitman** » Tue Apr 24, 2012 11:01 pm

Hi all,

I think I have a problem with MultiWii 2.0 firm. I have a multiwiicopter with PARIS 4.0, bma180 and a WMP. I have changued this into config file:

#define QUADP
#define BMA180
#define MOTOR_STOP

#define ACC_ORIENTATION(X, Y, Z) {accADC[ROLL] = Y; accADC[PITCH] = -X; accADC[YAW] = Z;}
#define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] = -Y; gyroADC[PITCH] = X; gyroADC[YAW] = Z;}

You can see the behavior in this video:

http://www.youtube.com/watch?v=br3-SZr3 ... r_embedded

It's seems like a bug, because with 1.9 firm, everything works fine.

What can I do?

thx

Bye!

fr3d · Post by **fr3d** » Wed Apr 25, 2012 12:40 pm

bitman wrote:Hi all,

I think I have a problem with MultiWii 2.0 firm. I have a multiwiicopter with PARIS 4.0, bma180 and a WMP. I have changued this into config file:

#define QUADP
#define BMA180
#define MOTOR_STOP

#define ACC_ORIENTATION(X, Y, Z) {accADC[ROLL] = Y; accADC[PITCH] = -X; accADC[YAW] = Z;}
#define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] = -Y; gyroADC[PITCH] = X; gyroADC[YAW] = Z;}

You can see the behavior in this video:

http://www.youtube.com/watch?v=br3-SZr3 ... r_embedded

It's seems like a bug, because with 1.9 firm, everything works fine.

What can I do?

thx

Bye!

try to disable bma180

Code: Select all

//#define BMA180

or add

Code: Select all

#define BMA180_ADDRESS 0x82

bitman · Post by **bitman** » Wed Apr 25, 2012 1:03 pm

I tried to disable BMA180 but It got worst,

But I,ll add this code...let me try...

thx

Bye!

bitman · Post by **bitman** » Wed Apr 25, 2012 6:25 pm

Ok, I,ve tested this:

add BMA180_ADDRESS 0x82 => The same.
add BMA180_ADDRESS 0x82 and #define BMA180 => The same.

And also changued this:

#if !defined(BMA180_ADDRESS)
//#define BMA180_ADDRESS 0x80
#define BMA180_ADDRESS 0x82
#endif

But nothing ocurs. Sometimes ACC doesn't works, others works too bad.

Thx!

Bye

wilco1967 · Post by **wilco1967** » Wed Apr 25, 2012 8:33 pm

My tri tail servo is mechanically not completely correct.
When flying straight, It needs approx 1560 us on the tail servo as shown in the GUI to keep the heading.

So I tried to trim it by adjusting TRI_YAW_MIDDLE to 1560, but it doesn't seem to do anything
Even tried 1800 (just to see if it would move at all), but no luck. It stays in the same centre position....

I'm using dev20120414, this is with a promini 328
On earlier versions (then with Flyduino mega), it seemed to worked ok.

if I change (in output):

servo[5] = constrain(tri_yaw_middle + YAW_DIRECTION * axisPID[YAW], TRI_YAW_CONSTRAINT_MIN, TRI_YAW_CONSTRAINT_MAX); //REAR

to

servo[5] = constrain(1560 + YAW_DIRECTION * axisPID[YAW], TRI_YAW_CONSTRAINT_MIN, TRI_YAW_CONSTRAINT_MAX); //REAR

it works ok.....

Seems like the variable tri_yaw_middle gets overwritten somehow, but I cannot find how/where :roll:

Hamburger · Post by **Hamburger** » Wed Apr 25, 2012 11:04 pm

It is stored in eeprom and can be changed via lcd or via terminal of arduino ide.
Else you can clear eeprom and upload mwii again.

wilco1967 · Post by **wilco1967** » Thu Apr 26, 2012 9:31 pm

Hamburger wrote:It is stored in eeprom and can be changed via lcd or via terminal of arduino ide.
Else you can clear eeprom and upload mwii again.

Aha !
now I understand......
Thanks Hamburger....

I don't have an LCD, so I never thought about this posibility to use the arduino terminal (serial monitor)....
Took me a while to figure it out, but now I got it working through the serial monitor of arduino

Some steps for so others may also used this.... I fly multiwii for almost one year and did not know, and I think there might be more people like that around.... :roll:

- First ensure #define LCD_CONF is active (not commented)
- select #define LCD_VT100
- upload your program so settings take effect

- open serial monitor in arduino (right top corner)
- select baudrate 115200

- Put pitch stick forward FIRST, and only after that put throttle / yaw stick to bottom right (assuming mode 2).
Please be aware, if you first put the throttle / yaw to bottom right, it will start the motors :!:

On the serial monitor, now the settings should appear
- with pitch up / down, you can scroll through the parameters.
- with roll left / right, you can change parameters.

here I could change the tri_yaw_middle to the required position...

when finished, throttle to left bottom, and pitch forward to save and exit.

See also http://multiwii.googlecode.com/svn/bran ... -57721.pdf for all commands

Wilco.

Cronalex · Post by **Cronalex** » Sat May 05, 2012 3:23 pm

I have a multiwii crius SE and I do not work in version 2.0 headfree why? What should I do?

Ausi1972 · Post by **Ausi1972** » Sun May 06, 2012 12:45 pm

I have the crius multiwii se and have tried the headfree mode. It works but my aileron is reversed on it, the aileron is fine in stable and acro mode but headfree it is reversed. Is there a setting to reverse it?

Ausi1972 · Post by **Ausi1972** » Sun May 06, 2012 12:46 pm

I have just noticed that on my tx the rudder and aileron are reversed which makes it correct in the GUI but I guess I could put them to normal then reverse them in the code?

Ausi1972 · Post by **Ausi1972** » Sun May 06, 2012 12:49 pm

Other than that for a super cheap first build quad using the wrong esc's and having lots of vibrations it is still flying very stable and alt works great. It flies on it's own hands off sticks for at least 30secs before it starts to drift away.
I am now in the process of building a much nicer unit with a naze32 and proper Simon esc's. Also might be tempted to put some quality motors on it.

Ausi1972 · Post by **Ausi1972** » Sun May 06, 2012 9:03 pm

I am using Multiwii 2.0 (NOT DEV)

I think I may have found a problem either with my config, my Crius SE board or the code (not sure which).

In the Multiwii gui if I switch on only the graph for the mag yaw then rotate the quad there is almost no movement in the line. However if I pitch the quad with only this same same graph line (MAG YAW) goes up and down nicely.
If I only show the pitch or roll for the MAG the lines roll up and down nicely pitch and roll of the quad as expected.

I have calibrated the mag several times, whilst connected via USB to the multiwii GUI I hit the calib mag button then rotate the quad 2 to 3 times on the yaw, roll and pitch axis.

Here is my config.h stuff:
#define QUADX
//#define YAW_DIRECTION -1
#define CRIUS_SE
....
//#define SERVO_TILT
#define TILT_PITCH_MIN 1020 //servo travel min, don't set it below 1020
#define TILT_PITCH_MAX 2000 //servo travel max, max value=2000
#define TILT_PITCH_MIDDLE 1500 //servo neutral value
#define TILT_PITCH_PROP 10 //servo proportional (tied to angle) ; can be negative to invert movement
#define TILT_ROLL_MIN 1020
#define TILT_ROLL_MAX 2000
#define TILT_ROLL_MIDDLE 1500
#define TILT_ROLL_PROP 10
.....
//#define ACC_ORIENTATION(X, Y, Z) {accADC[ROLL] = Y; accADC[PITCH] = -X; accADC[YAW] = Z;}
//#define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] = -Y; gyroADC[PITCH] = X; gyroADC[YAW] = Z;}
//#define MAG_ORIENTATION(X, Y, Z) {magADC[ROLL] = X; magADC[PITCH] = Y; magADC[YAW] = Z;}
#define ACC_ORIENTATION(X, Y, Z) {accADC[ROLL] = X; accADC[PITCH] = Y; accADC[YAW] = Z;}
#define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] = X; gyroADC[PITCH] = Y; gyroADC[YAW] = Z;}
#define MAG_ORIENTATION(X, Y, Z) {magADC[ROLL] = -Y; magADC[PITCH] = X; magADC[YAW] = Z;}

SovGVD · Post by **SovGVD** » Mon May 07, 2012 8:58 pm

wilco1967 wrote:if I change (in output):

servo[5] = constrain(tri_yaw_middle + YAW_DIRECTION * axisPID[YAW], TRI_YAW_CONSTRAINT_MIN, TRI_YAW_CONSTRAINT_MAX); //REAR

to

servo[5] = constrain(1560 + YAW_DIRECTION * axisPID[YAW], TRI_YAW_CONSTRAINT_MIN, TRI_YAW_CONSTRAINT_MAX); //REAR

it works ok.....

Seems like the variable tri_yaw_middle gets overwritten somehow, but I cannot find how/where

the same bug, i changed tri_yaw_middle variable to TRI_YAW_MIDDLE (define in config.h)

Hamburger · Post by **Hamburger** » Tue May 08, 2012 10:01 am

SovGVD wrote:the same bug, i changed tri_yaw_middle variable to TRI_YAW_MIDDLE (define in config.h)

or you could read the two posts following the one you quoted for explanation and usage guide.

Ausi1972 · Post by **Ausi1972** » Fri May 11, 2012 7:36 pm

Ausi1972 wrote:I am using Multiwii 2.0 (NOT DEV)

I think I may have found a problem either with my config, my Crius SE board or the code (not sure which).

In the Multiwii gui if I switch on only the graph for the mag yaw then rotate the quad there is almost no movement in the line. However if I pitch the quad with only this same same graph line (MAG YAW) goes up and down nicely.
If I only show the pitch or roll for the MAG the lines roll up and down nicely pitch and roll of the quad as expected.

I have calibrated the mag several times, whilst connected via USB to the multiwii GUI I hit the calib mag button then rotate the quad 2 to 3 times on the yaw, roll and pitch axis.

Here is my config.h stuff:
#define QUADX
//#define YAW_DIRECTION -1
#define CRIUS_SE
....
//#define SERVO_TILT
#define TILT_PITCH_MIN 1020 //servo travel min, don't set it below 1020
#define TILT_PITCH_MAX 2000 //servo travel max, max value=2000
#define TILT_PITCH_MIDDLE 1500 //servo neutral value
#define TILT_PITCH_PROP 10 //servo proportional (tied to angle) ; can be negative to invert movement
#define TILT_ROLL_MIN 1020
#define TILT_ROLL_MAX 2000
#define TILT_ROLL_MIDDLE 1500
#define TILT_ROLL_PROP 10
.....
//#define ACC_ORIENTATION(X, Y, Z) {accADC[ROLL] = Y; accADC[PITCH] = -X; accADC[YAW] = Z;}
//#define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] = -Y; gyroADC[PITCH] = X; gyroADC[YAW] = Z;}
//#define MAG_ORIENTATION(X, Y, Z) {magADC[ROLL] = X; magADC[PITCH] = Y; magADC[YAW] = Z;}
#define ACC_ORIENTATION(X, Y, Z) {accADC[ROLL] = X; accADC[PITCH] = Y; accADC[YAW] = Z;}
#define GYRO_ORIENTATION(X, Y, Z) {gyroADC[ROLL] = X; gyroADC[PITCH] = Y; gyroADC[YAW] = Z;}
#define MAG_ORIENTATION(X, Y, Z) {magADC[ROLL] = -Y; magADC[PITCH] = X; magADC[YAW] = Z;}

Forget all of that. I have just built up again, same motors but with HK F-20A ESC's flashed with Simon code, the Crius MWC SE in a DJI F450 V2 frame.
Been out in the garden with restricted space and found it flies super stable and everything is working perfect now.
Headfree mode is amazing. it makes flying a total breeze, very strange to get used to. No more trying to keep it tail in etc. Just go fly!!!!
Altitude hold is also working great.
Looking forward to a great weekend of flying my new toy!

Crashpilot1000 · Post by **Crashpilot1000** » Sun May 13, 2012 10:19 pm

BTW:
I have NO NUNCHUK in flight bug with MultiWii_dev_20120504. My tri ran on 1.9 before and i skipped the official 2.0, so i can not say, if it was affected with FW 2.0.
viewtopic.php?f=8&t=1455&p=13973#p13973

Y.Mita · Post by **Y.Mita** » Fri May 18, 2012 1:27 pm

Seems to find some bugs in 20120504.

I install v2.0 and it works perfect, but 20120504, I can't start CALIB_ACC and CALIB_MAG from MultiWiiConf. Try eeprom_clear but nothing change.
Also from RC stick, I can start MAG calibration, but can't start ACC calibration.
With v2.0, both CALIB_ACC and CALIB_MAG and RC stick ACC caribration and RC stick MAG caribration works well.

Is this something setting error?

My Hexa Flyduino Mega with FreeIMU v0.3.5_MS.

Pyrofer · Post by **Pyrofer** » Fri May 18, 2012 3:12 pm

Hey, I just put the latest 2.0 DEV build on, and noticed I can't trim with the remote anymore!

When I move the sticks I get no response on the LEDs like I did before and it doesn't seem to change anything.

Crashpilot1000 · Post by **Crashpilot1000** » Tue May 22, 2012 8:42 am

Hi !

In the current code there are some problems with the locking in of a new hight for the Baro/PID controller:
Original:

Code: Select all

 #if BARO
    if (baroMode) {
      if (abs(rcCommand[THROTTLE]-initialThrottleHold)>20) {
         baroMode = 0; // so that a new althold reference is defined
      }
      rcCommand[THROTTLE] = initialThrottleHold + BaroPID;
    }
  #endif

Problem1:
At the moment the throttlestick is altered a new hight is locked for the PID controller long before the copter could have possibly reached a new hight or has altered his position. This can also lead to a feedbackproblem.

Problem2:
With this code the throttlechannel is rasterized in 21 steps, that gives a sluggish throttleresponse and an unnatural feeling for the pilot.

Possible Solution:
Give the pilot full control over the throttlechannel.
Lock in a new hight for the Baro PID controller only under the following circumstances:
The copter has done a substantial hight (in my code 60cm) change and the pilot wanted it by stickinput (change "20").
I changed the code and tested it for 2 days - and the baro behaviour improved. Perhaps i have to raise the value of "60" for my BMP085 to e.g. "100".
I posted my findings in my german forum (http://fpv-community.de/showthread.php? ... post146766) and another user reports (http://fpv-community.de/showthread.php? ... post146996) that his copter behaves significantly better than with the original DEV 20120504.
My findings should also apply for the new DEV, but is untested.

Please look into this. I think my new code is far from perfect, but it flies better.
I am new to C and arduino programming.

Cheers

Crashpilot1000

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
EDIT 26.05.2012: I did a new Version: http://fpv-community.de/showthread.php? ... post148827
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

New Code:

Code: Select all

static uint8_t baroloopcounter=0;
static int32_t thrsticksum=0;
static int16_t thrstickmw=0;
static int32_t estaltsum=0;
static int32_t estaltmw=0;

Code: Select all

  #if BARO
    if (baroMode)
    {
      if (baroloopcounter <64)
      {
        estaltsum=estaltsum+EstAlt;
        thrsticksum=thrsticksum+rcCommand[THROTTLE];
        thrstickmw=0;
        estaltmw=0;
        baroloopcounter=baroloopcounter+1;
      }
      else
      {
        baroloopcounter=0;
        estaltmw=estaltsum>>6;
        thrstickmw=thrsticksum>>6;
        estaltsum=0;
        thrsticksum=0;
        
//        debug3=thrstickmw - initialThrottleHold;
//        debug4=estaltmw - AltHold;
        
        if (abs(estaltmw - AltHold)>60 && abs(thrstickmw - initialThrottleHold)>20) //Did the hight significant change over time on purpose?
        {
          baroMode = 0; // so that a new althold reference is defined
        }
       }
     rcCommand[THROTTLE] = rcCommand[THROTTLE] + BaroPID;
    }
  #endif

AlouetteIII · Post by **AlouetteIII** » Tue May 22, 2012 9:24 am

@CrashPilot1000 - cool - what BARO PIDs did you have for the best result and have you tried it in combination with Acc Z variations.

which sections to replace the code you show? which tabs? And did you see if this still applies to 2.0.522 version ? thanks

Crashpilot1000 · Post by **Crashpilot1000** » Tue May 22, 2012 10:35 am

Hi !
I just tried the new MultiWii_dev_20120522 with my code in the backyard and it works very well though its windy here in NW Germany.
The changes are done in the main tab of the code. Just place the new "statics" in front of the others and replace the original code (i quoted under "Original") with the new one. BTW i did my last flight (BMP085 Baro) with ..."abs(estaltmw - AltHold)>100 ..." and "...thrstickmw - initialThrottleHold)>40...". Just play with the values. Uncomment Debug 3 and 4 and watch the values in the GUI. Debug 3 tells you the change of the throttlestick and debug 4 tells you the change of the Altitude in cm of the sensor. You can test it while disarmed. If you see Debug 3=0 the code has locked in a new hight. At the moment i use the stock PID for alt/baro. I looked at the ACCZ values as well, and its beyond my capabilities to make real use of them. At the moment i can figure out with a good probability if the copter was rising or falling while locking a new altitude. This could be used e.g for a small throttleburst to support the Baro.