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!

[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).

[skimoose]

Originally Posted by 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.

The New Haven display we used needed to have a jumper soldered onto the PCB traces to enable I2C communication. Check the New Haven literature to see if the model you used needed this jumper. The pads were not drilled so you needed to surface solder a very short piece of bare copper wire across the two adjacent pads.

[virtuald]

Originally Posted by skimoose

The New Haven display we used needed to have a jumper soldered onto the PCB traces to enable I2C communication. Check the New Haven literature to see if the model you used needed this jumper. The pads were not drilled so you needed to surface solder a very short piece of bare copper wire across the two adjacent pads.

Yeah, ours had that requirement also. Its possible we soldered the wrong set on accident, however.

[timmmoore]

Steve_Alaniz for the CMPS03 you should be able to do a I2C read of 2 bytes from register 2. Haven't tried it but I have one so I will connect it and see.

[Steve_Alaniz]

Originally Posted by timmmoore

Steve_Alaniz for the CMPS03 you should be able to do a I2C read of 2 bytes from register 2. Haven't tried it but I have one so I will connect it and see.

Tim
Oh we DID do a two byte read initially, but that was too much resolution for our application so we dropped back to a one byte read.

Steve

[timmmoore]

Steve, I have tried 1 and 2 byte reads on CMPS03 without problem with SRF08 running at the same time.
I also found a way to cause the I2C bus to hang with both devices being accessed at the same time.
Difference
hang: 2 parallel while loops, 1 accessing CMPS03, 1 accessing SRF08
no hang: 1 while loop, accessing SRF08 then CMPS using a sequence

If you remove 1 or the other device physically from the bus but leave the code running both 'work'. But with both connected it may hang - it normally works for a while then hangs the while loop - I would expect this unless the I2C FPGA code has locking behavor for multiple accesses, you would end up with multiple conflicting bus accesses.

So you probably want to put all I2C accesses in 1 thread, store the results in local/global variables and access the variables when needed.

[Steve_Alaniz]

Originally Posted by timmmoore

Steve, I have tried 1 and 2 byte reads on CMPS03 without problem with SRF08 running at the same time.
I also found a way to cause the I2C bus to hang with both devices being accessed at the same time.
Difference
hang: 2 parallel while loops, 1 accessing CMPS03, 1 accessing SRF08
no hang: 1 while loop, accessing SRF08 then CMPS using a sequence

If you remove 1 or the other device physically from the bus but leave the code running both 'work'. But with both connected it may hang - it normally works for a while then hangs the while loop - I would expect this unless the I2C FPGA code has locking behavor for multiple accesses, you would end up with multiple conflicting bus accesses.

So you probably want to put all I2C accesses in 1 thread, store the results in local/global variables and access the variables when needed.

Thank you Tim... good information. We'll give it a try.


Steve

[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.

[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