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 →
Some time ago, I made the decision to move all of the feedback elements of the prototype Keyglove design to a separate I2C-controlled module, instead of using direct I/O pin connections. I did this because I also added three new touch sensors and better Bluetooth link and mode detection, and I simply didn’t have enough I/O pins to satisfy everything at the same time. The I2C bus was already being used by other modules anyway, so adding an additional slave device didn’t reduce the number of available pins anywhere else. At the same time, I freed up five whole pins for other functionality (Red, Green, Blue, Vibe, and Piezo). Not bad.
Read more →
So, after extolling all of the electronic virtues of the v0.3 Kit PCB only a few days ago, I’ve gone ahead and created a new revision of the board already. It turns out that it can indeed be smaller, without sacrificing any of the existing functionality. In fact, v0.4 is a full 25% smaller even than v0.3, giving us a PCB that is now a mere 46% of the original v0.1 board’s size.
Read more →
Good news on the kit PCB! I think I’ve got a winning combination of size, layout, and functionality. I just posted Keyglove Update #17 on the Kickstarter project page yesterday which discusses some of what I’m going to explain here, but I’ll summarize that bit again for those of you who don’t follow those updates, and include a bit more technical detail here and there.
Read more →
While working on the iWRAP code library for the Bluegiga WT12, one of the issues I’ve come across is trying to create a good way to detect and manage active Bluetooth links. The iWRAP firmware, controllable entirely over a simple UART connection, has three different possible modes. As I mentioned in my last post about the Keyglove Kit board, the most efficient solution is to avoid the high-demand MUX mode and instead rely on regular DATA/COMMAND mode switching and active link detection using two GPIO pins.
Read more →
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.
Read more →
Keyglove #09 – Wireless Mouse Movement Demo from Jeff Rowberg on Vimeo.
Finally! I have managed to incorporate the Bluegiga WT12 sufficiently into the current prototype hardware, along with the still-in-progress iWRAP code library to control it easily and transparently. This video demonstrates the first true combination of Bluetooth wireless functionality and the actual Keyglove code, rather than just a proof-of-concept Arduino sketch. This is a major milestone; wrapping up the remaining core Bluetooth functionality should be pretty straightforward now.
Read more →
Keyglove #08 – Orientation Demo from Jeff Rowberg on Vimeo.
NOTE: For the uber-eager, the actual rotation starts at the 1:00 mark. There’s some introductory explanation of what’s happening and the hardware in use that occurs on before that.
This video is a demo of the IMU algorithm results (a.k.a. sensor fusion) achieved with SparkFun’s 6DOF motion sensor board, which uses an ADXL345 digital 3-axis accelerometer and ITG-3200 digital 3-axis gyroscope. The readings from the board are raw from each device, and combined on the Teensy++’s MCU to create a quaternion representation of the orientation.
Read more →
One of my main goals for the Keyglove is to allow it to be used on as many devices and operating systems as possible with no complicated driver installation or configuration every time you set it up. Using a USB connection and Human Interface Device (HID) profiles, along with the Bluegiga WT12 Bluetooth module that also supports HID profiles, the Keyglove can appear to the host devices as a standard keyboard, mouse, or joystick, none of which require drivers. This allows for basic usage with almost no work.
But what about special types of usage? What about reconfiguring the Keyglove’s behavior, even if most of the time you do just want to use it as a keyboard and mouse? What about extending the capabilities beyond what I imagined, or implementing your own special driver for your particular hardware or software application? Obviously a HID-only approach is too limited. So, we turn to basic serial communication, which is one of the easiest methods to communicate with a hardware device in a way that pretty much anyone can work with, regardless of the platform. It works the same over Bluetooth as it does over a USB virtual serial port (which is built into the main Keyglove processor), and it’s also easy to adapt to a direct connection to another microcontroller, should anyone want to do that.
Read more →
The core of the Keyglove’s motion capture system is made up of a digital accelerometer and gyroscope. Both of these devices measure only one value—the accelerometer measures linear acceleration, while the gyroscope measures rotational velocity. This means that if the accelerometer is perfectly still and perfectly level, then it will experience only the force due to gravity (9.8 m/s2 downward), and if the gyroscope is held still in the same position, it will experience no measurable force at all. All of the math for dealing with velocity as it relates to position applies as well to gyroscopes and it does to accelerometers, but for the purpose of this post, I’ll focus only on the accelerometer.
Read more →