MultiWii

Hey guys!

I've been noticing this odd behavior for some time, but so far I was thinking it would be related to other factors than the software.
Still after discussing it with other Naze32 users, seems that they also had the same happening and with the same characteristics.

What I see is when doing turns to the left and when yaw is used at some stage the quad spins out of control to that side. I noticed it
quite well when doing slow left turns when the yaw is used.

Examples:

3:28 >> https://www.youtube.com/watch?v=YBy8WBgqRds#t=204
(I have more examples and worse than that one)

As I already expect this to happen most of the time I can quickly compensate with right yaw and preventing it from do a flat spin and go out of control.

Another pilot, FC, quad, .... :

https://www.youtube.com/watch?v=9LC7T9ozG3s#t=18
and
https://www.youtube.com/watch?v=9LC7T9ozG3s#t=58

And I know yet another person that told me yet the same.

It's always to the left side and if you don't expect it, and that happened to me, you can almost loose control and slam the quad in the ground if you're too low.
Like I said, if it was only me I would assume it was a pilot or quad issue, but seeing two other having the exact same issue I'd say that might be something on the software.

Does anyone else had this issue happening as well?

Have you tried upgrading firmware....
iterm reset stuff was bugged by mistake in one of the releases...

I can't answer for the other guys, but I'm running the latest version, I keep it always up to date.
Plus if it was iterm reset it would affect turning for both sides no?

My last check was to swap the FC but as I saw more having the same issue. I may still try it.

IceWind wrote:What I see is when doing turns to the left and when yaw is used at some stage the quad spins out of control to that side. I noticed it
quite well when doing slow left turns when the yaw is used.

Does anyone else had this issue happening as well?

Yes, I've had this issue and confirm it's still present in latest baseflight firmware and also in cleanflight.

I notice it more frequently on my smaller 250 size quad on normally windy days. And yes, always when yawing to the left.

Last time I had the issue I was flying on an empty beach in the wind, I've also had it in my local park, again in the wind.

No flight modes were enabled, acro only. My yaw & pitch rate and pids are non default. pid controller is default. My yaw rate was probably 0.04, pitch rate probably 0.02.

Thanks for confirming this issue, at least now that multiple people have reported it an investigation and fix should be more likely.

IceWind, could you open an issue on the baseflight issue list, I would, but I can't ...

i also had that issue in the past - lost it lately.
smells like an high frequency noise issue.

added:
i just flew the 08-15 variant of baseflight.
i get unwanted changes in the motorspeed after hard accelerations.

brm wrote:i also had that issue in the past - lost it lately.
smells like an high frequency noise issue.

Interesting brm, is there anything I should record to veryify this? Do you think grabbing a screenshot of the configurator showing acc/gyro data would be useful - i could record them at high frequency at various throttle positions if you think that would help identify the problem.

@dominicclifton
you can collect high speed gyro data and throw it against a fft algorythm.
what is interesting to see are the spikes beyond the propellerwash.

on my medium quad i had no gyro noise - so i removed my pt1 element.
will add it again on the smaller quad and then i will see.
in essence the filter mimics a first order gauss-markov filter.
which is prob. what we need ...

I have been having a slightly annoying control problem, and after posting this in an rcgroups thread it seems Im not alone. THis happens in acro mode, when inclined at a forward angle and centering the stick or applying a little back elevator to reduce the flight angle, the quad will often violently over-correct in that direction. IT seems to want to level itself and even goes beyond that. You can see one such occurrence in the very beginning of this video (7s mark):
https://www.youtube.com/watch?v=CbD0YOhmjJ8
It overcorrects so badly, it even flip upside down in the other direction.

This next video is from someone else, here you can see it a little bit at the 6s mark (pilot says he centered the stick there), and more clearly at the 16s mark:
https://www.youtube.com/watch?v=DHQFHmr6gp4

I checked my telemetry logs to make sure it wasnt failsafe kicking in, but my RSSI was never even low. I also made sure I never somehow accidentally switched to horizon or angle mode, which I didnt (I do use horizon sometimes for flips, but thats not when I have this problem). Also for the record, my cg is spot on.

Are accelerometers ever used in acro mode? I may be wrong, but I have the distinct feeling that they are used and sometimes baseflight seems to try to "help" me. For instance when doing flips. Is this at all possible?

