MultiWii 2.0 bug report

Alexinparis · Post by **Alexinparis** » Mon Apr 02, 2012 7:13 am

Hi,

I will try to maintain a list of reported bugs.
This post can be used only to report new bugs and discuss about solutions.
One strength of multiwii if the important user number. So we should benefit from it

For the moment:

- HEX problem on pro mini (reported at least 3 times)
viewtopic.php?f=8&t=1290&start=240#p11414
edit: should be corrected in 14 April dev version

- VBAT reading (reported 2 times)
viewtopic.php?f=8&t=1461

- potential bug with CRIUS LCD (reported at least 3 times, worked fine with 1.9)
viewtopic.php?f=8&t=1463#p11473

- in flight acc calibration, corrected in dev
memberlist.php?mode=viewprofile&u=471
edit: should be corrected in 14 April dev version

- potential bug with nunchuck:
viewtopic.php?f=8&t=1455&p=11561#p11561

airmamaf · Post by **airmamaf** » Mon Apr 02, 2012 8:24 am

A problem with Nunchuck
viewtopic.php?f=8&t=1455

dramida · Post by **dramida** » Mon Apr 02, 2012 10:47 am

Standard serial LCD config in multiwii 2.0 not working as it should. Strange characters and shifted words appears on lcd. To mention that on MWC1.9 the same LCD is working fine. See the clip i made this morning to show this behavior.

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

Hardware:
Crius SE with atmega 328p and serial LCD
Software: MWC 2.0

Hamburger · Post by **Hamburger** » Mon Apr 02, 2012 12:11 pm

What is 'standard LCD'? 3 wire sparkfun?

UndCon · Post by **UndCon** » Mon Apr 02, 2012 3:06 pm

My 3wire sparkfun works OK

the chinsese copy "crius LCD" is crap (shifted but in previous firmware as well)

JohnyGab · Post by **JohnyGab** » Mon Apr 02, 2012 6:07 pm

I haven investigated it, but no effect turning on/off the mag mode, on a Quad usign the HMC5883L sensor

jevermeister · Post by **jevermeister** » Mon Apr 02, 2012 9:02 pm

I found a bug in INFLIGHT_ACC_CALIBRATION:

when the calibration is done inflight it is commited by a beep with:

Code: Select all

         blinkLED(10,10,2);      //buzzer for indicating measurement finished

in line #302 of sensors.pde
this is a very bad idea inflight: blinkLED is delaying the code, hamburger warned me about that some time ago: Shame on me!!
Some users reported out of control copters, and I noticed a rise in cycle time until overflow while the speaker beeps using this function.
Perhaps we should delete the function blinkLED and replace it with a better one.

I replaced this bug in sensors.pde with:

Code: Select all

          toggleBeep = 2;      //buzzer for indicatiing the end of calibration

Nils
ps.:regarding mag mode: I use QuadX BMA020, WMP, HMC5883L,BMP085, maghold and everything working fine.

ronco · Post by **ronco** » Mon Apr 02, 2012 9:52 pm

Alexinparis wrote:- HEX problem on pro mini (reported at least 3 times)
viewtopic.php?f=8&t=1290&start=240#p11414

Hi,

it may be the combination of the new soft pwm code and ppm RX!

in the new code we use one timer channel for two motors.. soft pwm is general very "other interrupt sensitiv" so it may be that the ppm interrupts do more jitter to the soft pwm then a normal rx does.

hard to explain .. the old soft pwm method starts at 125 (1ms) and ends on 250(2ms) the new starts on 5(1ms) and ends on 250(2ms).

so if the "other interrupt jitter" pushes the new soft pwm method lower then 0 (-6 for example) it switches to a lower frequency where the duty time is arround 2ms(full throttle). this cant happen with the old one because it will not fall under 0 (jitter will not be -126).

so it may be a solution to add the old method for hexas without servos.

regards Felix

fr3d · Post by **fr3d** » Mon Apr 02, 2012 11:02 pm

