Optical Mouse Navigation

[Kyle Fenton]

Originally Posted by phrontist

Max Lobovsky said the exact same thing. But there is one problem with this! Try using a ball mouse with a carpet patch as your mouse pad for an hour and I garuntee your enthusiasm for this idea will be curbed.

Yeah I was figuring the same thing. Just use a ball mouse. Optical mice are not meant to detect any fast movements. You can prove this by moving your optical mouse very fast on the mouse pad you will see that the curser on the screen seems to go in random patterns.

The only problem with ball mice that I can figure is the problem with resistance, but that should be negligible

[gnormhurst]

Okay, let me play devil's advocate.

Wheel encoders have been done before, and I assume they work. If a robot uses differential (two-wheel) drive and we keep track of each wheel's motion, and the tires are pneumatic and don't ever slip on the carpet, can't we measure not only x and y but rotation as well?

So my question is this: what great advantage does an optical mouse have over wheel encoders that makes us want to make this work? Other than being really cool, that is.

[phrontist]

Originally Posted by gnormhurst

Okay, let me play devil's advocate.

Wheel encoders have been done before, and I assume they work. If a robot uses differential (two-wheel) drive and we keep track of each wheel's motion, and the tires are pneumatic and don't ever slip on the carpet, can't we measure not only x and y but rotation as well?

So my question is this: what great advantage does an optical mouse have over wheel encoders that makes us want to make this work? Other than being really cool, that is.

Well, Astronouth and I were actually talking about this last night. The problem is, there is a ton of slippage, all the time. And even if there weren't it's less precise in general. You can do it, a lot of people have, but optical will be much more precise and accurate. If you have rotating wheels, you gain some more accuracy: see "StangPS".

Optical, if you interface to the chip using quaderature, is, from a code standpoint, just as easy as using quaderature wheel encoders. Easier, in fact. The only issue is optics and illumination, both of which I am near solving.

I'm totally psyched, as I believe I'll be the first to have a working, all optical, nav system. Whether all optical is even a good idea remains to be seen.

And once this works, I've got an even cooler idea to work on, Muhahaha!

[jonathan lall]

Originally Posted by gnormhurst

Okay, let me play devil's advocate.

Wheel encoders have been done before, and I assume they work. If a robot uses differential (two-wheel) drive and we keep track of each wheel's motion, and the tires are pneumatic and don't ever slip on the carpet, can't we measure not only x and y but rotation as well?

So my question is this: what great advantage does an optical mouse have over wheel encoders that makes us want to make this work? Other than being really cool, that is.

The problem is that wheel slippage always occurs, in every turn one makes (not to mention once pushing becomes a factor). Some robots with conventional swerve-style steering have a differential to minimize (but not by any means eliminate) this, but therein lies the problem. An encoder or hall effect sensor is placed somewhere on the drivetrain, which propels the robot, but does not reflect its actual movement as accurately as some would like. You are absolutely right that this usually doesn't prove troublesome to robots that steer as you describe, but they represent a minority in FIRST. This problem is especially the case with tank-style steering robots, i.e. most robots.

Enter terrain-following. Instead of looking at what the propulsion device is doing to estimate where the robot is, we are following the movement of the robot. Assuming the camera doesn't skip a beat and screw up, we get a much more accurate guidance system that opens up possibilities of pinpoint accuracy.

[phrontist]

Originally Posted by jonathan lall

The problem is that wheel slippage always occurs, in every turn one makes (not to mention once pushing becomes a factor). Some robots with conventional swerve-style steering have a differential to minimize (but not by any means eliminate) this, but therein lies the problem. An encoder or hall effect sensor is placed somewhere on the drivetrain, which propels the robot, but does not reflect its actual movement as accurately as some would like. You are absolutely right that this usually doesn't prove troublesome to robots that steer as you describe, but they represent a minority in FIRST. This problem is especially the case with tank-style steering robots, i.e. most robots.

Enter terrain-following. Instead of looking at what the propulsion device is doing to estimate where the robot is, we are following the movement of the robot. Assuming the camera doesn't skip a beat and screw up, we get a much more accurate guidance system that opens up possibilities of pinpoin accuracy.

What is terrain following, and how is it different than optical mouse based navigation?

[jonathan lall]

