Share this project


Share this project

A glove-based input device that provides full mouse/keyboard control built for wearable/mobile computing and handicapped users.
A glove-based input device that provides full mouse/keyboard control built for wearable/mobile computing and handicapped users.
95 backers pledged $12,474 to help bring this project to life.

New Keyglove firmware, KGAPI protocol, and working Bluetooth


How do I update thee? Let me count the ways...

Since my last post, I have created a lot of documentation, written a lot of new code, done just a bit of yak-shaving, and published all of the new code and docs to the Keyglove Github repository and a new Arduino firmware documentation page on the project website. These accomplishments involved some ancillary activities, and there are also some other points to mention, so as usual I will try to address each main topic in turn.

New Keyglove firmware Arduino code

The most significant news is the updated and largely rewritten Arduino firmware source code that powers the microcontroller at the core of the Keyglove design. Since this is an open-source project, it has always been my intention to publish the complete source so that anyone can understand or modify the functionality however they might wish to. However, I am a bit of a neat freak when it comes to code. Well, "a bit" may be an understatement. It's hard for me to work with or around code that isn't organized, and/or formatted, and/or documented well, and it's even harder for me to publish it knowing that others may need or want to use it in their own designs. Before I feel good about handing something to the world, it must pass my own tests for organization, readability, and documentation.

In light of this, a significant portion of my work on the Keyglove project over the last few months has been making all of my code consistent, splitting it up as logically as possible into modular files, and finally documenting the heck out of it. I am proud to say that these efforts have paid off, and I've published the not insignificant results to the Github repo, and all of the documentation to go with it.

Keyglove Arduino documentation
Keyglove Arduino documentation
Keyglove Arduino file list
Keyglove Arduino file list

It's great to write so-called "self-documenting" code, and I have tried to do that. I don't want people to need to refer to documentation any more than is absolutely necessary, and well-written, well-commented code can go a long way. But at the same time, there is no substitute for good documentation. The code that makes perfect sense to me because I wrote it might make no sense at all to someone else. The documentation linked above is my initial attempt to make sure that doesn't happen. It will undoubtedly be improved over time, but for now, it's a good start.

So what exactly does the current published Keyglove firmware support?

  • Teensy++ 2.0 microcontroller
  • USB (wired) HID and serial connectivity
  • Bluetooth (wireless) HID and serial connectivity
  • Up to 37 touch sensors
  • MPU-6050 6-axis motion sensor
  • Blinking LED feedback
  • RGB LED feedback
  • Vibration motor feedback
  • Piezo buzzer feedback