dramida wrote:Standard serial LCD config in multiwii 2.0 not working as it should.

mine lcd from sparkfun work fine
tested on 328 et 2560 with mc 2.0

fr3d · Post by **fr3d** » Mon Apr 02, 2012 11:04 pm

JohnyGab wrote:I haven investigated it, but no effect turning on/off the mag mode, on a Quad usign the HMC5883L sensor

same with allinone + atmega2560 tested with orginal pid

fr3d · Post by **fr3d** » Mon Apr 02, 2012 11:09 pm

put level PiD "D" term @ 99 or less,
all other pids @re originals

active stable mode
after 60/120 secondes the copter go down slowly ..... until it touch the grass
impossible to takeoff until replug batteries.

test and tell me (bma020+wmp+bmp085)
put level D @ 100 the pb doesn't appear.
plz test in the grass @ low altitude
I've changed bma020 address @ 0x82
I've pluged wmp+ and bmp085 on bma in order to be have a vcc and i2c @ 3volts in this way bma give me a good llc with arduino @ 5volts. No i2c error if connected with a battery. board is jussih v1.11
I've tested with mw 2.0pre1(ve r201) and multiwii 2.0 (ver 20)

Alexinparis · Post by **Alexinparis** » Tue Apr 03, 2012 11:05 pm

fr3d wrote:put level PiD "D" term @ 99 or less,
all other pids @re originals

active stable mode
after 60/120 secondes the copter go down slowly ..... until it touch the grass
impossible to takeoff until replug batteries.

test and tell me (bma020+wmp+bmp085)
put level D @ 100 the pb doesn't appear.
plz test in the grass @ low altitude
I've changed bma020 address @ 0x82
I've pluged wmp+ and bmp085 on bma in order to be have a vcc and i2c @ 3volts in this way bma give me a good llc with arduino @ 5volts. No i2c error if connected with a battery. board is jussih v1.11
I've tested with mw 2.0pre1(ve r201) and multiwii 2.0 (ver 20)

level D should only limit the ACC correction.
difficult to investigate...

fr3d · Post by **fr3d** » Wed Apr 04, 2012 6:38 am

Alexinparis wrote:
fr3d wrote:put level PiD "D" term @ 99 or less,
all other pids @re originals

active stable mode
after 60/120 secondes the copter go down slowly ..... until it touch the grass
impossible to takeoff until replug batteries.

test and tell me (bma020+wmp+bmp085)
put level D @ 100 the pb doesn't appear.
plz test in the grass @ low altitude
I've changed bma020 address @ 0x82
I've pluged wmp+ and bmp085 on bma in order to be have a vcc and i2c @ 3volts in this way bma give me a good llc with arduino @ 5volts. No i2c error if connected with a battery. board is jussih v1.11
I've tested with mw 2.0pre1(ve r201) and multiwii 2.0 (ver 20)

level D should only limit the ACC correction.

difficult to investigate...

it's like drift.... but not in roll/pitch but with power
the idea it's keeping copter stable....
an autolanding eastereggs ?

dramida · Post by **dramida** » Wed Apr 04, 2012 10:15 am

The serial LCD from Crius was working fine in MWC 1.9 but in MWC 2.0 dose not work anymore. This is definetly a BUG, regardless of your opinion about LCD quality.
The demonstration of the two software MWC version and the BUG is shown here http://www.youtube.com/watch?v=L7TtpjYjvGo

UndCon wrote:My 3wire sparkfun works OK

the chinsese copy "crius LCD" is crap (shifted but in previous firmware as well)

klaudius666 · Post by **klaudius666** » Thu Apr 05, 2012 8:20 pm

Same problem on Crius LCD with multiwii 2.0.
Looked at difference between 1.9 and 2.0 lcd code, but there are really too many change.
Perhaps a bad serial transmission, or character set problem ?

If someone give me some suggestion i can recompile and test for some solutions

