Optical mouse for mecanum Odometry?

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

[engunneer]

it probably would show up as a device. you probably need a gaming mouse to make sure you don't get velocity limits. Optical mice can't tell you rotation, so you would nee 2 mice to get full information. Reading carpet may be tricky.

[cad321]

https://www.chiefdelphi.com/forums/s...=Optical+mouse

Just going to leave this here

[Poseidon5817]

There have been multiple previous threads on this subject, and I think the consensus tended to be that it is possible, with the right mouse (mice) and spacing from the floor. In this case, what is keeping you from using a gyro and/or encoders?

[AriMindell]

Originally Posted by Poseidon5817

what is keeping you from using a gyro and/or encoders?

We want accurate X/Y position of our mecanum drive, and research told me that encoders are not accurate enough with mecanum wheels due to slipping of casters.
In addition, I think that you cannot determine your current position independent of time with just the encoder positions for mecanum, since it matters what combination of velocities you have each timestep.
That said, we are planning to use a gyro for heading. The mouse would only be for translation.



Sent from my iPhone using Tapatalk

[Poseidon5817]

Originally Posted by AriMindell

We want accurate X/Y position of our mecanum drive, and research told me that encoders are not accurate enough with mecanum wheels due to slipping of casters.
In addition, I think that you cannot determine your current position independent of time with just the encoder positions for mecanum, since it matters what combination of velocities you have each timestep.
That said, we are planning to use a gyro for heading. The mouse would only be for translation.



Sent from my iPhone using Tapatalk

You can determine your position independent of time, as encoders can tell you both the position and velocity of the bot at any given time. That being said, I cannot speak to the accuracy of encoders with mecanum wheels, but I imagine that it could be feasible depending on how it is implemented.

[Ether]

Originally Posted by AriMindell

Could we use a Computer mouse with an optical sensor to calculate the position of our [mecanum] robot?!

Using only a single optical mouse, with no additional sensors, consider the following scenario:

1) drive forward 5 feet

2) rotate in-place around the mouse 180 degrees

3) drive forward another 5 feet

... what is the position of the robot according to the mouse?



[EDIT this info was not in your original post:

That said, we are planning to use a gyro for heading. The mouse would only be for translation.

[Hitchhiker 42]

Originally Posted by AriMindell

We want accurate X/Y position of our mecanum drive, and research told me that encoders are not accurate enough with mecanum wheels due to slipping of casters.

Why not go with accelerometers? Those don't depend on slipping.

[MrRoboSteve]

You should be more specific about your positioning requirements. It's one thing to calculate position during an autonomous routine (a la Ether's description above), and another thing to know your position 45 seconds into the match.

If you're talking an autonomous scenario, you can use motion profiling to control acceleration and manage wheel slip.

[AriMindell]

Originally Posted by Hitchhiker 42

Why not go with accelerometers? Those don't depend on slipping.

Correct me if I'm wrong, but I believe that accelerometers are pretty bad at tracking velocity or position, because the two integrations result in a massive amount of noise.


Sent from my iPhone using Tapatalk

[StevenB]

Six years ago I wrote a paper on using optical mice for robot odometry, and as far as I know it's still the most comprehensive review of this topic. While we built a system that worked fairly well for our senior design project, I don't recommend mice for FRC. For one thing, acquiring mice that you can easily interface with and building an appropriate lighting and lens system is a bit tricky (although I'm happy to help if you want to try). The mice often have huge errors in their measurements, because the readings are highly dependent on the surface quality, illumination, distance to the surface, and focus of the lens. For example, while the measurements may be repeatable on carpet, you'll get very different results on the gaffer's tape delineating the various zones on the field. In our system, we did a least-squares fit with six mouse sensors to estimate the position and orientation of the robot.

I've attached my paper if you'd like to read more.

[Jared Russell]

Originally Posted by AriMindell

Correct me if I'm wrong, but I believe that accelerometers are pretty bad at tracking velocity or position, because the two integrations result in a massive amount of noise.

That's correct. You can typically obtain a position estimate for a wheeled mobile robot much more reliably through other means.

Typically the biggest challenge with using an optical mouse for position is that they are designed to glide over a smooth surface at a very precise height. You will almost certainly need some sort of suspension, and even that may not be enough for guaranteeing you don't lose track when traversing bumps and seams in the carpet. (EDIT: StephenB's post goes into more detail).

I wouldn't give up totally on using encoders on mecanum wheels for positioning. Although the rollers on the perimeters can spin freely, any movement in x, y, or theta will result in proportional rotation on a sensed axle (assuming your rollers may have rotated, but have not lost traction). However, 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.).

Alternatively, going back to the optical mouse idea, you could make something that is more similar to a ball mouse:

You don't even need a ball; two passive omniwheels mounted at right angles and connected to encoders could give you unambiguous X and Y measurements, even if your mecanum wheels have lost traction. As in the optical mouse case you are gonna want some sort of simple suspension to deal with irregularities in the carpet, but omniwheels at least have no trouble reliably rolling over typical imperfections in FRC field surfaces.

[AriMindell]

Originally Posted by Jared Russell

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

This is definitely an interesting approach. I will update this post once we do some more testing and decide which method we're going to use. Thanks!




Sent from my iPhone using Tapatalk

[Kaleb Dodd]

In 2015 we experimented with using a mouse to track position for our kiwi drive but we found that even with a gaming mouse that had a fast refresh rate we still couldn't get accurate distance measurements when driving on the field. We ended up using an encoder on each wheel and a gyro to track our x,y position on the field but we had to be careful and not accelerate too fast or the wheels would slip and we would lose our position. A mecanum drive would also have similar problems with wheels slipping so you might want to implement some acceleration control or for a quick solution just slowly ramp up the power when you first start moving which is what we did in our 2015 code posted here https://www.chiefdelphi.com/media/papers/3180?

[jwhite]

Not a direct answer to your question, but I found this thread quite informative on this subject:

https://www.chiefdelphi.com/forums/s...d.php?t=132758

with what looked like a very clever suggestion from Ether on this.

(But I couldn't track down the thread with the 'homework' Ether assigned in 2014, which I bet would also be interesting).