anyone else use the I2C bus?

[Steve_Alaniz]

Hi All
I actually have a question. We figured out how to use the I2C bus and used a Devantech Electronic compass to give us feedback from the robot for positioning information. We thought about also using a Devantech ultrasonic detector on the same I2C bus but for some reason, we were only able to read one sensor at a time and the commands for the second sensor read were ignored. We asked the NI guy at nationals and he essentially said that "we didn't expect anyone to use this" so we never got an answer as to why we couldn't read multiple devices over the I2Cbus.

So two questions:
1) Did you use the I2C Bus? (Brag a little! I'd love to hear what you did.)
2) Were you able to read two or more devices?

Steve

[davidfv]

Originally Posted by Steve_Alaniz

We asked the NI guy at nationals and he essentially said that "we didn't expect anyone to use this" so we never got an answer as to why we couldn't read multiple devices over the I2Cbus

I guess the NI guys never met a bunch of FIRST robotics programmers. You give them data inputs, they will try to use them! Steve great job at trying to use the system to it's fullest. I will ask my programmers what they tried to do, I do not have the answer. I just hope that the NI will not underestimate the students in the future. They should know, "If it is there, someone will try to use it"

Great Job!

[Dave Flowerday]

Originally Posted by Steve_Alaniz

So two questions:
1) Did you use the I2C Bus? (Brag a little! I'd love to hear what you did.)
2) Were you able to read two or more devices?

Yes, we used I2C with 4 different devices. They are custom-developed modules for our crab drive wheels that each measure the speed of 2 wheels (1 driven and one idler wheel). We have 4 modules installed and 4 backups, and each has a unique I2C address. On startup, our robot checks to see which modules are on the I2C bus. If it matches the list of 4 that it knew about from last time (saved in a file on the flash disk), then it continues normally. If the list is different, it shuts down our traction control and requires the user to run a calibration routine (which drives each wheel motor individually to determine which sensor address is connected to each wheel).

The only issues we had with this were:
1) The I2C driver in WPIlib forces you to use a certain I2C "protocol" where the register address is always sent and then you can read or write up to 4 bytes. I would have preferred if it didn't impose this register address protocol on us (there's no reason in our application that we couldn't have issued a read without first writing a register address). This wouldn't impact you though since the Devantech sensors appear to use this fairly-standard protocol.

2) The I2C pullups in the digital sidecar were not sufficient to overcome the electronic noise on the robot. The sidecar uses the recommended value (3.6Kohm if I remember correctly). When we first tried our setup with those default values, we were getting corrupted readings a large percentage of the time (or the sensor wouldn't hear its own address because that was corrupted and it would simply not respond). We added an external 1Kohm parallel resistor to our SDA and SCL lines to increase the drive current (after checking the datahseets for the parts used inside the sidecar to make sure this wouldn't cause any issues) and that almost eliminated the problem. After that, once every few seconds we'd get a bad reading but mostly it was fine. It's possible this could have been your problem, but I'd have to hear more about what exactly happened when you hooked up both sensors to know for sure.

Anyway, long story short, yes it was possible for us to read multiple sensors on the I2C bus. Attached is an image of one of our crab drive modules showing the custom sensor board we built.

[MattD]

We used the I2C bus for our LCD menu system. Our display was purchased from New Haven Display. This was the only device we attempted to use.

Originally Posted by Dave Flowerday

1) The I2C driver in WPIlib forces you to use a certain I2C "protocol" where the register address is always sent and then you can read or write up to 4 bytes. I would have preferred if it didn't impose this register address protocol on us (there's no reason in our application that we couldn't have issued a read without first writing a register address). This wouldn't impact you though since the Devantech sensors appear to use this fairly-standard protocol.

We had a rather difficult time with this as well. From what I noticed, we could only send a register address and one byte of data. The LCD we used doesn't follow this scheme, but we were lucky in that every command starts with a 0xFE byte followed by another byte to identify the command. We just used 0xFE as the register address, so it looked like this:

...
	static const UINT8 kCommandPrefix = 0xFE;
...

/**
 * Send a command (without any parameters) to the LCD.
 * 
 * @param command The command to send.
 */
void LCD::SendCommand(UINT8 command)
{
	m_i2c->Write(kCommandPrefix, command);
}

From there on, we could only send a limited amount of commands (only those that did not require any parameters). Rather than asking the LCD to move the cursor to a specific location we had to keep sending move right/left commands. Also, text could only be written 2 characters at a time.

In the end, it did work, but it's kind of sloppy. I'm hoping that the I2C driver will become a little more flexible in the future.

[crake]

Originally Posted by davidfv

I guess the NI guys never met a bunch of FIRST robotics programmers. You give them data inputs, they will try to use them! Steve great job at trying to use the system to it's fullest. I will ask my programmers what they tried to do, I do not have the answer. I just hope that the NI will not underestimate the students in the future. They should know, "If it is there, someone will try to use it"

Seeing how there are FIRST veterans and mentors on both the NI and WPI teams, I disagree with these statements

