Arduino Mini 05, I2C noise

So I'm trying to build a Micro Drone/Quadcopter... All electronics are working nicely... I can nicely control all 4 motors, there is a accel/gyro/magneto (MPU9150) in place which works properly, except for when I start turning the motors at a certain rate...

So what did I do? I wrote a simple sketch which turns all 4 motors slowly (analogWrite(10)), when I turn the quad at about 45 degrees it stops all 4 motors (liek it's supposed to), at this rate the motors turn smoothly when I keep it leveled, and even when I move it around "within the 45 degree ranges"... But when I turn up the analog write rate (40) the gyro appears to send wrong readings, because the motors start-stop-start-stop when the quad is perfectly leveled and not moving...

Now I'm currently just using the raw data of only the 3 axis of the accelerometer, I do know that I need special algorithms to combine accel and gyro to get proper readings because of gyro drift, accelerometer being desturbed by the physsical vibration of the motors etc. etc.

But I'm pretty sure that the issue that I'm currently facing is due to some kind of interference on the analog ports (I2C, 4 and 5), usually this is solved by using the AREF right? but the Arduino Mini 05 (genuine) doesn't have one...

Does anyone have any ideas on how to solve this issue, or maybe I'm looking in the wrong direction?

Aref is the analog reference voltage. How on earth would it have any connection whatsoever with a digital 6DOF processor?

Paul__B: Aref is the analog reference voltage. How on earth would it have any connection whatsoever with a digital 6DOF processor?

It's connected using I2C (SCL SDA, ports A4 and A5), and it's 9DOF...

Still has nothing to do with AREF, then.

michinyon: Still has nothing to do with AREF, then.

SparkyRih: ... or maybe I'm looking in the wrong direction?

Let me put you out of your misery.

You need to understand.

Ports A4 and A5 - same as ports A0 to A3 - are digital ports which happen to have extra interface circuitry to optionally (and individually) multiplex them to an ADC in the chip. There are also ports A6 and A7 on the SMD chips which share the same analog multiplexer but have no digital interface.

An in addition, ports A4 and A5 have yet another interface connected to them which is the I2C module.

Paul__B: Let me put you out of your misery.

You need to understand.

Ports A4 and A5 - same as ports A0 to A3 - are digital ports which happen to have extra interface circuitry to optionally (and individually) multiplex them to an ADC in the chip. There are also ports A6 and A7 on the SMD chips which share the same analog multiplexer but have no digital interface.

An in addition, ports A4 and A5 have yet another interface connected to them which is the I2C module.

Ok, but what is causing my incorrect reading then?

SparkyRih: Ok, but what is causing my incorrect reading then?

Don't know, but as I understand it, one of the problems with quadcopter design is the danger of motor vibration affecting the gyros and accelerometers - which would kick in at certain speeds.

Daresay you will have to figure that out. Should be a fair bit of discussion on the subject somewhere.

Paul__B: Don't know, but as I understand it, one of the problems with quadcopter design is the danger of motor vibration affecting the gyros and accelerometers - which would kick in at certain speeds.

Daresay you will have to figure that out. Should be a fair bit of discussion on the subject somewhere.

I know about the motor vibration, I wrote about that in my initial post, but that has nothing to do with the current behavior...

But I think I found something, the noise on the I2C lines has to be dealt with in both hardware and software...

I think I can get it right by changing the default 100KHz TWI_FREQ in the wire library to 400KHz, and then adding some pull-up resistors on the I2C lines...

Yes you always need pullup resistors, use 4K7. Making the bus run faster will make your problem worse though.

To diagnose electrical noise, you really need an oscilloscope so you can see what's really going on. The noise may be coming in on the power supply, for example.

For longer I2C buses (10cm or more) don't run the SDA and SCL side-by-side. Capacative coupling between the two will distort the signals terribly. Put a ground or power wire in between. Extra strong pullups can usually help. 4k7 is my starting point - you could probably go to 1k or less.

MorganS: To diagnose electrical noise, you really need an oscilloscope so you can see what's really going on. The noise may be coming in on the power supply, for example.

For longer I2C buses (10cm or more) don't run the SDA and SCL side-by-side. Capacative coupling between the two will distort the signals terribly. Put a ground or power wire in between. Extra strong pullups can usually help. 4k7 is my starting point - you could probably go to 1k or less.

I already planned on using an oscilloscope :)

I just did so, and I did change the frequency to 400KHz (I didn't read these posts, so I didn't read about the comment about making it worse)...

It's hard to measure while the motors are running, but when the motors are not running the SCL is very clear... But the SDA (50KHz, shouldn't it be 400KHz as well?) does seem to be not so clear....

We tried adding some pull-ups, 1.5K made the MPU9150 unusable (the arduino does recognize it, but it doesn't get any readings)...

We tried several values of the pull-up resistors, but we couldn't find any change in behavior...

Wires a just a couple of mm, it's really a small quad that fits in one hand...

But the SDA (50KHz, shouldn't it be 400KHz as well?)

No it should not. It is data and so only changes when the zero changes to a one in the data so a data byte of 11110000 will look like only one cycle.

It's hard to measure while the motors are running, but when the motors are not running the SCL is very clear

Then you need to suppress the noise from the motor. Separate regulators for the motor and the I2C device are often used or heavy decoupling on the motor supply can be used.

I think I found the issue!

I removed the pull-ups, I just connected the IMU to the Arduino Mini 05 using I2C…

I was reading raw data of the accelerometer the entire time, thinking it would not affect the behavior that I was testing, but man I was wrong…

So I started to try to implement the complementary filter, and I saw some minor changes in behavior, it got slightly better (but still far from usable)… So I used the Kalman filter, and again improvement, but still not usable… But when I try to hold the frame steady (by holding all 4 arms of the quad as steady as possible in an attempt to reduce as much motor vibration as possible), the behavior of the quad is ALMOST acceptable…

So I think the frame is the biggest issue here… So I guess I can say that the I2C bus should be perfectly fine right?

SparkyRih: So I think the frame is the biggest issue here... So I guess I can say that the I2C bus should be perfectly fine right?

Do I not seem to recall saying that some half a dozen posts ago?

Paul__B: Do I not seem to recall saying that some half a dozen posts ago?

No you don't... I don't know about that, I forgot I guess XD (No just kidding, I know you did, and you were right)

I just didn't believe that it would have this big of an effect, the effect which these "small vibrations" have is seriously huge...

Also, when I "squeeze" the plastic body a bit with my fingers, it finally does what it's supposed to do, even at "flyable motor speed"...

SparkyRih: So I guess I can say that the I2C bus should be perfectly fine right?

Read this and then put the pull up resistors back.

http://www.dsscircuits.com/index.php/articles/47-effects-of-varying-i2c-pull-up-resistors