Joachim08 · Post by **Joachim08** » Fri Apr 06, 2012 11:00 pm

More and more people report about the toilet bow effect they experience with 2.0 and ACC.
Alex can you seriously look into the matter ? Changing PID simply doesnt help.
In 1.9 there is no such behaviour.

Thanks

Joachim

kalle123 · Post by **kalle123** » Sat Apr 07, 2012 3:10 pm

1. Failsave settings

#define FAILSAVE_OFF_DELAY - no motor STOP after xx sec.

2. When activating alternative motor stop by uncommenting #define MOTOR_STOP

Failsave settings NOT working.

BR KH

kalle123 · Post by **kalle123** » Tue Apr 10, 2012 10:09 am

kalle123 wrote:1. Failsave settings
#define FAILSAVE_OFF_DELAY - no motor STOP after xx sec.
2. When activating alternative motor stop by uncommenting #define MOTOR_STOP
Failsave settings NOT working.
BR KH

Sorry, but I think I found the reason ....

Using JETI REX MDP RX.

shikra · Post by **shikra** » Tue Apr 10, 2012 11:49 pm

Joachim08 wrote:More and more people report about the toilet bow effect they experience with 2.0 and ACC.
Alex can you seriously look into the matter ? Changing PID simply doesnt help.
In 1.9 there is no such behaviour.

Thanks

Joachim

Really strange - it should only affect the differential between motors e.g between left/right not all at same time. I don't see how it can from the code. Really is a minor limit change.

I have flown many flights with it on start to finish. No such issues. Is Baro on at same time and causing some strange effect? I've had mine on by mistake and wondered why I couldn't fly it level....

shikra · Post by **shikra** » Tue Apr 10, 2012 11:55 pm

dramida wrote:The serial LCD from Crius was working fine in MWC 1.9 but in MWC 2.0 dose not work anymore. This is definetly a BUG, regardless of your opinion about LCD quality.
The demonstration of the two software MWC version and the BUG is shown here http://www.youtube.com/watch?v=L7TtpjYjvGo

UndCon wrote:My 3wire sparkfun works OK

the chinsese copy "crius LCD" is crap (shifted but in previous firmware as well)

Don't leave lcd in when reprogramming..... Same happened to me twice. I had to reset LCD to default speed of 9600. I posted in LCD thread earlier

shikra · Post by **shikra** » Tue Apr 10, 2012 11:58 pm

I think the two Sirius mag defines are incorrect. Could not get it to look good in GUI and gave me weird yaw issues (as you might expect :roll:

)
I think the following is correct. Not flown, but it looks good in GUI - needs a recal after change....

#define MAG_ORIENTATION(X, Y, Z) {magADC[ROLL] = X; magADC[PITCH] = Y; magADC[YAW] = -Z;}

jevermeister · Post by **jevermeister** » Wed Apr 11, 2012 5:50 am

You should use the method descriped in the faq to test if the sensour orientation is correct.I had a very hard time finding the correct orientation via trial and error until someone shoeed me the method in the faq :-)

.
Sometimes all goes back to RTFM. I do these mistakes again and again *sigh*
Nils

ApoC · Post by **ApoC** » Wed Apr 11, 2012 11:58 am

viewtopic.php?f=8&t=1480

This is the Problem, what i have with 2.0. And its only in 2.0 so, that i have the Errors. But i cant get this "2.0 flashed Arduino" back to work with an older version, like 1.9 or 1.8.

shikra · Post by **shikra** » Wed Apr 11, 2012 5:10 pm

You are right - I should have !

But why make it easy? Always read the manual last right !! I didn't know that was written down, but it is a good idea. Sort of thing real easy to forget over time when a new board comes along.

Actaully I don't usually use the mag - first time I really looked at the code even. The other sensors are dead easy to figure out, but this one did take a little longer.

Anyway - tested and it flew great. Vid to follow