In general, teams have only begun to tap the potential of the new control system. I'd love to see teams create sensors and other interfaces (especially off-season). There will also be improvements made from season to season which will advance the system capabilities.

So keep up the great work, and please do feel free to share

[virtuald]

We tried to use an I2C LCD from New Haven to work also, but unfortunately we weren't ever able to get it to work and gave up due to time constraints. I had noticed the same quirk with the I2C API on that, but it seems like we weren't ever able to initialize the device correctly or something.

We ended up doing our menu using using the DriverStation LCD when that ability was released, and thats worked for our needs perfectly.

Of course, now that I have my embedded web server working on the bot, I'm not quite as interested in the LCD at this point. Probably should try again though...

[crake]

Originally Posted by virtuald

Of course, now that I have my embedded web server working on the bot, I'm not quite as interested in the LCD at this point

That sounds cool - what info are you serving?

[virtuald]

Rather than repeating the information, go to the Google Code site that I created for the library: http://code.google.com/p/webdma/

Demo interface: http://www.virtualroadside.com/botface/index.html

Its pretty sweet. I'm uploading a video to YouTube right now that shows our robot being driven around using the web interface. Not particularly controllable since I didn't intend for it to be used in that way, but theres no reason one couldn't redo the interface to make that work (its mostly javascript).

[Steve_Alaniz]

Originally Posted by Dave Flowerday

Yes, we used I2C with 4 different devices. They are custom-developed modules for our crab drive wheels that each measure the speed of 2 wheels (1 driven and one idler wheel). We have 4 modules installed and 4 backups, and each has a unique I2C address. On startup, our robot checks to see which modules are on the I2C bus. If it matches the list of 4 that it knew about from last time (saved in a file on the flash disk), then it continues normally. If the list is different, it shuts down our traction control and requires the user to run a calibration routine (which drives each wheel motor individually to determine which sensor address is connected to each wheel).

The only issues we had with this were:
1) The I2C driver in WPIlib forces you to use a certain I2C "protocol" where the register address is always sent and then you can read or write up to 4 bytes. I would have preferred if it didn't impose this register address protocol on us (there's no reason in our application that we couldn't have issued a read without first writing a register address). This wouldn't impact you though since the Devantech sensors appear to use this fairly-standard protocol.

2) The I2C pullups in the digital sidecar were not sufficient to overcome the electronic noise on the robot. The sidecar uses the recommended value (3.6Kohm if I remember correctly). When we first tried our setup with those default values, we were getting corrupted readings a large percentage of the time (or the sensor wouldn't hear its own address because that was corrupted and it would simply not respond). We added an external 1Kohm parallel resistor to our SDA and SCL lines to increase the drive current (after checking the datahseets for the parts used inside the sidecar to make sure this wouldn't cause any issues) and that almost eliminated the problem. After that, once every few seconds we'd get a bad reading but mostly it was fine. It's possible this could have been your problem, but I'd have to hear more about what exactly happened when you hooked up both sensors to know for sure.

Anyway, long story short, yes it was possible for us to read multiple sensors on the I2C bus. Attached is an image of one of our crab drive modules showing the custom sensor board we built.

WHOA! Excellent Dave! Ok One thing I didn't mention was that we were using Labview and our issues with the devices was almost certainly the implementation of the I2C bus within Labview or a timing issue with reading the sensors within the FIRST program.
The second unit addressed just didn't respond, as if it were not even connected. We didn't have much time to play around with it so we didn't explored changing which we addressed first. We decided to wait until we could consult an NI guy and, well you know that story. I looked at their vi... as much as I was allowed, and saw that they had it fixed such that you had to send data when you addressed a register. We had to send a false data byte even though we only needed to address a register and then read. We correctly guessed the compass would ignore the extra data so it worked anyway.
I'll try the extra resistors when we work on it again. Thanks for the suggestion.
Your address scheme for the backup units is really elegant! Nice planning with the calibration mode! Nice crab system too! We didn't have time to add speed sensors, that's on our next years wish list

Seve

[Joe Hershberger]

Originally Posted by Steve_Alaniz

WHOA! Excellent Dave! Ok One thing I didn't mention was that we were using Labview and our issues with the devices was almost certainly the implementation of the I2C bus within Labview or a timing issue with reading the sensors within the FIRST program.

I'm surprised you're having trouble... I tested talking to 3 different sensors on the same bus at the same time, using the LabVIEW examples. Are you sure you could address your second sensor at all?

Perhaps you had a wiring problem. Also, the Digital Sidecar has all the needed pull-up resistors. The devices should not have pull resistors in them.

Originally Posted by Steve_Alaniz

The second unit addressed just didn't respond, as if it were not even connected. We didn't have much time to play around with it so we didn't explored changing which we addressed first. We decided to wait until we could consult an NI guy and, well you know that story.

You just didn't consult the correct NI guy. The statement that we didn't expect I2C to be used this year is completely false.

Originally Posted by Steve_Alaniz

