On power and I2C issues

A project log for krex

Kyle's robotics experimentation platform.

Kyle IsomKyle Isom 07/11/2019 at 17:210 Comments

I haven't completely sorted out the power issues; they seem to be somewhat mitigated by ramping up the motors (which I'm doing manually). I still get random shortages, though. I wonder if it's just drawing too much power, so I need to consider that. The datasheet mentions a max of 170mA max draw at 3V, and looking around on the internet makes it look like it's under 200mA. So, let's say 200mA per motor * 4 motors, which is 800mA. Now the motor hat is rated to provide 1.2A per motor with a max draw of 3A, so it seems like that's well within the design specs.

The other problem I'm facing is with the I2C bus. I can talk to the motor controller just fine, but I'm having issues talking to the IMU with what looks like a bus issue. Occasionally, there are arbitration issues on the bus, random NAKs, and the rest of the time it's a crapshoot whether the who am I register (which should return a fixed value) actually returns that value. I'm using the Linux i2c-dev library, which provides a file descriptor onto the bus. When it fails, I get one of two issues: "remote GPIO failed" or "resource temporarily unavailable." I haven't correlated the two yet to figure out which is the arbitration issue and which is the NAK.

The arbitration issues sound like competing masters. The IMU (an MPU-9250) has a master mode, so I should probably make sure that's disabled.

Hardware-wise, I basically have this:

jetson -> motorhat -> expander -> IMU

The expander is just a solderable breadboard that acts as a bus multiplexer: it lets me connect a bunch of things to the I2C bus. One row of pins is connected to the motor hat's I2C pins (which break out the I2C bus from the Jetson), ground, and a 3.3V connection. The IMU is a 3.3V device and it's definitely powered.

Both the motorhat and the IMU have pull-up resistors, so that's something else to consider.

So, the next steps to sort out the I2C problems are

And the next steps for debugging the power problems are