Vertigo wrote:I have been having a slightly annoying control problem, and after posting this in an rcgroups thread it seems Im not alone. THis happens in acro mode, when inclined at a forward angle and centering the stick or applying a little back elevator to reduce the flight angle, the quad will often violently over-correct in that direction. IT seems to want to level itself and even goes beyond that. You can see one such occurrence in the very beginning of this video (7s mark):
https://www.youtube.com/watch?v=CbD0YOhmjJ8
It overcorrects so badly, it even flip upside down in the other direction.

This next video is from someone else, here you can see it a little bit at the 6s mark (pilot says he centered the stick there), and more clearly at the 16s mark:
https://www.youtube.com/watch?v=DHQFHmr6gp4

I checked my telemetry logs to make sure it wasnt failsafe kicking in, but my RSSI was never even low. I also made sure I never somehow accidentally switched to horizon or angle mode, which I didnt (I do use horizon sometimes for flips, but thats not when I have this problem). Also for the record, my cg is spot on.

Are accelerometers ever used in acro mode? I may be wrong, but I have the distinct feeling that they are used and sometimes baseflight seems to try to "help" me. For instance when doing flips. Is this at all possible?

acro mode is gyro only.
there are two possible sources:
- gyro noise
- vibrancy of the frame

we will what what to do against it ...
but first there is:
- birthday party
- family
...

in the 2nd video i have nearly the same sound when the problem occurs.
the motorspeed rises for a few moments.

acro mode is gyro only.

Thats what you'd think; but for instance if you enable throttle angle correction, then it no longer is; then even in acro mode the acc is being used. I had that enabled initially, and figured that might be the source of the problem, but disabling it doesnt seem to cure the problem and the other people reporting the issue never enabled it. But perhaps acc is used in other places too, Im thinking TPA or something similar?

there are two possible sources:
- gyro noise
- vibrancy of the frame

I doubt its vibrations. There are none to be felt, all props are balanced and the video is pretty much jello free, and my mobius is taped straight to the frame, no rubber mounts or anything. It also happens more or less predictably, not random. Pretty much every time it happens now, I knew there was a chance it was going to happen: typically forward flight, slight easing off or light pulling back on elevator stick, and the error also always seems to rotate backwards far too much, never rolling for instance and Ive never seen it happen when applying forward stick.

Gyro noise, Ill let you explain when you have time.

there is a difference between static and dynamic balancing.
the later is ok - the other is wasted time.

I dont have a vibration problem. My problem appears identical to what Thorvald reported here:
viewtopic.php?p=53330#p53330
and antix here:
viewtopic.php?f=23&t=1947&start=900#p53402

The only difference is that upgrading the firmware apparently cured it for them, while it doesnt for me. FWIW, Im using a white Rev5 funfly board.

edit: perhaps best continued in this new thread created by another user with the same issue:
viewtopic.php?f=22&t=5551

Vertigo wrote:I dont have a vibration problem. My problem appears identical to what Thorvald reported here:
viewtopic.php?p=53330#p53330
and antix here:
viewtopic.php?f=23&t=1947&start=900#p53402

The only difference is that upgrading the firmware apparently cured it for them, while it doesnt for me. FWIW, Im using a white Rev5 funfly board.

edit: perhaps best continued in this new thread created by another user with the same issue:
viewtopic.php?f=22&t=5551

Did you type "defaults" without quotes in CLI after you've upgraded firmware?

I even did a full chip erase since I was experimenting with other firmwares. then reimported my dump. All the settings are where I want them, nothing weird there.

Concerning the yaw issue reported esp. on miniquads.
BRM pointed out that it is most likely a problem of gyro noise and/or vibrancy of the frame. I agree with that, however the mixer may play a part within that problem as well. When maxing out a motor (like sharp turns etc.) the current multiwii mixing can do funny things (seen that..) esp. on the yaw axis (most sensitive for that). That's why I did a dynamic compression of the range in those situation. It basically scales the actually requested PWM range (by the PID controller) to the physically available PWM range. From my flight testing it is better so enabled by default in my stuff. You can check out the altered mixer part here: https://github.com/Crashpilot1000/TestC ... xer.c#L400 .
Cheers Rob

