Mouse motor encoder / robot interface

I have been thinking about this for a while, and am working on bits and pieces in the form of a "HOWTO." Between work and family, it is taking longer than I thought.

I was stalled on my robot because I needed a cheap counter/timer rig to handle the encoders. I was looking around for something that was easily interfaced to a PC, but was well below the $100 mark. (Remember: sub $500 robot.)

Then someone suggested that I sit a mouse on each of the wheels. While it was an interesting idea, it lacked any sort of mechanical integrity. I did, however, start thinking about what an old roller ball mouse was. The are, in essence, an unpowered two wheeled robot.

Right now, the plan is to extract the LED and detectors from a mouse and either modify a drive train to incorporate them directly, or create an easy to make encoder housing.

The interface will be PS/2, USB, or even serial. These devices should be around for several more years and can be had for about $5.00. On top of the encoders, the button could even be used as touch sensors. (It is humorous to think of your robot as a big mouse)

Another big advantage of using a mouse like this, is the availability of software for testing. You don't have to write any code, simply use a mouse program. On wheel will go left or right, the other wheel will go up or down, the buttons will show up as menu items.

What do you think?

Reply to
mlw
Loading thread data ...

I know several others have done what you are talking about. I don't have any links handy, but I bet they will come up on a search of "Mouse Robot" and or "mouse encoder"

Joe

Reply to
cadcoke3

And here I was thinking "oh, I'm so smart." :-)

Anyway, it is still a chapter I think :-)

Reply to
mlw

I have done it. I implemented the PS/2 protocol in C on the 8051 board that controls my robot's drive motors. It worked fine for position control, but since the mouse transmits movement update packets "when it feels like it", I had problems with precise velocity control. If the encoder sample rate is not constant, the PID math goes to hell. The mouse will let you set the maximum sample rate only.

A larger (than 3 to 1) gear reduction between the motor armature and drive wheels may have mitigated the problems I had.

Jeff.

Reply to
Jeff Shirley

Where did you find the programming specs? I'd be curious to read. I have only seen the very lightest of treatments.

I assumed that the serial nature of the device was going to be a bit, "unpredictable" WRT timing, but there should be no accumulated error. The timing calculations would require a bit more information and probably have to use multiple readings from the mouse, and the gear ratio is pretty high.

Reply to
mlw

Ive done the mouse thing before and yes it does work, and works rather well as long as you take above mentioned considerations into account.

I've done it both ways, interfacing the mouse to a micro, and using a ps/2 port. The nice thing about using a mobo to do it is that you can usually change the polling rate for the ps/2 port, in esence, getting more data as fast as you want to get it. This can be done with a micro as well, but it takes more special code inside the micro, whereas the mobo you can jsut set a setting isnide the os.

You can get mice for a dollar or even less from surplus houses. The easiest way I've ever done it is use two mice, open them up, and rip out the encoders for one of the axes (jsut the wheels, not the sensors).

Aply 5 volts to the power pin of each mouse, one mouse per wheel, and use the data out to tell you where your moving, and even how fast.

I've also done it with one mouse, but the linkage to make it use both axes is a pita, and not worth the headache (in my opinion, but using two mice usually negates the easy integration with the mobo system).

Reply to
Andy P

In my case that OS would be Linux.

Really? Then what's the point?

I was planning on using the mouse PC board as a component and build encoders on the motor shafts of each wheel. That way, encoder reads come in at the same time for each wheel. This should help with keeping the opposed wheel control closer and reduce the total I/O.

Reply to
mlw

My first thought is what is the big deal about writing a mouse driver that you would need to use other peoples programs?

Secondly what are you going to use the encoders for? Motor control or navigation or both?

Industrial robots make up for a lack of "brains" by using absolute precision that exceeds that of any human.

But if it is the human abilities that you are interested in than relying on exacting motor control or navigation may not be the way to go.

A radio controlled plane, or car does not require encoders etc. because they are controlled by a human brain. Only dumb machines require such sophistication.

Encoders for navigation are useful for a dumb machine if you can reset them somehow to compensate for slippage. But if you have vision you can see where you are and determine without a compass what direction you are moving and so can a visually controlled robot.

A human at night in a dark house does not use exacting positional data. I can estimate how far to walk (turn motor on for x seconds) until I hit an object. I might follow the wall with my hand which can detect corners or doors.

