This is the first of a few could-have-been-backdated posts which chronicle the developments in the Keyglove project’s recent past, but which I didn’t write about at the time they occurred (oops). This miniseries of historical non-fiction covers the past 13 months or so, starting around the beginning of November 2014. “Over a year, again?!” I hear you cry. Indeed, and I apologize for another long period of silence—even though it fortunately wasn’t totally devoid of progress. For an extremely brief explanation, here’s a list of the “life stuff” that has happened during the same period of time:

• Bought a house
• Had a child (which is to say, my wife did)
• Moved into the aforementioned house
• Employer got bought out by Silicon Labs
• Unexpected family medical issues
• Took a new job opportunity at Cypress

I had no desire or intention of staying so silent, but…well, I’ll just say that it’s been quite a year.

Okay, back to the stuff you came here to read.

My adventure with this huge refactoring endeavor started with a bug that I couldn’t figure out. It made zero sense, and the behavior changed without any detectable reason based on seemingly unrelated code changes. My announcement to the world of this fact came in the form of this tweet:

Running into a strange bug that I think must be a memory leak. I found a workaround, but the behavior in both cases makes no sense. Argh…

— Keyglove (@keyglove) November 2, 2014

After continued troubleshooting yielded no progress, I eventually posted my predicament to the Arduino Forum.

I am running into a problem which seems to have to do with the code execution pointer, and the behavior makes zero sense at all. There is a conditional statement which doesn’t match, and since the code it controls is only one line, I omitted the surrounding { } braces for brevity. This is a pattern that I have reused many other times all throughout this fairly complex project without any observable bad consequences. However, when I let the code run this way, execution apparently stops at that line…

Three pages of sometimes maddening miscommunication or misinterpretation later, I got a startling revelation when the patient and wise Nick Gammon pointed me towards a pre-written resource he put together quite some time ago on Arduino project structuring.

This was a big surprise to me, because the last I’d heard, Arduino’s IDE imposed some pretty weird restrictions on code structure (one of its presumed weaknesses), including that you could only have typical .cpp/.h source/header file pairings in included libraries, from the official “Libraries” folder. This meant that the main project had to be one .ino file and a big collection of header files, each of which actually had a both declaration and implementation code inside (typically a bad idea). Nick’s guide proved that this was an incorrect assumption on my part.

I've just (!?) learned that Arduino sketches can be structured the same way most C++ projects are, with .cpp/.h pairs within the sketch.

— Keyglove (@keyglove) November 5, 2014

This makes me more giddy than it probably should, despite (or because of?) the massive code restructuring that is about to take place.

— Keyglove (@keyglove) November 5, 2014

After no small amount of work completely restructuring the whole Arduino project, I had all of the code back in line with conventional organization, and the inexplicable bug disappeared. Nick Gammon is my hero.

I pushed the massive commit to the Github repo as soon as I got it to compile and function as well as it had before the refactoring started—except for the fixed bug, of course. In addition to that fix, the new standardized code structure allows me to avoid some really strange “workaround gymnastics” that I had to include before. The order of #include lines in various places had been extremely delicate, with way too many compile-time dependencies built into the order of those lines. The new code is much safer, more obvious, and more forgiving. Three cheers for collaboration!

The post Another Giant Refactoring Milestone appeared first on Keyglove.

Help us fund the final production stages of The Power of Glove, a feature documentary profiling the enigmatic NES controller that helped define a generation of gamers.

The Power Glove was a 1989 Nintendo controller that promised to forever change the way humankind interacted with technology. Originally released by Mattel, the Power Glove was the first mass-marketed, gesture-based video game controller, and its hype was immense.

Immediately after its release, however, gamers were disappointed by the Power Glove, and critics panned it as a worthless gimmick. Yet unlike many gimmicks and critical failures of the past, the Power Glove has not been simply swept under the rug. Over two decades after its release, the Power Glove continues to resonate with video gaming and technology fans, becoming the focus of art pieces, songs, videos, hacking projects, and other forms of cultural repurposing.

The Power of Glove is the story behind the legend and legacy of the Power Glove.

I have no affiliation with these guys, but it looks like a fun project. $10 gets you the digital download. I’m looking forward to it.

The post The Power of Glove, a Power Glove Documentary appeared first on Keyglove.

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.

The post Functional Bluetooth and Rewritten iWRAP Library appeared first on Keyglove.

• 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.

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 any touch sensor changes state), and inside that event handler you use the “motion_set_mode” command to turn on and off 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:

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.

The API itself is fundamentally defined in its entirety in JSON format, which should make it as easy as possible to work with the protocol and integrate in any way you choose into custom host applications.

The post Keyglove API (KGAPI) Protocol Features appeared first on Keyglove.

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.

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.

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, and frankly, I’m proud of how far the firmware has come and how clean it is now. (And, of course, the fact that it works as intended.)

The post Shiny New Keyglove Firmware on Github appeared first on Keyglove.

1. Pull all touch points to logic high
2. Select possible combination [X, Y] from touch definition array
3. Set point [X] low
4. Measure the level of point [Y], and if it is low, then touch combination [X, Y] is active
5. 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 digitalWrite() and 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.