Crashpilot1000 wrote:Concerning the yaw issue reported esp. on miniquads.
BRM pointed out that it is most likely a problem of gyro noise and/or vibrancy of the frame. I agree with that, however the mixer may play a part within that problem as well. When maxing out a motor (like sharp turns etc.) the current multiwii mixing can do funny things (seen that..) esp. on the yaw axis (most sensitive for that). That's why I did a dynamic compression of the range in those situation. It basically scales the actually requested PWM range (by the PID controller) to the physically available PWM range. From my flight testing it is better so enabled by default in my stuff. You can check out the altered mixer part here: https://github.com/Crashpilot1000/TestC ... xer.c#L400 .
Cheers Rob

i would not reduce output range.
instead you should limit/dampen the input.
phsics is easy: after an action you will see the counteraction.
concentration on the later does not solve the problem.

i have prepped an older variant and will test this in gyro mode only.
the weather is a bit shitty ...

Seems the channel mapping is wrong ... inherited form multiwii

I did solve by deleting all channel mapping in the sbus, spektrum, sumd and ppmsum drivers.


Then i readded channel mapping in computeRC, but this time on the left side of assignment


Now finally, i can read the channel order on transmitter and put it in the map without additional guesswork.

Vertigo wrote:I dont have a vibration problem. My problem appears identical to what Thorvald reported here:
viewtopic.php?p=53330#p53330
and antix here:
viewtopic.php?f=23&t=1947&start=900#p53402

The only difference is that upgrading the firmware apparently cured it for them, while it doesnt for me. FWIW, Im using a white Rev5 funfly board.

edit: perhaps best continued in this new thread created by another user with the same issue:
viewtopic.php?f=22&t=5551

mcfg.gyro_lpf = 188; // supported by all gyro drivers now. In case of ST gyro, will default to 32Hz instead
and the problem is gone.
it was what i said.

Plüschi wrote:Seems the channel mapping is wrong ... inherited form multiwii

I did solve by deleting all channel mapping in the sbus, spektrum, sumd and ppmsum drivers.

Code: Select all

// This stuff:
data = 988 + (spekChannelData[mcfg.rcmap[chan]] >> 1);   // 2048 mode
// becomes this:
data = 988 + (spekChannelData[chan] >> 1);   // 2048 mode

Then i readded channel mapping in computeRC, but this time on the left side of assignment

Code: Select all

rcData[mcfg.rcmap[chan]] = rcReadRawFunc(chan);

Now finally, i can read the channel order on transmitter and put it in the map without additional guesswork.

Are you sure this doesn't break anything else?
If so, you could open an issue/pull request on github...

I had my cjmcu TX settings in mode 1 instead mode 2, which caused the confusion

I did retest with graupner and futaba, and the way it was is fine, no need to do anything.
Seems the mwii problem was already solved in baseflight.

brm wrote:

Crashpilot1000 wrote:Concerning the yaw issue reported esp. on miniquads.
BRM pointed out that it is most likely a problem of gyro noise and/or vibrancy of the frame. I agree with that, however the mixer may play a part within that problem as well. When maxing out a motor (like sharp turns etc.) the current multiwii mixing can do funny things (seen that..) esp. on the yaw axis (most sensitive for that). That's why I did a dynamic compression of the range in those situation. It basically scales the actually requested PWM range (by the PID controller) to the physically available PWM range. From my flight testing it is better so enabled by default in my stuff. You can check out the altered mixer part here: https://github.com/Crashpilot1000/TestC ... xer.c#L400 .
Cheers Rob

i would not reduce output range.
instead you should limit/dampen the input.
phsics is easy: after an action you will see the counteraction.
concentration on the later does not solve the problem.

i have prepped an older variant and will test this in gyro mode only.
the weather is a bit shitty ...

Last week I was away so not possible to continue to test this.
But I'm back online and I can go back to testing, if you have a example code I can give it a try.

I can replicate the issue quite easily. My only doubt is that it mostly happens when turning to the left, I don't even recall having it happening when
turning to the right. Same for other people that I discussed this with.

IceWind wrote:

brm wrote:

Crashpilot1000 wrote:Concerning the yaw issue reported esp. on miniquads.
BRM pointed out that it is most likely a problem of gyro noise and/or vibrancy of the frame. I agree with that, however the mixer may play a part within that problem as well. When maxing out a motor (like sharp turns etc.) the current multiwii mixing can do funny things (seen that..) esp. on the yaw axis (most sensitive for that). That's why I did a dynamic compression of the range in those situation. It basically scales the actually requested PWM range (by the PID controller) to the physically available PWM range. From my flight testing it is better so enabled by default in my stuff. You can check out the altered mixer part here: https://github.com/Crashpilot1000/TestC ... xer.c#L400 .
Cheers Rob

