Quote:
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