Is anybody successfully using RoboRIO I2C?

I asked this before and got crickets. Please forgive the repost, but is ANYBODY having success with anything plugged into the I2C pins on the RR?

The I2C pins on the NavX breakout work fine for us, but the same device plugged into the RR pins runs for a while then drops out.

1 Like

We did get some Roborio to Arduino I2C comms to control a set of RGB LED’s. One hurtle to over come was the requirement of 5k pull-up resistors from SDA and SCL to VCC. What other question might you have?

We saw similar looking symptoms in 2015 on a gyroscope, but presumed it was something to do with our wiring. I don’ think we’ve tried it much since.

Got any code we could look at?

We plug an arduino into it and the arduino is plugged into a pixy2 for vision. We just use SDA and SCL for it if that helps. I don’t know exactly what you need it for so I can’t really say whether or not what you’re doing would work, but I wish you the best of luck

I’ve never found the “onboard” I2C pins to work correctly at all. I’m not sure if it’s a library issue, hardware (wasn’t aware a pull up resistor was needed), or something else entirely. Connecting the same sensor (LIDAR in 2017) to the MXP solved the issue entirely.

1 Like

Ditto.

This was a couple years ago so I don’t remember the specifics but we put a scope/analyzer on the RR and the I2C wasn’t behaving properly so we go through the NavX for our I2C needs.

By this do you mean you plug in to only those two pins on the RR, with 3.3v and ground handled elsewhere?

I’ll run the pullup question by our EE mentor. Does the NavX breakout board provide these itself?

We used the onboard I2C for communicating with an Arduino we were using for light sensor data, and it worked fine for us, didn’t need a pullup resistor. If you notice a trend of about how long it takes for communication to drop out, I can see if we can try and reproduce the issue when we have some free time.

We did have issues with the sensor data later in matches, but we currently believe that was because of the bad batch of batteries because that issue didn’t show up in the shop or on the practice field.

Back in 2015 we got one of the earlier version of the Lidar Lite to talk, but for some reason were only able to get the i2c port on the MPX breakout to work, not the one on the RIO. Never made it on the robot.

Every year I keep asking different kids to hook up and test various i2c sensors to the RIO directly, every year if we do end up using them it is through an arduino and the data is then returned via DIO pins or a serial conversation.

Never seems to get high enough on the priority list to get done properly.

We have a pixy2 working over I2C, but had to get 5V from the VRM (since the I2C port only has 3.3V available).

Do you have any idea what what I2C clock speed that device operates at? With an Arduino connected to the I2C, we found that we had to set the clock speed on the Arduino to match that of the RoboRio.

Wire.setClock(400000); // set clock speed to fast to match RoboRio I2C clock speed

Yes. The arduino was powered through the voltage regulator module.

We’ll have a closer look at this too. I can’t think of why the onboard I2C would use/expect a different clock speed than the one coming through the MXP breakout, but clearly something is different between them.

Looking at the pixy2 docs, it looks like they have internal pullups, so that’s a point for that theory. Looking at the line follower schematic, I don’t see internal pullups. It’s still unclear why it works through the MXP port though, as I don’t see any pullups there either.

We will definitely give it a try with external pullups, probably later this week. We’ll post our findings.

Clearly others are seeing similar problems, so if something works for us maybe it will help them too.

Thanks to all for the input!

We use the roborio i2c directly to an arduino for led controls.

roborio code:

final I2C arduino = new I2C(Port.kOnboard, 4);
final String data = "ENABLED:000";
boolean success = arduino.transaction(data.getBytes(), data.getBytes().length, new byte[0], 0);

arduino code:

String state = "";
String additionalInfo = "";
boolean stateChanged = true;

void setup() {
  Wire.begin(4);
  Wire.onReceive(receiveEvent);
}

void receiveEvent(int howMany) {
  String input = "";

  while (Wire.available() > 0) {
    char n = (char) Wire.read();
    if (((int) n) > ((int)(' '))) {
      input += n;
    }
  }

  int index = input.indexOf(':');
  if (input.substring(0, index) != state) {
    stateChanged = true;
  }

  state = input.substring(0, index);
  additionalInfo = input.substring(index + 1);
}

We use both I2C ports (Normal Onboard and Onboard MXP) with one Rev Robotics Color Sensor on each. They seem to work well.

Are you using external pullup resistors on either port?

I haven’t looked at it in awhile, but I seem to remember that the roboRIOI I2C port is at 400 kHz, 3.3v but 5v tolerant (substitute 5v from DIO power pin, MXP 5v or PI 5v).
Make sure you use the voltage required by your device.
The RoboRio I2C library uses 7 bit addressing (1 - 128) and 112 is the default address of the RoboRio. An Arduino, for example, uses 8 bit addressing. The clock and data I2C lines on the roboRIO have 2.2kOhm pullup resistors to 3.3v, so make sure that’s compatible with the I2C device.

The MXP I2c shares DIO 14/15 pins and those have a pullup, too.
MXP_DIO-I2C_Circuits

We’re using external pullup resistors on the MXP port. We’re not using any on the normal onboard port. Both I2C devices work as expected. After reading the NI roboRIO User Manual (refer to diagram that @Mark_McLeod posted) , I’m not even sure if the pullup resistors were needed.