• There’s a lot more bit flipping than there needs to be. For example, the “Y” sensor gets pulsed low five times during the course of all combination tests, and it only really needs to be pulsed once if the subsequent corresponding pin reads are all done in the right order.
• The digitalWrite() and digitalRead() functions are ridiculously slow compared to direct port manipulation (~20 times slower).
• The specific polling speed is generating some capacitance or crosstalk or I don’t even know what, but the end result is that I’m getting phantom touch reports when nothing is actually touching. The problem is far, far less likely to occur when I set the CPU to 4MHz instead of 8MHz, which is what leads me to believe it has to do with the polling frequency and pattern.

My original I/O read loop looks like this:

// loop through every possible 1-to-1 sensor combination and record levels
for (i = 0; i < KG_BASE_COMBINATIONS; i++) {
    p1 = combinations[i][0];
    p2 = combinations[i][1];

    pinMode(p1, OUTPUT);    // change to OUTPUT mode
    digitalWrite(p1, LOW);  // bring LOW (default input level is HIGH)
    if (i < 32) {
        // write value to sensors1
        if (digitalRead(p2) == LOW) bitSet(detect1, i);
    } else {
        // write value to sensors2
        if (digitalRead(p2) == LOW) bitSet(detect2, i - 32);
    }
    pinMode(p1, INPUT);     // reset to INPUT mode
    digitalWrite(p1, HIGH); // enable pullup
}

It produces pulses that are about 11.4 microseconds wide, and the whole cycle through all tests takes about 2 milliseconds (or ~20% of the 10ms-wide interval allowed for the entire board to run at 100 Hz):

It’s really very clean and functional, and certainly a straightforward way to do it without a complete architecture shift and writing code that will only function with one specific Arduino or Teensy or Keyglove board design at a time. Well, honestly, 20% of a 10ms cycle is way too long for that functionality. Improving it is definitely worth writing some platform-specific code with a new architecture.

So I did.

The new code directly accesses the PIN and PORT registers that the AT90USB1286 provides (e.g. DDRB, PORTB, and PINB), and it will only work properly on that specific MCU. It also avoids any kind of abstracted pin definition array and runs through the entire complement of touch combinations manually in one long list. I’m not opposed to loops, of course, but it’s difficult to work efficiently with hardware registers at a bit level when using loops.

Here’s what one portion of the new code looks like, the part that checks all of the “Z” combinations:

// check on Z combinations (PB5)
SET(DDRB, 5);       // set to OUTPUT
CLR(PORTB, 5);      // set to LOW
delayMicroseconds(3); // give the poor receiving pins a chance to change state
_pina = PINA; _pinf = PINF;
CLR(DDRB, 5);       // set to INPUT
SET(PORTB, 5);      // pull HIGH
if (!(_pinf & (1 << 2))) touches[3] |= 0x02;    // M (PF2)
if (!(_pinf & (1 << 3))) touches[3] |= 0x04;    // N (PF3)
if (!(_pinf & (1 << 4))) touches[3] |= 0x08;    // O (PF4)
if (!(_pina & (1 << 2))) touches[3] |= 0x10;    // P (PA2)
if (!(_pina & (1 << 1))) touches[3] |= 0x20;    // Q (PA1)
if (!(_pina & (1 << 0))) touches[3] |= 0x40;    // R (PA0)

The approach here is streamlined in two different ways compared to the previous approach:

1. Direct register access is used instead of pinMode(), digitalRead(), and digitalWrite(). This is MUCH faster.
2. Combinations are set and read in batches instead of one at a time. So all combinations that use “Z” are done at once by setting “Z” low and then individually reading the pin register bits for all other potentially affected pins. This means that instead of doing 240 pin mode/level change operations for all 60 combinations, I only have to do 11 (and even this could be reduced further). Also, because of point #1 here, each of those 11 actions executes about 20 times faster than each of the 240 actions before.

The bottom line is that the new approach completes the entire test in about 50 microseconds instead of 2 milliseconds. That is a speed increase by a factor of 40. Amazing.

One interesting hiccup I had to work through was that although the code looked right and the majority of the touch combinations appeared to work, there were some that just would not register properly, even though they worked when I manually tied the failing pins to ground. The solution turned out to be that delayMicroseconds(3) call. The failing combinations involved, in every case, the input pins on the first port that I read after changing the logic level of the single output pin being tested. Since the very next call was to read the other port status, this executed so fast that the internal pin circuitry didn’t have enough time to detect the voltage change by the time I tried to read it. Go figure! Adding a tiny delay solved the problem instantly.

The above code (direct register polling) is what I have running now for development, but there is actually something more I need to do to improve it significantly: stop polling and use interrupts instead, at least while there are no active touches. This will allow the MCU to sleep for the vast majority of the time, greatly extending battery life. The downside to interrupts is that there is no easy way to detect exactly which two pins were connected together, unless you have a zillion different interrupts. I don’t, and I wouldn’t want to do that even if I could, because it’s too complicated given the other option. Instead, this will be the approach:

1. Enable “falling edge” interrupts for a subset of pins (e.g. palm and thumb sensors), and pull them all high.
2. Set the rest of the pins to output/low.
3. When any of the interrupts are triggered, enter the polling loop to determine exactly which touches are active.
4. As soon as no more touches are active, stop polling and go back to interrupt-only.

