Project  - Voice Activated Eblock

CS 179J: Senior Design Project in Architecture / Embedded Systems

Project Description (Long Nguyen):
We will be designing a new eBlock that will be able to recognize some sort of speech or possibly clap from the user that will designate whether we want the eBlock to output a logical “yes” or a logical “no.”  For more background information about eBlocks click on this site.  This eBlock that we wish to design will be able to interface with the common set eBlock protocol, which can be found here, and will be able to fit within our pooled budget of approximately one hundred and fifty dollars.  Our eBlock will be designed to be a speaker-independent system, which elaborates to a multiple-user interface.

Our time constraints correlated to scratching out the entire idea about doing a custom speech recognition eBlock by plain programming on the PIC microprocessor.  This method would have required too much time, which we did not have.  The design procedure would include learning about speech patterns and recognition that entire quarter classes are devoted to.  After that, we would have needed to program the entire method through equations and using Fast Fourier Transform.  These programming techniques would have been too taxing on the PIC programming since we would need many multipliers and had intense computations that would have made the entire design too slow in response to the user.

The Plan (Ron Feliciano):
We have revised our plan for creating both the complicated “Voice Recognition” and the simpler “Clapper” eBlocks. Instead of having a small portion of our group (3 people) create the simpler eBlock on their own, we have decided that it would be beneficial for all groups to create “Clapper” eBlocks. Each two or three person team would create their own “Clapper” eBlock from one of the links provided on our websites. Ideally, we would all work on the “Clappers” together at the same time. In this way, we could help each other out if difficulties arise. This decision was made so that everyone would have a more intimate knowledge of the “Clapper” design, the creation process, and also the eBlock protocol. Also everyone would have to learn how to program the PIC. These skills would undoubtedly be valuable when the group tries to tackle the creation of the “Voice Recognition” eBlock. After the “Clappers” are finished (we estimate this should require no more than about a week), three people would continue on to working on the “poor man’s Voice Recognition” eBlock. This eBlock involves very rudimentary sounds (shouts) to activate the eBlock. The rest of the team would work on the most complicated design of all, the full Voice Recognition eBlock, using the Voice Extreme IC. These last two parts of the project should take whatever time is left. If all goes well, we should have three levels of design for this eBlock. The most complicated being the Voice Recognition block, the middle ground “Poor man’s” Voice Recognition block, and quite a few of the simple clapper eBlocks. If either (or neither) of the two more complicated designs are not finished, then at least we have the simple “Clapper” eBlocks to fall back on.

Software Approach?? (Rima Fata):
There are two approaches to voice recognition: “template matching” and “feature analysis.” In “template matching,” a microphone will pick up the input and using an A/D store it into memory. Then conditional statements are then used to try and match the input with what is in the template. Downside to this implementation is that the program can not have a template for each potential user. Hence, if there is more than one person needing to use the eBlock, it will not work. In this case, the program must be trained with the new user voice by speaking words provided by the computer. This creates a limited vocabulary.

The second approach uses the Fourier Transform or LPC (linear predictive coding.) First of all, the process uses the FFT to attempt to find characteristics that are similar between the actual digitized voice input and the expected one. The algorithms for the FFT are generally found to be of O (nlogn). The FFT Chips generally come with a minimum of 70 ~ 300 I/O pins, average 5000mW power and need a datapath width of 10 ~ 32 bits. It can compute at 1024 point complex transform; refer to chart at www-star.stanford.edu/~bbaas/fftinfo.html.

The FFT itself requires a lot of resources for computation because of its repeated multiplications. Therefore, problems are created for processors working for voice recognition due to low processing horsepower and memory availability. Most applications of voice recognition are done through DSP (digital signal processing) controllers because of needed computation resources. The data width is needs to be a minimum of 16 bits. The processor must include floating point arithmetic, a minimum 8-bit ADC at a sampling frequency of 8 kHz.

The greatest limiting factor is the memory. Flash memory and RAM memory are needed for the data, recognition software, and input buffer. If the input buffer is implemented using the RAM, assuming one user, 30 commands, and the same sampling frequency of 8 kHz then you need 8k x 16 of RAM.The flash memory needed to implement only voice dependent assuming again one user is a minimum of 32k x 16 bit, which uses about 1k x 16 per command. According to the data sheet the PIC 16F628 has 2048 x 14 bits of flash and 224 x 8 of RAM. (www.us.design-reuse.com/articles/article2289.html)

Week 3 & 4 (thru Wed. Jan. 28th) (Eric Frohnhoefer):
For the next week we have a number of goals we would like to achieve that will help everyone in the group gain a better understanding of the current design of existing eBlocks and  if circumstances permit the use of the Voice Extreme Module. By the beginning of our next meeting the group proposal along with an outline of our weekly goals should be complete. The outline will allow us to, at a glance, track our progress to determine whether we are on track or not to complete the project on time. Set goal will also help keep out meetings focused on the task at hand instead of going off into  unhelpful tangents.