jevermeister wrote:You should use the method descriped in the faq to test if the sensour orientation is correct.I had a very hard time finding the correct orientation via trial and error until someone shoeed me the method in the faq .
Sometimes all goes back to RTFM. I do these mistakes again and again *sigh*
Nils

shikra · Post by **shikra** » Wed Apr 11, 2012 5:25 pm

Start with basics.
2.0 should be fine

first try with just WMP
to do that use I2C speed of 100hz. All specific boards and independant sensors disabled.

If good:
Now add specific sensor bma020
//#define BMA020

If no good, try alternative address for BMA...
#define BMA180_ADDRESS 0x80

ApoC wrote:http://www.multiwii.com/forum/viewtopic.php?f=8&t=1480

This is the Problem, what i have with 2.0. And its only in 2.0 so, that i have the Errors. But i cant get this "2.0 flashed Arduino" back to work with an older version, like 1.9 or 1.8.

ApoC · Post by **ApoC** » Thu Apr 12, 2012 5:36 am

Hey

Im not new in MWii.I know how to setup the conf. That is not the Problem.

shikra · Post by **shikra** » Thu Apr 12, 2012 9:17 am

ah - it's hard to tell knowledge level.
Is it possible to separate the wmp and BMA and recompile to test individually? Maybe one of devices has broken and is affecting the other?

Magnetron · Post by **Magnetron** » Thu Apr 12, 2012 2:22 pm

I Alex,
some user report on italian forum that with MultiWii v2.0 on Nano with hexa configuration seems that motor 5 and 6 have differents speed. With v1.9 seems that this problem was not present...

ronco · Post by **ronco** » Thu Apr 12, 2012 9:29 pm

Magnetron wrote:I Alex,
some user report on italian forum that with MultiWii v2.0 on Nano with hexa configuration seems that motor 5 and 6 have differents speed. With v1.9 seems that this problem was not present...

hi Magnetron,

im not Alex but i did the changes to the promini with hexa..
thay dont have a different speet but the signal range is different now .. it starts end ends higher then it was in privius MWC versions .. but now thay are similar to the motors 1-4 means 1000 -1850 bevore it was ~950- 1800 ms.

so relearning the throttle range to the ESCs of motor 5 & 6 should fix this

regards

Felix

Alexinparis · Post by **Alexinparis** » Thu Apr 12, 2012 11:31 pm

ronco wrote:
Magnetron wrote:I Alex,
some user report on italian forum that with MultiWii v2.0 on Nano with hexa configuration seems that motor 5 and 6 have differents speed. With v1.9 seems that this problem was not present...

hi Magnetron,

im not Alex but i did the changes to the promini with hexa..
thay dont have a different speet but the signal range is different now .. it starts end ends higher then it was in privius MWC versions .. but now thay are similar to the motors 1-4 means 1000 -1850 bevore it was ~950- 1800 ms.

so relearning the throttle range to the ESCs of motor 5 & 6 should fix this

regards

Felix

Hi Felix
For some reasons, some ESCs need to have a lower min value even after a good calibration.
This is the purpose of MINCOMMAND.
with the current code for 5,6,7,8 motors on a promini, it's not possible.
I think we should rethink the code to make this possible.

ronco · Post by **ronco** » Fri Apr 13, 2012 10:18 am

Alexinparis wrote:Hi Felix
For some reasons, some ESCs need to have a lower min value even after a good calibration.
This is the purpose of MINCOMMAND.
with the current code for 5,6,7,8 motors on a promini, it's not possible.
I think we should rethink the code to make this possible.

Hi Alex,
should be possible now for hexas without servos -> viewtopic.php?f=8&t=1246&p=12066#p12066

regards felix

tru168 · Post by **tru168** » Fri Apr 13, 2012 5:15 pm

Hi,

I'm using BMA020 and WMP, works all version but when loaded with version 2.0 , I got I2C error. unselect the BMP020 in sketch and WMP works perfectly.

