Jump to content
Keyglove Forums

jrowberg

Administrators
  • Content count

    22
  • Joined

  • Last visited

  • Days Won

    2

jrowberg last won the day on March 31 2015

jrowberg had the most liked content!

About jrowberg

  • Rank
    Administrator
  1. Trying to build one: questions

    Hello, Welcome to the field! Mixing code and hardware is tons of fun. (Also, sometimes complicated and difficult.) The "no activity" problem you're running into may be a blocking I2C call. Do you actually have an MPU-6050 connected, or are you running with just the Teensy right now? The code tries to do some initialization steps during the boot process, and the Arduino "Wire" library used for I2C communication has some blocking function calls in it such that it can totally freeze if the expected signals aren't seen on the wire. There is no timeout. If you don't have a motion sensor, make sure you go into the "config.h" source file and change the motion configuration so that it doesn't try to use it. You'll know that the boot process succeeded if you see the Teensy's orange LED flash briefly every couple of seconds. If there's no blinking LED, then it didn't finish the boot process. As for debugging, if you have KB+Mouse+Joystick USB selected, then Serial.print() calls won't go anywhere. You need a USB configuration with Serial in it in order for that to work. Serial is also used for the KGAPI host communication protocol, so if you have serial enabled, you should see data come from that port from time to time, e.g. touch events. It's binary data, not human-readable ASCII, to use a terminal application that can display hex (like Realterm). Or, you can use the Python stub console script. That's primarily what I use for rapid testing, since it speaks KGAPI easily without manually assembling or parsing binary packets. For 3.3V vs. 5V, I did that because all of the sensors and the Bluetooth module that I chose use 3.3V natively, so that avoids the need for additional regulators. It also makes it easier to reliably power the device with a standard single-cell LiPo battery. Concerning Teensy configuration, there is a comment block in the "support_board_teensypp2_t19.cpp" file that shows the function of all pins. The sensors are all inputs most of the time; touches are detected by very briefly setting one pin to output mode and then reading the input logic state of all other pins to which it might be connected. This is typical of a scanning keyboard matrix, though the implementation is a little more straightforward and relies less on reusing multiple pins for more than one key. See this Keyglove blog post for some further discussion.
  2. VR getting really popular

    Adding flex sensors is one way to quickly increase the amount of usable data that the glove can process and respond to. I have a set of 5x flex sensors for prototyping in the future, and it's been on the Keyglove roadmap for quite some time as well--I just haven't gotten to a point where I can add them in. Part of the problem with the flex sensors in particular is that they require either an extra external SPI/I2C ADC device, or else five extra ADC connections directly into the MCU. Once I switch to the ATSAM3X8E, this won't be an issue, but it's still a bit of a challenge with the Teensy++, where I'm pretty strapped for pins. I'll also need to add API methods for working with the flex data, but that is relatively simple now that the codebase is so completely rewritten to support that kind of feature addition. Currently, there is no specific way to speed up Keyglove development which comes to mind, unless you happen to know someone who can tackle the physical glove construction challenges inherent with e-textiles. I've got the next batch of prototyping hardware pending delivery from OSH Park, and once it shows up, I'll be able to build the latest Keyglove kit prototype design and test to see how it works. If it's solid, it will be the foundation of the kit design and the starting point for the all-in-one custom controller board based on the AT90 MCU. The DIY flex sensor glove video is quite good; it looks like he did a great job. The Keyglove source is fully open, so you are more than welcome to use it as the foundation for something built with flex sensors if you like.
  3. Bluetooth module for HID usage

    Hello Nico, As noted in some of the other posts, I am unfortunately not familiar with the HC-05's capabilities other than that it does not appear to support anything other than basic SPP (serial port) connections. I might be wrong about this, but everything I have seen so far about the module indicates this. As for the WT12, although it is a very powerful Bluetooth module because of the iWRAP firmware that runs on it, iWRAP only implements the HID device side of the profile, and not the HID host side. You would not easily be able to connect a HID device (like a Wii remote) to a WT12, since iWRAP is only built to work in the other direction.
  4. wireless communication

    Hello Abrez, The Arduino forums would probably be a better place for this question rather than the Keyglove forums; I cannot help much specifically with those kinds of questions due mainly to a lack of time. Based on the value you are seeing though, I would guess that you have mixed up the byte ordering (MSB / LSB of a 16-bit value are backwards) or else that you have not properly shifted the values into the correct bit position. But again, I recommend the Arduino forums.
  5. Similar Build

    Hi George, This is essentially the primary goal of the Keyglove project; all of the progress I've made towards this effort has been posted online either on the project website here, or Facebook, or Twitter; everything you see online now is basically everything that I can offer in terms of information at this time.
  6. Component Requirments

    I haven't yet, no. I've been focused primarily on the core firmware functionality, using whatever hardware I can make work in the prototyping environment in the meantime. I plan to move on to fine-tuning the hardware once the software does what I need.
  7. Interfacing bluetooth with teensy as HID

    Hello Niranjan, I am not really familiar with the HC-05 module, as I have never used it before. I am only currently planning to write support for the Bluegiga WT12 module running their proprietary iWRAP firmware, so anything else would (for now anyway) need to be implemented yourself. I understand the HC-05 module is primarily used for a Bluetooth SPP connection, so it should be possible to get at least some data transferred between the Teensy and a PC with a properly configured Bluetooth dongle. However, I am not sure how precisely to do this. You would need to implement connection establishment and management into the Keyglove code according to whatever communication and setup protocol is used by the HC-05. It also does not appear at first glance that the HC-05 supports Bluetooth HID, but only has SPP. (This is one major reason that I really like the WT12 module with iWRAP firmware--it does everything.) I would recommend the following resources, found through a basic Google search: http://www.instructables.com/id/Cheap-2-Way-Bluetooth-Connection-Between-Arduino-a/http://www.instructables.com/id/Arduino-AND-Bluetooth-HC-05-Connecting-easily/http://www.instructables.com/id/Modify-The-HC-05-Bluetooth-Module-Defaults-Using-A/http://forum.arduino.cc/index.php?topic=154649.0Good luck!
  8. Component Requirments

    Hi Matt, I'm not sure about integrating a trackball, but the other components are fundamentally the same: Teensy++ for the main MCU, and a Bluegiga WT12-A for Bluetooth if you want wireless support. I'm still working on re-integrating Bluetooth support into the rewritten code base from a couple of months ago, and without that, the only viable interface is USB HID or CDC (both of which work fine, but they are wired). Apart from that, my current prototype glove is an Ektelon Classic Pro racquetball glove, and everything plugged into a Keyglove Kit PCB which itself also needs a new revision to accommodate a different motion sensor board (GY-521 instead of MPU-6050 breakout from SparkFun) and a reshaped WT12 module. The kit PCB makes the sensor attachment simpler by breaking out exactly the right Teensy++ pins into a rough hand shape, instead of being all mixed up and spread around in two straight lines. For build photos, I would recommend these photosets on the Keyglove FB page: https://www.facebook.com/media/set/?set=a.337898686244084.83149.160471600653461&type=3https://www.facebook.com/media/set/?set=a.454140811286537.105123.160471600653461&type=3https://www.facebook.com/media/set/?set=a.473407879359830.110642.160471600653461&type=3https://www.facebook.com/media/set/?set=a.466423573391594.108778.160471600653461&type=3I haven't refined the current firmware, parts list, or build process to the point where it makes sense to rewrite the build instructions online to make them current, unfortunately. I hope to do that before too much longer though.
  9. nRF51822

    The nRF51822 is definitely an intriguing module; I'd be willing to check into it once I get the main platform working (Arduino + classic Bluetooth). There are two challenges that it would introduce: significantly reduced I/O pin count, and BLE throughput (which admittedly isn't the module's fault, but rather the BLE protocol's fault). It would be quite difficult to push out as much data as I'm currently generating over a BLE link, which means either that the device would have to be used differently or else the data would need to be preprocessed and/or compressed before sending it in a way that is still useful to the receiving end. Bsaically, I haven't yet, but I might in the future. Thanks for the suggestion!
  10. iWRAP5

    I would expect so, yes. It depends on how the receiving side is built to process the HID reports, but I've never really worked on that end of the exchange before.
  11. iWRAP5

    If you included the report ID in your descriptor, then the reports should be different: 0x9F 0x04 0xA1 0x01 0x00 0x010x9F 0x04 0xA1 0x01 0x00 0x00Any luck with those (should press + release button 1)?
  12. iWRAP5

    Although this is only a guess (that is, I haven't tested it with your descriptor), it looks like it defines the following: Four 2-bit values for each direction, probably where [00] is no movement, [01] is positive movement, and [10] is negative movementEither 1-bit values for each button, probably where [0] is not pressed and [1] is pressedThe D-pad data should go in the first payload byte of the report (all four 2-bit fields in one 8-bit byte), and the button data should go in the second payload byte of the report (all eight 1-bit fields in one 8-bit byte). I'm not sure which direction is in the 2 LSBs and which is in the 2 MSBs, or the button order either though it is likely that bit 0 (0x01) is button 0, and bit 7 (0x80) is button 7. There appears to be no report ID defined, so either that should be left out, or else it should be zero. Probably left out. Therefore, the raw byte sequence to press and release button 1 should be either this: 0x9F 0x03 0xA1 0x00 0x010x9F 0x03 0xA1 0x00 0x00...or this (if the Report ID byte is present and 0x00): 0x9F 0x04 0xA1 0x00 0x00 0x010x9F 0x04 0xA1 0x00 0x00 0x00And the raw byte sequence to move one D-pad direction and release should be either this: 0x9F 0x03 0xA1 0x01 0x000x9F 0x03 0xA1 0x00 0x00...or this (if the Report ID byte is present and 0x00): 0x9F 0x03 0xA1 0x00 0x01 0x000x9F 0x03 0xA1 0x00 0x00 0x00Try that out and see if we get lucky.
  13. iWRAP5

    The iWRAP library was bundled in with the code originally, but although I took it out from there (at the moment anyway), it still lives in its own separate repo: https://github.com/jrowberg/iwrapI haven't made any changes to speak of to that library code in quite some time, though there are a few modifications that I haven't pushed to the repo yet. These do not constitute full iWRAP5 support though, especially in the HID area. Actually, iWRAP5 is largely backwards compatible with earlier versions, with HID being one of the few areas where what used to work will no longer work. For what you need, I would recommend this Keyglove blog post: http://www.keyglove.net/2013/05/30/complex-bluetooth-hid-with-iwrap-and-the-bluegiga-wt12It deals specifically with HID usage in iWRAP5, complete with tested example settings and raw HID report byte structures.
  14. Autodesk Inventor COM API

    That algorithm appears to be roughly correct. It really depends on how exactly you want to have the motion affect the model in Inventor--whether and how to use motion scaling, smoothing, acceleration, etc. I am not opposed to releasing the VB code that actually accomplishes the Inventor COM interfacing, but I'm not sure what state it's in at the moment since I've been focusing rather heavily elsewhere and have replaced my PC since that video was made. I need to reorient myself with the interface and clean things up a bit first, and of course make sure that it is working as intended. Once that's done, I will add that code to the repository.
  15. doubt!!!

    Hi Suresh, Currently the only thing that I have published is what you see on the Keyglove website, though there was a newspaper article which discussed the Keyglove among a couple of other Kickstarter projects: http://www.roanoke.com/living/1703324-12/arts--extras-kickstarter-providing-capital-successes-in.html
×