Using optical mouse for x-y encoding for robotics

[photon1116]

Has anyone had any luck or even heard of anyone using an optical mouse as an X-Y encoder for a moving robot using the floor? I know the focal distance is 0 as it rides on the desktop, so #1 problem would be increasing the focal distance. Optics is not one of my studies, so at the first point I am stymied. Interfacing on the other hand probably would not be a problem, since it has a built-in USB interface.

The robot i'm using has 4 independent wheel motors so using 4 or even 2 (right & left wheels work in tandem) wheel-mounted encoders makes the math a nightmare especially since slippage (which does happen) would screw up the calculated X & Y positions. I probably could use GPS, but don't think it would be accurate enough. I do have a compass board that i made for direction.  Any thoughts?  Thanks.

[legacy]

you are looking for an "optical flow" sensor, every kind of optical mouse are using this kind of chips, e.g. ADNS3080.
sparkfun should have a breakout (with plastic lens), unfortunately you still need "odometry" algorithms.

[legacy]

wheel-mounted encoders makes the math a nightmare especially since slippage

that is not the best approach, you should NEVER put the encoder on the wheel, you'd better put the encoder on the motor side, with a protection from the IR sun light which could saturate the sensor.

personally i am using a kit for that: my motors are coming with an embedded quadrature optical encoder on them
unfortunately they are expensive, 40 USD for a motor+encoder

[dannyf]

There are two kinds of optical mouses and they work quite differently.

using 4 or even 2 (right & left wheels work in tandem) wheel-mounted encoders makes the math a nightmare

If you are using the other kind of optical mouse, you would need only one sensor.

I probably could use GPS,

That would require the robot to be used outdoors - otherwise, indoor positioning is actually a very promising field right now.

Another approach is to use accelerometers / gyros but their accumulative errors can be significant over a long period of time.

[legacy]

There are two kinds of optical mouses and they work quite differently.

btw, see the "optical flow" sensor, see the ADNS3080 chip, it has been used in the first series of Microsoft optical mouse.

That would require the robot to be used outdoors - otherwise, indoor positioning is actually a very promising field right now.

the GPS has not a precision of mm (1/1000 of meter), it has a circular error of meters, so you can say the robot is +/- near a position, also you need double precision to evaluate longitude and latitude, plus a correction of geodetical trasform

gps is not so easy to be used, and not so useful, it may be used by fly bot to have an idea of they hot-points.
e.g. the start point is +/- here (around this point with a radius of 2-4 meters), and the destination point is +/-  there  (around that point with a radius of 2-4 meters)



IMU are able to say you relative movements, for the absolute coordinate you cumulate a lot of errors, also the gyro has intrinsically errors


my conclusion is: use encoders + dsPIC33F to have quadrature, that is the easiest and best performance solution over all, then add other sensors to have a sort of "fusion", this way the bot can handle errors

[photon1116]

Thanks legacy & dannyf for the quick replies.

Legacy, the key words "optical flow sensor" & ADNS3080 are exactly what I am looking for.
Doing a search brings:
http://www.digikey.com/product-detail/en/ADNS-3080/ADNS-3080-ND/1233153
http://store.scoutuav.com/product/add-ons/optical-flow-sensor/
http://store.jdrones.com/Optical_flowsensor_p/senopt01a.htm
http://store.3drobotics.com/products/optical-flow-sensor
and
Mouser:  http://www.mouser.com/ProductDetail/Avago-Technologies/ADNS-3080/?qs=RuhU64sK2%252bsop/60ZpFX6g==
which tells me that the ADNS3080 is an obsolete part & is probably why in the links above the module is out of stock. No problem, now I know what type of chip to look for.
I may end up having to use motor encoders, although it may be an expensive proposition as you point out.

dannyf, indoor positioning might be OK, i presume you would use 3 transmitters and triangulation such as cell phone locators using 3 towers use. In the long run though, to have the robot relocatable, it might not be the best choice.

I did try positioning my pc mouse about 1/2" from the desktop and had some luck moving the cursor on the screen with a laser pointer reflecting off the desk, so maybe focusing is not required if I use that method.

Thanks again guys for your timely responses.

[legacy]

yes, this chip is obsolete for mouse, but it is still used in breackout kit

i have been using it and it is excellent 

[legacy]

p.s.
i you look around this kind of mini-retina (30x30 pixel), you will see a lot of interfaces

• spi
• custom
• usb directly

you have a lot of choices about the optical flow chips, unfortunately you need plastic lens, so my suggestion is to go for the optical flow v1 kit, it is SPI, it is cheap, it has lens, and it is ready just out of the box

no arduino good code, there is something in dydrone repo, you have to check it out
( i have written my own driver, and i do not use arduino, i am an AnalogDevices's DSP fan)

[photon1116]

Thanks legacy. Yeah, coding will not be a problem if I get the specs. The robot I was refering to is Arduino-based. I will leave that hardware for the basic motor commands  but for the rest of the robot I prefer PIC as i can use assembly (my favorite) easily & Proton+ Basic compiler for floating point calcs & spi. Don't like C for programming & using assembly with Arduino looks daunting. I haven't checked out AnalogDevices's DSP yet, but will as per your recommendation.

Looks like mini-retina encoding will fit the bill nicely. Might need to add some illuminating LED's on the bottom of the robot as per the low-light warning on the Optical Flow Sensor board.

[legacy]

yep, also an other good kind of sensor is a LiDAR, see this other thread about 

[photon1116]

Wow the Lidar seems like the ultimate course-mapping device. Too bad the ICP-SLAM is C++ based but for bit hacking with Lab-VIEW loved the page HERE

[Richard Crowley]

Optical mouse cameras/processing are NOT accurate enough to MEASURE position.
They are adequate for measuring direction and speed with a rather large margin of error.
This is not a problem in mouse application because it is used in a "closed loop" system which includes your eyes, brain, and hand.
If you used it on a prepared micro-grid pattern, you might approach some kind of useful accuracy.
But I doubt that you can get anywhere near actual distance measurement on random surfaces.

[legacy]

Optical mouse cameras/processing are NOT accurate enough to MEASURE position.
They are adequate for measuring direction and speed with a rather large margin of error.
This is not a problem in mouse application because it is used in a "closed loop" system which includes your eyes, brain, and hand.
If you used it on a prepared micro-grid pattern, you might approach some kind of useful accuracy.
But I doubt that you can get anywhere near actual distance measurement on random surfaces.

yes, i agree 

[legacy]

SLAM

real SLAM needs the quadtree algorithm, as real path planner needs real A*++ algorithm.
i hate C++ for embedded metalbare stuff, but … you can have C++ on linux-embedded boards
extremely cheap price, e.g. the AriaG25 is an arm9 @400 Mhz with 256Mbyte of ram
its cost is 25 euro, and is perfect for C++ algorithms which are very heavy ram consuming.
( SLAM and A*++ need a lot of ram for their computations )

[photon1116]

Optical mouse cameras/processing are NOT accurate enough to MEASURE position.
They are adequate for measuring direction and speed with a rather large margin of error.
This is not a problem in mouse application because it is used in a "closed loop" system which includes your eyes, brain, and hand.
If you used it on a prepared micro-grid pattern, you might approach some kind of useful accuracy.
But I doubt that you can get anywhere near actual distance measurement on random surfaces.

yes, i agree 

Yes, I understand; due to the random distances between light and dark areas that the optical flow sensor is seeing on random surfaces, accurate measurement is not possible. Hmm...so much for that idea. Thanks for your input Richard.

Regarding the  LiDAR/SLAM, I'll do some more reading on it. Thanks legacy.