Even when actively in use, I expect that touches won’t be active for more than 20% of the time due to human dexterity and reaction time. Therefore, I expect this approach should let the MCU sleep for a lot of the time that the device is on.

The post Digital I/O Touch Detection Code Improvements appeared first on Keyglove.

First, I wanted to see what I could easily find out about the Glass Bluetooth subsystem. So, I plugged in my WT12 breakout and an FTDI board for simple control from a host PC and opened Realterm. The Bluegiga iWRAP firmware running on the WT12 has a couple of commands that are useful for discovery, namely INQUIRY (find other Bluetooth devices) and SDP (service discovery protocol for finding out what a given device can actually do via Bluetooth).

In order to get glass into “discoverable” mode, all you have to do is go to the normal Glass Home Settings card, and swipe to the Bluetooth card. Glass will then be discoverable for a short while (probably 60 or 120 seconds, but I didn’t measure it).

Once it is discoverable, we can run an inquiry and SDP discovery from iWRAP. Here’s the basic inquiry/name response, including the Class of Device reported by Glass (running XE7 firmware):

in 10 name
INQUIRY_PARTIAL f8:8f:ca:24:5b:84 200714
INQUIRY 1
INQUIRY f8:8f:ca:24:5b:84 200714
NAME f8:8f:ca:24:5b:84 "Jeff Rowberg's Glass"

Pretty basic stuff. The MAC is unique to each device, and the name reported is based (apparently) on the Google account it’s set up with. The Class of Device can be reverse-engineered with the CoD Generator. 0x200714 works out to the following:

• Major service class: Audio (0x200000)
• Major device class: Wearable (0x700)
• Minor device class: Helmet (0x10), Glasses (0x4)

This makes sense based on what Glass is, and what functionality it provides. It’s a wearable device, and it acts as a phone headset. That’s about it from a Bluetooth perspective, as far as I know.

Now we can try an SDP search for all reported services:

sdp f8:8f:ca:24:5b:84 1002 all
SDP f8:8f:ca:24:5b:84 < I 0 I 10000 > < I 1 < U 111e U 1203 > > < I PROTOCOLDESCRIPTORLIST < < U L2CAP > < U RFCOMM I 0d > > > < I 5 < U BROWSE > > < I 9 < < U 111e I 105 > > > < I SERVICENAME S "Handsfree" > < I 311 I 1d >
SDP f8:8f:ca:24:5b:84 < I 0 I 10001 > < I 1 < U f96647cf-7f25-4277-843d-f407b4192f8b > > < I PROTOCOLDESCRIPTORLIST < < U L2CAP > < U RFCOMM I 0e > > > < I 5 < U BROWSE > > < I SERVICENAME S "Glass Identity" >
SDP

This is a pretty sparse SDP list, but not too surprising based on the CoD above. They have the hands-free profile (HFP), a custom Glass Identity service (not sure how this works yet), and that’s it. Note that the SDP entries don’t specify everything the device supports, but only what it provides itself.

The next step is to pair with the device. However, this is where I ran into my first snag, and that is that Glass wouldn’t accept my pairing request when I tried from the iWRAP side:

pair f8:8f:ca:24:5b:84
SSP COMPLETE f8:8f:ca:24:5b:84 HCI_ERROR_AUTH_FAIL
PAIR f8:8f:ca:24:5b:84 FAIL

I thought maybe this was because it had an active link with my Nexus 4, but when I turned my phone’s Bluetooth system off to test this, the same thing happened. It might have worked if I completely unpaired my phone first, but I didn’t want to try that since it’s not a good solution anyway, and there are better alternatives with a bit of work. Apparently, the only thing you can easily do with it out of the box when it comes to Bluetooth is to pair it to a phone using the Hands-Free Profile and PAN profile (for Bluetooth tethering). Therefore, I had to follow the instructions in the Voiding Your Warranty: Hacking Glass session from Google I/O 2013. Fortunately, this only requires a couple of basic steps that did not in fact require voiding my warranty, or even rooting the device.

Here’s the process:

1. Install and set up the Android Developer Tools bundle (a good Glass-oriented guide is here)
2. Install the ADB drivers modified to work with Glass (a bit of a pain on Windows 8, since the modification makes them unsigned and a special restart is required)
3. Install settings.apk and launcher2.apk using ADB

For the purpose of documenting this process, I also installed the excellent and free Droid @ Screen to capture Glass screenshots over ADB, as shown here and above:

Once the ADT/ADB setup is done and the new .apk files are installed, swiping all the way left on the Glass timeline and tapping to access the Settings card results in a new prompt, asking whether you want to use Glass Home or Launcher to complete the action.

Using Glass Home will take you to the normal timeline-based settings area, but selecting Launcher takes you a generic normal-looking Android home screen, with no icons.

Swipe and tap on the app tray icon to bring up the list of apps, of which on my device there are now three:

Selecting the new “Settings” app gives us the classic Android Settings view. Many of these items will generate an “Unexpected error” message followed by dumping you back in the app tray. However, the all-important Bluetooth section works, and that’s good because that is where we need to go.

From here, we can see currently paired devices (e.g. my Nexus 4), and we can discover and pair with other devices, which is what we need to do now.