I looked at their vi... as much as I was allowed, and saw that they had it fixed such that you had to send data when you addressed a register. We had to send a false data byte even though we only needed to address a register and then read. We correctly guessed the compass would ignore the extra data so it worked anyway.

Perhaps you are misinterpreting the interface. The current API to I2C on the FPGA allows you write to one register or read from between 1 and 4 sequential registers. In either case, the device will be addressed, then the register will be addressed, and finally the data will be moved. Only when you're using a device that does not have a register-level I2C API does this scheme not work nicely. You should not use a register write when you are trying to do a register read.

The intention is that it will be more flexible in the future so that other custom API types can be easily supported as well.

[Joe Hershberger]

Originally Posted by Dave Flowerday

The only issues we had with this were:
1) The I2C driver in WPIlib forces you to use a certain I2C "protocol" where the register address is always sent and then you can read or write up to 4 bytes. I would have preferred if it didn't impose this register address protocol on us (there's no reason in our application that we couldn't have issued a read without first writing a register address). This wouldn't impact you though since the Devantech sensors appear to use this fairly-standard protocol.

The API to the FPGA was designed this way to make it easy to interface with sensors that use this register type of API. In fact, every sensor we tested with used this type of API. It is our intention to make it more flexible in the future.

Originally Posted by Dave Flowerday

2) The I2C pullups in the digital sidecar were not sufficient to overcome the electronic noise on the robot. The sidecar uses the recommended value (3.6Kohm if I remember correctly). When we first tried our setup with those default values, we were getting corrupted readings a large percentage of the time (or the sensor wouldn't hear its own address because that was corrupted and it would simply not respond). We added an external 1Kohm parallel resistor to our SDA and SCL lines to increase the drive current (after checking the datahseets for the parts used inside the sidecar to make sure this wouldn't cause any issues) and that almost eliminated the problem. After that, once every few seconds we'd get a bad reading but mostly it was fine. It's possible this could have been your problem, but I'd have to hear more about what exactly happened when you hooked up both sensors to know for sure.

Did you try shielding the cable? By adding stronger pulls, you can cause problems with other sensors that can't pull the bus to ground. The most egregious are the hi-technic NXT sensors. They actually have series resistors on the bus making them pretty weak at pulling the bus low.

[timmmoore]

Multiple sensors does work from labview, I have tested up to 5, though I have found once you put 4/5 with a wire length of 18" you do need to add additional resistors to get reliable responses.
Having a more flexible api would be very nice:
1. separate write/read will be useful - see HMC6343 below
2. Timeout on bus especially slave clock stretching. I have seen cases where a sensor goes wrong and holds the SCK low, the bus stalls, I2C read stalls, etc.
Some comments about sensors:
devantech - srf08, cmps03, tap81 should all work. I have tried the srf08 with the example and it works. I have used all the rest before and their I2C interface is similar.
I2C-IT IR - works
LIS3LV02DQ - works (need a 3.3V to 5V convertor). I have tried other LISX accelerometers in the past, they all have similar I2C so should work.
HMC6343 - so far not working and I dont see a way to get the required timing.
PSP-NX Mindsensors - works, the other mindsensors have the same I2C interface so should work though I haven't used them before.

On a separate note - can we have the SPI interface more flexible as well. As far as I can tell, it supports mode 0 and 1 but not mode 2/3 (where clock is inactive high).

[EricVanWyk]

Originally Posted by Steve_Alaniz

2) Were you able to read two or more devices?

I heard rumor that the NXT devices all have the same i2c address, which would prevent you from using more than one of them.

[timmmoore]

I believe all the lego sensors use I2C address 2. You can reprogram the I2C address for the mindsensors nxt sensors but I dont believe you can with lego sensors.
There is also a i2C bus switch that allows multiple sensors with the same address to be connected and you switch 1 sensor in at a time. I have used one but I dont rememebr it at the moment. If you are interested I can dig ti out.

[Dave Flowerday]

Originally Posted by Joe Hershberger

The API to the FPGA was designed this way to make it easy to interface with sensors that use this register type of API. In fact, every sensor we tested with used this type of API. It is our intention to make it more flexible in the future.

Yes, I realize it is the most common interface, so I wasn't completely surprised by it, just a little disappointed. Actually, a bigger concern that I'd have in the future is that it be capable of reading or writing more than 4 bytes at a time.

Did you try shielding the cable? By adding stronger pulls, you can cause problems with other sensors that can't pull the bus to ground. The most egregious are the hi-technic NXT sensors. They actually have series resistors on the bus making them pretty weak at pulling the bus low.

Shielding was my first thought, but it would have been difficult to repeat all the wiring that we had installed. Lots of custom-crimped Molex connectors, and the cables ran down through the rotating shaft of our crab modules and had to be terminated after installation. We were only using the sensor boards that I developed so I knew that my board wouldn't have any issue overcoming the pullups. And as I mentioned, I inspected the schematic of the sidecar to make sure the parts used inside it could sink the necessary current.