Realistic Velocity Calculation

[Mike Marandola]

Originally Posted by Caleb Sykes

Not quite an optical mouse, but I know that a couple of teams have mounted unpowered omni wheels beneath their robot that are connected to encoders in order to measure distance. Syncing the data with this with an angular measurement could then determine velocity and position. I think I remember 111 doing something like this last year, but I am unable to find the thread describing it.

33 used omnis for odometry last year but I heard they didn't use them later on in the season.

[Joshua Sicz]

Originally Posted by Greg McKaskle

Integrating the acceleration to get velocity is theoretically correct and simple, but won't yield good results unless you can handle lots of pesky details.

The biggest problem is that the accelerometer is operating in the earth's gravity field. You have a big force that just doesn't go away. You can sit still and calibrate it out, but if you tilt just a tiny bit, gravity's "down" vector starts to show up in your other orthogonal dimensions you really care about. And since you are accumulating, it adds up quick and appears that your robot has been accelerating and is now traveling across the field. My understanding is that good IMUs also contain a good inclinometer ( a specialized gyro) so that they measure the tilt and correct for it.

If this were straightforward, you'd also see tons of phone apps that not only counted steps, but told you how fast you were walking/driving and didn't need GPS and cell triangulation to know your location. Cars wouldn't measure wheel speed either. They would use the same technique.

So the concept is a good one to discuss and experiment with, but a little bit of additional analysis will show the need to cancel gravity for matches in order for this to work well enough.

Greg McKaskle

Wow, this is one great explanation. This explains so much of why the accelerometer was giving us all of those weird values. And it makes since why they wouldn't do it this way. Over the summer I am going to arrange a project for this to see if you can get something out of the data we are getting.

Thank you so much, it was very helpful!

[Joshua Sicz]

Originally Posted by Spoam

You can find the velocity by numerically integrating the acceleration values (e.g. trapezoid sum them, or continuously add the acc value*time step). This is probably very imprecise though, so I would test it empirically and not have anything vital depend on those values.

This is exactly what we have been doing. It doesn't give us anything useful, yet... By yet I mean is the accelerometer is giving us really weird data and the reason why is explained in an earlier post.

[Joshua Sicz]

Originally Posted by slibert

Just wanted to amplify Greg's point. It's complicated, so will take some focused effort and time, and understanding of the physics and related math.

The process is (a) the gravity vector has to be calculated, and to be done accurately, (b) the gyro and accelerometer data must be fused and filtered. Then (c), that vector is subtracted from calibrated accelerometer data to yield linear acceleration, (d)
rotated to be in "world" coordinates (overcoming pitch/roll effects and rotation), then (e) double-integrated to yield distance-traveled vectors in x and y axes.

In case you're interested, the navX MXP does parts (a-d). Here's a link to some Java code that does the calculations for (b-d) [step a is done in hardware on the navX MXP] so you'll get a feel for the process. In this code (see the setQuaternion() function), the gravity vector is derived from a quaternion (a representation of the orientation of the body which has fused the gyro and accelerometer data). This is then subtracted from the calibrated accelerometer, yielding linear acceleration.

The navX MXP provides this information to the RoboRio, and there are teams discussing on Chiefdelphi using the navX MXP and attempting to do step (e), what you are describing. The standard caveat is that this requires a double-integration (acceleration->velecity->distance) and small amounts of noise and error will quickly compound, so that actual distance that this will be accurate for is something still to be determined.

The next step after that would seem to be (f) fuse the encoder data w/the estimated distance vector, which if done well could potentially increase the quality of the estimate of the distance vector.

Yes, since the beginning of the season our team has been looking for the NavX board but it has been sold out at andymark every time we check. I would love to get one to play around to do what you are saying. Thank you so much for those link they will be very helpful.

[gpetilli]

Originally Posted by GeeTwo

HMMM.. I wonder if anyone has ever implemented an optical mouse solution applied to the carpet beneath an FRC robot...you'd need to use two of them in different locations to also measure rotation, but it'd be a great way to know if you lost traction. Oh, well - not my problem this year; shove it into the "off-season projects" folder, er, file cabinet.

we are mounting 4 Vex 2.75" omni-wheels with encoders, 2 for x, 2 for y (on wheel in each corner). achieved x = (x1+x2)/2, achieved y = (y1+y2)/2 and achieved r = ((x1-x2)+(y1-y2))/2. Built frame yesterday, mounting "pedometers" Monday.

[RunawayEngineer]

Originally Posted by GeeTwo

HMMM.. I wonder if anyone has ever implemented an optical mouse solution applied to the carpet beneath an FRC robot...you'd need to use two of them in different locations to also measure rotation, but it'd be a great way to know if you lost traction. Oh, well - not my problem this year; shove it into the "off-season projects" folder, er, file cabinet.

Preface for younger CD'ers: computer mice used to work by rolling on a ball that would allow it to sense movement by its rotation.

I haven't heard of a team using an optical mouse, but I do vaguely remember a swerve drive team that used a mouse-ball to track it's position in autonomous way back in 2008. I didn't catch which team it was, unfortunately.

[Alan Anderson]

Originally Posted by RunawayEngineer

I haven't heard of a team using an optical mouse,...

WildStang and the TechnoKats collaborated on an odometer experiment using optical mice a decade ago. We determined two things. First, optical mice (at the time) were not capable of keeping up with the velocity of a typical FRC robot. Second, trying to use lenses to focus on the carpet from a few inches away in order to scale the velocity down to something the mouse sensor can handle does not work reliably. The scale varies with height and even a couple of millimeters of bounce throws off the measurements enough for them to be less accurate than a simple wheel speed encoder, even with the wheel slipping.

It's possible that modern mice are more able to track high speed motion.

[Ether]

Originally Posted by gpetilli

we are mounting 4 Vex 2.75" omni-wheels with encoders, 2 for x, 2 for y (on wheel in each corner). achieved x = (x1+x2)/2, achieved y = (y1+y2)/2 and achieved r = ((x1-x2)+(y1-y2))/2. Built frame yesterday, mounting "pedometers" Monday.

Let's chat about this offline.

[duane]

We have been trying to use the built-in accelerometer to convert to velocity to convert to distance. The biggest problem I am seeing is the random values from the accelerometer to begin with. The noise seems to be quite high (I should add some numbers, but I don't have them right now).

However, from the reading of this thread, it seems like we are not going to be successful at this attempt.

What else would the accelerometer be used for on the RoboRio if not for velocity/distance? Seems odd to spend the money on a device that has limited functionality.

What am I missing?

[GeeTwo]

Originally Posted by duane

We have been trying to use the built-in accelerometer to convert to velocity to convert to distance. The biggest problem I am seeing is the random values from the accelerometer to begin with. The noise seems to be quite high (I should add some numbers, but I don't have them right now).

However, from the reading of this thread, it seems like we are not going to be successful at this attempt.

What else would the accelerometer be used for on the RoboRio if not for velocity/distance? Seems odd to spend the money on a device that has limited functionality.

What am I missing?

• They are rather good at telling what your tilt angle is when you aren't moving - many teams used them to find the balance points on the bridges in Rebound Rumble. We were considering using them to find the edges of the scoring platform this year - drive up relatively slowly and you know you're there when you begin to tilt. We dropped this in favor of a "curb feeler" approach.
• They also make decent collision sensors - if you're accelerating more than 2g's, you probably hit something.
• When combined with wheel encoders, they could also be used to determine if you have lost traction.
• If you have stability issues (e.g. fall over in a sharp turn), they could be part of a solution to stay upright.