Optical Mouse Navigation

[phrontist]

Originally Posted by Alan Anderson

No, as I said before, it's not a focus problem.

The "telephoto mouse" we constructed has a bit more than a centimeter of variation in range where it will still track the carpet if appropriately illuminated. But it won't track it consistently if the distance isn't kept absolutely constant.

I'm sorry, I don't know that much about optics, please explain how this is not a focus problem. Logically, if you move the mouse up and down it will be tracking larger and smaller patches of carpet. Why would a sudden jump in registered distance occur if it were getting a clear image? If it didn't have a large enough depth of field, it would make sense if a sudden jump occured, for that would indicate the feild of view had been passed and the sensor was no longer in focus. Please clarify.

[Max Lobovsky]

Originally Posted by seanwitte

Another option is to use a counter with synchronous serial output. You can tie the data and clock lines from all of the accumulators to two RC pins, then have one dedicated RC pin for the Chip Select on each accumulator. The code to shift in the bits would be easy to implement but I think Kevin Watson has already written it.

My original design was to use an 8 bit counter and shift register for each axis but I decided that the increased complexity in circuit and software was not worth saving a few pins. (Save the pins for what, anyway?) I did look for a counter with shift register combined, and the only one I (think I) found is http://www.digikey.com/scripts/DkSea...sus.dll?Filter The reason I say think is because the datasheet is very unclear (no truth tables or anything). Additonally, it is only 4 bit, so I would either have to poll it outside the main loop using a timer interrupt or cascade it. Again, the complexity was prohibitive.

I will soon post pictures of my counters and sensors (which I think should void any of this discussion because of their simplicty.) Everything has been tested except for the robustness of the sensors on a running robot.

[phrontist]

Originally Posted by Max Lobovsky

My original design was to use an 8 bit counter and shift register for each axis but I decided that the increased complexity in circuit and software was not worth saving a few pins. (Save the pins for what, anyway?) I did look for a counter with shift register combined, and the only one I (think I) found is http://www.digikey.com/scripts/DkSea...sus.dll?Filter The reason I say think is because the datasheet is very unclear (no truth tables or anything). Additonally, it is only 4 bit, so I would either have to poll it outside the main loop using a timer interrupt or cascade it. Again, the complexity was prohibitive.

I will soon post pictures of my counters and sensors (which I think should void any of this discussion because of their simplicty.) Everything has been tested except for the robustness of the sensors on a running robot.

Just to clarify, max is reffering to omni wheels with encoders on them, not optical mice. The interfacing is the same though.

[the_undefined]

Hmm reading that I thought the Logitech Mx 1000 Mouse could be very interesting for a project like this since its about 20x better then any optical mouse beacause it's actually really using a laser but I couldn't find it at the pages of the authorized resellers ...

Who wants to look at it: Logitech Mx 1000

[phrontist]

Originally Posted by the_undefined

Hmm reading that I thought the Logitech Mx 1000 Mouse could be very interesting for a project like this since its about 20x better then any optical mouse beacause it's actually really using a laser but I couldn't find it at the pages of the authorized resellers ...

Who wants to look at it: Logitech Mx 1000

Sure you could use it! It's from the same manufacturer as all the other chips, but I don't see a datasheet for it on their site linked above. I don't think this is possible though, because you'd need to illuminate a huge area by laser standards. It's easy to illuminate a 5mm by 5mm patch, but try 6 by 6 centimeters.

UPDATE: You're in germany? I wasn't aware that there was a team there yet... that's uber cool.

[BrianJennings]

Sorry to get off topic, but is this project being doen by someone who does stuff at DW college? If so, just wondering, becuase my dad was talking about you doing it, if not, then you should sollaberate with the guy who is doing it, because he seems to know alot about it... It is posted on these forus somewhere...

[the_undefined]

Originally Posted by phrontist

Sure you could use it! It's from the same manufacturer as all the other chips, but I don't see a datasheet for it on their site linked above. I don't think this is possible though, because you'd need to illuminate a huge area by laser standards. It's easy to illuminate a 5mm by 5mm patch, but try 6 by 6 centimeters.

UPDATE: You're in germany? I wasn't aware that there was a team there yet... that's uber cool.

Hmm I'm not in Germany right now, I'm doing an exchange year in Atlanta, Ga right now and joined their robotics club their since I like programming a lot and it's not every day you can play around with plc's and all that stuff : ). But as far as I think Germany has one or two teams, too but I'm not quiete sure about that since thats just what somebody told me o_O.

My Highschool is competing for the first team this year but we got some good suport/sponsoring on our site so I hope we can get a decent robot together : ).