i would not reduce output range.
instead you should limit/dampen the input.
phsics is easy: after an action you will see the counteraction.
concentration on the later does not solve the problem.

i have prepped an older variant and will test this in gyro mode only.
the weather is a bit shitty ...

Last week I was away so not possible to continue to test this.
But I'm back online and I can go back to testing, if you have a example code I can give it a try.

I can replicate the issue quite easily. My only doubt is that it mostly happens when turning to the left, I don't even recall having it happening when
turning to the right. Same for other people that I discussed this with.

mcfg.gyro_lpf = 188;
set the gyro_lpf value using the cli to a higher value.
doing so i am unable to reproduce my problem.

Got it, going to try that.

But raising so much the LPF won't leave the quad a bit mushy?
I want to keep my super fast and crisp rolls, flips and turns.

IceWind wrote:Got it, going to try that.

But raising so much the LPF won't leave the quad a bit mushy?
I want to keep my super fast and crisp rolls, flips and turns.

this is the 1st step.
rising the gyro_lpf means reducing the delay.

brm wrote:

IceWind wrote:Got it, going to try that.

But raising so much the LPF won't leave the quad a bit mushy?
I want to keep my super fast and crisp rolls, flips and turns.

this is the 1st step.
rising the gyro_lpf means reducing the delay.

Mmmm doesn't the lpf works are a filter, filtering out unexpected spikes in the gyro readings?
Well either way, less talk and more testing here.

I've started by moving to 98 the gyro_lpf, going to fly the mini in a few and then depending on the results bump to 188.

IceWind wrote:

brm wrote:

IceWind wrote:Got it, going to try that.

But raising so much the LPF won't leave the quad a bit mushy?
I want to keep my super fast and crisp rolls, flips and turns.

this is the 1st step.
rising the gyro_lpf means reducing the delay.

Mmmm doesn't the lpf works are a filter, filtering out unexpected spikes in the gyro readings?
Well either way, less talk and more testing here.

I've started by moving to 98 the gyro_lpf, going to fly the mini in a few and then depending on the results bump to 188.

the 2nd step is adding a spike filter.
first we need to know if it's solving your problem.

Tested with 98 and it was no good. Slammed the quad in the ground while doing a fast turn at low altitude.
Wi'll try to test with 188.

IceWind wrote:Tested with 98 and it was no good. Slammed the quad in the ground while doing a fast turn at low altitude.
Wi'll try to test with 188.

i think you are fighting with gyro noise.
i don't expect that it will be much better with higher values.
time will tell until you are through the testing.

Where do you get those values from 98 and 188? Why not just have a round number?

strips wrote:Where do you get those values from 98 and 188? Why not just have a round number?

classic RTFM.
the datasheet from invensense says what to put in these registers.

brm wrote:

strips wrote:Where do you get those values from 98 and 188? Why not just have a round number?

classic RTFM.
the datasheet from invensense says what to put in these registers.

Thanks,
I wouldn't know to look at invensence. I thought the values was for Baseflight to do some magic.

They're also listed in drv_mpuXXXX.c as well. If you enter anything other than the value, it'll default back to 42.

By bad. Should have checked the code first.

Thanks.

The new binary doesn't work for me. Made a backup of my old configuration, updated the firmware with Baseflight Configurator (loading online firmware), restored the configuration. The Naze32 boots up just fine, I can switch flight modes, but as soon as I flip the arm switch, it becomes unresponsive. No reaction on USB, no reaction to throttle, all LEDs on.

Features I enabled: VBAT, TELEMETRY, MOTOR_STOP, PPM. Telemetry connected to a FrSky D4R-II.

Tried this on two copters, both with Naze32 Acro, happens on both of them. I'll try it without restoring from backup later today.

Same problem for me.
I have new Afro32 rev.5 and at monday it was flying good. Today installed new firmware without configuration restore, Setting minimum features I have unresponsible device after Arming.
Motor checking is correct, PPM is shown via Configurator. Last firmware have some time problems connecting to Configurator, See slow motion of copter immage at first screen, or wrong position of Receiver bars and Connection hold. Only full disconnect from USB can help.

Is it possible to get old firmware till new bugfixing? I have last week of good wether this Year next raining.raining.......

