PS/2 Mouse PID motor control on Linux, code and description

Here is some of my first "proof of concept" code to use a PS/2 mouse to control two motors with PID.

Description of system Velleman K8000 I2C I/O board for D/A converters. Generic roller ball PS/2 mouse all hacked. Two kids ride-around toy motors. Mini-ATX (now called ITX) EPIA motherboard. Mandrake Linux 9.2

The code as follows:

i2cdev.cpp and i2cdev.h, I2C bus interface class k8000.cpp and k8000.h, k8000 inteface class. mouse.cpp and mouse.h, PS/2 mouse interface class mousecode.h, ps/2 mouse protocol codes.

mpwm.cpp, a hacked disaster of test code.

http://64.46.156.80/robot/mousrobot-050412.tar.gz You will not be able to compile this code "as is" because it is being built within a much larger code framework, but it shouldn't take much work, and the mouse, i2c, and velleman classes should require almost nothing. Feel free to post questions if you want to try it and get stuck.

The one interesting class is the "kbd" class used in mpwm.cpp, on Linux it wraps code for testing for a key present on the console and reading it. The important aspect of that code is:

Boolean MFKbd::iskey() { #ifdef Linux

int n; char ch; int result = FALSE;

TRACE_FUNCT("iskey");

if(m_waiting != EOF) result = TRUE; else { m_ionew.c_cc[VMIN]=0; tcsetattr(0,TCSANOW,&m_ionew); n = read(0,&ch,1); m_ionew.c_cc[VMIN]=1; tcsetattr(0,TCSANOW,&m_ionew);

if(n == 1) { m_waiting = ch; result = TRUE; } }

return result;

#elif defined( WIN32 ) return _kbhit(); #else return 0; #endif }

Theory of operation: (in mpwm.cpp)

Encoder is a virtual class to define a set of encoders. Ps2Encoder is an implementation of Encoder that uses the PS2 mouse interface class, Mouse. PIDControl is a class that implements PID control. In the function: CalcPID: PID stands for: Proportional, Integral, Derivitive error is the difference between target and actual. Propotional comes from the current error times a "gain" value. Integral comes from an accumulated error times a "gain" value. Derivitive comes from the difference between the previous error and current error times a "gain" value.

Loop operation:

Check if a key is hit, if so, read it and act on it. (Allows to play with the various gains and speed.) get current time of day. Update the encoder values. Calculate elapsed time from start Get the current encoder values. Scale them for elapsed time. calculate the PID. If a second has passed, print a report. (Test code, will not be there later.) Calculate the proper values for the motor control. Send them out if they are different than the last time. Save the current time as start. loop.

Reply to
mlw
Loading thread data ...

"mlw"

As you have spent some time hacking a PS/2 mouse, what are the basic steps to make it work as a displacement sensor?

I have to measure the activity of a shock absorber or a small RC monster truck. The delta of the travel is about 3 inches.

Another day I've opened an old mouse I have around and I found out that they use optical encoders (incremental), so how can they tell the direction of movement?

Cheers

Reply to
Padu

Google on "quadrature encoder"

Best regards, Spehro Pefhany

Reply to
Spehro Pefhany

I looked about three ball mice, and they all seem to be built the same way.

The optical sensor is actually two photo-diodes next to each other. The wheel rotates across the front of the two diodes, breaking the light from the I/R LED transmitter.

If you look very carefully at the mouse wheel, you'll notice the teeth are somewhat triangle shaped to make up for the round shape of the wheel and makes the gap between them is fairly rectangular.

Rotating in one direction, light from the i/r led hits one photo-diode first and then hits the second.

It is VERY important that you orient the pick-up dual photo-diode sensor correctly. The diodes are next to each other and the gaps in the wheel seem to be carefully matched. If you position the pick-up 90 degrees off, the light will hit the two photodiodes at the same time.

Reply to
mlw

"Spehro Pefhany" wrote

I know what a quadrature encoder is, my astonishment is that the encoder I saw in the mouse doesn't look like one.

Reply to
Padu

"mlw"

So that's the catch... I was expecting to see two light beams in order to provide the phase shift of the signal. Very clever.

Now, I see 4 wires that are important for the encoders: VCC, GND and two signal wires. What is the messaging protocol? I2C?

Reply to
Padu

They are just phototransistors.

Best regards, Spehro Pefhany

Reply to
Spehro Pefhany

No, it is a TTL serial interface, around long before I2C. If you download the code, you'll see it is a packet based protocol, the file mousecode.h has all the important parameters. The files mouse.cpp and mouse.h show how to talk to the mouse as if it is a serial port. (on Linux.)

Reply to
mlw

I'm not sure that a mouse is the correct instrument for your application. I can see a possibility of losing a count at each end of the movement. Maybe you could use one of the micro switches on the mouse to indicate "top of position" or something. You'll still get error, but it won't accumulate.

Reply to
mlw

"mlw"

That would be even better, I suppose then that I could plug it directly to a PIC USART port right? Would you be kind to send those files to me by e-mail? I cannot open rar files.

Reply to
Padu

"mlw"

I don't need that many precision, just a rough estimate of activity to feed a fuzzy controller (LOW, MD, HIGH) and I don't mind loosing the count at the end of the travel. The switches would only tell me when suspension bottoms out (or something similar).

I've investigated some linear displacement potentiometers, but they are too expensive for what I need, and free stuff is really hard to beat.

Reply to
Padu

They are tar.gz files, if you are using Windows, WinZIP will handle them. If you have a Mac, you have tar.

Reply to
mlw

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.