LSM303 (9-dof board) "crashing"?

[jrjbertram]

Hi,

I am seeing something weird with my 9-dof board. I'm starting to integrate several working pieces of a robot together... Auduino, CC3000, and 9-dof breakout board w/ LSM303. I'm finding that when I start up my motors to rotate my robot around, the LSM303 (I *think*.. could be one of the other devices on the 9-dof breakout board) seems to get "stuck" at a value... even as the robot rotates.

I sort of expected something to go wrong... I'm firing up dc motors only a few inches away from the sensor... but the part that has me puzzled is after I reset the board (either via serial monitor or via the reset button on the CC3000 shield), I then am unable to 'begin' the LSM303's accel class. All that class is doing is reading in a control register to see what value it is... the value I get back is 0x0, so the class's 'begin' method bombs out. After multiple resets (I've tried as many as 10-15 or so)... still can't get it to communicate.

If I power cycle the board by removing the USB serial cable, then reattaching it, I'm able to "clear out" the error. When I reconnect the serial cable, I'm able to see that I get past the init of the LSM303 and friends, and I see valid values coming out of it again.

As a "stupid check", when I was seeing this "hang", I loaded the LSM303's acceleration sample sketch onto the board, and it too was unable to complete the 'begin' call. After a true power cycle, it was able to start spitting out the raw acceleration values. *brain exploded*


So -- my question for you all is (a) whether anyone is seeing anything like this ... long shot.... or (b) whether its possible to "crash" the I2C bus in such a way that a reset won't clear it? I haven't seen anything like that with an Arduino previously.


A few other salient details...
* I'm using the Due's dedicated I2C pins and they are connected only to the 9-dof board. I'm not sharing the I2C bus with any other devices.
* If I hand rotate the robot without running the motors, I'm able to get readings that seem reasonable from the sensor for as long as I care to leave it on. Have seen no previous hangs / issues.
* The motors are powered from their own DC battery, and are operated through an h-bridge. The motor battery and Arduino power/USB do share a common ground... I've got a wire running from "ground" of both circuits... was assuming that's a necessary/good idea.
* The CC3000 runs fine when the motors are activated... no crashes... continues to spit out packets.

Also... I'm possibly unfairly targeting the LSM303 because its the first I happen to initialize of the sensors on that 9-dof board. I could run other combinations of tests on the gyro or the magnometer.

My next steps are going to be to dig into the datasheet for the part... I'll also probably try to put an I2C analyzer on the bus maybe?

Anyone have any other ideas..? Thanks in advance,

- Josh.

[adafruit_support_bill]

I know they have had some difficulties with the wire library on the Due. It is one of the reasons why 1,5,x is still in Beta. But I'm not sure if that is the reason for the issue you are seeing.

If I understand correctly, you are only seeing the problem when you rotate the sensor array via the DC motors. If that is the case, I'd suspect some sort of interference. Things to try:
Route sensor wires away from the DC motors and motor wiring as much as possible. You might also consider shielding the wires.
Add capacitors to the DC motors to suppress the brush noise. 1uF each between the motor terminals and from each motor terminal to the metal case of the motor. (This needs to be done at the motor. It doesn't work if you add them at the other end of the wire.)

[jrjbertram]

Was poking around with this some more. I added 1 uF capacitors between the motor terminals, that didn't seem to make a difference. (Haven't yet added capacitors between the motor case and each motor terminal... I have space issues and the caps I found at radio shack are too big.)

One thing that DOES seem to help... adding "extra" wires between the Arduino's ground and my proto board's ground strip. My robot seems to run for maybe 30 seconds instead of dying after 1-2 seconds. I'm wondering if when I run the motor the ground in the circuit is somehow moving?

I have two DC batteries that power the robot.. one drives the motor (via an H-bridge circuit), and one drives the electronics. I connected the two batteries negative terminals together to form a common ground for the circuit, which I assumed would be needed for the H-bridge to work correctly.

In general, there should be a common ground between your motors' circuit and your arduino's electrical circuit, correct? Or do I need to use an opto-isolator and separate the circuits from each other entirely?

I have a cheap oscilloscope (a bitscope).. would a good test be to connect it between various ground points in the circuit and look for some kind of voltage spike when I turn on the motors? (I'm a little concerned that the voltage spike could exceed the 20v input limit on the bitscope's inputs though... but if that were the case, I'd probably be smoking components left and right?)

Thanks in advance for any ideas you might have...

- Josh.

[adafruit_support_bill]

One thing that DOES seem to help... adding "extra" wires between the Arduino's ground and my proto board's ground strip.

Motors do tend to have fairly 'peaky' current demands. And depending on how you have things wired up, those current peaks could be messing with your ground. Providing dedicated power and ground connections for your motors and for the rest of the circuitry can help avoid those problems. If you post some photos or a diagram of your circuit we can take a look for potential ground issues.

[jrjbertram]

Finally got some time to play with this again. Just a followup that adding in optoisolators fixed my issue. The motor control circuit is now electrically separate from the Arduino / LSM303 / etc circuit, and I no longer see the "hang" on the I2C bus. Robot now moves around and does a basic sense-and-avoid of obstacles... fun times!

Thanks again for the help along the way,
- Josh.