Mouse motor encoder / robot interface

  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

cadcoke3@yahoo.com wrote:


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

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

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.
--
Jeff Shirley
no-spam@mindspring.com
"Bill Gates is filthy rich, but that doesn't mean I want to be married to him."

Jeff Shirley wrote:


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.

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

Andy P wrote:


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.

mlw wrote:

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.

http://www.boondog.com/tutorials/mouse/mouseHack.htm


The optical mouse has been used:
www.massey.ac.nz/~wlxu/reports_pdf/mecanum2.pdf


-
John

In my research I was able to find some cool information about the mouse. If
you put the mouse in "remote" mode, you can poll at regular intervals.

mlw wrote:

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

JGCASEY wrote:


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

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

I'm not even focusing on vision yet.


The system I am trying to build needs PID.

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.

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

for a reasonable price?

Rich

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.

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

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

No pun intended, I'm sure.

--
(Replies: cleanse my address of the Mark of the Beast!)

Teleoperate a roving mobile robot from the web:
http://www.swampgas.com/robotics/rover.html

Coauthor with Dennis Clark of "Building Robot Drive Trains".
Buy several copies today!

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