Keyglove Kit Initial Development

I’ve got quite a backlog of updates for you all, seeing as I’ve been quite busy but haven’t actually written any real blog posts here for over two months. Some of the updates may end up being bundled together, but my goal is to keep them each focused on a single subject to better explain what’s going on. We’ll see. Those of you keeping any eye on the @keyglove Twitter feed and/or the Facebook page have undoubtedly seen the steady stream of quick updates and photos that have been posted, but for those relying only on blog posts, I apologize for the apparent silence.

If you need a quick update without waiting for upcoming posts, check out the two links above—especially the Facebook page—and read through a bit of the history until sometime back around Christmas.

Keyglove Kit PCB

One of the things I’ve been working on is a way to make building a Keyglove yourself much easier, either piecemeal on your own or out of an eventual complete kit. Although there are relatively decent instructions available for a partial build already, there are a few reasons why it’s still pretty hard to do. The biggest problem is that there are just so many connections, especially once you start hooking up the sensors. If you’re working with a small solderless breadboard for prototyping, it gets insanely messy. And even if you can get all the connections right by hand, the last thing you want to do is have to disconnect even one pin—especially if it’s a sensor—because it can be a big headache to get it plugged back into the right spot.

The recent addition of interrupt-driven motion detection requires the use of the E4 and E5 pins on the Teensy++ board, both of which are internal and not the standard 0.1″ pitch. Adding the WT12 module with the most recent published design isn’t even possible, since two of the GPIO connections conflict with the RGB/vibe/piezo feedback module. In short, it’s way too easy to get frustrated with building your own, and that’s the last thing I want to have happen.

So, I’ve created a PCB that takes the place of the solderless breadboard, and instead provides a pre-routed board that is essentially just a collection of female or male header blocks, ready for quick connections of pre-built modules or logical sets of sensor cables, where everything is labeled and no jumper wires are necessary. In addition, the physical layout of the board is such that it’s smaller in every dimension than the solderless breadboard, and it includes a strategically placed empty space to hold the recommended lithium polymer battery.

While there’s still a little bit of work that you’ll have to do to use the internal E4/E5 pins on the Teensy++ board, since they’re a weird pitch and too small for normal header pin access, the rest of the board is designed for a simple plug-and-play approach. The board accepts a total of six modules:

• Teensy++ (required)
• SparkFun 6DOF module or Keyglove 9DOF module
• Keyglove LiPower module + LiPo battery
• Keyglove Feedback module
• Keyglove EEPROM module
• WT12 UART module

Note here that the Teensy++ is actually the only part that is strictly required. All you’ll get is touch detection, but it will work just fine that way. The other modules give you great capabilities like motion control, wireless support, feedback, and more flexible touchset programming, but you can easily get by without one or more of those. The motion sensor module can be either the 6DOF board or the custom Keyglove 9DOF board based on the MPU-6050. (Note that none of the Keyglove modules are available for purchase just yet, but they will be as soon as they are adequately revised and tested.)

Further, instead of being manually connected to the right I/O pins on the Teensy++ board, the sensors are broken out into per-finger headers:

• 1x 6-pin header for the thumb
• 4x 7-pin header for each other finger
• 1x 3-pin header for the palm

The bottom of the PCB is clearly labeled to indicate which sensor belongs with which pin. This in particular makes the whole process vastly simpler.

Since the LiPower board (USB/battery charger) requires the power from the USB connection but not the D+/D- data lines, we need a good way to “forward” those connections straight into the Teensy, since the Teensy also uses a mini USB connection, and it would be a huge pain to have to plug two cables in to the kit board every time you wanted to reprogram it and charge the battery at the same time. Further, the Teensy++ must be modified for 3.3v operation, so the VCC/GND pins from the Teensy can’t be used for LiPo charging, even if the current draw was supported. On top of that, the Teensy doesn’t break out the USB D+/D- pins, since under normal circumstances that would be a huge waste of precious board space.

My solution for the Keyglove kit is to use a small USB jumper cable that is connected all the time. The Keyglove LiPower board does break out all five USB lines, so those are brought to a 5-pin header on the edge of the board. This allows a short USB jumper cable (5-pin header on one side, mini USB on the other) to be connected to the Teensy so that the required connections are always present. It’s not the most elegant solution ever, but I think it pretty much is the most elegant solution that doesn’t involve a totally custom controller board—which, of course, is the main goal anyway. The kit is mostly an intermediate/alternative step.

Here are the photos from the Keyglove Kit v0.2 photo album on Facebook: (the v0.1 design never made it off the ground)

[fbphotos id=345497755484177]

Design Changes for 37 Sensor Connections and Bluetooth GPIO

One thing that I’ve finally been able to accomplish is to allow a full 37-sensor design with the Teensy++ board, which was previously not possible due to a shortage of I/O pins. Since I added three extra sensors on the thumb for more flexibility, I’ve been resigned to the fact that I just wouldn’t be able to use all 37 in the Teensy-powered version, but instead only in the full production version. This is no longer the case.

I’ve taken the feedback module and converted it into an I2C slave device, which means it’s now going to use just the SDA/SCL lines on the Teensy (which are already used for other I2C devices anyway). This freed up five whole I/O lines—red, green, blue, vibration, and piezo—which have been reassigned to the final three sensor connections (labeled 9, 0, and a*) and the two newly added GPIO connections from the Bluetooth module.

The GPIO additions are even more important at this stage than just those last three sensors, honestly, because without any GPIO access, some of the WT12 control becomes significantly harder to accomplish. The iWRAP firmware on the WT12 has two different modes: COMMAND mode and DATA mode. Whenever a Bluetooth link is active, the modules switches to DATA mode, and to take it out of this mode requires an escape sequence (those familiar with old-school modems may remember the typical “+++” escape sequence they used). However, the HID protocol used by the Keyglove actually ignores this escape sequence, since it is reasonable to assume that someone might at some point want to type “+++” without spontaneously altering the state of their wireless keyboard connection.

This leaves a third mode, known as MUX mode or multiplexing mode, where each command or data transmission is wrapped in a special framing packet so that both can be sent at the same time. This works, but it is much more resource-intensive for the WT12’s internal processor, and is therefore more limiting that I would like. GPIO access completely solves this problem by providing a very simple way to trigger a switch to COMMAND mode whenever necessary, and by providing a way to tell whether there are any active Bluetooth connections without querying the device over the UART connection. This will be extremely beneficial.

So what about that new I2C slave feedback module? It isn’t finished yet, but it’s now powered by an ATTiny44 MCU doing the heavy lifting of some PWM fading code, piezo frequency control, and of course the I2C protocol transmissions. It’s almost done, but not quite. The ATTiny’s code is available on GitHub in its current state.

Keep watching for more info. There should be some very good news about a glove manufacturer shortly!

On February 19, 2012   /   Development, Hardware, Uncategorized   /   2 Comments