Hi everyone! I have been tasked with creating a master class (Java) for all things I2C because the last time we used it, the robot had some major lag issues, and once the sensor crashed the robot so hard it stopped moving during competition. The device I will be communicating with is the GY85 accelerometer/compass/gyro sensor. Is there anything I should know? Any fun stories? (Any and all information is appreciated!)
I’ve only heard of a couple teams that have gotten I2C to work well (besides the accelerometer). What I would personally do is get an arduino and a CAN shield and read the sensors using I2C on arduino and then send the data over CAN. I am on a Formula SAE team and we are doing something similar to this and it works really well.
Also, Teensy 3.1 has CAN built in (minus a microchip for the i/o for CAN) and that has something like 22 analog ins, so if you are reading lots of sensors (like the Formula team I am on) you could use that to read sensors too.
Also, I love your name
ProTip: Learn binary and put the numbers on the System.out in netbeans so then its less calculation for the computer.
We got a MaxBotix I2C sonar sensor because our first sensor :yikes: got shocked because we didn’t keep it in the proper equipment. It worked well with little problems!
I didn’t think about using an Arduino, but that’s a good idea!
I couldn’t tell you how many times the sensor’s been hot-plugged accidentally by the death spirals that were supposed to be a closed loop drive system! I can’t believe it still works…
Have you tried writing to non-Jaguar CAN devices on the cRIO? Or to arbitrary CAN devices on the roboRIO? WPILib does not currently have any user APIs for arbitrary CAN devices/traffic. This seems substantially harder than just getting I2C to work on the roboRIO itself.
I don’t think you want the try to make some generic “master class” where you attempt to handle more than just the device in question. The class provided is already the master class! 
That sounds like a pretty complex solution to a simple problem. There would have to be some extenuating circumstances to warrant such a design.
Most simple sensors like I2C sensors don’t care if you hot-plug them. They just see it as powering up.
LabVIEW has a generic API for accessing CAN. If Java doesn’t, that may be a bug.
Are you referring to a master I2C class, or a master GY-85 class? The FIRST I2C class kept hanging up the robot because it would start another transaction when another was already active. I’m just making this class to make sure that doesn’t happen, and to make the code look cleaner and nicer to read in general.
Perhaps I’m reading too much into your choice of name. I think you should attempt to write a class that is capable of interacting with the sensor you care about and nothing more. Speculative generality is your enemy. It will add complexity and give you nothing positive in return. You can always refactor in the future when you have new requirements.
I’m surprised that the Java class allowed more than one write at a time to the I2C bus. I haven’t looked to see if that is a bug or a misunderstanding. Certainly on the new roboRIO that should not be possible due to the Linux device driver that must be talked to on the new system. Your class should not need to deal with this level of synchronization.
Sorry for my vague-ness. Words are hard 
!
Well I’ve always heard of hangs and program crashes because of bad i2c code., never CAN. And it is easier to get all of your sensor data from 1 source (CAN) and you can pre process the data. That’s the way I would do it. It also allows you to develop code faster (you only have to compile arduino code, not the whole robot code).
It seems like i2c isn’t really fully developed on the cRIO or the roboRIO. Bit that’s just what I have heard
The transaction method in the cRIO Java code is synchronized, you cannot execute two transactions at once.
Speculation and FUD seems unhelpful. Perhaps we should stick to actual data and not hearsay? Especially when it comes to a system that’s still in Beta, in the hands of 90 teams, and which has no current bugs filed against the I2C software from a quick glance at the Beta tracker.
I understand that, but if I2C freezes the whole robot, then that is a big problem. CAN won’t freeze your whole robot, and a lot of things already run off CAN. If the arduino freezes, it probably won’t freeze your robot. I am just trying to stay on the safe side, and that is what we will be doing next year if we use I2C for something.
There were a few problems with I2C on the cRIO that caused people problems.
- The cRIO software expected an 8 bit address, whereas most people were used to a 7 bit address. The roboRIO now uses a 7 bit address.
- The cRIO’s clock skewing behavior caused problems for some devices. It always supported a “compatibility” mode to solve those issues, and was enabled by default in 2014. This is no longer necessary on the roboRIO.
- If the device stopped communicating in the middle of a transaction, the cRIO software would be stuck in an infinite loop waiting for data. http://firstforge.wpi.edu/sf/go/artf1726 This is not present on the roboRIO.
I think many people have complained about the CAN implementation on the cRIO.
To be fair, only 3 of the 90 teams have reported testing I2C.
Ooh sounds like I2C is going to be a good way of communicating this year! I am excited! I love how easy I2C is to set up on an arduino, but I have never gotten it to work on a cRIO. Hopefully that will be a lot easier this year!
And I meant that I haven’t heard of CAN crashing the whole robot.