One weird thing happen if i use v2.0, when I check on my GUI, the I2C error keep counting fast , but when I turn my copter upside down, the I2C error stop counting and everything works again, turn my copter slowly, when it pass 90 degree and it start counting I2C error again.

IT IS A BUG for sure , I have a few boards fitted with WMP and BMA020, some are homebrew, and some are PARIS board. All of them behave the same as mentioned above.

Now I can't fly all my copters , unless I downgrade to lower version.

Joachim08 · Post by **Joachim08** » Fri Apr 13, 2012 6:16 pm

shikra wrote:
Joachim08 wrote:More and more people report about the toilet bow effect they experience with 2.0 and ACC.
Alex can you seriously look into the matter ? Changing PID simply doesnt help.
In 1.9 there is no such behaviour.

Thanks

Joachim

Really strange - it should only affect the differential between motors e.g between left/right not all at same time. I don't see how it can from the code. Really is a minor limit change.

I have flown many flights with it on start to finish. No such issues. Is Baro on at same time and causing some strange effect? I've had mine on by mistake and wondered why I couldn't fly it level....

Unfortunately i am not a coding specialist... On the German fpv forum you can find a 5 page thread about the tbe effect. Lots of pilots have this problem.
It is not related to the sensors or IMU, even with WMP and BMA020 it shows up... So Baro is off or not existing.
It is really strange as we are forced to use 1.9 where this issue is non existend. Some of us even cannot use 1.9 anymore as we have the MPU6050 sensor which is only supported in 2.0.

So our quads are grounded at the moment.

ronco · Post by **ronco** » Fri Apr 13, 2012 6:18 pm

tru168 wrote:Hi,

I'm using BMA020 and WMP, works all version but when loaded with version 2.0 , I got I2C error. unselect the BMP020 in sketch and WMP works perfectly.

One weird thing happen if i use v2.0, when I check on my GUI, the I2C error keep counting fast , but when I turn my copter upside down, the I2C error stop counting and everything works again, turn my copter slowly, when it pass 90 degree and it start counting I2C error again.

IT IS A BUG for sure , I have a few boards fitted with WMP and BMA020, some are homebrew, and some are PARIS board. All of them behave the same as mentioned above.

Now I can't fly all my copters , unless I downgrade to lower version.

Hi,

did you fly this boards with 1.9?

and do you have external pullup resistors ?

regards Felix

fr3d · Post by **fr3d** » Fri Apr 13, 2012 8:38 pm

playing with 2.0 wmp+ & bma020 & bmp085 without pb in acro. some trouble in stable mode...after flying a few minutes, quad drift, Quad can't find is ealier plane position,and motors slowdown if you change level d term pid.
I've modified bma like this
add 2.2 k resistor on i2c lines with 5v,
plug wmp+ & bmp085 with 3.3v,
scl & sda solder inside bma020.
config.h external pullup, wp @ 100khz, and bma_180_address @ 0x82

crashlander · Post by **crashlander** » Fri Apr 13, 2012 8:57 pm

Hello,
I'm starting to implement MultiWii on flying-wing (Arduino Mega, ATAVRSBIN) but my right servo midpoint starts at 2000 (pic1)

pic1.png: PIC1; (12.05 KiB) Not downloaded yet

(in GUI and in real life), and only moves down to 1500 when I move elevator in maximum position (pic2)

pic2.png: PIC2; (9.64 KiB) Not downloaded yet

.
The behavior is same in pass-throu and in giro assisted mode.
My ugly fix is to change line 747 in Output from:

Code: Select all

servo[1]  = constrain(servo[1] + wing_right_mid, WING_RIGHT_MIN, WING_RIGHT_MAX );

to

Code: Select all

servo[1]  = constrain(servo[1] + wing_right_mid-500, WING_RIGHT_MIN, WING_RIGHT_MAX );

But that is probably not how it was meant originally.

Regards
Andrej

Hamburger · Post by **Hamburger** » Fri Apr 13, 2012 10:46 pm

