Recent Changes for "Open Myoelectric Signal Processor" - Open Prosthetics Project Wiki

Open Myoelectric Signal Processor

JonKuniholm — 2009-07-28 21:02:29

Differences for Open Myoelectric Signal Processor

Deletions are marked with - .	Additions are marked with +.
Line 1:	Line 1:
	+ [[Image(Myopen Board Version 1.jpg, 600, thumbnail)]]

Open Myoelectric Signal Processor

JonKuniholm — 2009-07-28 20:58:53

Upload of image Myopen Board Version 1.jpg.

Open Myoelectric Signal Processor

JonKuniholm — 2009-02-05 17:51:02

Differences for Open Myoelectric Signal Processor

Deletions are marked with - .	Additions are marked with +.
Line 38:	Line 38:
- =Related Projects We Should Be Aware Of (reuse code, be compatible with, already do what we're trying to do, etc.)=	+ =Related Projects We Should Be Aware Of/Ideas for Potential Uses (reuse code, be compatible with, already do what we're trying to do, etc.)=
Line 41:	Line 41:
	+ + From the MFAD program at SVA that is currently working on prosthetics from a Graphic Design and 3D form approach: + It struck me when Jon Kuniholm spoke to us that there is a need to develop MyoElectric Technology further and bring down the price. I think there would be a lot of interest in this technology in the private market for other uses, that could serve to further software, hardware and cost if it was attached to the right products. Video games have obvious applications: who can forget the power glove and imagine if it was actually a glove that reacted to your muscle movement! Attached is a clip of someone who got his hands on some of the MyoElectric sensors and worked out some software to compose music. I think this is amazing: [http://www.youtube.com/watch?v=dhRJqZ33_3I]. I think if this technology was opened up to a mass market we would see changes happen quickly, it may just be a matter of getting the right people interested. If anyone has questions or comments please send me an email at mattluckhurst@yahoo.com. Please feel free to examine this idea further and let me know if it is feasible or not. Thanks.

Open Myoelectric Signal Processor

JonKuniholm — 2008-06-22 10:44:24

Differences for Open Myoelectric Signal Processor

Deletions are marked with - .	Additions are marked with +.
Line 43:	Line 43:
- We have decided for now to develop both hardware and software under the Lesser General Public License [http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License (L-GPL)]. We have made this decision because we would like to allow the possibility for commercial prosthetic devices to link proprietary software to the software we are releasing, as well as create hardware that does the same thing (need more detail on L-GPL implications for circuit schematics).	+ We had originally decided to develop both hardware and software under the Lesser General Public License [http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License (L-GPL)]. We made this decision because we wanted to allow the possibility for commercial prosthetic devices to link proprietary software to the software we are releasing, as well as create hardware that does the same thing (need more detail on L-GPL implications for circuit schematics). + + We have revisited this decision, and the project is now [http://en.wikipedia.org/wiki/GNU_General_Public_License GPL].

Open Myoelectric Signal Processor

marcelod — 2008-05-22 20:23:09

Differences for Open Myoelectric Signal Processor

Deletions are marked with - .	Additions are marked with +.
Line 50:	Line 50:
- Other regulations are a thorny issue - things like UL approval will most likely be costly ($30,000), but will be necessary if we were to sell hardware products directly to consumers. Certifying the equipment will necessarily add to the cost of the device, as will insuring the manufacturers against liability (large as the device will be electrically connected to the user). We are currently looking for ideas to mitigate potential liability pitfalls, one idea is to offer the devices only in kit or incomplete form. Additionally, we should try to meet ISO 60601 criteria established for medical devices. The hardware should be designed such that it is possible to certify it if need be - and, besides, these regulations are meant to enforce product safety, and we do want to make the system as safe as possible! At present, the safety requirements include:	+ Other regulations are a thorny issue - things like UL approval will most likely be costly ($30,000), but will be necessary if we were to sell hardware products directly to consumers. Certifying the equipment will necessarily add to the cost of the device, as will insuring the manufacturers against liability (large as the device will be electrically connected to the user). We are currently looking for ideas to mitigate potential liability pitfalls, one idea is to offer the devices only in kit or incomplete form. Additionally, we should try to meet IEC 60601-1 criteria established for medical devices. The hardware should be designed such that it is possible to certify it if need be - and, besides, these regulations are meant to enforce product safety, and we do want to make the system as safe as possible! At present, the safety requirements include:

Open Myoelectric Signal Processor

JonKuniholm — 2008-03-12 17:27:14

Differences for Open Myoelectric Signal Processor

Deletions are marked with - .	Additions are marked with +.
Line 45:	Line 45:
- We have been accused of being naive for thinking that we can get away without addressing the issue of intellectual property, and that we need to at least come up with some sort of license for what IP folks believe must be out there already covering this area. [http://www.google.com/patents?vid=USPAT6244873 This patent] covers a similar idea, referencing the wireless capability. Volunteers to help do a real patent search and begin negotiating away whatever roadblocks there are would be greatly appreciated.	+ We have been accused of being naive for thinking that we can get away without addressing the issue of intellectual property, and that we need to at least come up with some sort of license for what IP folks believe must be out there already covering this area. [http://www.google.com/patents?vid=USPAT6244873 This patent] covers potentially related idea, referencing only the wireless capability. Volunteers to help do a real patent search and begin negotiating away whatever roadblocks there are would be greatly appreciated.

Open Myoelectric Signal Processor

JonKuniholm — 2008-03-11 19:41:09

Differences for Open Myoelectric Signal Processor

Deletions are marked with - .	Additions are marked with +.
Line 42:	Line 42:
- =Licensing=	+ =Licensing and Intellectual Property Issues=
Line 44:	Line 44:
	+ + We have been accused of being naive for thinking that we can get away without addressing the issue of intellectual property, and that we need to at least come up with some sort of license for what IP folks believe must be out there already covering this area. [http://www.google.com/patents?vid=USPAT6244873 This patent] covers a similar idea, referencing the wireless capability. Volunteers to help do a real patent search and begin negotiating away whatever roadblocks there are would be greatly appreciated.
Line 56:	Line 58:
- =Intellectual Property Issues= - We have been accused of being naive for thinking that we can get away without addressing this issue, and that we need to at least come up with some sort of license for what IP folks believe must be out there already covering this area. [http://www.google.com/patents?vid=USPAT6244873 This patent] covers a similar idea, referencing the wireless capability. Volunteers to help do a real patent search and begin negotiating away whatever roadblocks there are would be greatly appreciated. -

Open Myoelectric Signal Processor

JonKuniholm — 2008-03-11 19:39:27

Differences for Open Myoelectric Signal Processor

Deletions are marked with - .	Additions are marked with +.
Line 56:	Line 56:
	+ =Intellectual Property Issues= + We have been accused of being naive for thinking that we can get away without addressing this issue, and that we need to at least come up with some sort of license for what IP folks believe must be out there already covering this area. [http://www.google.com/patents?vid=USPAT6244873 This patent] covers a similar idea, referencing the wireless capability. Volunteers to help do a real patent search and begin negotiating away whatever roadblocks there are would be greatly appreciated.

Open Myoelectric Signal Processor

JonKuniholm — 2008-01-09 19:19:55

Differences for Open Myoelectric Signal Processor

Deletions are marked with - .	Additions are marked with +.
Line 46:	Line 46:
- This seems to be a thorny issue - things like UL approval will most likely be costly ($30,000), but will be necessary if we were to sell hardware products directly to consumers. Certifying the equipment will necessarily add to the cost of the device, as will insuring the manufacturers against liability (large as the device will be electrically connected to the user). We are currently looking for ideas to mitigate potential liability pitfalls, one idea is to offer the devices only in kit or incomplete form. Additionally, we should try to meet ISO 60601 criteria established for medical devices. The hardware should be designed such that it is possible to certify it if need be - and, besides, these regulations are meant to enforce product safety, and we do want to make the system as safe as possible! At present, the safety requirements include:	+ Prosthetic components are regulated by the federal government as Class I (exempt) medical devices, as discussed ["Federal Regulation of Prostheses" here]. As the discussion points out, a device marketed as a prosthetic component is subject only to the subset of general requirements that involve record-keeping, complaint tracking, and establishment registration. Because a myo signal processor capable of pattern recognition operates on the same fundamental scientific principle, i.e. skin surface EMG signals, it would not be subject to any exception to exemption described in section [http://www.accessdata.fda.gov/scrIpts/cdrh/cfdocs/search/search.cfm?db=CFR&ID=890.9 21CFR90.9], just as the example given in the regulation would not deny an exemption to a cutting device that cut by the same method, e.g. blade as opposed to laser. Given the apparent ease with which these requirements could be met, it might be easier to market this device as a prosthetic component than nearly anything else, including a toy.l + + Other regulations are a thorny issue - things like UL approval will most likely be costly ($30,000), but will be necessary if we were to sell hardware products directly to consumers. Certifying the equipment will necessarily add to the cost of the device, as will insuring the manufacturers against liability (large as the device will be electrically connected to the user). We are currently looking for ideas to mitigate potential liability pitfalls, one idea is to offer the devices only in kit or incomplete form. Additionally, we should try to meet ISO 60601 criteria established for medical devices. The hardware should be designed such that it is possible to certify it if need be - and, besides, these regulations are meant to enforce product safety, and we do want to make the system as safe as possible! At present, the safety requirements include:

Open Myoelectric Signal Processor

JonKuniholm — 2007-12-19 15:15:05

Differences for Open Myoelectric Signal Processor

Deletions are marked with - .	Additions are marked with +.
Line 7:	Line 7:
- Source for hardware and software will be maintained with version control, etc., on [http://sourceforge.net/projects/myopen SourceForge]. The project name on SourceForge, created in a punny and hopefully not disastrously nearsighted moment, is "MyOpen." Strenuous objections can be raised in any available forum.	+ Source for hardware and software will be maintained with version control, etc., on [http://code.google.com/p/myopen/ our Google Code page]. The project name, created in a punny and hopefully not disastrously nearsighted moment, is "MyOpen." Strenuous objections can be raised in any available forum.

Open Myoelectric Signal Processor

JonKuniholm — 2007-12-18 16:42:22

Changed the estimated dimension of the buglabs module from engaget.

Differences for Open Myoelectric Signal Processor

Deletions are marked with - .	Additions are marked with +.
Line 60:	Line 60:
- * To connect as a buglabs device, we'll need to fit their size requirements. At present this is estimated to be about 3.5 x 3.5 x 1".	+ * To connect as a buglabs device, we'll need to fit their size requirements. At present this is estimated to be 2" x 2" x 1/2".

Open Myoelectric Signal Processor

JabberWokky — 2007-12-15 21:01:01

Mediawiki markup -> Clickwiki markup

Differences for Open Myoelectric Signal Processor

Deletions are marked with - .	Additions are marked with +.
Line 25:	Line 25:
- I2C / TWI - Ethernet - USB - Analog (e.g. onboard DAC) - * Otto Bock prosthetics require 0-5V signaling, offset 1.25/1.3V. - * May also want to add analog feedback to user, e.g. through vibrator motors. - JTAG - RS-232 (?) - CAN (?) - Bluetooth? (e.g. via BlueCore-4 in the NXT brick)	+ * I2C / TWI + * Ethernet + * USB + * Analog (e.g. onboard DAC) + * Otto Bock prosthetics require 0-5V signaling, offset 1.25/1.3V. + * May also want to add analog feedback to user, e.g. through vibrator motors. + * JTAG + * RS-232 (?) + * CAN (?) + * Bluetooth? (e.g. via BlueCore-4 in the NXT brick)
Line 36:	Line 36:
- ** hence, low power, < 150mw. Each interface must be able to be switched off.	+ * hence, low power, < 150mw. Each interface must be able to be switched off.
Line 59:	Line 59:
- SPI / I2C, details forthcoming. - To connect as a buglabs device, we'll need to fit their size requirements. At present this is estimated to be about 3.5 x 3.5 x 1".	+ * SPI / I2C, details forthcoming. + * To connect as a buglabs device, we'll need to fit their size requirements. At present this is estimated to be about 3.5 x 3.5 x 1".
Line 62:	Line 62:
- ** If we want to fully replace the Nunchuck, it will be necessary to add a 3-axis accelerometer.	+ * If we want to fully replace the Nunchuck, it will be necessary to add a 3-axis accelerometer.

Open Myoelectric Signal Processor

tlh24 — 2007-12-15 20:39:58

Differences for Open Myoelectric Signal Processor

Deletions are marked with - .	Additions are marked with +.
Line 14:	Line 14:
- * Prosthetic users - * Gamers - * Education, e.g. http://www.vernier.com/nxt/index.html - * Hackers, students, creators, and other innovators.	+ * Prosthetic users + * Gamers + * Education, e.g. http://www.vernier.com/nxt/index.html + * Hackers, students, creators, and other innovators.
Line 22:	Line 22:
- * Available for approximately $250 - * Available for cheaper in kit-form - * capable of a variety of modes of communication with a host device, including - I2C / TWI - Ethernet - USB - Analog (e.g. onboard DAC) - * Otto Bock prosthetics require 0-5V signaling, offset 1.25/1.3V. - * May also want to add analog feedback to user, e.g. through vibrator motors. - JTAG - RS-232 (?) - CAN (?) - Bluetooth? (e.g. via BlueCore-4 in the NXT brick) - * Battery or USB powered ( 3 - 5.5V in) - ** hence, low power, < 150mw. Each interface must be able to be switched off.	+ * Available for approximately $250 + * Available for cheaper in kit-form + * capable of a variety of modes of communication with a host device, including + I2C / TWI + Ethernet + USB + Analog (e.g. onboard DAC) + * Otto Bock prosthetics require 0-5V signaling, offset 1.25/1.3V. + * May also want to add analog feedback to user, e.g. through vibrator motors. + JTAG + RS-232 (?) + CAN (?) + Bluetooth? (e.g. via BlueCore-4 in the NXT brick) + * Battery or USB powered ( 3 - 5.5V in) + ** hence, low power, < 150mw. Each interface must be able to be switched off.
Line 48:	Line 48:
- * 4kv user isolation from mains and / or computer interface (USB, ethernet, etc) - * Robust EMI protection on the input, via transistors, TVS, or diodes. - * Open-circuit failure mode for any amplifier inputs. I've been in an OR where the electrophysiology amplifiers (Plexon) failed to one of the +-2.5 power rails, and I do not want to see that again. - * Predictable failure modes for any of the other inputs to prevent excessive current input (e.g. USB somehow connected to mains) from being reflected in the isolated power supply. - * Robust to strong RF interference. This may be just a matter of proper shielding & software rejection of faulty signals.	+ * 4kv user isolation from mains and / or computer interface (USB, ethernet, etc) + * Robust EMI protection on the input, via transistors, TVS, or diodes. + * Open-circuit failure mode for any amplifier inputs. I've been in an OR where the electrophysiology amplifiers (Plexon) failed to one of the +-2.5 power rails, and I do not want to see that again. + * Predictable failure modes for any of the other inputs to prevent excessive current input (e.g. USB somehow connected to mains) from being reflected in the isolated power supply. + * Robust to strong RF interference. This may be just a matter of proper shielding & software rejection of faulty signals.
Line 57:	Line 57:
- * Lego NXT (I2C interface .. but beware, not open collector) - * Buglabs - SPI / I2C, details forthcoming. - To connect as a buglabs device, we'll need to fit their size requirements. At present this is estimated to be about 3.5 x 3.5 x 1". - * Wii Nunchuk remote (I2C interface, slightly encrypted but still hackable) - ** If we want to fully replace the Nunchuck, it will be necessary to add a 3-axis accelerometer. - * Windows / Linux computer. Through either USB or Ethernet. (Ethernet is preferred, as driver development is much easier). - * Xbox 360 / Playstation 3 (through USB, though driver/software development there may be challenging)	+ * Lego NXT (I2C interface .. but beware, not open collector) + * Buglabs + SPI / I2C, details forthcoming. + To connect as a buglabs device, we'll need to fit their size requirements. At present this is estimated to be about 3.5 x 3.5 x 1". + * Wii Nunchuk remote (I2C interface, slightly encrypted but still hackable) + ** If we want to fully replace the Nunchuck, it will be necessary to add a 3-axis accelerometer. + * Windows / Linux computer. Through either USB or Ethernet. (Ethernet is preferred, as driver development is much easier). + * Xbox 360 / Playstation 3 (through USB, though driver/software development there may be challenging)

Open Myoelectric Signal Processor

tlh24 — 2007-12-15 20:37:53

Differences for Open Myoelectric Signal Processor

Deletions are marked with - .	Additions are marked with +.
Line 3:	Line 3:
- Along with a couple of collaborators (and we'd love to have more), we are exploring the development of an extremely flexible open hardware module that could be used with the Buglabs device, the LEGO NXT platform, and as a USB device that could be used with the OLPC (laptop.org) and traditional linux and windows computers. The components of the device would be modular, so we could populate them as needed, and use the same design for a variety of applications.	+ Along with a couple of collaborators (and we'd love to have more), we are exploring the development of an extremely flexible open hardware module that could be used with the Buglabs device, the LEGO NXT platform, and as a USB device that could be used with the OLPC (laptop.org), and traditional linux and windows computers. The components of the device would be modular, so we could populate them as needed, and use the same design for a variety of applications. The USB interface could also be used for connecting to game consoles, such as the Xbox360 and Playstation 3; the I2C bus may be useful for connecting to the Nintendo Wii via the Nunchuck input.
Line 12:	Line 12:
	+ = Customer Statement = + The goal is to make an affordable, safe, open-source EMG processor for the following markets: + * Prosthetic users + * Gamers + * Education, e.g. http://www.vernier.com/nxt/index.html + * Hackers, students, creators, and other innovators. + +
Line 14:	Line 22:
- - capable of a variety of modes of communication with a host device, including - - USB - - I2C	+ * Available for approximately $250 + * Available for cheaper in kit-form + * capable of a variety of modes of communication with a host device, including + I2C / TWI + Ethernet + USB + Analog (e.g. onboard DAC) + * Otto Bock prosthetics require 0-5V signaling, offset 1.25/1.3V. + * May also want to add analog feedback to user, e.g. through vibrator motors. + JTAG + RS-232 (?) + CAN (?) + Bluetooth? (e.g. via BlueCore-4 in the NXT brick) + * Battery or USB powered ( 3 - 5.5V in) + ** hence, low power, < 150mw. Each interface must be able to be switched off.
Line 26:	Line 46:
- ==Certifications We Should/Must Seek==	+ This seems to be a thorny issue - things like UL approval will most likely be costly ($30,000), but will be necessary if we were to sell hardware products directly to consumers. Certifying the equipment will necessarily add to the cost of the device, as will insuring the manufacturers against liability (large as the device will be electrically connected to the user). We are currently looking for ideas to mitigate potential liability pitfalls, one idea is to offer the devices only in kit or incomplete form. Additionally, we should try to meet ISO 60601 criteria established for medical devices. The hardware should be designed such that it is possible to certify it if need be - and, besides, these regulations are meant to enforce product safety, and we do want to make the system as safe as possible! At present, the safety requirements include: + + * 4kv user isolation from mains and / or computer interface (USB, ethernet, etc) + * Robust EMI protection on the input, via transistors, TVS, or diodes. + * Open-circuit failure mode for any amplifier inputs. I've been in an OR where the electrophysiology amplifiers (Plexon) failed to one of the +-2.5 power rails, and I do not want to see that again. + * Predictable failure modes for any of the other inputs to prevent excessive current input (e.g. USB somehow connected to mains) from being reflected in the isolated power supply. + * Robust to strong RF interference. This may be just a matter of proper shielding & software rejection of faulty signals. +
Line 29:	Line 56:
- Buglabs, LEGO NXT	+ In order of priority: + * Lego NXT (I2C interface .. but beware, not open collector) + * Buglabs + SPI / I2C, details forthcoming. + To connect as a buglabs device, we'll need to fit their size requirements. At present this is estimated to be about 3.5 x 3.5 x 1". + * Wii Nunchuk remote (I2C interface, slightly encrypted but still hackable) + ** If we want to fully replace the Nunchuck, it will be necessary to add a 3-axis accelerometer. + * Windows / Linux computer. Through either USB or Ethernet. (Ethernet is preferred, as driver development is much easier). + * Xbox 360 / Playstation 3 (through USB, though driver/software development there may be challenging)

Open Myoelectric Signal Processor

JonKuniholm — 2007-12-13 15:43:42

Differences for Open Myoelectric Signal Processor

Deletions are marked with - .	Additions are marked with +.
Line 7:	Line 7:
- Source for hardware and software will be maintained with version control, etc., on ["http://sourceforge.net/projects/myopen" SourceForge]. The project name on SourceForge, created in a punny and hopefully not disastrously nearsighted moment, is "MyOpen." Strenuous objections can be raised in any available forum.	+ Source for hardware and software will be maintained with version control, etc., on [http://sourceforge.net/projects/myopen SourceForge]. The project name on SourceForge, created in a punny and hopefully not disastrously nearsighted moment, is "MyOpen." Strenuous objections can be raised in any available forum.
Line 23:	Line 23:
- We have decided for now to develop both hardware and software under the Lesser General Public License ["http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License" (L-GPL)]. We have made this decision because we would like to allow the possibility for commercial prosthetic devices to link proprietary software to the software we are releasing, as well as create hardware that does the same thing (need more detail on L-GPL implications for circuit schematics).	+ We have decided for now to develop both hardware and software under the Lesser General Public License [http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License (L-GPL)]. We have made this decision because we would like to allow the possibility for commercial prosthetic devices to link proprietary software to the software we are releasing, as well as create hardware that does the same thing (need more detail on L-GPL implications for circuit schematics).

Open Myoelectric Signal Processor

JonKuniholm — 2007-12-13 15:40:30

Differences for Open Myoelectric Signal Processor

Deletions are marked with - .	Additions are marked with +.
Line 6:	Line 6:
	+ + Source for hardware and software will be maintained with version control, etc., on ["http://sourceforge.net/projects/myopen" SourceForge]. The project name on SourceForge, created in a punny and hopefully not disastrously nearsighted moment, is "MyOpen." Strenuous objections can be raised in any available forum.
Line 20:	Line 22:
	+ =Licensing= + We have decided for now to develop both hardware and software under the Lesser General Public License ["http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License" (L-GPL)]. We have made this decision because we would like to allow the possibility for commercial prosthetic devices to link proprietary software to the software we are releasing, as well as create hardware that does the same thing (need more detail on L-GPL implications for circuit schematics). +

Open Myoelectric Signal Processor

JonKuniholm — 2007-12-07 23:32:06

Differences for Open Myoelectric Signal Processor

Deletions are marked with - .	Additions are marked with +.
Line 17:	Line 17:
- ["http://openeeg.sourceforge.net/doc/"] - ["https://sourceforge.net/projects/oip"]	+ [http://openeeg.sourceforge.net/doc/] + [https://sourceforge.net/projects/oip]

Open Myoelectric Signal Processor

JonKuniholm — 2007-12-07 23:31:20

Differences for Open Myoelectric Signal Processor

Deletions are marked with - .	Additions are marked with +.
Line 1:	Line 1:
	+ OPP is seeking to encourage experimentation with myoelectric control in order to inspire more rapid development of mechatronic prostheses for amputees. Because of the extremely small market size for upper extremity prosthetics, we think that one way to encourage this activity is to develop toys or user customizable devices that are capable of myoelectric signal processing. With wider access and experimentation with the technology, perhaps we could see interesting developments beyond the traditional venues of corporate R&D and educational institution research. + + Along with a couple of collaborators (and we'd love to have more), we are exploring the development of an extremely flexible open hardware module that could be used with the Buglabs device, the LEGO NXT platform, and as a USB device that could be used with the OLPC (laptop.org) and traditional linux and windows computers. The components of the device would be modular, so we could populate them as needed, and use the same design for a variety of applications. + + This project is in the very early stages of development, and we intend to use this space for the initial exploration of the project, including the development of a problem statement and design requirements for the device. We are planning on running all electronic source documents, including the board schematics, through a sourceforge-hosted site. Please contact us if you are interested in contributing. + + =Problem Statement= + Design a device capable of collecting 16 or fewer channels of skin surface myoelectric signals (EMG), processing the collected data, and delivering to a host device the results of signal processing algorithms such as pattern recognition in real time. + + =Design Requirements= + We would like the device to be + - capable of a variety of modes of communication with a host device, including + - USB + - I2C + + =Related Projects We Should Be Aware Of (reuse code, be compatible with, already do what we're trying to do, etc.)= + ["http://openeeg.sourceforge.net/doc/"] + ["https://sourceforge.net/projects/oip"] + + =Regulatory Issues= + ==Certifications We Should/Must Seek== + + =Devices We Hope to Interface With= + Buglabs, LEGO NXT