Optical mouse for mecanum Odometry?

[Daniel_LaFleur]

Originally Posted by AriMindell

We are working on finding ways to calculate robot pose for a mecanum drive. Many of the papers I have found on this subject use optic flow sensors or cameras to watch changes in the ground. Could we use a Computer mouse with an optical sensor to calculate the position of our robot?

What would our limitations be using this method?

Does the roborio support Human Interface Devices plugged into the USB ports?

We are a Java team, and I wonder if we could use the JInput library on the Roborio to get the position of the mouse.

Any thoughts on this are greatly appreciated!
EDIT:
The mouse would only be used for translation. We would use a gyro to track robot turns, and transform our coordinate system to continue tracking the mouse translation.

Why not use a follower wheel?

[Ether]

Originally Posted by Jared Russell

unlike determining the necessary wheel speeds for a mecanum drive to achieve a given x, y, theta velocity (inverse kinematics), taking 4 independent velocity measurements and obtaining an x, y, theta velocity (forward kinematics) has 4 inputs and 3 unknowns; it is an overdetermined system. Due to noise you are virtually guaranteed not to have measured 4 velocities that exactly solve the equations. One common approach to deal with this is to use a least-squares solution, which would find 4 new velocities that are consistent and minimize the mean square "error" between what you measured and what your kinematic model says is possible. (A nice side effect is that you can measure this error - "residual" - and use it as a signal that you might be less certain about the vehicle's motion and could be colliding with something, etc.).

The math for the above is discussed here, starting at the bottom of page 7.

If you let A = R/r, b = Ω, and x = V,

then the inverse kinematic equation for b (given A and x) is:

b = Ax

... and the least-squares forward kinematic solution is given by solving the inverse kinematic equation for x (given A and b), which can be done several different ways (one of which is shown in the linked paper).

The residuals are then a straightforward computation:

residuals = b - Ax

If you intend to pursue this further and need help with the math you can start a new thread.

[Ubiquity]

The quick answer is many have tried to use optical mice for Odometry, and the consensus is it doesn't work. Commercial robots (Fetch, Savioke) solve SLAM(Simultaneous Location and Mapping) using a variety of techniques combined with odometry. These include lidar, sonar, optical flow, compasses, accelorometers, etc. Some use wifi and optical features (Fiducuals). While odometry is ok for rough distance, it is not so good for determining pose.

It is interesting to consider why this is. Typically, a differential robot is controlled by adjusting the speed of the motors via PID. So getting the robot to go straight in autonomous should be easy (Ha.). Even if you could get motors to respond perfectly to speed commands, wheel alignment, slipping, mechanical differences all conspire to mess with you. Turning is worse. to turn in place with a diff drive, the wheels need to rotate opposite directions simultaneously for preciously .

With good odometry you should be able to get an FRC robot to go forward 10ft within about 6 inches in autonomous. Try to make a 10ft square and see you'll be 3 feet off and turned 30 degrees.

[Ether]

Originally Posted by Ether

The math for the above is discussed here, starting at the bottom of page 7.

Bottom line, after the math is done and the smoke clears:

Mecanum "forward kinematics" (least squares fit of vehicle motion given wheel speeds):

FWD = r*(w1+w2+w3+w4)/4

STR = r*(w1-w2+w3-w4)/4

Wv  = (1/k)*(w1+w2-w3-w4)/4

r is wheel radius
k is |trackwidth/2| + |wheelbase/2|
w1,w2,w3,w4 are FL,BL,BR,&FR wheel speeds in rads/sec
Wv is robot clockwise rotation rate in radians per second