Andrej,
you must reset the eeprom. The code is interpreting some garbage from eeprom. This makes the midpoint go crazy.
In Arduino IDE in the examples is a small sketch for resetting the eeprom.
Or you could increment the eeprom version number in eeprom.pde
Hamburger

Alexinparis · Post by **Alexinparis** » Sat Apr 14, 2012 12:55 pm

ronco wrote:
Alexinparis wrote:Hi Felix
For some reasons, some ESCs need to have a lower min value even after a good calibration.
This is the purpose of MINCOMMAND.
with the current code for 5,6,7,8 motors on a promini, it's not possible.
I think we should rethink the code to make this possible.

Hi Alex,
should be possible now for hexas without servos -> viewtopic.php?f=8&t=1246&p=12066#p12066

regards felix

ok, this bug should now not appear anymore with the dev release 14 April

Alexinparis · Post by **Alexinparis** » Sat Apr 14, 2012 1:00 pm

Joachim08 wrote:More and more people report about the toilet bow effect they experience with 2.0 and ACC.
Alex can you seriously look into the matter ? Changing PID simply doesnt help.
In 1.9 there is no such behaviour.

Thanks

Joachim

As long as I can't reproduce this problem, I can't help
Main difference between 1.9 and 2.0 is the sensor orientation definition, and LEVEL D which should be left to 100 to have the 1.9 behavior.

Alexinparis · Post by **Alexinparis** » Sat Apr 14, 2012 1:02 pm

tru168 wrote:Hi,

I'm using BMA020 and WMP, works all version but when loaded with version 2.0 , I got I2C error. unselect the BMP020 in sketch and WMP works perfectly.

One weird thing happen if i use v2.0, when I check on my GUI, the I2C error keep counting fast , but when I turn my copter upside down, the I2C error stop counting and everything works again, turn my copter slowly, when it pass 90 degree and it start counting I2C error again.

IT IS A BUG for sure , I have a few boards fitted with WMP and BMA020, some are homebrew, and some are PARIS board. All of them behave the same as mentioned above.

Now I can't fly all my copters , unless I downgrade to lower version.

I have a quad with a WMP clone + BMA020.
It works perfectly for me with 2.0.
I2C errors should have nothing to do with the multi orientation.

jevermeister · Post by **jevermeister** » Sun Apr 15, 2012 6:56 pm

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.

Hamburger · Post by **Hamburger** » Sun Apr 15, 2012 9:59 pm

Nils
2.0 is not very precise or do yoh really use the official release?
Better name the revision from svn you use.

Quadro-Fan2011 · Post by **Quadro-Fan2011** » Sun Apr 15, 2012 10:19 pm

Hi All,

this is my first of hopefully many comments and discussions. I have no education in prgramming so many many thanks to all of you who are able to know what "what if else means"

Here is my problem. I built up an octocopter with a multiwii board (MWC MEGA beta). I uploaded the 2.0 Version and selected Octoflat p because it is a plus octo with one arm in front. After calibration I tested roll and pitch and it was wrong/switched. The arrow on the board for flight direction shows correctly to the front arm but the pitch/roll is wrong.

Then I tried the Version 1.9 and with this it works. Pitch and Roll is correct now. Foirst flight test was great. So I think this is a mistake in the 2.0

All Versions I downloaded from here
http://code.google.com/p/multiwii/downloads/list

By the way in the config tool the octo is named octox. The same in Version 2.0.

Best wishes

Michael

jevermeister · Post by **jevermeister** » Sun Apr 15, 2012 10:26 pm

Hamburger wrote:Nils
2.0 is not very precise or do yoh really use the official release?
Better name the revision from svn you use.

Hi hamburger.
Thank you for your answer.
I use the official MW 2.0 release.I downloaded it via the link.It is no svn revision.
I checked my connecftions but I could not find a loose connections by having a look at the gui while manopulating the connections.

Nils

Alexinparis · Post by **Alexinparis** » Sun Apr 15, 2012 10:29 pm