Originally Posted by phrontist

What is terrain following, and how is it different than optical mouse based navigation?

It's not different. Say I took some Agilent optical mouse sensor and placed it on the bottom of my robot. The camera would map the terrain over which the robot passes by comparing frame to frame. Hence the term "terrain following." This isn't to be confused with US Air Force LANTIRN technology, which is completely different... I mean more on the order of a non-INS that doesn't guesstimate position based on what the propulsion system is doing. A robot with a non-drive wheel hooked up to an encoder works by the same principle as an optical mouse then, and could be classified as "terrain following," though it's of course not as accurate as an optical mouse.

[phrontist]

Originally Posted by jonathan lall

It's not different. Say I took some Agilent optical mouse sensor and placed it on the bottom of my robot. The camera would map the terrain over which the robot passes by comparing frame to frame. Hence the term "terrain following." This isn't to be confused with US Air Force LANTIRN technology, which is completely different... I mean more on the order of an INS that doesn't guesstimate position based on what the propulsion system is doing. A robot with a non-drive wheel hooked up to an encoder works by the same principle as an optical mouse then, and could be classified as "terrain following," though it's of course not as accurate as an optical mouse.

How far along are you guys to a working system? I'm just waiting on parts

and I think Mr. Putnam actually has something working

[jonathan lall]

Originally Posted by phrontist

How far along are you guys to a working system? I'm just waiting on parts

and I think Mr. Putnam actually has something working

We have no plans for this year. Perhaps if other teams figure it out we'll brush the dust off our optical sensors. We never wanted to use a lens to zoom-out the image because of a lack of interest and many other uncertainties with this technology as it applies to guidance systems (for example, if we could program a guidance system that's appreciably better, and if we could get the inputs into the RC at all).

[Craig Putnam]

Originally Posted by phrontist

How far along are you guys to a working system? I'm just waiting on parts

and I think Mr. Putnam actually has something working

Well, there is "working" and then there is "ready to reliably run in autonomous mode match after match". We definitely have not reached the latter state yet.

We have the optical system / circuit board mount done and ready to go. We have the illumination system done and ready to go. We have a presumably illegal interface chip (PAK-VIa from Al Williams, Inc.) between the mouse and the PIC that has to go (sigh...). And we have some PID code taking inputs from the mouse and gyro that is getting there, but isn't quite ready for prime time either.

We have a prototype system using an unmodified mouse mounted to the mini robot controller. If I have to divert a lot of time into eliminating the PAK chip then I have serious doubts as to whether we will get there in time.

[gnormhurst]

Originally Posted by Craig Putnam

If I have to divert a lot of time into eliminating the PAK chip then I have serious doubts as to whether we will get there in time.

I can certainly understand that.

What we need is somebody to step up and solve the direct-PIC interface (eliminate the [wonderful] PAK chip). Maybe this solution would start with Kevin's new serial port code.

Any volunteers? Or two who want to work together? I imagine Kevin would be happy to consult!

[Gdeaver]

The solution is easy. The mouse chip that is probably in your mouse is a Aligent 2610. The data sheet can be found at 2160data sheet . The chip uses a SPI interface. Kronos robotics has an app note on this very subject. It can be found at Kronosroboticsmouse . From the data sheet Pin 3 is the IO and pin 4 is the clock. You need to find the circuit board traces for these 2 pins and follow them to the USB PS2 interface chip. After you find them, remove the interface chip and re-solder 2 wires to the circuit board as shown in the app note. The mouse I used had a different interface chip. The board was coated. I had to hold the board up to an intense light to see the traces. Next you need to cut the end off the mouse cord and solder on some pins or sockets depending on if you going to use a bread board or the robot controller. This will allow you to power you mouse and interface it to the PIC. I used a Kronos Dios Microcontroller and the code from their site to get it working. The Dios is a Pic microcontroller very similar to the PIC in our robot controller. It is programed in basic. Kronos basic has a software function to send out synchronous serial streams that make the SPI communications easy. They have code examples to get it working. The nice thing about the Dios basic language is that they have high level function to communicate to another micro with ether rs232 or rs485. You could use the Dois chip to interface to the robot controller using Mr. Watson's serial port libraries. The other option is to have the mouse talk directly to the robot controller. While the PIC in our RC has hardware SPI, I believe it is tied up with communications between the 2 PICs in the RC. This means the SPI would have to be done with software or what is called bit banging. Maybe someone on the forum could reference some examples of Software SPI code. While getting the mouse to talk to the RC is doable, I think where this all will fall apart is in adapting optics and illumination to keeping the mouse a couple inches off the carpet . Can an optic system be adapted to the mouse that would maintain focus as the robot bounces around? The chip is also very sensitive to the wave length , Intensity and angle of the illumination. The mouse may be a good replacement for an encoder. Place a wood disk on the inside of the wheel and mount the mouse as close as possible with out touching. The programing could be easier as it wouldn't have to deal with interrupts. The possibility of replacing a gyro and encoder with a cheap mouse is enticing