Youl'll probably hear more from me in the next team since I'll probably have some questions (especally regarding programming/etc. soon). I just had a look at the default code from 2004 so far and no chances to trie anything out but it didn't seem horrible difficult to me (at least the standard functions/etc.). We'll probably have a little Testrobot for the club from tomorrow on which has the same chip so I can start playing around with it, which will probably cause the first question soon (or may not, if it's googleable : ) ...

Ok bye guys,

Felix "the_undefined" Geisendörfer

[Alan Anderson]

Originally Posted by phrontist

I'm sorry, I don't know that much about optics, please explain how this is not a focus problem. Logically, if you move the mouse up and down it will be tracking larger and smaller patches of carpet. Why would a sudden jump in registered distance occur if it were getting a clear image?

The "larger and smaller patches of carpet" will appear to be moving by "smaller and larger distances" as seen by the sensor. If you travel three feet, the mouse will record a certain number of counts. If you then raise the mouse and travel the same distance, the mouse will record fewer counts.

An optical mouse works by tracking offsets in the image at the sensor. The image at the sensor is a scaled representation of the carpet being viewed. The scale factor varies with distance from the carpet. If the distance is not kept perfectly consistent, the resulting measurements are likewise not consistent.

[gnormhurst]

Devil's Advocate here again...

Is there a findamental problem with using an optical mouse? The mouse reports a delta distance since the previous frame, as best as it can determine by performing a correlation between the current and the previous frame. But any fractional part of that measurement is not carried forward to the next measurement, and is lost.

For example, let's say you were trying to get the robot to move perfectly straight, but it was moving very slightly to the right, so slightly that the X axis change was less than one pixel of the mouse's imager per frame, say 1/3 pixel. The mouse will output zero change (because the best correlation would be "zero" offset).

On the next frame the mouse again compares the frame with the previous frame, and again the motion is so slight (1/3 pixel, not 2/3 because we only compare adjacent frame pairs) that the mouse again reports zero change. But the robot is moving steadily to the right.

Our program accumulates the deltas to measure position, but zero plus zero plus zero will be zero -- the slight drift to the right is never observed.

Compare that with a pair of wheel encoders. The difference between the two wheel encoders might be only 1/3 tick, but the error is "remembered" mechanically, so that the next time the difference is 2/3 tick, and finally the third time one side reports an extra tick compared to the other side, and the drift is detected.

The lack of memory for fraction pixel offsets seems fundamental to the optical mouse. Am I missing something? Is the resolution so high that my example would result in a trivial guidance error over the length of the field? If I knew the effective "size" of one pixel (on the carpet) I could calculate the potential error accumulation.

-Norm

[phrontist]

Originally Posted by gnormhurst

Devil's Advocate here again...

Is there a findamental problem with using an optical mouse? The mouse reports a delta distance since the previous frame, as best as it can determine by performing a correlation between the current and the previous frame. But any fractional part of that measurement is not carried forward to the next measurement, and is lost.

For example, let's say you were trying to get the robot to move perfectly straight, but it was moving very slightly to the right, so slightly that the X axis change was less than one pixel of the mouse's imager per frame, say 1/3 pixel. The mouse will output zero change (because the best correlation would be "zero" offset).

On the next frame the mouse again compares the frame with the previous frame, and again the motion is so slight (1/3 pixel, not 2/3 because we only compare adjacent frame pairs) that the mouse again reports zero change. But the robot is moving steadily to the right.

Our program accumulates the deltas to measure position, but zero plus zero plus zero will be zero -- the slight drift to the right is never observed.

Compare that with a pair of wheel encoders. The difference between the two wheel encoders might be only 1/3 tick, but the error is "remembered" mechanically, so that the next time the difference is 2/3 tick, and finally the third time one side reports an extra tick compared to the other side, and the drift is detected.

The lack of memory for fraction pixel offsets seems fundamental to the optical mouse. Am I missing something? Is the resolution so high that my example would result in a trivial guidance error over the length of the field? If I knew the effective "size" of one pixel (on the carpet) I could calculate the potential error accumulation.

-Norm

While I can't give you an exact figure (after optical modification), I'm using a chip with 800 dpi resolution. Even if that is reduced 10 fold, it's still many, many times more precise AND accurate than encoders. Your arguement is not a logically flawed one, but this is happening on such a small scale, I think it will actually be more straight than gyros or encoders. We'll see!

[phrontist]

Originally Posted by Alan Anderson

The "larger and smaller patches of carpet" will appear to be moving by "smaller and larger distances" as seen by the sensor. If you travel three feet, the mouse will record a certain number of counts. If you then raise the mouse and travel the same distance, the mouse will record fewer counts.

An optical mouse works by tracking offsets in the image at the sensor. The image at the sensor is a scaled representation of the carpet being viewed. The scale factor varies with distance from the carpet. If the distance is not kept perfectly consistent, the resulting measurements are likewise not consistent.

Right, but I still think this will be more accurate than anything else out there. I think it's entirely possible to keep the mouse within a 8mm range. And how long is it really going to be out of whack? A few tenths of a second perhaps... So lets say it misses 300 counts. That's a few inches off, and even if this happens fairly regularly its still so much dramatically better than any other robot navigation solution. It's not going to be perfect, but it will be better than it needs to be.

I think the bigger issue will be different surfaces, which will have to be accounted for by using banner sensors to detect changes. This will be interesting.

At the very worst, infrared and ultrasonic sensors are precise enough that they could be mounted near the optical sensor and used to scale data live. I really don't think it will come to that though.

[Craig Putnam]

Originally Posted by gnormhurst

Devil's Advocate here again...

Is there a findamental problem with using an optical mouse? The mouse reports a delta distance since the previous frame, as best as it can determine by performing a correlation between the current and the previous frame. But any fractional part of that measurement is not carried forward to the next measurement, and is lost.

...snip...

-Norm

It certainly is a legitimate concern, but I think in the grand scheme of things it will turn out to be a non-issue.

I am *not* using the mouse to give me lateral distances (call it the x-axis offset distance) in part for the reasons you have stated. Rather, I am using a rate gyro to tell me how much rotation the robot has experienced in the most recent time interval. I use the mouse to give me just the y-axis offset, i.e., distance traveled. A little trig and a couple of approximations later I can calculate a lateral offset which *is* accumulated.

The real question is: How much error will accumulate during autonomous mode using the <whatever> navigation system, and is it so much that the <whatever> navigation system is not reliable? Obviously all of these different systems have their individual strengths and weaknesses.

If during the (presumed) 30 seconds of autonomouse mode (good grief, I don't believe my fingers just typed that - but I like it!) - if during that time period the robot is only off by a couple inches then I will be ecstatic. [ I calculate that my refitted mouse should have a 1/4" resolution. We'll see if that holds up or not... ]

The wheel encoder system we used last year had about a 6 inch resolution. I know that much greater resolution is possible using wheel encoders, but that's what we had. So if the optical mouse works better, then great. If it doesn't work better, then maybe we all learned something.

[lynca]

I have been performing a experiment to validate optical mouse sensing with off the shelf robotic componets.

My work started with writing a custom PS/2 driver with an HCS12 microcontroller from motorola. Basically using a standard SPI interface I was able to communicate between the mouse successfully.
http://iarc1.ece.utexas.edu/~lynca/m...I_oscopeTests/

the code released is not meant for a PIC but can serve as a guide on implementing communication between a mouse and SPI port.
contact by email for the project which is still under development,
http://iarc1.ece.utexas.edu/~lynca/m...dia/FIRST/src/

My solution was not simple and easily transferable. Therefore I was determined to find something better for the robotic community.
I discovered Al William here near my area who had implemented a much more elegant PS/2 driver on a chip he call PAK XI (earlier version pak6).
http://www.awce.com/pak6.htm

Testing pictures, http://iarc1.ece.utexas.edu/~lynca/m...a/FIRST/PAKXI/

I also tested above, the gp5 with great success, I have misplaced my hyperterm outputs but email and I'll provide picture evidence if requested.
http://www.awce.com/gp5.htm

In all, the drivers can be implemented with any PIC (including RC) but an offboard processor streaming serial port commands of x and y is a very quick solution (GP5 through programming port). I have a Microchip project which does so but the code is messy at the moment, please email me a code request if curious.


thanks for your time,

~Andrew Lynch
for in depth look at PS2 driver for a PIC
http://www.computer-engineering.org/

[russell]

Well with my season over I am now working on some non FIRST related robotics projects. The first (and more relevant to this discussion) of these is trying to build a robot that can navigate our school, and build a sonar map which it can use for plotting routes between its location and its destination. The robot will be based around a PC running linux. Right now I am just toying with the idea of trying to use an optical mouse for measuring travel.

As far as mounting height why dont you just use a regular optical mouse mounted on one of the skinny pneumatic rams with a regulator regulating the pressure down to say 10 psi. Then you mount the ram such that it is not fully extended when the mouse is on the ground, so the mouse will always be being gently pressed on the ground. Then if you encounter terrain that is unsuitable for the mouse (put a sonar range finder pointing at the ground in front of the mouse to detect bumps) you simply retract the ram until you are back on flat ground. Just a thought.

[Alan Anderson]

Originally Posted by russell

As far as mounting height why dont you just use a regular optical mouse mounted on one of the skinny pneumatic rams with a regulator regulating the pressure down to say 10 psi. Then you mount the ram such that it is not fully extended when the mouse is on the ground, so the mouse will always be being gently pressed on the ground...

If you're going very slowly, that might work. The problem is that an optical mouse will lose tracking completely if it moves too fast. One reason for considering a "telephoto mouse" mounted high is to trade resolution for maximum speed.