News

Interfacing with a BCM2042/BP20422 Bluetooth HID Module

Interfacing with a BCM2042/BP20422 Bluetooth HID Module
Update 4/6/2011: the design files for the breakout board shown below from Wayne and Layne has been made available here. Thanks, guys! (Remember this board is optimized for the BluePacket BP20422 module, and the pair button doesn’t work with other modules.)
Update 6/24/2011: one guy has been able to successfully integrate a BP20422 clone module into an existing full-size IBM Model M keyboard to convert it from wired to wireless. This included a lot of custom circuit design work and firmware replacement, which may be useful to you depending on your own interests. Check out his detailed documentation here.

The CE Compass WKB-1500 Bluetooth Keyboard I ordered arrived in the mail a while back, and I took to testing and dismantling it immediately.

Now, I decided to buy an actual device instead of just a Bluetooth module for two reasons: first, and most importantly, the only source I know of for the HID-profile module I was looking at has been out of stock for quite some time. There is currently no place I’ve been able to find, even internationally, where you can buy a single HID-enabled module. There are many places to buy SPP-enabled modules, and in many cases these can be adapted to providing keyboard and mouse support. All they require is a driver on the host device to translate the serial data into input control signals. However, my goal is to have the Keyglove be detected natively as an input device, so that no special driver is required. The HID Bluetooth profile specification is basically just a hardware Bluetooth wrapper around the standard HID profile used with USB keyboards and mice, as far as I know, which makes it perfect. The only problem is that nobody sells those modules by themselves, so I decided to try taking one out of another device.
Read more

Teensy++ Controller Board Adventures

Teensy++ Controller Board Adventures

I placed an order for a set of Teensy++ parts from PJRC quite some time ago with the understanding that it was out of stock and would likely take a least a couple of months to fill the order. That’s exactly what happened, and I ended up receiving the parts sometime in December. Because of other stuff I was working on both related and unrelated to the Keyglove, I wasn’t able to find time to really make use of the new parts until the middle of January.

Now that I’ve had a chance to, though, all I can say is: the Teensy++ is a really awesome device!
Read more

VIDEO: Typing With Prototype B

Well, this has certainly been a long time in coming. I’ve been really busy with all kinds of work, most of which has not been related to the Keyglove project, which is why it’s been almost three weeks since my last update. However, I’ve been able to make enough progress here and there to post this video for you today.

Keyglove #04 – Typing With Prototype B from Jeff Rowberg on Vimeo.

Basically, this shows another proof-of-concept typing demonstration using the new glove construction with a full sensor array. All 34 sensors are attached to the glove: five sewn on the fingertips, one sewn on the lower thumb segment, three sewn on the palm. All of the rest are remote control rubberized keypad contacts which I cut from a cheap broken universal remote I got off of eBay.
Read more

Prototype B is Imminent

Prototype B is Imminent

Ever since I was able to actually type some stuff in Microsoft Word using the Keyglove—albeit very slowly and methodically, and only through the use of a makeshift serial translator program in VB and the use of the SendKeys() function—I’ve been increasingly eager to finish this glove prototype as quickly as possible. Granted, “etaoinsrhdlucwvmgkfpxybqjz” is not very impressive, but it’s one of each letter of the alphabet, and it came right out of my fingers without a keyboard. Pretty awesome, really.

The first thing I’ve finished that will make Prototype B a reality is the quick connect breakout board. The Arduino Mega is a great board by itself, but when you’re working with multiple test gloves, each of which has up to 34 unique sensor connections on it, constantly cutting, soldering, and heat-shrinking new header pins on every wire for every set of sensor leads can get really tedious. This board uses a couple rows of spring terminals designed for high-gauge wire to eliminate the need for soldering (and managing) header pins for each new glove attempt. Additionally, I’ve labeled each terminal as shown in the photo so that it’s immediately obvious which hole is for which sensor. No more testing every connection with the serial debug output!

I built the board using a basic 2″x2″ ProtoBoard, some stackable headers, and spring terminals (all from SparkFun). I had to use a very sharp knife and a little ingenuity to connect the spring terminals together to make rows of 18 pins, since they came in blocks of six. They actually stack together horizontally very nicely, and it was fortunate for me that I needed 18 and they came in an even factor of that number. The only downside to the board construction is that it inevitably covers five of the existing header pins on the Mega board, most of which are important. One of them is the “B” sensor input, and two are the I2C DATA and CLOCK pins (used for the accelerometer). To solve this problem, I just stuck an 8-pin 90-degree header in so I can still get to everything I need.

