Home : Projects : EID
Like a lot of people who type a lot (upwards of 10 hours on a bad day), I have problems with numbness, pain and stiffness in my fingers and wrists. I also find conventional keyboards pretty frustrating; the sheer wastefulness of closing at least one push-to-make, release-to-break switch to form each character, even when there are longer patterns (sometimes far longer patterns) that repeat so often, sometimes with slight variations, is starting to annoy me more and more. Now that it looks like I might actually be inviting health problems not so far down the line, I've decided it's time to do something about it.
To avoid disappointing anyone much further down the page, this project is in the earliest stages at the moment, but given that I have nearly all the hardware now and a good idea of how I'm going to go about this, it'll hopefully move fairly quickly - particularly since, if it works, it will speed my other projects along quite nicely and hopefully increase the chances I'll be able to play the guitar past 30. My aim is to be able to replace my (admittedly excellent, despite its redundant bells and whistles) Microsoft Natural Keyboard 4000 with my homebrew input device at work and at home by the end of 2010.
Very General Overview
Basically, the plan is to assemble hand-mounted glove-like devices (but probably more open than gloves) using linear potentiometers to read the positions of my fingers. Possibly supplemented by a few switches, these will be attached to Devantech's SD84, one of which I've just purchased from the (always excellent) Active Robots, who've rapidly become my preferred supplier for robot and interface related bits and pieces for the Lereco project.
The SD84 connects via USB to the 'helper PC', which runs a special, full-screen application I'll need to develop (probably in, or at least mostly in, Python, possibly supplemented by a little C if things need to move a little more quickly). To make the device a little more portable, I want to use my Asus Eee PC - I'm hoping to use this at home and at work and given the experimental nature of the prototype it's likely to undergo too many tweaks and changes for maintaining two of these to be worthwhile. The cost of building two would be little painful as well.
The helper PC reads the digital and analogue inputs on the SD84 and writes digital outputs. One of the great things about the SD84 is that it has such a large number of very flexible channels; I'm probably going to need a large proportion of the 36 available analogue input channels, but relatively few digital inputs and outputs, so there should be more than enough to play with.
The output channels connect to a home-built interface which will short together the appropriate pairs of traces on a PCB I've cannibalised from a faulty Dell USB keyboard to produce each possible keystroke. The USB cable attached to this PCB will simply plug into the host PC and appear to be a conventional keyboard. I'm not sure how standard the little edge connector on this keyboard PCB is, but I'll post full details under this project of which pairs produce which keystrokes soon just in case it's useful to anyone.
To answer some questions
Although people tend to back away slowly rather than ask questions when I tell them about this project, here are a few of the questions people have shouted over from a safe distance:
- Why do this?
- Why use the SD84?
- Why use a keyboard PCB?
- What is the helper PC doing?
- What are Accel 1 and Accel 2 on the block diagram?
- Can I join in with this project?
- Can I have one?
Why do this?
There are a number of interpretations of this question. If you're questioning my sanity in wanting to do this at all, I think you'll probably agree I'm unlikely to be best equipped to answer this question.
If on the other hand you're wondering if there aren't already decent hardware solutions for this kind of input on the market, well, I haven't found one quite like this. Building my own homebrew piece of hardware lets me design and tweak it to make it as ideally suited to my needs as at all possible, which an off-the-shelf solution is unlikely to allow. To be honest, I've looked at a range of 'ergonomic' input devices and the curvy Microsoft Natural Keyboard 4000 has been the best so far (even beating a strange arrangement I used for a while with a pair of keyboards, one for each hand).
Maltron do a good range of off-the-shelf adapted keyboards for a variety of purposes, but the cost is prohibitive, and while they do seem to work well for their users I'm not convinced they'd really address the problem of having to type large numbers of keystrokes, many of which I'm sure can be avoided entirely.
Another interpretation might be to ask why it's necessary to use custom hardware at all, rather than just focusing on the software side of this project to reduce repetition and accelerate typing. I've written a few pieces of software (including the software I use to maintain this website) to reduce the amount of typing I have to do, which in a way is a simple form of that approach. Also, lots of integrated development environments have neat features like Autocomplete, which can help avoid excessive typing by identifying repetitive code features like identifiers when only a few characters have been typed. Features like this are spreading into other applications too, like the Awesomebar in Firefox. Even the humble Cut, copy, and paste can save a lot of typing if used as often as possible.
I've decided to build this contraption anyway for a few reasons. Firstly, these various helpful features are great but tend to be quite specialised and different from each other, and this will allow me to produce something consistent I can wrap around various pieces of software, regardless of the 'accelerator' features the applications themselves are trying to provide. Secondly, these features in themselves tend to increase productivity without reducing the overall number of keystrokes per day (granted, the same will probably prove to be true in a sense for my device, but at least it has the advantage that there are no actual keystrokes, just relatively shock-free waves).
Finally, I'm actually very interested in learning about the SD84 and devices like it. The knowledge I gain from this little project should be very useful for Lereco's robot sub-project as well, and for who knows what else.
Why use the SD84?
I chose the SD84 rather than the PhidgetInterfaceKit 8/8/8 from Phidgets (which I already own and have been playing with; I'll post more about it soon) mostly because of the sheer number of I/O channels on the SD84. The 8/8/8 only gives me 8 analogue input channels, and I'm fairly sure I'm going to need at least twice that for this project. The SD84 supports reconfiguration of its channels as inputs, outputs and analogue inputs, which is great.
Support for the SD84 under Ubuntu Linux was embarrassingly good as well, which was a plus - I'd do a little 'how to' article but seriously, just plug it in and look for /dev/ttyUSBn appearing, it's that simple.
I think the excellent, readily available documentation (I'll forgive the apostrophe abuse) was the clincher in this case. I like to feel confident I'm going to be able to use something properly before I part with cash.
Why use a keyboard PCB?
Interesting question. Given that I'm going to have to write custom software anyway, why jump through the hoop of the keyboard PCB?
I liked this approach because I'd already reverse-engineered a keyboard PCB so I had a lot of the details, and I want to use this without installing anything weird on the controlled computer so that my employer's more likely to tolerate me using it on a work PC, where I do most of my typing. I'd probably have gotten away with writing a custom driver for it to be honest (given that I'm a software developer I can't really imagine what the objection would be) but being able to say it's essentially just a keyboard from the perspective of the controlled PC might be a bonus.
Also, my work computer is a Windows PC, but my home workstation is a Linux box, so this is one way I can use the same simple interface for the last hop into the controlled computer without writing any special software for it twice for seriously different platforms.
The lack of any pointer-type input from the 'gloves' may prove to be a slight pain later, but I have some ideas for how that could be fixed. I built a footswitch mouse sometime in 2008 or 2009 (I don't remember exactly when) so only the actual pointer movement would still need a solution. If it becomes a hassle I'll come up with something. In the meantime, keyboard input certainly covers most of my interaction with computers.
What is the helper PC doing?
The helper PC reads position and other sensor information from the 'gloves' and identifies patterns in the input. Patterns can be translated to one or more keystrokes, which can be sent to the host computer via the SD84's outputs.
The EEE PC makes a good helper since it should have adequate processing power for this job and has a neat little screen that can sit under the host computer's main screens without being too much of a distraction. The screen makes keyboard input more of a two-way conversation; I'm planning to use this for disambiguation, particularly of gestures that stand for larger numbers of keystrokes, or gestures which must be followed by more gestures to fill in gaps in the associated pattern (almost mail-merge style).
What are Accel 1 and Accel 2 on the block diagram?
They're accelerometers. They're dotted because the first prototype isn't going to have them, but I have a feeling I won't be able to resist adding them if funds allow at a later stage in the project. Adding detection of movements of the whole hands would probably be great - I can readily imagine a 'pull down' gesture for iconify, for example, and a 'pushing out' for maximise.
At a current price (16 March 2010) of £88.32 plus VAT each there's no way they're going to make it into the project until I've proved a simpler prototype can work and be useful though! You never know, they may even get a little cheaper before I end up buying them.
Can I join in with this project?
Not yet - it's my own crazy thing for now. I keep promising to get some server side machinery, including a contact system, working on this website but it's been 80% there for about four months now. Hopefully I'll get time soon.
Can I have one?
I'll try to post enough detail here that you could fairly easily build one; I'm not planning at this stage to try to manufacture and sell these, though if it turns out to be at least half as awesome as I'm sure you agree it looks like it could be (based on the fact you're reading this answer) I might think about it.