The development between now and my last post has been pretty significant. I published a new Kickstarter project update a few days ago, but I don’t want to fragment the news updates, so I’m (mostly) reproducing that content here.
The biggest news is the updated and largely rewritten Arduino firmware source code that powers the microcontroller at the core of the Keyglove design. Since this is an open-source project, it has always been my intention to publish the complete source so that anyone can understand or modify the functionality however they might wish to. However, I am a bit of a neat freak when it comes to code. Well, “a bit” may be an understatement. It’s hard for me to work with or around code that isn’t organized, and/or formatted, and/or documented well, and it’s even harder for me to publish it knowing that others may need or want to use it in their own designs. Before I feel good about handing something to the world, it must pass my own tests for organization, readability, and documentation.
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.)
Leave a Reply