Select and activate the “Search for devices” option to discover any visible Bluetooth devices nearby. In order for this to work, the Keyglove’s WT12 module has to be in discoverable mode. In iWRAP terms, this means PAGEMODE 3, or else PAGEMODE 4 with no active connections. Fortunately for us, this is how I have it set up.

Since the Keyglove does show up as it should, all we have to do is select it and tap to pair. I have also configured it to use “just works” pairing mode, which doesn’t have man-in-the-middle protection enabled, but as a result means that neither side has to deal with any PIN codes.

Aaand, voila! We’re paired and connected with my combo HID descriptor and ready to have some fun.

At this point, now we issue a “SELECT 1” command to iWRAP running in the serial terminal to select the HID input link, then send raw reports or, for basic ASCII alphanumeric characters and space/backspace/enter, simply type them into the serial terminal (iWRAP translates these for you). The raw HID reports give you more control over exactly what is sent to the device, so I like to use those instead of the automatically “wrapped” ASCII characters.

While you can certainly send your everyday typed alphanumeric characters and symbols and things to Glass, the Glass Home interface makes it not all that useful at the moment. What I am mainly interested in is how to actually control Glass, to navigate through the timeline, select things, and trigger special actions like changing the volume, taking a picture, turning the projector on and off, etc. Through a lot of experimentation, I found that at least most of what I want to do is possible. I couldn’t find a HID report that would instantly snap a photo, but it is still quite possible that one exists—or that a specific combination would work. If anyone knows, I would love to hear from you.

The main reports that I wanted to test were non-alphanumeric keyboard codes and all of the Consumer Page reports I could try. I am sure that I didn’t manage to find all of the functionality possible, but I’ve got a good start. The keyboard reports are simple enough; each one is a single code, triggered by sending a report with that code in one of the six available key slots followed shortly (I used a 20ms delay) by a report with 0x00 in that same key slot. This effectively simulates a press and release. Remember from the last post that in iWRAP, the keyboard raw report format is this:

0x9F 0x0A 0xA1 0x01 [modifier] 0x00 [key1] [key2] [key3] [key4] [key5] [key6]

So, sending the “Enter” key (code = 0x28) looks like this:

0x9F 0x0A 0xA1 0x01 0x00 0x00 0x28 0x00 0x00 0x00 0x00 0x00

0x9F 0x0A 0xA1 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

Here are the relevant keyboard codes that I found to be useful in working with the timeline UI:

• 0x28 – Enter (select)
• 0x29 – Escape (cancel/back)
• 0x4f – D-pad Right
• 0x50 – D-pad Left
• 0x51 – D-pad Down
• 0x52 – D-pad Up
• 0x65 – Menu

There aren’t that many, but with these actions, you can replace the vast majority tapping or swiping the side of Glass. (The new double-tap/hold that you can do in the XE7 web browser is one that I haven’t figured out yet.) The Menu report gives you access to the app’s menu, assuming it has one. There’s no other way to do this with Glass as far as I am aware, so there’s an added bonus: new functionality! Here’s an example of using the Menu report to access the wallpaper setting on the Launcher app, followed by basic D-pad selection:

So what about other shortcuts? For that, we look to Consumer Page reports. These have a different structure, if you recall:

0x9F 0x05 0xA1 0x02 [field1] [field2] [field3]

It’s set up for a 3-byte-wide set of bitfields instead of distinct key slots. The same concept for press/release cycles applies here though. Here are the relevant consumer page reports that I found to be useful for Glass:

• 0x00 0x00 0x01 – Volume Up
• 0x00 0x00 0x02 – Volume Down
• 0x00 0x00 0x08 – Toggle projector on/off (no sounds generated)
• 0x00 0x08 0x00 – Home
• 0x00 0x16 0x00 – Projector off (w/sound, like escape/swipe down)

These actions combined with the D-pad navigation and selection above give you the power to do just about anything with Glass remotely. More detail on Android-specific HID input can be found here, though I haven’t fully grasped everything there myself yet. Here’s an example of volume control with the above reports:

But what about actual tapping, for controlling touch-based apps or accessing settings that you can’t get to with the D-pad? This is mainly useful for development/porting purposes, since an app designed with Glass in mind will by definition not rely much on touch in the way that apps designed for touchscreens are. Even so, having this ability would be handy.

This is where the 3rd report in our custom HID descriptor comes in: we can actually use the mouse in Android! Who knew? Yes, it might look a little odd, but it works just fine. You can send typical “click” actions (though I could not see any different behavior between different button values, e.g. left vs. right vs. middle), and you can send three axes of motion data for X/Y movement as well as scrolling. Here’s an example of accessing the detailed volume settings after clicking on the button on the right

There you have it, everyone. Complete control of Glass via Bluetooth HID is actually quite easy. Other than the initial pairing hurdle, it’s no more complicated than any other Bluetooth HID implementation. Now I just need to integrate the proof of concept code with the Keyglove firmware. This may be a bit of a challenge because there are a few different ways to do it—should I use pure touch controls (e.g. tap to “swipe” left or right), or touch + motion (e.g. tap to activate, move to navigate)? Or both? It’s a flexible platform, so it won’t be locked down in any case. I will try to configure it both ways and see what feels more natural.