Quadro-Fan2011 wrote:Hi All,

this is my first of hopefully many comments and discussions. I have no education in prgramming so many many thanks to all of you who are able to know what "what if else means"

Here is my problem. I built up an octocopter with a multiwii board (MWC MEGA beta). I uploaded the 2.0 Version and selected Octoflat p because it is a plus octo with one arm in front. After calibration I tested roll and pitch and it was wrong/switched. The arrow on the board for flight direction shows correctly to the front arm but the pitch/roll is wrong.

Then I tried the Version 1.9 and with this it works. Pitch and Roll is correct now. Foirst flight test was great. So I think this is a mistake in the 2.0

All Versions I downloaded from here
http://code.google.com/p/multiwii/downloads/list

By the way in the config tool the octo is named octox. The same in Version 2.0.

Best wishes

Michael

Hi,
I don't know the board you use and its sensors, but it seems that it is not a predefined one.
The sensor orientations changed in 2.0, it might explain your problem.
The GUI shows the same indication octo X for all octo configs. It's normal because the GUI is not fully implemented for 8 motor configs.

Alexinparis · Post by **Alexinparis** » Sun Apr 15, 2012 10:33 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.

It looks like a bad ESC+motor combination.
could you test the motor stop stress test ? : take the multi firmly with one hand, start the motor to mid-gaz and tilt the multi violently to test the motor response.
If one motor stops, it's not good.

Quadro-Fan2011 · Post by **Quadro-Fan2011** » Sun Apr 15, 2012 10:46 pm

Hi Alex thank you for that.

The board has no name but it has all sensors described in the sketch. So I can use them. If you say that the sensor directions has changed is that for gyro and acc? and why did you do that? Will it work if I switch the board?

I have an old copter with bma020 - the software is 1.7. That means that I have to change the sensor direction first if I want to use the 2.0?

Greetings

Michael

jevermeister · Post by **jevermeister** » Sun Apr 15, 2012 11:42 pm

It looks like a bad ESC+motor combination.
could you test the motor stop stress test ? : take the multi firmly with one hand, start the motor to mid-gaz and tilt the multi violently to test the motor response.
If one motor stops, it's not good.

I had this with my old HK SS 18A. One of them stops after this maneuver.
I switched to hobbywing pentium 18A.
Just djd the stress test wirh them. THey do not stop.
Could it be a loose I2C or rx connector.You can see in the video,that the glitch appears on all 4 motors.The copter drops a few cm.

I start to loosr faith here. I cannot trust my copter anymore. What if he drops from 100m with gopro onboard...
Nils

LenzGr · Post by **LenzGr** » Mon Apr 16, 2012 8:38 am

jevermeister wrote:Could it be a loose I2C or rx connector.You can see in the video,that the glitch appears on all 4 motors.The copter drops a few cm.

I start to loosr faith here. I cannot trust my copter anymore. What if he drops from 100m with gopro onboard...

It could be several things. Maybe a bad solder joint on one of the ESCs or the connecting power or servo cables? Did you try re-calibrating the ESCs?
Or maybe the timing is too high? IIRC, the 2.0 firmware had some optimizations related to the PWM output that drives the ESCs. Could be they are now getting saturated (using an alternative firmware might help).

Alternatively, check the motor bearings - do they all run smoothly without any resistance?

Joachim08 · Post by **Joachim08** » Mon Apr 16, 2012 10:07 am

Alexinparis wrote:
Joachim08 wrote:More and more people report about the toilet bow effect they experience with 2.0 and ACC.
Alex can you seriously look into the matter ? Changing PID simply doesnt help.
In 1.9 there is no such behaviour.

Thanks

Joachim

As long as I can't reproduce this problem, I can't help
Main difference between 1.9 and 2.0 is the sensor orientation definition, and LEVEL D which should be left to 100 to have the 1.9 behavior.

Level D is set to 100 as standard in 2.0 and the behavior is totally different from 1.9 .... I have tried to change values up and down without luck.