[Kevin Watson]

Originally Posted by Gdeaver

...This means the SPI would have to be done with software or what is called bit banging. Maybe someone on the forum could reference some examples of Software SPI code...

I wrote an example asynchronous serial transmitter a while back. It shows how to implement a serial transmitter using a timer and a state machine. It might get the creative juices flowing (hint: you'll need to tie the SPI clock line to an interrupt line and clock the SPI state machine in the ISR). The code can be found here: http://kevin.org/frc.

-Kevin

[Craig Putnam]

Originally Posted by Gdeaver

... While getting the mouse to talk to the RC is doable, I think where this all will fall apart is in adapting optics and illumination to keeping the mouse a couple inches off the carpet . Can an optic system be adapted to the mouse that would maintain focus as the robot bounces around? The chip is also very sensitive to the wave length , Intensity and angle of the illumination....

I actually have the optics working - at least on a test bed. Focus is a concern, but the purpose is to guide the robot during autonomous mode. I'm hopeful there won't be so much bouncing around during that time that focus would be lost to an extent that seriously hampers navigation. I may be able to get more depth of field if I stop the aperature down a bit. That means I will need more intensity, but I already have way more than I need.

The LED cluster I'm using matches the wavelength requirement of the Agilent chip almost exactly so that's not a problem. I also have the mount for the LED cluster done which will allow us to bring the light in at a fairly low angle. Not as low as it is with a mouse, but it seems to work on the test bed nicely.

I'm assuming the Kronos Dios microcontroller is available from the approved list of suppliers? I have already run afoul of last year's rule R71 with the interface chip I'm presently using (a PAK-VIa from Al Williams, Inc.). That interface chip works fine, but I can't get it from last year's approved list, so (I'm presuming) it's no good to me for use onboard a competition robot. I could hope that R71 gets revisited this year and the possible sources of electronics get opened up, but I can't count on that happening.

Thanks very much for the pointer!

[Gdeaver]

The Dios or Athena chip was pointed out because the example code is all there. It would be a good option for proto typing because of all the tools. The ability to capture and plot data are part of the environment. However, even though all the parts on a carrier board are available from digikey, it is a special PIC. A strict interpretation of last years rules would prohibit it. After the set up is debugged it's just getting the software in pic c on the robot controller. Someone out there on the form must of played with a SPI device.
WE just need some sample code of bit banging.

[phrontist]

Hmmm...

I don't think bit banging is nessicary at all. In fact, I don't plan to use interrupts at all. If you look at David Flowerday's post above, he links to the incredibly useful aligent site which has information on all of their chips. Many of the chips have quaderature output, which is really really easy to interface to! But the following issues came up in a discussion between Max and I:

1. The mouse would generate interrupts way to fast when the robot was at top speed, even with optics and such
2. You need three optical axis's, which means six pins to take quaderature input. Some of the digital inputs on the RC and grouped together, so while possibly doable, it becomes harder.

The solution is to use an accumulator chip, which will take in quaderature input and count "rotations" of the pattern, outputting it in as 8 binary outputs, which can in turn be read by the RC without issue. But no! I hear you cry... you need 8 digital inputs per axis! Well this is where the clever bit come in, once again courtesy of Max. The output of these chips can be turned on and off (and their counts can be reset), through one of the digital outs on the RC. So you connect all three accumulators to the same 8 pins, and than you poll them every so often (as long as its fast enough that the accumulators don't overflow). So you just turn each chip's output on in turn and read the values in!

Pretty cool, huh?