The post Controlling Glass via Bluetooth with a Bluegiga WT12 appeared first on Keyglove.

The enabling factor here compared to the last time I tried this (quite some time ago) is the addition of custom descriptor support in iWRAP5. I don’t know of any other module which allows the degree of simple customizability in this area that the WT12 does. It was the best module I saw two years ago, and the new features are icing on the cake. (Yes, I have been working at Bluegiga since last October, but bear in mind I was singing this module’s praises long before that started.)

So how does this configuration actually work? There are three important pieces involved:

1. Building the HID descriptor
2. Configuring iWRAP
3. Sending HID report packets

Naturally, I will explain each in order.

Building the HID descriptor

To be honest, this is the part I am least confident about. I have learned a lot about HID descriptors, but only enough to be dangerous instead of simply clueless. In short, they are sent from a device to a host during the connection establishment phase so that the host will know what kind of data to expect from the device, how it will be formatted, and what it should do with it. A HID descriptor is built using a predefined binary “language” of sorts; data bytes either denote a field or setting, or else are the byte(s) contained within the previously denoted field or setting. There are many aspects to these definitions, and I don’t fully understand them all yet. It will be much better if I point you to the resources that were most helpful for me:

• Step 13 of Frank Zhao’s USB Wii Classic Controller Instructable
• Frank Zhao’s USnooBie HID Report tutorial (way to go, Frank!)
• The USB HID device class specification (PDF)
• The USB HID usage tables specification (PDF)
• The USB HID Descriptor Tool
• USBlyzer for complete descriptor analysis of an existing USB device
• The raw HID descriptor structs found in PJRC’s Teensyduino source

Actually, the first and last links ended up being the most practically useful to me. The others are good for cross-referencing things or getting into a detailed understanding. It’s a great list to get started with if you’re looking for HID development resources. Also, USBlyzer can be amazing if you are trying to mimic the behavior of an existing wired USB device, since it can show you both the descriptor structure as well as the actual HID report traffic.

But what’s all this about USB? Wasn’t the whole point of this to be all wireless and Bluetoothy and stuff? Well, it turns out that the important bits of device-specific USB HID descriptors pretty much apply directly to Bluetooth HID, because as best as I can tell, Bluetooth HID is basically USB HID wrapped in a wireless transport layer. It isn’t exactly the same, of course, but the most important pieces—namely, the HID descriptor and corresponding HID reports—match.

Now, what about Bluegiga’s HID documentation? There is a HID application note for iWRAP which is quite good if you are interested in single-function devices, or if you know what you are doing with descriptors. But if you’re only good at following directions and you want a combo device, it’s less obvious. (I will be fixing this shortly, because now I can!) There are example descriptors supplied for a standard keyboard, standard mouse (X/Y + 3 buttons), consumer page control (e.g. calculator and music controls), and a gamepad. But what if you want a keyboard/mouse/gamepad device all in one?

It turns out that this is really not difficult at all. There are two basic rules you have to follow:

1. Take each individual descriptor and mash them all together into one big long one.
2. Make sure each report structure definition includes a “Report ID” byte (0x85) and unique value (0x01 or higher).

The first one is easy. The second one is not so easy if you don’t know where the Report ID byte should go. Based on my tests, it needs to go after the innermost “Collection” start field (0xA1 0xnn) somewhere. I don’t know what the rule is exactly, but I put them (when they weren’t already there) immediately after this “Collection” start field. Each report needs its own unique ID so that the host device knows which kind of report you’re sending, whenever you send one. Pretty straightforward.

Here is the actual descriptor I put together for my successful test last night, in C struct form:

static const uint8_t hid_descriptor_combined[] = {

    // KEYBOARD

    /****/ 0x05, 0x01, /* USAGE_PAGE (Generic Desktop) */
    /****/ 0x09, 0x06, /* USAGE (Keyboard) */
    /****/ 0xa1, 0x01, /* COLLECTION (Application) */
    /******/ 0x05, 0x07, /* USAGE_PAGE (Keyboard) */
    /******/ 0x85, 0x01,   /* REPORT_ID (1) */
    /* 1 byte Modifier: Ctrl, Shift and other modifier keys, 8 in total */
    /******/ 0x19, 0xe0, /* USAGE_MINIMUM (kbd LeftControl) */
    /******/ 0x29, 0xe7, /* USAGE_MAXIMUM (kbd Right GUI) */
    /******/ 0x15, 0x00, /* LOGICAL_MINIMUM (0) */
    /******/ 0x25, 0x01, /* LOGICAL_MAXIMUM (1) */
    /******/ 0x75, 0x01, /* REPORT_SIZE (1) */
    /******/ 0x95, 0x08, /* REPORT_COUNT (8) */
    /******/ 0x81, 0x02, /* INPUT (Data,Var,Abs) */
    /* 1 Reserved byte */
    /******/ 0x95, 0x01,  /* REPORT_COUNT (1) */
    /******/ 0x75, 0x08, /* REPORT_SIZE (8) */
    /******/ 0x81, 0x01, /* INPUT (Cnst,Ary,Abs) */
    /* LEDs for num lock etc */
    /******/ 0x95, 0x05, /* REPORT_COUNT (5) */
    /******/ 0x75, 0x01, /* REPORT_SIZE (1) */
    /******/ 0x05, 0x08, /* USAGE_PAGE (LEDs) */
    /******/ 0x85, 0x01, /* REPORT_ID (1) */
    /******/ 0x19, 0x01, /* USAGE_MINIMUM (Num Lock) */
    /******/ 0x29, 0x05, /* USAGE_MAXIMUM (Kana) */
    /******/ 0x91, 0x02, /* OUTPUT (Data,Var,Abs) */
    /* Reserved 3 bits */
    /******/ 0x95, 0x01, /* REPORT_COUNT (1) */
    /******/ 0x75, 0x03, /* REPORT_SIZE (3) */
    /******/ 0x91, 0x03, /* OUTPUT (Cnst,Var,Abs) */
    /* Slots for 6 keys that can be pressed down at the same time */
    /******/ 0x95, 0x06, /* REPORT_COUNT (6) */
    /******/ 0x75, 0x08, /* REPORT_SIZE (8) */
    /******/ 0x15, 0x00, /* LOGICAL_MINIMUM (0) */
    /******/ 0x25, 0x65, /* LOGICAL_MAXIMUM (101) */
    /******/ 0x05, 0x07, /* USAGE_PAGE (Keyboard) */
    /******/ 0x19, 0x00, /* USAGE_MINIMUM (Reserved (no event indicated)) */
    /******/ 0x29, 0x65, /* USAGE_MAXIMUM (Keyboard Application) */
    /******/ 0x81, 0x00, /* INPUT (Data,Ary,Abs) */
    /****/ 0xc0, /* END_COLLECTION */

    // CONSUMER PAGE

    /****/ 0x05, 0x0c, /* USAGE_PAGE (Consumer) */
    /****/ 0x09, 0x01, /* USAGE (Consumer Control) */
    /****/ 0xa1, 0x01, /* COLLECTION (Application) */
    /******/ 0x85, 0x02, /* Report ID 2 */
    /******/ 0x05, 0x0c, /* USAGE_PAGE (Consumer) */
    /* 8 media player related keys */
    /******/ 0x15, 0x00, /* Logical Min 0 */
    /******/ 0x25, 0x01, /* Logical Max 1 */
    /******/ 0x09, 0xe9, /* Usage (8-bit), Volume Increment */
    /******/ 0x09, 0xea, /* Usage (8-bit), Volume Decrement */
    /******/ 0x09, 0xe2, /* Usage (8-bit), Mute */
    /******/ 0x09, 0xcd, /* Usage (8-bit), Play/Pause */
    /******/ 0x19, 0xb5, /* Usage Min (Scan Next Track, Scan Previous Track, Stop, Eject) */
    /******/ 0x29, 0xb8, /* Usage Max */
    /******/ 0x75, 0x01, /* Report Size */
    /******/ 0x95, 0x08, /* Report Count */
    /******/ 0x81, 0x02, /* Input type 2 */
    /* 8 application control keys */
    /******/ 0x0a, 0x8a, 0x01,/* Usage (16-bit), LSB first, e.g. this is 0x018a Email Reader */
    /******/ 0x0a, 0x21, 0x02,/* Usage (16-bit), Generic GUI Application Control Search */
    /******/ 0x0a, 0x2a, 0x02,/* Usage (16-bit), Application Control Bookmarks */
    /******/ 0x1a, 0x23, 0x02,/* Usage Min (16-bit), AC Home, Back, Forward, Stop, Refresh */
    /******/ 0x2a, 0x27, 0x02,/* Usage Max (16-bit) */
    /******/ 0x75, 0x01, /* Report Size */
    /******/ 0x95, 0x08, /* Report Count */
    /******/ 0x81, 0x02, /* Input type 2 */
    /* Application launch keys + record & rewind */
    /******/ 0x0a, 0x83, 0x01,/* Usage (16-bit), Application Launch Generic Consumer Control */
    /******/ 0x0a, 0x96, 0x01,/* Usage (16-bit), AL Internet Browser */
    /******/ 0x0a, 0x92, 0x01,/* Usage (16-bit), AL Calculator */
    /******/ 0x0a, 0x9e, 0x01,/* Usage (16-bit), AL Terminal Lock / Screensaver */
    /******/ 0x0a, 0x94, 0x01,/* Usage (16-bit), AL Local Machine Browser */
    /******/ 0x0a, 0x06, 0x02,/* Usage (16-bit), AC Minimize */
    /******/ 0x09, 0xb2, /* Usage (8-bit), Record */
    /******/ 0x09, 0xb4, /* Usage (8-bit), Rewind */
    /******/ 0x75, 0x01, /* Report Size */
    /******/ 0x95, 0x08, /* Report Count */
    /******/ 0x81, 0x02, /* Input type 2 */
    /******/ 0xc0,      /* End Collection */

    // MOUSE

    0x05, 0x01,       // USAGE_PAGE (Generic Desktop)
    0x09, 0x02,       // USAGE (Mouse)
    0xa1, 0x01,       // COLLECTION (Application)
    0x09, 0x01,       //   USAGE (Pointer)
    0xa1, 0x00,       //   COLLECTION (Physical)
    0x85, 0x03,       //     REPORT_ID (3)
    0x05, 0x09,       //     USAGE_PAGE (Button)
    0x19, 0x01,       //     USAGE_MINIMUM (Button 1)
    0x29, 0x03,       //     USAGE_MAXIMUM (Button 3)
    0x15, 0x00,       //     LOGICAL_MINIMUM (0)
    0x25, 0x01,       //     LOGICAL_MAXIMUM (1)
    0x95, 0x03,       //     REPORT_COUNT (3)
    0x75, 0x01,       //     REPORT_SIZE (1)
    0x81, 0x02,       //     INPUT (Data,Var,Abs)
    0x95, 0x01,       //     REPORT_COUNT (1)
    0x75, 0x05,       //     REPORT_SIZE (5)
    0x81, 0x03,       //     INPUT (Cnst,Var,Abs)
    0x05, 0x01,       //     USAGE_PAGE (Generic Desktop)
    0x09, 0x30,       //     USAGE (X)
    0x09, 0x31,       //     USAGE (Y)
    0x09, 0x38,       //     USAGE (Wheel)
    0x15, 0x81,       //     LOGICAL_MINIMUM (-127)
    0x25, 0x7f,       //     LOGICAL_MAXIMUM (127)
    0x75, 0x08,       //     REPORT_SIZE (8)
    0x95, 0x03,       //     REPORT_COUNT (3)
    0x81, 0x06,       //     INPUT (Data,Var,Rel)
    0x05, 0x0c,       //     USAGE_PAGE (Consumer Devices)
    0x0a, 0x38, 0x02, //     USAGE (Undefined)
    0x95, 0x01,       //     REPORT_COUNT (1)
    0x81, 0x06,       //     INPUT (Data,Var,Rel)
    0xc0,             //   END_COLLECTION
    0xc0,              // END_COLLECTION

    // RAW 16-BYTE I/O

    0x06, 0xAB, 0xFF,   // Usage Page (Vendor-Defined 172)
    0x0A, 0x00, 0x02,   // Usage (Vendor-Defined 512)
    0xA1, 0x01,         // Collection (Application)
    0x85, 0x04,         /* REPORT_ID (4) */
    0x75, 0x08,         // Report Size (8)
    0x15, 0x00,         // Logical Minimum (0)
    0x26, 0xFF, 0x00,   // Logical Maximum (255)
    0x95, 0x10,         // Report Count (16)
    0x09, 0x01,         // Usage (Vendor-Defined 1)
    0x81, 0x02,         // Input (Data,Var,Abs,NWrp,Lin,Pref,NNul,Bit)
    0x95, 0x10,         // Report Count (16)
    0x09, 0x02,         // Usage (Vendor-Defined 2)
    0x91, 0x02,         // Output (Data,Var,Abs,NWrp,Lin,Pref,NNul,NVol,Bit)
    0xc0,               // End Collection
};

