Trackball motion tracking

Hi everyone,

I have been thinking for a while about a good way to track robot motion in all directions, I have considered mice, but apparently lazer ones are illegal, and optical ones unreliable. So I’ve moved on to something more like a trackball, it could be mounted between the front wheels and lightly pressed against the ground using some kind of elastic force. What are your thoughts? Also does anyone know of a trackball-esque device that could handle speeds up to 16 fps? After a couple of hours of looking, the best I could find was 30in per second, which is nothing to an FRC robot.

I would use a gyro in conjunction with an accelerometer. I can’t say much for trackballs though.

team 27 had a very good system this year, they made small vex encoders which dropped down onto vex omni wheels. that is what i would do. another way to do this would be to change the disks on the trackball in order to make them work at higher speeds.

It has been done in the past. In 2009 a couple teams made some traction control attempts.
Couple of ideas:
http://www.chiefdelphi.com/media/photos/32440 (you would have to mount 2 for x and y)
http://www.chiefdelphi.com/forums/showthread.php?t=65135&highlight=trackball+mouse

This might be worth looking into:
http://imakeprojects.com/Projects/seeing-eye-mouse/

A Gyro/Accelerometer combo will work in the short term but there is drift over time. Higher accuracy/lower drift sensors are available but expensive.

As for the original question it may be beneficial for you wo take apart an old mouse. Typically a trackball mouse includes two encoders that ride along the ball and measure the displacement (X and Z axis), it would be fairly easy to custom build your own devise with sufficient resolution to function at the required speed.

Keep in mind that will track only the point between the front wheels. It will not tell you where the back end of the robot is.

**

My new alternative to achieve this is an IMU, if it was low enough cost and easy enough to use, it could work great.

http://en.wikipedia.org/wiki/Inertial_measurement_unit#Disadvantages

**

There are a lot of ways to do robot odometry, each with their advantages and disadvantages. There is no one best solution; it all depends on what you need the system to do and - as my father who worked on ultra-high precision guidance systems would remind me - how much you’re willing to pay.

Wheel encoders on driven wheels
This is the tried and true method: measure how much each wheel turns, and use this information to figure out the robot’s position. You probably already have the hardware, and the software is pretty straightforward. But, as you’ve already ascertained, when the wheels slip, what you measure is actually how far the wheel spins, and not how far the robot moves. If you assume that the wheels never slip, you can derive your position from only two encoders.

Wheel encoders on non-driven wheels
This is an attempt to deal with the wheel slip problem caused by the above method, and could use encoders on omniwheels or a device similar to a traditional ball mouse. The problem is that this tends to result in fragile and/or high-precision components riding along on the carpet, risking damage, causing a small amount of friction, and picking up dust. Like the above method, you only need two encoders if your measurement wheels are parallel and you assume they don’t slip. Three encoders is better; a trackball provides two axes but needs at least a third axis so you can determine rotation.

Pure IMU
Use a gyro and dual-axis accelerometer to calculate position. You could also use an off-the-shelf IMU, which typically includes a 3-axis gyro, a 3-axis accelerometer, and maybe a 3-axis magnetometer. The advantage is that an IMU is completely independent of your robot kinematics - it doesn’t matter what drivetrain configuration you use, the algorithm is exactly the same. It works even if you’re pushed sideways.

Mathematically, it’s pretty straightforward to implement, but as Ether and others have pointed out, IMUs suffer from accumulated error. A gyro isn’t too bad, since you only have to integrate rate to get the heading. But with an accelerometer, you’re integrating twice to get from acceleration to position, and a tiny error can accumulate and hurt you pretty quickly. And with a 2-axis sensor, if your robot tips so that the accelerometer is no longer horizontal you’ll be hosed in no time.
This is where my dad chimes in and says that if you’re willing to pay $1M, you could use an IMU to get sub-millimeter accuracy for days… but in FIRST we have a parts budget to worry about.

Hybrid IMU/Encoders
It’s pretty common to use wheel encoders to track distance and a gyro to measure heading. For our 15-second autonomous mode, you don’t have to worry much about collisions and wheel slip, so the encoders are a pretty good solution. This is simpler and more accurate than what you’ll probably be able to do with an inexpensive accelerometer.

Mouse sensors
Mouse sensors have a lot of advantages: they don’t have to contact the tracking surface, have very high resolution, and are dirt cheap. However, they have several drawbacks: they are very sensitive to height, they have limited tracking speed, and they typically have to be very close to the tracking surface. The focus, tracking speed, and sensor height problems can be solved (or at least mitigated) by using a lens to focus the sensor on a larger patch of surface. The scale part of height sensitivity has also been solved, but it’s a little trickier to implement.

Laser mice and optical mice work on exactly the same principles, and are subject to the same errors. Even if we could use laser mice, they would have the same problems.

A major part of my senior design project included making a robot navigation using a set of 6 optical mice, and I’ve posted some of my work on my website: http://www.botsnlinux.net/school_projects.php. In the unlikely event that I actually have free time this summer, I would like to adapt my system for an FRC bot and see how well it works. My gut sense is that I can probably get it to work at least as well as an encoder/gyro solution, but it will require a lot of experimentation and tuning. Unless there’s a compelling advantage (such as in Lunacy), it probably isn’t worth the effort during the build season.

This is currently what we use, and it works great. I might like to do some extra coding on this method, but it should work quite well. The intent of this thread was give a robot the ability to track absolute position on the field and integrate it with perhaps laser scanning in order to allow the robot to avoid obstacles and perform something which is more like autonomous and less like recorded driving. I recognize that this level of capability is entirely unnecessary in FRC, but it would be REALLY cool.

I tried this in FTC this year and it SUCKED. I’m sure it could be done right, but we definitely did it wrong.

I have however been looking at integrated IMU solutions (can’t seem to find a link now). They have already done most of the work and I might be able to get accuracy of ±1.5" for 20 second for under a grand (I’m not sure, but you might run it by your dad). This would be the best solution, and would meet the requirements of any FRC team. (A small one which could handle ±0.5" for 40 seconds on 9 volts would also make your FTC team gods on the field.)