Well, there are a number of posibilities.
The search phrase: "ps2 keyboard interface touch sensors" does't return
anything usefull in the realm of rebotics.
If someone has done this I would like to hear about it.
PS2 gives serial data. You have 101 keys or more.
Problem is that keys are stuck on matrix, and
matrix is two plastic sheets with traces on them.
The keys push the plastic sheets together, connecting
traces, and the chip in the keyboard turns the signals
into serial data..
If you can find a PS2 keyboard with microswitches
it would be a great touch sensor. You could take
each switch out, solder wires to them, and mount
them wherever you like.
Commodore 64 keyboards have microswitches,
I think Apple II comuters do too. Problem with them
is they can only detect 1 key down with the
keyboard encoder chip.
I think it is a good idea to use ps2 keyboard as
touch sensor if you want to put 4 of them on
your bot, one on each side.
You cannot easily seperate 1 PS2 keyboard into many
switches. The time it would take would outweigh
The keyboard is a touch sensor already. It senses
which fingers are touching firm enough to actuate
If you had bothered read the first link that is returned
when you Google "PS/2 Keyboard" you would already know the
answer to this question. Why don't you take a few moments to
read up on the subject?
Someone asked why I bother to post, my reason is that I am building my
robot. I am building my robot in a way that *anyone* interested in building
one should be able to, with a limited budget but a reasonable skill set,
build it out of commonly available parts. It is targeted toward a high
school student level.
I am posting questions and information as part of this. It is good to get
opinions of others, not nessisarily that you agree, but to hear concerns or
facts as they relate to your question. Sort of "bouncing" the idea off the
group. Isn't *that* what this news group is supposed to be about?
If someone is interested in building a robot themselves, they may come to
this group or search google. They may find this and other discussions and
the dialogs may be helpfull.
Certainly Brian Dean's response was helpfull.
To Brian Dean's credit, he took the time to respond with information
that is readily available on the net.
Just like you assume that people know what I2C means, I assume
that you know how to do basic research on the net. I assumed
that when I said:
you would take a few seconds from your schedule to go to Google,
type "PS/2 Keyboard" and look at the results.
Here's how it works:
You go to Google.Com at:
You type "PS/2 Keyboard" into the search window and
click on the [Search] button.
Google responds with a page of search results.
The first result is to Adam's web page at:
You click on Adams web page it brings you to a
redirect page at:
This brings you to a page of links:
PS/2 Mouse/Keyboard Protocol
PS/2 Keyboard Interface
PS/2 Mouse Interface
and a couple of translation links.
Click on the first link and it brings you to:
which is a very complete description of the electrical
interface to the PS/2 keyboard including connector
pin-outs and signal timings.
Click on the [Back] button to go back to step 5.
Click on the second link and it brings you to:
which is a very complete discussion of the keyboard
software issues. The discussion on scan codes occurs
about 15% of the way into the document.
Brian's message is a synopsis of the information presented
in Adams's document.
In short, you can use any key on a PS/2 keyboard except the
Pause/Break key as a touch sensor. (You'll have to read the
document to find out why the Pause/Break key doesn't work.)
For further comments on this thread I am going to *assume*
that you have *read* Adam's two web pages on the topic.
High school has advanced since my time! So now they
are experts in electronics, operating systems and C++?
As I wrote before, we all enter this hobby at a different
skill levels. Your level with respect to programming
environments is high. If you don't provide an interface
with your programs to a lower level of programming
skill your software will be limited in accessibility
Any group is about whatever those in it at the time
decide it is about, it is democratic by nature.
Sometimes it's quicker and easier to ask a question
than to search google. If someone has already been
there, done that, they can give a faster and better
response than google. Google cannot compete with the
human brain as a search engine. One day, maybe, with
a bit of built in AI and knowledge of the needs and
skill level of the person using it a search engine
will do better. Wouldn't that be nice, an AI expert
that can respond to your needs without telling you
to go search Google :)
It is a bit like an expert refusing to answer a
question until the person has done the hard yards
in the subject as they have done. Perhaps accuse
them of not wanting to learn :)
If someone asks me how a TV works I don't tell
them to go do an electronics course, I give them
an answer commensurate with their knowledge base.
Also it can sometimes be just as easy to give the
answer as to tell them to go ask the Google God.
Search engines are great. But people are greater.
And so can their books on a subject.
And even if we are on different wave lengths it can
be motivating. After all your business about building
your PID I was motivated to give my motors PWM speed
control and design a suitable encoder.
Well, not experts, obviously. If it is done right, they should be able to
build the basic system with the level of skill and expertise you would
expect from a high school student taking electronics in school.
Then, it is just installing Linux. That may be a hard part. (they should
have some challenges, I suppose.) Then install my programs and run "robot."
At that point it should be usable from any language via a web services
If they want to do more, they can delve into the specifics of the program.
I am thinking that each function, motor control, object avoidence, speech,
will all be implemened in a UNIX shared library (like a Windows DLL) and
spun off into its own thread.
If you take a look at my code (I posted some proof of concept code that
maintains speed via PID)
Actually, what a usenet group is supposed to be about is described in its
I see no point in responding "go search google." I'm sure we've all done it,
but it isn't really very polite. One assumes they've searched using some
engine, but if someone knows something and is willing to contribute a few
minutes of their time, why not ask?
Even though I search google and alltheweb, I like to pose the topic to
others for a number of reasons. Not the least of which is it lets other
people benefit from the process.
On Wed, Apr 13, 2005 at 11:47:54PM -0400, mlw wrote:
Actually, that's not how it works. Each key press generates several
codes which are transmitted serially to the motherboard. Conversely,
each key release also generates a sequence. You get "make" codes and
"break" codes for each key. Shift, alt, control, etc are just another
key which generates their own unique sequence. Even caps lock are
just regular keys. The driver is actually responsible for turning on
the caps lock led by sending a command back down to the keyboard
controller - they keyboard itself doesn't do it on its own.
The driver has to decode the key input data stream to figure out which
key was pressed, whether shift is being held down, etc. Also, not all
keys generate the same number of bytes on press and release. It's not
as simple as one would think on first glance.
BDMICRO - ATmega128 Based MAVRIC Controllers
Cool. Like I said, I have never done any keyboard work. Some of the research
I did to find what I needed to implement the mouse encoder mentioned the
basic communication similarities of the keyboard.
So, it should be possible to dremel apart a PS/2 keyboard and wire bumper
switches to the various matrix connections. I'll rip one apart this weekend
and take a look and do some experimentation.
Many keyboard designs are capacitive, detecting keypresses by the
increase in capacitance at that crossing in the matrix, rather than
physical (electrical) contact. Direct connection of a switch may not
work, or one may work but several activated at once, especially if
they share a common matrix line, may not work the same as actual
look around http://arcadecontrols.com/arcade.htm they have articles and
discussions relating to interfacing buttons to the PS/2 keyboard port,
both through hacked keyboards and through boards designed for the purpose.
If you're up to serious microcontroller programming to roll your own
interface, http://www.computer-engineering.org/ps2protocol/ is a good
You might get lucky - I've had some apart that have the controller on a
small PCB that goes to a connector into which the "printed" cables of
the key matrix plug. I reckon that if you had one of those and
desoldered the connector (after tracing the matrix!), you could hook a
ribbon cable to it to a more "friendly" connector, say a bit of nylon
terminal block (connblock).
Kadina Business Consultancy, South Australia
Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here.
All logos and trade names are the property of their respective owners.