The second thing I’ve managed is a successful experiment using the conductive rubber keypad contacts from a cheap TV remote. The remote uses a very small (1/8-inch diameter) contact to short each pad on the main remote circuit board, and the material on this contact has great conductivity. Using a small knife, I cut a couple of the pads off the main keypad and tested them for suitability, first touching the pad to a fabric sensor, and then touching two pads together. Both times, the sensitivity and conductivity were excellent.

Since the “target” sensors on the glove don’t need to be large (as discussed in the solution to Problem #3 listed in this post), these pads should work fine as sensors even though they are as small as they are. I’ve got some cheap for-parts remotes on order from eBay now for further testing, but for the moment I’m going ahead with these pads.

As you might be able to tell in the photo here, I’ve also switched to using enameled magnet wire for sensor leads. The stranded stuff had great flexibility, but the very nature of the many tiny stranded wires made it too difficult to work with for actual attachment to the sensors. So, to achieve a good compromise between size, flexibility, and stiffness, I’ve switched to 28 AWG magnet wire. It’s cheap, and it even looks cool. It’s thin enough not to be noticeably stiff, and it’s thick enough (and solid enough) to exhibit the right properties for sensor attachment—specifically, the ability to be poked through both the sensor fabric and the glove fabric. More importantly, as shown in the photo, I can poke the wire straight through these tiny conductive pads, bend it back, poke it through again, and pull it tight against the surface to create an instant and reliable electrical sensor attachment. With a bit of glue on the back, this is a remarkably durable way to do it. It sure is a lot easier than homemade conductive glue.

So, now I have a glove that is missing only the small sensors, but it has all the rest of them attached. I’ve decided to try using the conductive fabric for the large sensors (thumb, fingertips and palm), and also to quit taking shortcuts and just sew them on. Sewing them on undoubtedly takes time, but after all of my recent experiments with other materials and methods of attachment, nothing comes close to the result I am able to achieve using needle and thread. It looks good, feels good, and it holds nicely. There may be better ways to do it, but so far, I haven’t discovered them, and that’s certainly not for lack of trying. I was extra proud of myself for this one because this is the first prototype glove out of all my attempts that I actually got the palm sensors applied and/or attached with any kind of success. I’m really happy with how this has turned out so far.

Finally, I’ve got the sensor leads attached to all of the sewn sensors currently on the glove (four fingertips, two on the thumb, and three on the palm). The tail ends of these leads are pretty messy at the moment, but I’ve actually been able to keep the sensor ends organized well by weaving the wire itself directly into the glove fabric. I might need to add a few thread ties here and there, but I’ll wait to make that decision until I have the rest of the sensors attached. I hope to get that done by this weekend; if I can, I should be able to get a video up demonstrating all of the glove’s sensors and a little bit of real typing.

After that…who knows! Once I iron out the kinks in the mouse control and finish up the HID interface methods, maybe Keyglove kits will be coming soon!

Practicing with the Keyglove

Practicing with the Keyglove

This weekend, I finished most of the sensor mounting on my Prototype B glove. Actually, it should probably be called something more like “Prototype G” because of how many different things I’ve tried since Prototype A, but I’m going to stick with “B” since this is still only the second glove I’ve got quite this far on. All of the sensors are mounted and wired except for the three large ones on the palm. It’s the first time since my original attempt that I’ve been able to connect and test a nearly complete array of sensors, and I must say that it does work better than my first one.

However, I must also say that it still needs some work, specifically in the following areas:

  • The sensor size and placement is significantly better, but a few of them still need to be moved a bit due to the structure of the hand and the way the thumb reaches each other sensor.
  • The tiny stranded wire is more flexible than the larger solid wire I had before, but it is actually quite fragile (as far as wire goes, anyway). I’m going to try some enameled magnet wire instead.
  • This glove is nylon, not cotton. I’ve decided that I like the cotton one better, so I’m going to switch back to that for more testing.
  • I really need a faster way to connect and disconnect the sensor pins from the Arduino board. I think I may get some screw terminal sets and build a header breakout board or something.

Overall though, it’s a good step forward. With some more software modifications and a hacked-together serial interface program, I was even able to do some real typing in regular programs with the glove. Mouse movement should come soon as well. Now, I do want to reiterate here that using a serial driver (or foreground program, as I’m doing here) to type characters and move the mouse is not a permanent solution. I fully intend to make this into a complete OS-independent device that communicates with standard input device protocols—PS/2, USB, and Bluetooth. I’m only using a serial interface right now because it was easy and it works.

One thing I discovered in my five elated minutes of typing is that I have no idea how to type efficiently with the Keyglove. I expected this, of course, since I’ve never used it in a real typing environment before. I do have the beginnings of a letter-frequency-based touchset created, but I haven’t been able to practice with it at all since I didn’t have a fully working glove. This revelation of my sad inability prompted me to begin building a practice tool.

So, last night, I took a picture of each base touch combination as represented by my hand (60 in all), and then this afternoon I modified them to be more visually informative. Then, I created unique versions of the main sensor diagram to go along with each photo in order to eliminate any possible confusion as to what the photo is trying to show.

This evening, I put all of these images together into a very basic Training page. It’s currently only a full list of all 60 base touch combinations, but it will eventually grow into an interactive training app online. I may also make an standalone application for this, but I believe I can accomplish at least all of the training aspects with a web app. Customizing touchsets is another matter, but I’ll take care of that once I get a little farther along.

Take a look at the table on the Training page and see if there are any combinations that are very difficult for you to do. If there are, let me know. I’d love to get some feedback on the feasibility of what I have in mind. Although I’ve tried to stick with combinations that seem pretty easy, I am double-jointed (some say disturbingly so) and I might just be oblivious to the fact that some of them are impossible for normal people to make.

Once I make a few more changes to the Training page to add at least a minimal amount of interactivity, I’ll post the results of my first few practice sessions. My next immediate goal here is to create another proof-of-concept video that shows real typing, not just sensor touch recognition in a debug window.

Automatic Sensor Source Code Generation

Automatic Sensor Source Code Generation

At the same time as I’ve been trying all kinds of different approaches to sensor material and attachment (including paint, glue, wire, thread, tape, and fabric), I’ve been working on customization and efficient touch sensor test code as well. In a post quite a while ago, I mentioned that after spending some time figuring out all of the ergonomically possible combinations of touches, I actually came up with many hundreds of unique possibilities—a lot more than I’d anticipated.

As you might guess, it’s not very easy to work efficiently with hundreds of unique tests in the source code, especially after I came across a couple of base 1-to-1 combinations that I’d missed before. Making one slight change to the foundation of the system results in a tremendously complicate series of changes all through the code. I have to keep track of which pins correlate to which sensors, which base combinations exist, which complex combinations exist, and which order to check each of them in.

This last consideration has been the most difficult. I spent a few hours this past Wednesday working on the touch priority, and while it wasn’t difficult to do for the base combinations, to became extremely complicated as soon as I started to get into the complex ones.

So, I created a PHP script to automate the entire sensor code generation process. I realize that a PHP script may not be a good final solution, but I chose that approach because I use the language every day and it’s very easily accessible to me. I don’t know if web-based Keyglove configuration will be possible in the future, but if not, I can at least port it to other languages.

Anyway, the basic idea of the script is to use the sensor array, the base combinations, and a fun set of “impossible combination” arrays to build everything automatically. This takes care of literally all of the code necessary to paste into the Arduino IDE. On top of that, the PHP script also builds only the combinations needed for whatever touchset you want to define. That means smaller, simpler, more efficient code.

One of the problems I’ve had is in figuring out how to have the minimum possible code while still allowing touchset customization. It is possible to have a very flexible array list or hash table using pure Arduino code, but for a limited hardware scenario like the Arduino, it’s a bad idea to use dynamic memory allocation and complex data types all over the place. It can seriously slow down the process. So, for the moment, I’m relying on hard-coded sensor control. Actually, except for the touchset portion, the hard code this script generates is perfectly acceptable in any situation. I’d like to make the touchset code more dynamic, but that can wait for now.

The most complicated part of the script of the set of of “impossible combination” arrays. It is an associative array with one keyed element for each base touch combination, and each of those elements contains a list of other base touch combinations that are impossible while the element’s key touch combination is active. For example, the “AY” combination (index tip to thumb tip) would include “Y1” as an impossible combination (thumb tip to top of palm). Obviously, you cannot touch your index fingertip and your palm both at the same time with your thumb tip—unless you are freakishly double-jointed, anyway, and even then not in a very controlled and repeatable fashion.

The rest of the script uses a recursive build function and a few convenient features of PHP to directly create all of the code, complete with the correct touch test order. It’s beautiful. And, more importantly, it will save me hours and hours of time and lots of frustration trying to figure out everything manually.

I hope to have a good test video up within a week showing some real typing with the glove. That, of course, is contingent on finishing a good Prototype B. I’ve been trying so many different things lately that I think maybe I ought to take a few hours and simply build something that fundamentally works even if I’m only 80% satisfied with it. The last 20% will come later.

Conductive Glue Tests

Conductive Glue Tests

If you want the short version, here it is: unfortunately, I haven’t found a good way to use conductive glue yet, either for sensors or for sensor wire attachment. For more info, read on.

I’ve been occupied with all kinds of stuff for the last couple of weeks, which has made it difficult to keep up with posting new blog posts here. However, the project hasn’t been entirely dormant; as promised, I finally got the last of the conductive glue ingredients (carbon graphite powder), and I’ve tried a few different mixes to see what would happen. For reference, I started using the instructions and recipe here.

The first thing I noticed when trying to prepare the glue is that the graphite powder is extremely messy if you are not extraordinarily careful with it. It’s about as bad as laser toner, if you’ve ever messed with that. The powder is extremely fine and tends to “spray” all over the place, almost as if a pile of the stuff has some elastic properties. This was most noticeable when I dipped the measuring spoon into the container and tried to scrape off the excess. It ended up creating a nice scattered blanket of black powder all over the paper towel I used as a workspace cover.

I tried to measure the correct amounts of graphite and Liquid Tape, and immediately after I started stirring them together, I had doubts about whether I added enough Liquid Tape. It just seemed too dry. However, I have the same doubts every time I add a tiny amount of milk to a rice seasoning mix when I’m cooking (which is not often), so I guess I should just learn to trust the recipe. After I mixed it around for about 15 seconds, it really started to become a homogeneous paste, almost the consistency of cake frosting but nowhere near as tasty. (No, I didn’t try eating it.)

As you can tell from the photos, I used a ceramic evaporation dish and a small glass stirring rod to mix everything up. These materials were easy to get from Amazon and eBay, and I knew they would work even with harsh chemicals. Applying the newly mixed glue paste with the glass rod was a little bit of a challenge though. It’s kind of like buttering a piece of bread with a fork instead of a knife—you just get the feeling there has to be a better tool. Even so, it did get the job done, though the glue paste was very sticky. I tried a few different tests for comparison: (1) an entire sensor made from the glue mix, (2) attaching a sensor wire to conductive fabric using the glue mix, and (3) attaching a sensor wire to conductive fabric using pure Liquid Tape. Then I set the glove down to dry and then spent the evening doing something else for a couple of hours.

A note about cleaning: the carbon graphite powder is incredibly fine (it’s actually used for lubrication in some applications). Just try not to get it on anything you don’t want it on or you can’t throw away. It’s virtually impossible to remove it completely. The Liquid Tape is a nasty black goo, but it cleans up well enough with different solvents. You can use paint thinner if you want, but I used regular rubbing alcohol and a lot of pressure. It eventually came entirely off of the ceramic dish, glass rod, and my fingers.

After the glove had a chance to dry, I tried testing the conductivity of each of the three test scenarios. The conductive glue mix was electrically suitable both for attaching wires to other material and for touching two pieces of glue together (i.e. as sensor material, not just wire attachment material). However, it is physically unsuitable for two reasons: it becomes hard and crusty when it dries, and it doesn’t hold wires inside very well. In order to be really useful and well-suited to the task, it needs to be smooth and flexible after drying, and it needs to hold wires reasonably well. If a wire can become detached without a tremendous amount of force, then it’s a serious point of failure, especially when there is no good way to re-attach a sensor wire. Another significant problem is that the conductive glue in hardened form does not work well when used on a capacitive touch screen. This is a key benefit of using conductive fabric, since it is likely that a glove like this will be used in the context of a mobile device more often than not.

The pure Liquid Tape sensor wire attachment looked and felt nice enough (smooth and flexible), but was unfortunately not conductive. I didn’t really expect that it would be, since Liquid Tape is sold as an insulator, but I figured I would give it a try anyway. No luck there. Additionally, it’s not designed to hold things tightly, so it wasn’t that difficult to simply pull the wire out.

I tried again later with a different mix, that time using less graphite than Liquid Tape (probably 0.75:1 ratio). For logic signal detection, it’s okay if I have a few hundred ohms of resistance, since the connection can still be detected. I also mixed a much smaller quantity, since during the first test I ended up with at least five times as much as I needed. I tried the same tests, and found something that essentially performed the same as before electrically, but was only slightly better physically. The glue dried a little less hard and crusty, but nothing at all like the conductive fabric. It wasn’t really flexible, and still didn’t work at all with capacitive touch screens.

A couple of days later, after a stop by the hardware store, I tried another mix (Mix #4 from this page, a follow-up Instructable from the author of the first one linked above). This one used DAP contact cement instead of Liquid Tape. In short, this ended up being yet more flexible after drying, but was not notably better than the first two experiments above. In addition, DAP contact cement smells awful and retains some bad odor even after drying. This mix still didn’t come anywhere near the look, feel, or effectiveness of the conductive fabric. Interestingly though, it did perform a little better than the two previous experiments when testing with a capacitive touch screen. Still nothing like the fabric, but better.

So, I’m still looking for different alternatives. In the mean time, I think I am going to keep the conductive fabric approach for testing and work on the controller software for a little while. If I have any new hardware approach ideas, I’ll be sure to give them a shot though.

VIDEO: Data Visualization

Yet another new video demonstrating more refined accelerometer cursor control:

Keyglove #03 – Data Visualization from Jeff Rowberg on Vimeo.

This video demonstrates the massively updated Processing sketch that I am now using to test the glove’s sensors. It relies on serial data flow for everything and connects directly to the Arduino’s virtual COM port, making it unsuitable for a finished product (you’d want a true HID-compatible connection). However, with this tool, you can very easily see everything about the glove’s current condition to test things like touch sensitivity and mouse control.

I have temporarily postponed the PS/2 interface tests while I work on the core of the glove functionality. Now that I have a reliable test tool, the PC interface is not necessary for continued development and testing. Obviously, it will be eventually, but I’m not going to focus on that right now. The Processing sketch will do nicely until everything else is working well.

For anyone interested, that visualization program is available from the repository, and of course the Processing IDE is open-source and available here.

VIDEO: Accelerometer Tests

New video demonstrating accelerometer cursor control, complete with jitter reduction:

Keyglove #02 – Accelerometer Tests from Jeff Rowberg on Vimeo.

Although the real mouse interface isn’t working, I’ve rigged up a Processing sketch to graphically represent the same movement that will be affecting the mouse cursor once I get that part working. This means I can at least test the accelerometer code I have.

This test shows raw input control from the accelerometer, followed by 5-point averaging, then 20-point averaging, then graduated averaging depending on speed. The idea is to make the movement very responsive if you’re moving it quickly, but much less jittery if you’re trying to hold it in one place. Therefore, it averages only 5 points (fast) during quick movements, but averages 20 points (precise and still) during very slow movement.

This video demonstrates the “tilt translated to position” approach described in the previous blog post.

I’ll be making that Processing sketch available in the Google Code repository after I make a couple more tweaks to it. That should be extremely useful for testing the whole glove without any specific hardware interfaces in place. I want to add a raw accelerometer reading graph, 3D tilt display, and of course regular touch displays as well. Processing is pretty awesome, really.

Incorporating an Accelerometer

The accelerometers that I ordered from SparkFun arrived late last week. I got two of them: one analog (ADXL335) and one digital (ADXL345). The analog one is supposed to be much simpler to use, and it’s a little bit ($3) cheaper, but the digital one requires less power, is less prone to errors, and has more features (including a 0g detection interrupt). I ordered the analog one, then decided to give the digital one a shot even though they said it’s more complicated. I considered cancelling the order for the analog one, but I realized that I’d really like both so I can see the differences in capability first-hand.

So, all that being said, I tried to make the digital one work first, because I know I’ll be able to make the other one work. I do love a challenge.

It turned out to be much easier than I was afraid it would be, thanks to detailed information from Euristic at Live Fast, Code Young. With his code and instructions (with slight modifications for the Mega board pin differences), I had a test program reading data from the accelerometer in 10 minutes of effort. Amazing.

The ADXL345 has a total of 8 pins on the breakout board, which are labeled GND, VCC, CS, INT1, INT2, SDO, SDA, and SCL. For my purposes (and the test program), it is safe to completely ignore INT1 and INT2. Connect GND to the Arduino board ground (obviously), and VCC to the 3.3v pin (not 5V, this can damage the accelerometer). Short CS to VCC right on the breakout board, and solder a small jumper wire between GND and SDO. Finally, plug SDA and SCL into pins 20 and 21 respectively of the board. Note these pins are specific to the Mega; on other Arduino boards, SDA and SCL are analog pins 4 and 5 respectively. With this arrangement and the source code on the above linked blog, I had a steady stream of data flowing in.

Euristic’s schematic has two 10k resistors acting, I believe, as pull-ups from VCC to SDA and SCL. I am honestly not sure what their purpose is, since the behavior seems to be the same whether they are there or not. I left them in though.

After getting the device to work using Euristic’s code, I switched over to the slightly cleaner and more complete ADXL345 library from user kstevenard on Google Code. It works the same and has methods to make use of all the settings available on the accelerometer.

Next, I wrote some code that converts the measurements into angles for each axis. It isn’t perfect, but it’s certainly pretty close. I think a sharp movement would generate unusable data, but we’ll see. I’m still trying to get the PS/2 mouse code to actually move the mouse on my computer; it’s giving me a lot more trouble than the keyboard code did. I figured it would just work since I have the active PS/2 adapter and everything.

Types of motion detection

However, there’s another conceptual problem to solve here: how exactly should your physical motion be translated into mouse movement? There are three main approaches here, and I’ll try to explain each. Two are tilt-based, and one is movement-based.

First, tilt translated to velocity is where the speed of cursor movement matches the steepness of tilt. This is kind of like the way the Trackpoint mouse on ThinkPads work, and it’s also kind of like how a game console controller works (imagine moving a small hand or crosshairs around using the D-pad). Interestingly, I love the Trackpoint, and I can’t stand D-pad cursor movement. I think the Trackpoint must be implemented extremely well, but I know it’s still something people have to get used to.

Using this method is simple to understand but difficult to master with precision. You have to speed up and slow down the cursor at just the right moment in order to “land” on the desired target. It’s very easy to overshoot (or undershoot). It would feel something like the cursor is a marble on a table, and you have to tilt and then re-balance the table at just the right moment. Personally, this sounds terrible to me for normal cursor movement. On the other hand, if you wanted to use the tilt of your hand to control lateral movement in a 3D game, you might prefer this method.

Second, tilt translated to position is where the cursor position changes directly based on the orientation of your hand. If you turn your hand to the right and leave it there, the cursor will move to the right and stay there. In contrast to the previous method, it won’t keep moving until you make your hand level again. This movement can be tracked on any axis. This seems much more intuitive to me than the previous option for normal cursor movement.

The downside of this approach is that you can only rotate your hand about 180 degrees left/right and more like 90 degrees up/down. This means one of two things: either the range of motion would have to be calibrated so you could reach all edges of the screen through one full sweep of each axis, or else you would need a way to temporarily disable motion while you reoriented your hand.

This second “fix” is much the same as when you’re using a desktop mouse and you run out of space while moving across the desk, you simply pick up the mouse (to prevent backwards movement) and put it back down on the desk so that you have more room to move. Most of us do this without thinking about it. For this reason, I believe a similar solution could be used in the Keyglove, perhaps by having a simple “hold” touch combination that would leave you in “mouse” mode but prevent any motion. Then, when you release the “hold” touch, you would be free to continue moving.

Third, movement translated to position is where the speed of the cursor movement matches the speed of your hand movement. This is the easiest to implement in the code, but requires a lot more effort and available space. It does feel very Minority-Report-esque though. Essentially, if you move your hand up and down, the cursor moves up and down with it. Left and right movement function the same way. The downside of this approach is that you need more room to move around, it’s far more visually distracting, and it is also far more physically demanding than the alternatives. It might be nice for a vigorous presentation though. I would think that if you can master the first or second approaches using tilt (which are much more subtle by definition), there’s no reason you’d ever want to use this approach—at least not for mouse cursor movement. Obviously, movement-based gestures could still be very valuable.

So what’s the plan?

I want to build support for all three of these methods into the glove code. Maybe there can be three different “mouse-on” toggle combinations, one for each method, so you can switch between them as you wish. All three methods should have a temporary “hold” combination (like picking up the desktop mouse off the desk).

Now If I can just get this PS/2 mouse emulation code working, I’ll be able to really test it out.

Page 4 of 6« First...23456