It is up to the user whether and how each component is used in the whole system. The firmware has been written as a generic platform that can do all kinds of things (including things I haven't imagined), but doesn't necessarily need to. The totally default non-customized behavior is that it boots into an "idle" state after running through the initial setup process, and then simply waits for instructions from an external host. But with only a few lines of code in one single file (application.h for the coders reading this), you can include any autonomous behavior you want, even going so far as to make host control totally unnecessary by putting all relevant application logic right on the Keyglove itself.

Think of it as a keyboard + mouse + joystick + motion sensor combo device which you can load your own custom code into, and/or fully control from another device. It's extremely customizable. This brings us to...

Keyglove API protocol (KGAPI)

As I alluded to in the last update, I've now implemented a straightforward protocol that you can use to control the Keyglove. This is made up of the following basic types of communication:

  • Commands: sent to the Keyglove to make stuff happen
  • Responses: sent back from the Keyglove after commands are sent, acknowledging or reporting errors
  • Events: sent from the Keyglove when things happen that aren't directly triggered by commands, such as touch sensor changes or new motion data
This is the same kind of structure that you will find in many protocols used by hardware peripherals, so there's nothing really special here.

However, one important point to mention is that while you can use the KGAPI protocol from an external device like the PC to which you've connected the Keyglove, you can also use exactly the same "vocabulary" of commands, responses, and events right in your custom application code in the firmware. This gives you a lot of power and flexibility that you won't find in other similar devices; rather than just making external control possible, the Keyglove implementation makes it as easy and intuitive as possible to tweak the firmware itself (remember application.h?), even going so far as to use the same command names, parameters, etc.

What does this mean practically? Let's say that you write a Python script which talks to the Keyglove using KGAPI, and handles the "touch_status" event (which happens whenever a touch sensor changes state), and inside that event handler you use the "motion_set_mode" command to turn on and of the motion sensor based on the touch status. Rather than making the PC do that work, you could use the exact same set of commands and events to make that behavior part of the firmware itself.

You could further offload basically anything from the PC onto the Keyglove itself--touch interpretation, motion processing, Bluetooth connection automation, feedback, you name it--so the only thing the connected host sees is the actual control signals over the human input device (HID) interface. This is in fact how I assume many people will want to use the Keyglove, but this alone is too limiting. Not everyone has the same implementation vision as I do, and I want to empower as many different use cases as I possibly can with this platform. My last visit to Maker Faire powerfully communicated the importance of that goal to me, and now, it has become a reality.

Another feature worth mentioning is the ability to extend the KGAPI protocol with your own commands, responses, and events if desired. This is more than most people will want to mess with, probably, but for those who do, I've made every effort to make it easy. You can find reference code and comments in the custom_protocol.h file.

I am still working on a KGAPI reference manual, but it isn't quite ready yet. It's coming along, but it's still too bare. In the meantime, the previously linked documentation includes descriptions for all of the commands (functions beginning with "kg_cmd_..."), and there is a handy reference file for all of the possible event handlers you might need (the application_stubs.h file).

I also have a Python implementation of the whole API including a parser and a few test scripts, and I am working on a simple cross-platform graphical testing application, also written in Python and using the wxPython GUI toolkit:

Keyglove GUI Test Software
Keyglove GUI Test Software

This will be published as soon as I consider it to be stable. There are only a few fixes and additions remaining before it will reach that point. However, the core KGLib parser library and a console-based test script are already available on the Github repo.

Working Bluetooth system

So what's all this about Bluetooth? As some of you may know, the Bluetooth wireless system has been one of those lingering features that I couldn't quite manage to nail down for one reason or another. Well, I nailed it down. I've got a robust connection and data management system in place, built around the Bluegiga WT12 Bluetooth module and its powerful iWRAP firmware.

The solution to this longstanding problem involved much of the "yak shaving" that I mentioned earlier. (For a brilliant and hilarious explanation of yak-shaving, see this animating GIF.) In short, I totally rewrote the iWRAP parser library that I began years ago in order to make it function properly and fit nicely with the Keyglove API structure. The end result of that effort is a cleaner and much more intuitive interface that I and anyone else can use to talk to Bluegiga's classic Bluetooth modules, like the WT12 that I have in the Keyglove. While it technically stands on its own and isn't part of the Keyglove firmware, it dovetails perfectly between both the Keyglove and my day job at Bluegiga, and it has already been useful for other people in other applications.

In short, the new iWRAP code cleaned up one of the messiest and most complex parts of the Keyglove firmware source, and is now both much easier to understand and much easier to maintain (not to mention the more important fact that it actually works correctly).

With the right configuration, the Keyglove can now automatically reconnect to one or more previously paired devices, even going so far as to support simultaneous connections. This means, for instance, that you could connect to your PC and your smartphone at the same time, and have one set of touches trigger behavior on the PC while a different set controls the media functionality on your phone. Yep, it's that flexible.

Keyglove kit development

All of the above means that the main Arduino firmware is in a state where quite literally everything officially supported (so far) is totally working, at least as far as I have been able to test. There will undoubtedly be more coding required, but not right now. It's reached a stable milestone that I am satisfied with. Therefore, I feel free to focus on solving other problems that have been on the back burner for some time--most importantly, creating an easily reproducible kit which can be assembled with (ideally) not much effort using as many off-the-shelf parts as possible.

I have been in contact recently with some of the people who have worked on similar glove projects that heavily involve e-textiles, and I'm hopeful about the outcome of those efforts. Previous discussions with other individuals and companies haven't panned out yet, but I've actually met these people in person before, so as long as they have the time and I can make it worth their while, I will remain optimistic.

I am simultaneously taking a new approach to solving the very difficult problem of mounting and reliably wiring so many sensors on the glove. Honestly, 37 sensors is a lot. Most people won't want or need to use that many. Having 37 also tremendously complicates the sensor wiring, to say nothing of the tedious mounting process. So, in the interest of moving the football down the field, as they say, I'm creating a simplified variant of the design that cuts the sensor count down to a mere five: one for each fingertip. Since multitouch and touch order permutations are still easily possible, there are still many possibilities for customized behavior. Full alphabet input is probably not included in this unless you are extremely clever and/or patient, but that's okay for now.

Much like what I just finished with the firmware source, I'm trying to focus on the next milestone that I know I can achieve even if I don't have any help. Of course, I'm still pursuing the more ambitious goal for which I'll need help from others, but since I don't have any guarantees for how that will go and I still have rewards to deliver, I've dialed back the requirements for reaching the next step so that it is actually within my grasp. Once I make that goal, I'll set a new one and pursue it while starting from my new vantage point, so that one way or another I can achieve the final goal.

On the horizon

What can you expect in the next couple of months? Here's my high-level to-do list:

  • Create 5-sensor version of Keyglove kit with glove, battery, feedback, and wireless support
  • Continue discussion of complex e-textile implementation with contacts
  • Add content to KGAPI Reference Guide and publish
  • Finish initial release of Keyglove GUI testing software

Can I manage it by the end of September? I will do my best. As always, for more frequent but brief updates on the project (there have been 50 since the last Kickstarter post), be sure to keep an eye on the Keyglove Twitter feed and/or Facebook page.

Thanks for your continuing support!

New codebase, KGAPI protocol, and Bluetooth developments


Over the last few months, I have been working rebuilding the Keyglove code into something that is as plug-and-play as it can be with a few off-the-shelf components and open-source software. This has always been the goal, of course, but during the last iteration of development, things had started to get a little out-of-hand. As I hinted at the end of the previous update, part of this involved looking at what I had already created and reconsidering the approach based on new technologies that have been created and all of the knowledge I have gained over the last year since changing jobs.

Simplify and Standardize

One of the first things that I did was move all of the existing Arduino code into a backup folder and rebuild only the necessary parts piece-by-piece. This doesn't mean that I rewrote everything from scratch, but instead that I went through each existing source file and copied only the parts that I wanted to include in the official "this-is-guaranteed-to-work-and-be-supported" firmware. This doesn't mean that any functionality was lost; rather, it means that I was able to focus on finishing the parts that need to be there and stop being distracted by potential or partial support for things that aren't critical.

For example, there are a few different I2C motion sensors that I had written some code for, but since moved on to a different sensor that is cheaper and more capable. I also had some structured code for Arduino hardware variants (e.g. Arduino Uno, Arduino Pro Mini) which I have never meant to fully support myself, since it is impossible to incorporate the feature set I want with those boards. There was no reason to leave that code in the standard codebase.

As a result, there is now exactly one platform supported at the moment:

This is the hardware that I used for Prototype E at OHS and Maker Faire last year, and it fits with the Keyglove Kit PCB prototypes that I created to mount on the back of the Ektelon racquetball gloves. Given the performance possible with this hardware and small size and low price for exactly this configuration (~$75 for the above list), this is my target platform, and I am focusing exclusively on making it operate perfectly. I have also made the code "smarter" in that you can choose different configurations within the Arduino IDE, and compiler will take care of the code inclusions/exclusions for you without requiring any effort on your part.

My ultimate goal is to migrate to the Atmel SAM3X8E ARM processor (which is on the Arduino Due board), but I am holding off on that until the Teensy-based build is completely finished to the point where you can buy the parts, download the source code, open the Arduino IDE, compile it, and have a working device in two minutes. And honestly, apart from the glove attachment, we're almost there. I even used the current (published) code for a handbell motion capture test last week, and it performed admirably. You can find the latest code up on the Github repository, if you're interested.

Keyglove API Protocol (KGAPI)

I have my recent Bluegiga experience to thank in large part for the knowledge to pull off the standardization of the API communication protocol that I'm now using for the Keyglove. The protocol that I had before was remarkably similar to the binary one used by Bluegiga for a couple of their modules, but mine lacked a few of the features and structural definition. I have now modified the KGAPI structure such that it is easily defined and interpreted, and very extensible. I'm working with a simple protocol definition in JSON format. This is then run through a PHP script that I wrote which dynamically generates a complete KGAPI library code in Python (C/C++ coming) with example scripts for serial and raw HID usage, as well as very thorough documentation to go along with it:

This JSON API definition is enormously beneficial, since I can make a modification to the definition in exactly one location (the .json file), then re-run the documentation/code generator and have it automatically rebuild everything in a split second. I only have to make sure the definition is correct and in line with the actual Keyglove firmware, and everything else is done by the script. It's fantastic.

I've been working with Python because it makes an easy host platform, but I'll be adding pure C library support as well as VB and C# libraries for Windows development (which will let me revisit the Autodesk Inventor integration plugin I was working on last August). Stay tuned for more KGAPI updates. The documentation itself will be published as soon as I'm satisfied with the structure and introductory content.

Bluetooth Development

One more topic to discuss briefly: since I've been working at Bluegiga for just over a year now, I have an intimate knowledge of all things Bluetooth and iWRAP (the firmware they run on the Bluetooth modules). Because of this, I've been able to build in proper support for using the WT12 module, including reliable pairing and automatic reconnection to multiple devices. Here's a screenshot of some debug output showing what's going on behind the scenes:

I have been focused on wired communication as a baseline for the last few weeks, but I will be able to return to this code and fully integrate it in one development session, I expect. The above test worked reliably with an iPad, Android phone, Google Glass, and my Windows 8.1 desktop PC. The auto-connection algorithm is actually the same one I wrote a Knowledge Base article for Bluegiga on, but...I digress.

That is all for the moment. Remember that you can always follow the Keyglove development process in more frequent bite-size pieces on Facebook or Twitter.

Stepping Stone to Wearable Control with Bluetooth

Hello backers,

A few weeks ago, I finally got to pick up my Google Glass device in Palo Alto, and have (amid two business trips) been working on wireless control of Glass through Bluetooth within the context of the Keyglove design. Here's the first picture of the Keyglove taken through Glass--something that I was immensely excited to create, just for what it means about what I am now able to work on:

Since the day I took that photo, I've been able to explore in some detail exactly what kind of Bluetooth control is possible, and I'm pleased with the results. I just finished a rather technical blog post about the process here, which you can read if you're interested:

It does get to be pretty geeky regarding the discovery process, but there are lots of screenshots showing what various Glass display modes look like as well, so you might want to glance through it even if technical stuff isn't your thing (though perhaps I need not worry about this group of backers, since most of you are all pretty technical anyway!).

I'll be spending more time during this long weekend continuing to work on some embedded code changes that will make the Keyglove controller board operate more efficiently and hopefully take care of a couple of strange touch sensitivity problems I ran into earlier this year. The unintentional break from development during the first part of this year has given me some new approaches to work with, which is certainly one of the better possible outcomes of the delay.


Diving back in, and Google Glass plans

The last seven months have been somewhat of an unplanned hiatus from the Keyglove project. As I mentioned in my last Kickstarter project update as well as a bit later in a post on my personal blog, my position at Bluegiga has been taking virtually all of my time. There is a lot more travel, and some odd hours due to the global nature of the business and the kind of support I need to do. This has been getting better over time though—the odd hours part, anyway—and I am absolutely determined to get back into working on the project, for a few reasons.

For one thing, I have now passed the two-year anniversary of the successful Kickstarter campaign. It was one week ago today, in fact: April 27. That is a tremendously long time to wait, for all those of you who backed the project. I am continually encouraged by the ongoing support, and conversely by the conspicuous lack of impatience displayed despite the long, drawn-out development process and the painfully long silences at times (like over the last many months). I want to work on this project, and I want to do it now. This by itself is motivating.

For another thing, although I haven't had much time to <em>work</em> on the Keyglove, I have still found myself thinking about it quite often and at times doing what could be accurately called brainstorming. Some of the ideas I've had should prove to be fruitful once I immerse myself in development again. A corresponding observation to this point is that I think it will be beneficial for me to begin again with the codebase and designs I already have, but with a relatively fresh viewpoint. It will be easy for me to objectively evaluate the systems I have already built and look for any areas which may benefit from certain changes or a re-imagined approach. This kind of analysis is easier to do when you haven't been neck deep in the project for a while.

Third, there has been quite a bit of relevant innovation in the areas of wearable computing, wireless connectivity, battery technology, and low-power programmable microcontroller systems. Might it be worthwhile to incorporate an Arduino compatible ARM processor instead of the AT90USB MCU I have? Possibly. Bluetooth Low Energy for wireless comms? Very likely, at least as an option. Flexible PCBs? Maybe. New, tiny motion sensor? Sounds great. Bundling everything into a single FPGA? It could be done. The bottom line here is that six or seven months on the embedded system design timescale is significant. There is a lot that has happened in the world since then.

Perhaps the most personally exciting reason for me though is this:

I managed to snag a slot on the new Google Glass Explorers group as part of the #ifihadglass contest that Google put on back in February. I am definitely more excited about this than is healthy for someone as far down the list of early adopters as I am (though I am still thankful that I'm on the list in the first place). My entry tweet was about combining it with the Keyglove, and their reply came a little over a month later. I was (and am) ecstatic.

As it happens, I actually got to try a Glass device back towards the end of January of this year, while having dinner in San Francisco with a friend from college who is now way high up on the Glass development team. It was a pretty short demo, but I was completely enamored. Truth be told, I'd actually had a dream the night before about what it might be like, in subconscious anticipation of that eventuality. I truly can hardly wait for until my turn comes to get a development unit. This is exactly the platform for which I originally created the Keyglove. I don't know when I will get mine, but I want the Keyglove to be ready to take full advantage of the opportunity.

In my opinion (and others'), Google Glass has tremendous potential. Augmented reality and instant contextual information has a value that we can't accurately quantify yet. We don't have enough data to predict with. Glass will allow innovative people to expand the range of possibilities, to give us ideas about things we will find invaluable which today we can't even imagine since we don't have a mental framework to put them on. I want the Keyglove to be right there along side this discovery process, solving the input challenge where Glass so (comparatively) eloquently solves the output/display problem of wearable technology.

So, while I'm waiting for Glass...what's next?

I need to run through the Roadmap again and freshen things up a bit. Then I need to try compiling the last code snapshot I have and see exactly where I left things at the end of September. Then, I will read through the modular code structure I have and see if there are any structural changes to make right off the bat, or if I should go straight to fixing bugs and adding or completing features.

Begone, distractions! I have work to do!

Bluegiga, OHS, Maker Faire, and Seeed Studio

As most of you know, I got to participate in the Open Hardware Summit and then World Maker Faire at the New York Hall of Science at the end of September. This was an excellent opportunity, and for those of you who remember my update about the Keyglove exhibit at Maker Faire last year, let me say that this one went significantly better than last time--no sickness, no loss of voice, much better preparation, and of course more development done on the project. OHS was great as well, but I'll explain more about that in a moment. First, a bit of news about why it has taken me a full month to update you all about the trip to NYC.  

Bluegiga Adventures  

In the middle of August, I had a fantastic opportunity fall into my lap: Bluegiga Technologies offered me a position as the senior Field Application Engineer for their US customers. Bluegiga is the company that makes the WT12 module I use in the Keyglove for wireless communication, and it was entirely due to my search for a good Bluetooth module for the Keyglove that I found them in the first place back in 2011. I was just a customer then, and their products, documentation, and incredible customer service got me hooked.

My subsequent efforts to create a few breakout boards for my own prototyping (and later resale) and the Arduino code library I wrote to interface smoothly with their iWRAP firmware put me on their radar, and so they came to me a couple of months ago with a very good offer, which I accepted. It would have been crazy not to under the circumstances, though I and my previous employers were sad about my departure from their company--I've been a web application developer there for almost 10 years, since before I started college, and I enjoyed both the people and the work. But this position at Bluegiga was too good not to take.  

Fast forward to the beginning of October, literally one day after Maker Faire ended. I had a week-long trip to Atlanta for introductory training at Bluegiga's US headquarters, followed immediately by two weeks of more focused training at their main office in Finland. I got back from there on Sunday morning (the 21st of October), and I actually wrote a good part of this update while sitting on a plane on my way back from another week-long event in Chicago! The schedule has been crazy, but it's settling down a bit after this last trip, and I should be able to get back to a normal routine soon. There's still a whole lot of steep learning curve for me to overcome in a very short time.

So what does this mean for the Keyglove project? Well, it's still mine to work on; changing day jobs doesn't affect ownership. There is no competition with Bluegiga's products--quite the opposite, in fact--so they are more than happy to have me continue working on it. Most importantly, my head has now been crammed full of knowledge about their products, including some of their upcoming modules. I will be able to make the WT12 integrate as well as possible with the Keyglove, finish the iWRAP code library (which is still missing a few features), and plan much more thoroughly for incorporating Bluetooth Low Energy in the future. This will allow for better integration with new iOS devices and any other new hardware that supports BLE.

In short, my new position at Bluegiga will help tremendously in the areas of Keyglove development that use wireless technology. I am really excited about this.  

Open Hardware Summit

The Open Hardware Summit on September 27 was the first main event that we attended in NYC. (By "we" here, I mean myself, my wife, and her mom who came along this time and helped out a ton--thanks, Sonia!) The event took place at Eyebeam in the southwest part of Manhattan, and held at least a few hundred people. There were a few dozen speakers and even more exhibitors, including Super Awesome Sylvia, for whom I had the pleasure of demoing the Keyglove that evening. I met some great new people and a few current friends, and learned about amazing tech and even some things that will help with Keyglove development. One of the guys from Mach 30 even did a quick interview of me at the booth, which you can watch here if you're interested. (Pardon the noise; it was an incredibly loud environment.)

I most enjoyed the OHS speakers for the day, including a great keynote by Chris Anderson of Wired Magazine (his presentation starts around 11 minutes in on that keynote link), a humanitarian Geiger counter project by the guys at Freaklabs, and some interesting discussion about intellectual property and licensing when it comes to open-source hardware. One of my favorite lines: "Give away the bits, sell the atoms." Bingo! Chris Anderson's tale of a Chinese product cloner converted into a value-generating contributor was another great lesson. Structuring a company and development process to encourage openness is definitely the way to go. Or, at least, the way I'm going.

One of the main Keyglove lessons I learned at OHS is that the sensor wire connections still need work. They are easy to solder now that I have metal contacts, and electrically they are quite good. But mechanically, they are far too easy to break after normal usage by cold-working the solder joint. This means that I need some better strain relief. This could come in one or more forms: one guy recommended that I simply crimp the sensor wire in place between the two layers of the fabric snap, and avoid soldering altogether, since this is what made the stranded sensor wire so susceptible to cold-working. I really like this idea, but I need something that will also work for repairs, and there's no way to re-use a fabric snap to crimp a new wire end in. You'd have to replace the whole snap...which could work, but is quite difficult to do once the glove is already built.  

Another option is to use some kind of plastique glue, like a metalized epoxy or something with a silicone component. Depending on the conductivity of the glue itself, this could be used either instead of or in addition to an actual solder joint. One way or another, I have to improve the sensor connection technique, since at the moment it is the primary point of failure, and there's no way I would feel good about distributing something that is prone to break so relatively easily.  

I got an OHS album up on the Keyglove Facebook page if you would like to check it out.

Maker Faire NYC

This year, Maker Faire went fantastically better for us compared to last time. As I mentioned above, none of us got sick, I didn't lose my voice, and we got to stay and exhibit both Saturday and Sunday. I had a demo video looping on two iPads the entire weekend to help save repeated explanations, and that turned out very well. (That video is almost ready for publishing online, but needs a couple minor adjustments.)

We didn't run out of any materials, despite the fact that easily over a thousand people came by the booth over the course of the weekend. Giving away buttons for people who typed their names with the Keyglove was a fun addition this time around, and I heard from some people way over in the Maker Shed later that weekend that they saw a lot of people wearing them. Score!

Having multiple gloves was definitely helpful for accommodating those whose hands were not the same size as mine, and having multiple computers made it easy to run a personal demo from behind the booth at the same time as visitors got to try out the prototypes. At least three people said that it was the coolest thing they had seen at Maker Faire--which I know is very subjective and depends on what order they saw stuff, but it was still amazing to hear.

There were many people who asked for an explanation about what the Keyglove is really useful for, but unlike last time, I felt like nobody at all walked away from the booth unconvinced of the possible utility in at least one relevant area. Some liked it for the novelty, but pretty much everyone was excited about medical possibilities, or gaming possibilities, or 3D design input control applications. Somebody even mentioned that it could be useful for live, detailed feedback from a patient inside an MRI machine, since it could be far enough outside the machine and requires small enough movements not to disrupt the process. Who knew? This influx of new ideas is one of my favorite parts about exhibiting.

One of the other highlights of the weekend for me was getting to meet with Zack Freedman, who had a couple of weeks earlier finished a working prototype of what he calls a Pi-Borg, which is a combination of a Raspberry Pi and a modified MyVu Crystal EV head-mounted display built into a wearable computer. He stopped by the Keyglove booth, and we hooked up one of the Keyglove prototypes for what was the very first realization of my personal target use case for the project: a fully wearable computer. It was clearly a rough draft since there were some immediate calibration issues with mouse control, but as a successful proof-of-concept exercise, I got excited like you wouldn't believe. Well, actually, most of you probably would believe it.

On Sunday, John Baichtal of Make Magazine even gave us an Editor's Choice award for the exhibit! Thanks, John!

I got lot of good feedback over the weekend and met some great people, and I can hardly wait to get back to the project in earnest now that I am finished (for the moment) with all of this new job-related travel.

Check out the Keyglove Maker Faire photo album on Facebook if you are interested.

Seeed Studio

Speaking of getting back to the project, I have some good news about some components I have been able to get from the excellent people over at Seeed Studio and the suppliers they work with directly. I expect I'll be able to use their services even more as some of the last pieces fall into place for the kit version of the Keyglove, and then even more for sourcing, fabricating, and assembling the customized all-in-one controller boards. Despite being 18 months out from the end of the Kickstarter campaign, I still have a sizable chunk of the funds you all provided, and with an outfit like Seeed, it will actually go quite a long way. They are a great team to have available, especially for individual hobbyists like me.

Anyway, in the weeks prior to Maker Faire, I worked with Seeed to get some pre-fabricated rainbow header cables and molded (not cut) female headers to go with the Keyglove Kit PCB. Preparing the sensor cables was the most time-consuming step, after attaching the touch sensors to the glove itself (still working on that one).

As it turns out, getting those cables pre-made from Seeed not only saves a boatload of time, but the materials cost through them is actually far lower than what it costs me for the individual components! Amazing. The same thing goes for the female header pins, which are surprisingly expensive otherwise. In short, what had required about $10 and two hours (for each glove) now requires about $3 and no time at all. I will definitely keep employing their services as long as I have needs they can fulfill.

Next Steps

So, what's next, exactly? First, especially while everything is fresh in my mind, I'm going to go back and wrap up the wireless functionality with the WT12 Bluetooth module. This is a longstanding incomplete feature that will be good to have all finished. This mainly involves updates to the iWRAP code library I built and integrated into the Keyglove code, but it also involves a hardware modification of the Bluetooth module for the Keyglove Kit (which is a custom design). The Bluetooth module PCB is actually already sitting on my desk, but I need to get a new solder stencil so I can build the thing since there are quite a few surface-mount parts. I should be able to get the stencil within two weeks.

Second, I need to update a few things in my underlying code library for interfacing with motion sensors for improved speed and reliability. What I have now works most of the time, but it has no error recovery. When something doesn't communicate properly on the first try, everything locks up. This is obviously...well...bad.

Third, I need to work on that strain relief issue and experiment with a few different approaches. I'd like to get the hardware as done for the kits as soon as possible, since firmware updates are trivial for technically-inclined end users (e.g. many of you), and I'm sure those of you who pledged in return for kits would love to get your hands on them. This third step will also involve continuing to look for a company who can build the physical glove component with all of the sensors on it. I know there are people out there who can do this, but I just haven't connected with them yet.

That's enough for a short list of near-term to-do items. The new Bluegiga position is taking the majority of my time right now and for the next couple of weeks at least, but I'm determined not to relegate Keyglove to the bottom of the priority list. Keep your eyes open for more news, and thanks again four your support!