I have decided not to worry about encoders at all but rely on bumber switches and visual input alone.

If i did decide to use encoders I think I would whip up some hardware to use them for motor control and/or counting turns or joint positioning.

There is the option of an optical mouse? If you are using the standard two drive wheels perhaps it can be placed out in front to measure degree of turn and how far in each direction?

[XXXXX] | |-------(mouse) | [XXXXX]

Of course you can do the same thing if you happen to have a web cam as input :)

Machines (or chess programs) that rely on the brute solutions to a problem will most likely not scale up very well.

-John

Reply to
JGCASEY

One could create a diagnostic program to test that your mouse is working, but why bother? Just plug it in.

Well, motor control and dead reckoning.

I've done my share of robotic navigation in the past. Between dirt on the ground, tire ware, wheel alignment, minute differences in tire diameter, tire surface, etc. There is no "precision" in a mobile robot.

Using wheels is useful for navigation only in as much as a "ball park" that needs to be re-adjusted constantly.

Nope, motor control primarily, navigational "guessing" secondly.

To control the motors you need to know if they are moving.

[snip]

How do you control the motors? You can't use a PID system without encoders.

And that's what I am using the mouse for.

Interesting, but not reliable enough. IMHO

Reply to
mlw

The best way of doing it would depend I think on the mechanics of your setup?

Another option might be to use the scroll wheel found on most new mice? It could be held on the tyre with a flexible strip of metal.

formatting link

The optical mouse has been used:

formatting link

- John

Reply to
JGCASEY

If the image is moving then the motors are also moving.

The Cybug doesn't use encoders to control its motors. They are controlled by the intensity of light on the two photocells or by the whisker operated micro switches.

A line following robot doesn't need encoders the motors are controlled by a white line.

My little robot is no different except it uses a web cam instead of two photocells.

Instead of deciding "where it is" or "how fast it is moving" by looking at its wheels it does so by looking at the external world.

Because I don't have your programming expertise my system is a little primitive. The robot takes an image. Processes the image. Decides how long to run each motor. Runs the motors. When they stop it takes another image... When I can speed that up I will most likely need the smooth motor control of a PID system.

- John

Reply to
JGCASEY

I'm not even focusing on vision yet.

The system I am trying to build needs PID.

Reply to
mlw

Sorry, just my hobby horse, I won't bother you again.

And I will be interested to compare it with other PID systems. Rather important if you want to execute complex motor actions.

Reply to
JGCASEY

Does this exist: PID motor control board with H-bridges and encoder inputs ?

for a reasonable price?

Rich

Reply to
aiiadict

No pun intended, I'm sure.

Reply to
the Artist Formerly Known as K

Hi,

I cut apart a logitech mouse and it is used for motor feedback on my robot. I use a BASIC stamp to control Hbridges. I send motor routines a command:

FORWARD 8000

motor routine looks like this: RTMOTOR= ON LTMOTOR=ON if leftencoder >= distance then stop if rightencoder>= distance then stop

he curves and sways and turns. I programmed some RPM matching software to get the PWM to the motors running at same RPM... But by the time this happens, robot has curved a bit....

That is why I ask if there are PID controllers with encoder input for reasonable price. I'd like to be able to tell the motor controller to go FORWARD and have it match RPMS and keep robot in straight line without having to use any processor time.

RIch

Reply to
aiiadict

Note on logitech encoders:

I cut the PCB inside the mouse into 3 parts.

1 has IC's and resistor networks, the "main" PCB in the mouse. other 2 have encoders on them... I connected the 3 boards with wires so I can mount the encoders remote to the main PCB... I only wanted distance, not direction. This method was $1.00 (thrift store), has two outputs (encoder L and R), and took about 30 minutes to put together.

Rich

Reply to
aiiadict

In my sub $500 robot, I am working on a schematic for a MOSFET h-bridge that is really cheap. MOSFETs a couple comparitors, a couple opamps, resistors, and compacitors.

The Mouse encoder topic is for motor feedback.

Reply to
mlw

lol, funny.

I have "a" vision, but right now, it does not "include" vision, but it will.

>
Reply to
mlw

This is the time where you turn to a processor with more horsepower...

Reply to
blueeyedpop

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.