Hello I am trying to make a code that will take the roboRIO’s built in accelerometer and a Gyroscope so we can know how far the robot has traveled and the direction it is facing. The code will need to be integrated into the autonomous code to make the robot stop after a certain distance has been traveled and the angle it is facing.
Using an accelerometer to measure distance will require integrating a noisy signal twice.
It would be better to put encoder(s) on the wheel(s).
The September specs for the roboRIO showed that it included an accelerometer but I don’t believe it included a gyro. They may have snuck it in when I was not looking, but one reason the gyro may not work is that you need to physically add one.
Keep in mind that a gyro measures the rotation about the point where the sensor is located, so putting a gyro inside the roboRIO may be overly restrictive in that you would want to locate it at the center of rotation of the robot. A remote gyro makes more sense to me.
Integrating the accelerometer twice does not work very well your better off using the encoders on andymark because they are really simple to use! If you need help calibrating them and finding the distance per pulse let me know! I got my teams calibrated so they were off 1 inch per 6 feet!
My team is experimenting with this idea. We’re using mecanums.
Because the mecanums might slip some as they drive, and because the rate of slip may be variable, encoders on the wheels may not be very accurate. We’re going to try adding small, non-driven wheels in the center of the robot, perpendicular to each other. Each one will be on a pneumatic powered arm and be connected to an encoder so we can measure how far the robot has traveled in the x and y directions.
Because mecanums only slip along one axis, but not the other (at least not usually), it would be possible to use encoders to keep track of a mecanum drive, but I wouldn’t want to tackle it as one of many projects during build season. Your idea is rather like putting a roller-ball style mouse under the robot.
Well since no one has actually answered the question just speculated around the question 
I guess its up to me. That was one of the /very/ first things I did with the new roboRIO even before tank drive (being a 2nd year First’er and a 1 year VEX’er). After finding the javadocs it was very easy. I found the java docs here. And for the built in accelerometer I found it here. I have yet to find any kind of built in acceleromoter in the new roboRIO but MESSAGE ME IF YOU FIND ONE!!! Oh and you probably want smartdashboard stuff too!! I forgot!! The stuff hasn’t changed since last year in regards to the smartdashboard but the new javadocs are here the rest you might want to find in screensteps from the 2014 cRIO.
How many wheels?
Presumably two, as they’re perpendicular to each other, and the robot doesn’t seem like it’s going to climb the walls or travel unusually through time.
*I’d rather not speculate. Let’s let Pockets answer the question directed to him.
I believe he did, in the original post. It’s implicit, but the x and y directions definitely imply two wheels:
We’re going to try adding small, non-driven wheels in the center of the robot, perpendicular to each other. Each one will be on a pneumatic powered arm and be connected to an encoder so we can measure how far the robot has traveled in the x and y directions.
*I have a reason for asking the question. Can we please let Pockets answer it?
Fair enough. If it’s anything other than two, I’ll buy you lunch. If you’re in CONUS, I’ll drive to wherever it is you are to do so sometime this summer. All of CD is my witness on this.
Thanks for the kind offer, but I’ll tell you what: if it’s anything other than two, I’ll buy you lunch.
To avoid further degradation of the SNR on this thread, let’s use PM for any further discussion of this.
Yes, I meant two wheels. Sorry for the confusion.
Thank you. Can you give some more detail (see below)?
would you please show the calculations you plan to do with the two encoder signals to achieve that objective?