This should be the previous firmware hex from August (I just downloaded last week's version from Github):
https://dl.dropboxusercontent.com/u/642 ... flight.hex

Ok, tested some more. If FrSky telemetry output is enabled, the Naze32 instantly locks up when armed.

Telemetry has been fixed - new binary is up. Thanks for testing, guys.

Great...something new..and bf configurator is better and easier. And I see some new settings for GPS.

I've got an issue with Gyro Yaw.

I'm using a mpu6050 as a sensor.

I'm using the following test to make sure sensors are correct:
Tip board right - ACC ROLL, Gyro Roll Mag Roll should go up
Tip board forward ACC Pitch, Gyro Pitch Mag Pitch should go up
For above two action ACC and Compass Z should go down.
Rotate Clockwise - Gyro Yaw should go up
Sitting still Compass Z and Acc Z should be positive.

This is my understanding for Multiwii and I'm using Multiwii conf 2.3 with latest version of Baseflight Afro32 CLI version 2.3 Sep 29 2014 / 22:38:56.

EVERYTHING above tests ok EXCEPT for Rotate Clockwise - my yaw goes down.

I've tried align_gyro 5-8 but while that fixes Gyro, I cannot get bot Gyro Roll and Gyro pitch to then do the right thing - one will, but the other goes the wrong way.

Is anyone else seeing the same behaviour?

Is there a way to reverse the gyro.

I have the compass too and when I check my screen model against my board's movements, they screen model doesn't track the board smoothly. Gets a bit wacky / flippy.

Cheers,

Carl

wut
are you doing this on some homemade board where gyro isn't in standard orientation?

yes I am.

Pic here:

I've removed the sensor stack and have wired in a single gy-521 - mpu-6050.
The model now matches the board but seems to lose heading direction [yaw] slowly over time say 30 seconds.
However when I look at the gyro In multiwii conf 2.31 I still get yaw going down when I turn the board clockwise.
Also if I leave the align_gyro and align_acel at 0, the Acc readings seem crossed relative to gyro.
I cannot understand how that can be possible in a single MPU-6050.
Is that correct? Are the sensor tests above still accurate for baseflight?

Yeah, the old graph vs board movement instructions don't seem to work with baseflight. I adjusted align_acc to 2 which made the graphs match my first post. IE Acc / gyro roll and pitch match on board pitch and roll. However the model in Baseflight configurator becomes very unstable.

So did defaults and seems very stable. Calibrated gyros and acc but now when sensor is still I'm seeing the heading change by +1 degree every 3 seconds or so. This is just with the MPU-6050. No other sensors.

Timecop, is there any way to disable the mag board from the cli? Also, does the mag board effect the virtual quad model when I move the real board? I'm finding that the compass Z access is very high compared to x and Y. Maybe a faulty Mag?

Cheers and thanks,
Carl

You can't disable the mag board from the CLI.
I would suggest to look at the orientation on a naze and adjust the cli variable align_mag according to your orientation.
Also make sure that align_gyro and align_acc have the same value.

I think that would be a pretty cool feature to add. Yeah, I looked at the picture of a Naze32 and my compass is off by 90 cc.
Thanks. Hopefully I will get it all sorted.

timecop wrote:Telemetry has been fixed - new binary is up. Thanks for testing, guys.

i have just updated to 2.3 and since then, the arm switch doesnt work anymore in the gui, the switch where ARM is on flips, but doesnt turn green and the motor do not spin up if i move the thr stick. Any advice?



thanks

That part of the code wasn't touched.

Ok. These specific steps has blocked me from connecting to my naze32.

1. Install latest (october release) of Baseflight.
2. Start re set all settings.
3. Tick the "Third serial port" checkbox on the new tab page and hit save.

Now I can not connect with USB any more. I have tried to reflash the board. But when I try to flash I get "No response from the bootloader, programming failed".

Same result when I short the bootloader pads. But then it says: "Communication with bootloader failed".


If I try with hercules and send the reboot char, all three leds do not light up.

Flash loader demonstrator also do not want to connect, even though I start the naze with bootloader pads shorted so that only the blue led turns on.


Any ideas on how to connect to it again? I wasn't finished with the configuration, so now my spider hex is grounded :-/

In that long post I missed what it is that you actually did and what is it youre trying to do.
What is the "third serial port" checkbox?