this is a MPU-6050 Gyroscopic Accelerometer. It does a similar job to what this does but with a few differences. The MPU-6050 is much less expensive, it’s 3 axis as apposed 1 axis, and uses I2C communication. There will still be an advantage to the current gyroscope in that it’s an analog sensor and ROBOTC only allows the use of 8 I2C sensors (right now that would be 8 IME’s) and the MPU-6050 is I2C but the MPU-6050 (I like that word) is really cheap and is 3 axis. So what does everyone else think of this idea?
Vex wouldn’t sell it that cheap.
probably not, but it would still be nice to have something that’s three axis rather than one.
I agree that it would be nice, but it isn’t necessary
I’m not even sure what we could do with the third axis besides some lift that wobbles a lot. The second axis could be used for tilting as in over the bump in Toss Up. I am using this sensor on our robot, but I have to connect it to an arduino then communicate over a serial communication to the cortex. There is little no documentation on the vex cortex I2C port for robot C. Besides the IME I have not seen any one use the I2C port for some thing else, so Im not sure what the limits are right now of the I2C port. The sensor is a good sensor, because it can correct its gyro drift error with the 3 axis accelerometer after a couple of seconds.
As a mentor, I am all for any type of sensor that is new and different as it adds to the educational experience.
the fact that there are only IMEs that use the I2C port is another reason why this would be great! I would love to see more sensors that use I2C communication. We had shaft encoders, now we have shaft encoders and IME’s, why not do the same and have 2 gyros?
I believe the original plan was for VEX to release more sensors that would work on the I2C bus. I don’t know why the plan changed, perhaps our general disappointment with the reliability of the IMEs was a factor. One complication with the way that VEX has implemented the I2C bus is that devices need the ability to auto-negotiate an address with the cortex. This means that, although it is possible with careful planning, existing I2C devices may not play well with the IMEs. I have interfaced different parts but the only reliable way to do this is by using ConVEX as it allows access to the low level I2C polling. One example was posted here.
Adding a non-VEX I2C device
This is only competition legal for VEXU teams.