By the end of our meeting on Saturday January 24th, we hope to have a completed button eBlock and receiver eBlock that is able to interface with current eBlocks provided to us by Susan. By building eBlocks from scratch we will gain a better understanding of the internal workings of the eblock.  Each member should be able to program the PIC, breadboard an eBlock circuit, and have a basic understanding of the eBlock communication code. In addition to working eBlocks we hope to have a working clapper circuit.  At the very least we would like to be able to test the correctness of the clapper circuit by hooking it up to an oscilloscope to read the output values.

Along with gaining a better understanding of eBlocks we also want to become more knowledgeable on the Voice Extreme Module.  By class on Wednesday we hope to have compiled a list of links to useful resources related to developing on the Voice Extreme Module. If time permits and the Voice Extreme module arrives in time we would like to set up the development kit in Surge 283 and begin running through the tutorials in the Voice Extreme Toolkit Quick Start Manual. This way we can get a feel for the Voice Extreme Module.

Week 4 thru 6 (thru Wed. Feb. 11th) (Edward Lee):
Week 4 revolves primarily on the construction of the clapper-type eBlocks.  It is our goal to have several clapper-type eBlock prototypes by week 5 to demonstrate on the 28^th of January.   These prototypes will most likely exist in the form of circuits on breadboards.  This allows for visual inspection and critique during demonstration of the clapper-type eBlocks.  To accomplish this task of having several clapper-type eBlocks ready by the 28^th of January, the plan is to meet on the 21^st and the 24^th to move forward in design and implementation of the clapper-type eBlocks.

After the 1^st prototype demonstration in week 5, the overall team will be concerned with three overall goals till the 2^nd prototype demonstration in week 7.  The first of these goals is the refinement of the clapper-type eBlocks.  The second goal will be to begin work and make progress on the voice-activated eBlock based on the Voice Extreme IC if work has not already begun.  The third and last big goal is to begin work on the “Poor Man’s Voice Recognition eBlock” if work has not already begun.

Week 6 thru 8 (thru Wed. Feb. 25th) (RJ Jareno):
At this point, we should know what exactly our project is going to produce. If the first prototype did not include a finished clapper eblock, we will finish this up in week 6. In other words, by week 6 we should have a clapper eBlock that is ready to be a part of the current line of eBlock products. We will continue to work on the Voice Extreme and "poor man's" implementation.

It is expected that this "poor man's" implementation will not be finished. However, we will surely learn a vast amount of information concerning the design, implementation, and fabrication of a speech recognition system. This type of system is going to be more and more prevalent in every day society, so it does not necessarily mean that we have wasted our precious time if this implementation fails.

We are optimistic though that we may be able to produce a "voice sequence detector" eBlock. For example, the commands "on," "off", "hey," "hi," "no," and so on may output a yes but the commands "on on," "turn off, "hey hey," "hi hi" or any sequence of two words may output a no. Even though this may be silly to a normal speaker, one can consider this a useful tool for a handicapped person that may not be able to pronounce things correctly. Funny as it may sound, he/she may only be able to convey groans or grunts when communicating. In this case, this "voice sequence detector" eBlock would be a very useful product.

Week 8 thru 10 (thru Wed. Mar. 10th) (Kai Xing):
The last two weeks will be spent mostly on implementing the full functionality of whatever designs we’ve come up with, then polishing, packaging and turning them into nice products ready for sale or demonstration.  This includes writing up user manuals, and detailed technical information such as power estimation.  Then, each group will need to organize all the paperwork into a final report.

A lot of testing is needed.  A test plan should be made from the beginning of project.  All aspects of designs need to be tested along the building process.  Test results are good information that can be used to determine the quality of the product.  It’s going to be part of the final report.  For example, how hard does one have to clap to trigger the device; for the poor man’s, what different commands can the eBlock distinguish, and how often it detects correctly; for VE, how different users affect the output, etc.  A small manual is very useful to the user to avoid unexpected output due to design defects or constraints. All parts list, hardware schematics, software flow chart should be well documented and included in the report. It’s also good to have the product’s background and prospect information.  Different design approaches and problems encountered can be beneficial to future product developers.   

By week 9, all the clapper eBlock must have been finished and tested.  Tradeoff analysis on different versions can help us come up with the optimal way to build a clapper. So, the major goal is to achieve as much as possible on the poor man’s and VE designs if not finished yet.  It’s probably a good idea to have one member focus on documentation while the rest continue to work on the design to get the maximum turnout.  

Outline of Goals and Tracking of Progress (Eric Frohnhoefer) (Progress to be updated each week on a rotating basis):