I came across this gem of a Kickstarter project today, and I had to back it out of solidarity, shared interest, and an appreciation for historical innovation.
The Bluetooth system has been one of those lingering features that I couldn’t quite manage to nail down for one reason or another. Well, no more! It’s working now. 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 some yak shaving, within the overall context of Keyglove development. Here’s a brilliant and hilarious explanation of yak-shaving in animating GIF format:
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).
With the right configuration, the Keyglove can now automatically reconnect to one or more previously paired devices, even going so far as supporting 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.
For those not already aware, I’ve been working on a straightforward protocol that you can use to control the Keyglove. This (or at least the initial version of it) is now complete. This Keyglove API, or “KGAPI”, 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 particularly special here.
Read more →
The development between now and my last post has been pretty significant. I published a new Kickstarter project update a few days ago, but I don’t want to fragment the news updates, so I’m (mostly) reproducing that content here.
The biggest 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.
Read more →
I have been working with the same basic approach to digital touch detection since the inception of the Keyglove. That process goes something like this:
- Pull all touch points to logic high
- Select possible combination [X, Y] from touch definition array
- Set point [X] low
- Measure the level of point [Y], and if it is low, then touch combination [X, Y] is active
- Increment test combination index and go back to step #2 until complete
At first, this method of scanning to detect connectivity between arbitrary I/O pins without mechanical switches seemed wonderfully functional and easily implemented. I used Arduino’s built-in
digitalRead() functions, which was the simple solution. It was also plenty fast enough at the time. However, it has a couple of now-obvious shortcomings, plus another not-so-obvious one which I am hoping that I diagnosed correctly.
Read more →
Here we are, one step closer to my ultimate goal of using the Keyglove as a wireless input device to control a wearable computer. For this installment of progress, the milestone is Bluetooth control of Glass, using a Bluegiga WT12 module and the custom HID descriptor that I wrote about earlier. I won’t go into detail about what that descriptor does, since it’s all documented in the other post, but the short version is that it provides a keyboard, consumer page control (e.g. media), mouse, and raw bidirectional 16-byte packet transference.
Thanks to Bluegiga’s workhorse of a class 2 Bluetooth module and the latest iWRAP5 firmware with custom HID descriptor support, I have now been able to achieve the wireless capabilities I always hoped the Keyglove would have. Keyboard, mouse with scrolling support, consumer page reports, and raw HID packets for arbitrary data transmission. It isn’t fully integrated into the Keyglove code yet, and I’ve only tested it with manual control so far, but the firmware setup is solid. It’s now just a matter of translating the manual control I’ve already done into my codebase.
Read more →
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.
Read more →
This video demonstrates Keyglove Prototype D and the Keyglove Kit v0.4 PCB (v0.5 still pending design completion) along with the alpha Keyglove Manager app integrated with Autodesk Inventor using the COM API for true 3D input. This is just a sample of the kind of thing that can be done with the Keyglove. And, honestly, this isn’t even a very good demo due to the early stage of development of the Manager app and the loose mounting of the older revision of the PCB on the glove.
Read more →
As I continue building the code to support all the necessary aspects of the configuration and control protocol for the Keyglove, I am also thinking about the various ways the protocol will be used, and how to keep everything as predictable and flexible as possible. There are both wired and wireless methods of interfacing with this device, but it turns out to be a little more complex than that.
Read more →