Realistic Velocity Calculation

[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.

[Michael Hill]

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.

We did this on my high school team (45) back in 2004(?). I think we had white tape strips on black wheels for a primitive encoder.

[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.

[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.

[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.

[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.

[GeeTwo]

Originally Posted by Joshua Sicz

I have been helping out our student programmers on our team and we haven't found a good why to calculate velocity. We have a accelerometer that gives us reading in g's. So we just convert it to ft/s^2 and then take the timedifference between that last time the code was ran to calculate velocity. But what we are finding is the accelerometer doesn't give us consistent values.

Does any team have experience in this? Anything would help thanks!

In order to even have a chance at making this work, you would also need a gyroscope. At each time step, you would have to rotate the previous time step's x and y by the amount of angle you've turned (theta), then add the change in speed. Assuming x is to the right and y is forward, and theta is rotation to the right, you'd have to do:

• ynew = yold*cos(theta) + xold*sin(theta) + yacc*rdelta
• xnew = xold*cos(theta) - yold*sin(theta) + xacc*tdelta

This is known as inertial navigation, and you can very quickly get lost in the intricacies if you're actually trying to use it for more than a few seconds, or in more than two dimensions, or across more than an area the size of, say, an FRC arena. Even staying in a 27-foot square box and limiting yourself to 2 minutes and 30 seconds, it would probably be a good idea to have a "reset" button that you can hit when the robot is actually stopped that sets both values to zero.

[hexane]

Quadrature Encoders are probably the most accurate way to tell distance. To figure out velocity, make a variable that you set to the position of the encoder at the end of a program cycle, then figure out the change in position divided by the change in time.

[Joshua Sicz]

Originally Posted by GeeTwo

In order to even have a chance at making this work, you would also need a gyroscope. At each time step, you would have to rotate the previous time step's x and y by the amount of angle you've turned (theta), then add the change in speed. Assuming x is to the right and y is forward, and theta is rotation to the right, you'd have to do:

• ynew = yold*cos(theta) + xold*sin(theta) + yacc*rdelta
• xnew = xold*cos(theta) - yold*sin(theta) + xacc*tdelta

This is known as inertial navigation, and you can very quickly get lost in the intricacies if you're actually trying to use it for more than a few seconds, or in more than two dimensions, or across more than an area the size of, say, an FRC arena. Even staying in a 27-foot square box and limiting yourself to 2 minutes and 30 seconds, it would probably be a good idea to have a "reset" button that you can hit when the robot is actually stopped that sets both values to zero.

Awesome! We have actually played around we this exact thing this season and have got it to work with exactly they way you have said it to be done. Now I just need to get velocity from the x and y direction relative to the frame. Getting the code to output a realistic velocity because we get random numbers out of the accelerator.