Re: Optical Mouse Navigation
 

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.

Re: Optical Mouse Navigation
 

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.

Re: Optical Mouse Navigation
 

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

Re: Optical Mouse Navigation
 

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

Re: Optical Mouse Navigation
 

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.

Re: Optical Mouse Navigation
 

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

Re: Optical Mouse Navigation
 

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

Re: Optical Mouse Navigation
 

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.

Accumulation of small deltas?
 

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

Re: Accumulation of small deltas?
 

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! :D

Re: Optical Mouse Navigation
 

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.

Re: Accumulation of small deltas?
 

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.

Re: Optical Mouse Navigation with GP5
 

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/

Re: Optical Mouse Navigation
 

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.

Re: Optical Mouse Navigation
 

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.