Pardon the mix of comment formatting. I pulled these together from multiple sources and built one of them by hand. The structure of this descriptor is that the standard keyboard report has ID 1, consumer page report has ID 2, mouse report has ID 3, and raw generic 16-byte data packet has ID 4.

However, the above isn’t directly applicable to iWRAP configuration on the WT12 module, since iWRAP doesn’t use C structs as settings. This leads us to…

Configuring iWRAP

Luckily for all of us, the factory default iWRAP5 firmware—currently v5.0.1 build 620—supports all the HID customization we need. (It is also freely user-upgradable if you have or want a different build for whatever reason.) The default settings enable only the serial port profile (SPP), so we have to turn on the HID profile specifically, and write our descriptor. The maximum descriptor length is 255 bytes at the moment. For simplicity, here’s the full set of relevant initialization commands that I’m sending for the Keyglove’s Bluetooth module:

SET BT NAME Keyglove
SET BT CLASS 00540
SET BT IDENT USB:1d50 6025 1.0.0 Keyglove Input Device
SET BT SSP 3 0
SET CONTROL CD 80 2 20
SET CONTROL ESCAPE - 40 1
SET PROFILE HID d 40 100 0 en 0409 Keyglove Input Device
HID SET F2 05010906A1010507850119E029E715002501750195088102950175088101950575010508850119012905910295017503910395067508150025650507190029658100C0050C0901A1018502050C1500250109E909EA09E209CD19B529B87501950881020A8A010A21020A2A021A23022A27027501950881020A83010A96010A92010A9E010A94010A060209B209B4750195088102C005010902A1010901A10085030509190129031500250195037501810295017505810305010930093109381581257F750895038106050C0A380295018106C0C006ABFF0A0002A10185047508150026FF00951009018102951009029102C0

That ridiculously long “HID SET” line at the end is the descriptor itself. The lone preceding “F2” value is the length (in hex) of the whole thing, which is 242 bytes. I’m right at the edge of the size limit with this one.

Here’s a quick breakdown of these settings (see the iWRAP5 User Guide from Bluegiga for more detail):

• SET BT NAME Keyglove

  – Sets the Bluetooth device friendly name

• SET BT CLASS 00540

  – Sets the device class to “keyboard” (important for iOS compatibility)

