Frequent FC Malfunction

[Nicksdesign]

After over 40 years of flying RC stuff, I'm used to occasionally 'dumb thumbing' one into the ground. But, I darned tired of my FC trying to commit suicide. Especially since it usually starts by trying to run me down immediately after leaving the ground.

The problem is that, perhaps as often as half the time, it ends the start up process with a pitch/roll value that is clearly not supported by the accelerometer data. I've seen values as far off level as 17*. The FC retains this error offset regardless of the accelerometer data values. Let me be clear, this is not an accelerometer calibration issue. Repeated recalibration will not clear the error. The only way I've found to clear the error is to pull the plug, wait a few seconds, and reconnect the power. This seems to always clear the error so well that I'm going to make it a normal procedure.

The specifics: My FC is a Crius SE clone from GLB. I'm running 2.2 downloaded a couple of days after the official release. I believe that I've encountered the problem before this release. Since the FC functions correctly if it initializes correctly, I think it is safe to assume that I have my config.h settings correct. This happens in mag hold & horizon mode. I have not experimented with angle mode or horizon mode only. It does not effect accro mode. The FC is not accumulating errors. The FC is not being moved during the initialization process and is powered up level.

I sincerely hope someone can help solve this. My memory to verify that my FC is not in suicide mode before attempting to fly is not reliable enough. I think it is reasonable to expect the FC to more reliable.

Nick

I swear, my spell check program adds as many error as it fixes!

[copterrichie]

Just for reference, is this the board you have?

http://www.goodluckbuy.com/mwc-multiwii ... kout-.html

ATMEGA328P microcontroller
· ITG3205 three-axis digital gyroscope
· BMA180 triaxial accelerometer
· BMP085 pressure sensor
· HMC5883L axis magnetoresistive sensor (electronic compass)

[Nicksdesign]

No, this is the one: http://www.goodluckbuy.com/f450-quadcop ... mbled.html

I know this FC is not necessarily the product of the highest quality factory, but I don't see this as a quality issue other than the possibility that my board is more prone to the problem. The fact that a recalibration of the accelerometer does not clear the error in offset tells me that something is not being done that should be. I can recalibrate in any position and while it is clear that the recalibration is redefining the raw data values to level, the FC's conclusion always retains the random offset.

I'm loath to use the word 'bug' and understand that I'm the beneficiary of a lot of quality programming, but this would be a very strange hardware problem. I also know that anything is possible regardless of what I think.

Nick

[timecop]

With reject parts that go into making these so that China can make a couple cents per unit profit, I wouldn't be surprised at all that this is hardware issue. Good such example is ADXL345s that used to be (and probably still are) available from China for like 50c/ea. But all those were rejects from factory, and had huge axis biases - to the effect of up to 30 degrees or more. So to keep this reject adxl "level" you had to tilt it in various directions up to 30 deg. If you calibrated ACC, of course it worked, but the range would be greatly reduced, since offset in one direction would use up resolution (i.e. on a -8192 to 8192 scale, instead of "level" being zero, it would be something like +3000).

Anyway, tl;dr version: it is very likely that you do indeed have crappy hardware, maybe bad bypassing on the accel, dodgy/reject chip that fails self-test half the time, noisy 3.3V power supply, the possibilities are endless.

[Nicksdesign]

The problem may be unusual. But that combined with inexpensive hardware doesn't prove that it's a hardware problem any more than it proves that it's a software problem.

Nick

[Hamburger]

The problem may be unusual. But that combined with inexpensive hardware doesn't prove that it's a hardware problem any more than it proves that it's a software problem.

Nick

It is fact we do not hear such error reports very frequently. I take this as a strong indicator it is not a software problem.
Besides, no easy way for anyone else apart from you to track down the error you describe. Until further notice for other boards with same symptom it will get attributed to singular hardware issue - that is something we have heard before.
Sorry, I propose you get another board.

[Paulmann]

Hi,

I have sometimes the Problem in Level Mode when the I_Gain-Parameter of level is not set to zero.

[copterrichie]

ATMega328 flight controllers are very inexpensive, it would be very easy to exchange it to see if that is the problem.

[Nicksdesign]

I appreciate all help. The easiest and least expensive way for me to solve this problem is to just remember to check for it. When it shows up, cycle the power and the problem is gone. I can cycle power for hours and the problem doesn't show up. It only shows up when the power has been off for a long time, and then not always. As it so often happens, when you want the problem to occur, it just won't.

Replacing the board likely would also eliminate the problem. But, the engineer in me would like a better answer. If the cause is unknown, then there is no way to avoid it showing up again.

In my experience, there are times when rare problems occur when the cause can be either hardware, or software, or both. Sometimes hardware performance can approach the specification limits and this may be rare enough that the software doesn't handle it and the 'answer' is just get new hardware and thus likely avoid the rarity. Timing issues can cause this: the software works so well that the problem rarely shows up and it's easier to just blame the hardware and get new hardware when a small change in the software may be a more permanent fix. In my experience, hardware people tend to blame software and software people tend to blame hardware. And this can happen when the solution could be a change in either.

So, perhaps, consider this a favor. Is there a value generated during initialization that can cause this effect that is never recalculated even with a re-calibration of the accelerometer? I'm willing to look into the source code myself but I don't know where to start and MultiWii does a lot of nice things with so many options that the code is very hard to trace. I've reverse engineered complex software before, but it's not the sort of thing I'd like as a hobby.

Nick

[timecop]

It only shows up when the power has been off for a long time, and then not always. As it so often happens, when you want the problem to occur, it just won't.

100% hardware issue.

[Nicksdesign]

I think if I try to take this any farther, I'll be crossing into 'dead horse' area. So, unless someone would like to help me figure out where and how the 'hardware defect' is creating the erroneous result, I'm done with this thread.

I want to thank those who took the time to read and respond to this thread.

Nick

[timecop]

You're welcome to send it to me and I'll take a look.
Or you can use the source (you know, thats why its open), and write a simple testcase in arduino that ONLY reads accelerometer, and dumps its data.
then look at the stuff and see whats wrong.

When several people with a clue tell you its hardware (dodgy components/soldering/caps/whatever), you should believe it instead of insisting it has something to do with software.

[Nicksdesign]

Timecop, I did not insist it was software. I know, and knew all along that it is a result of an unusual hardware performance variation. That is a 'Duh'! But, there is also no proof that it is defective hardware. To prove that, it would have to be known how the problem is getting into the result and from that to comparing against the hardware spec. It is not rare for software to constrain the hardware to a subset of 'in spec' performance. It happens even in pure hardware designs too. Hardware performance numbers, just like anything else, vary within the spec range and most never gets close to the limits. It's nice that software performance only varies with the system clock. Working 99.9% of the time, isn't proof that there isn't a vulnerability in the design, just a high probability.

My purpose for this thread was NOT to blame either hardware of software, but to try to identify the root cause of the fault because I would like to know. If I wanted the easiest most no problem no need to know how it works multirotor, I could have just bought a DJI Phantom. I choose MultiWii precisely because it is not a 'plug and play' solution.

Nick

[timecop]

I given you solution how to check the hardware.
Get to it.