• SET BT IDENT USB:1d50 6025 1.0.0 Keyglove Input Device

  – Sets the VID/PID, version, and self-identifying description

• SET BT SSP 3 0

  – Enables PIN-less “just works” secure simple pairing

• SET CONTROL CD 80 2 20

  – Enables GPIO output signals for active link and DATA mode status

• SET CONTROL ESCAPE - 40 1

  – Enable GPIO input control for exiting DATA mode

• SET PROFILE HID d 40 100 0 en 0409 Keyglove Input Device

  – Sets the HID options to be a keyboard class device, English layout, no localization, version 1.0.0

• HID SET F2 ...

  – Explained above. Sets the actual HID descriptor.

Not all of these are strictly necessary for the HID functionality I’m going for (e.g. the “SET CONTROL …” commands and BT NAME), but the rest are. Note also that all of these persist through power cycles, since all of them are stored in non-volatile memory. Once these settings are applied the first time, you must power-cycle the module or issue a “RESET” command to make them take effect—particularly the newly enabled HID profile and HID descriptor.

Now we’re ready to actually send some data.

Sending HID report packets

iWRAP uses a specific encapsulation format for sending raw HID packets. It will actually let you send basic ASCII keyboard characters as plain bytes over UART—so the byte ‘a’ (0x61) sends the keyboard HID reports for pressing and releasing the ‘a’ key—but only if you have the standard keyboard descriptor included at the beginning of your full HID descriptor. As it happens, we do. But full control only comes through the use of raw HID packets, so that’s what we’ll be using here. The raw HID format, as described in the iWRAP HID app note, is always of this form:

0x9F [length] [data ... ... ...]

Where 0x9F is the start-of-frame byte, [length] is how many data bytes follow, and [data …] is the actual data itself. So, for a 6-byte packet example, it might be formatted like this:

0x9F 0x06 0xAA 0xBB 0xCC 0xDD 0xEE 0xFF

The above packet is invalid given our descriptors, but it illustrates the point. Remember that we have four unique reports in our combo descriptor above, so there are four possible kinds of raw reports we might send:

1. Keyboard

   0x9F 0x0A 0xA1 0x01 [modifier] 0x00 [key1] [key2] [key3] [key4] [key5] [key6]

2. Consumer page

   0x9F 0x05 0xA1 0x02 [field1] [field2] [field3]

3. Mouse

   0x9F 0x07 0xA1 0x03 [buttons] [x-move] [y-move] [v-scroll] [h-scroll]

4. Raw

   0x9F 0x12 0xA1 0x04 [data1 ... data16]

Note the Report ID byte in red. For testing purposes, I like using Realterm because (1) it’s free and (2) it makes sending or displaying binary data in hex format easier than anything else I’ve seen. The UI is definitely engineer-ish, but it doesn’t take too much getting used to, and it has some features that are very hard to do without in cases like these. Realterm has a “Send” tab where you can paste bytes in hex notation (either 0xAA or $AA) and then send them as binary data, which is excellent here.

One important thing to point out here is that for many operations that we tend to think of as a single action, like a keypress or mouse click, there are actually two things going on. One is the press and the other is the release. It is critical that you keep this in mind when sending raw reports. Pressing the ‘a’ key is actually sending one report with the key down and another with no keys down. Here are some examples of each kind of descriptor:

Press and release the ‘a’ key

0x9F 0x0A 0xA1 0x01 0x00 0x00 0x04 0x00 0x00 0x00 0x00 0x00

0x9F 0x0A 0xA1 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

Press and release the calculator button

0x9F 0x05 0xA1 0x02 0x00 0x00 0x04

0x9F 0x05 0xA1 0x02 0x00 0x00 0x00

Press and release the left mouse button

0x9F 0x07 0xA1 0x03 0x01 0x00 0x00 0x00 0x00

0x9F 0x07 0xA1 0x03 0x00 0x00 0x00 0x00 0x00

Send 16 bytes of raw data

0x9F 0x12 0xA1 0x04 0x00 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88 0x99 0xAA 0xBB 0xCC 0xDD 0xEE 0xFF

(This is a single action and doesn’t require a “release” report)

This successful implementation of complex Bluetooth HID is an excellent next step in the Keyglove development. While the raw HID (as far as I know) is not accessible on iOS devices, this same combo descriptor and iWRAP configuration allows you to connect to a PC, Mac, Linux machine, iPhone, and Android phone—and, I assume and very much hope, Google Glass. We shall see in approximately 10 days.

Until then, have fun with your own Bluetooth HID projects, if you are so inclined!

The post Complex Bluetooth HID Input with iWRAP and the Bluegiga WT12 appeared first on Keyglove.

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 work 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!

The post Diving Back In, and Google Glass Plans appeared first on Keyglove.

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.

The sensor connections to the controller board have also been wired into per-finger female headers, which means it’s far easier to swap in a new controller board whenever I update the design. I don’t have to find each individual pin connection and put them in the right order; it’s all conveniently broken out on the PCB, and I can just plug in each header into the six main connectors (thumb, four fingers, and palm). Now I just need to get that new PCB version fabricated so I can mount the board on the glove more easily.

The post VIDEO: Prototype D Autodesk Inventor COM API Demo appeared first on Keyglove.