Fall_Final_Report VOICE2.pdf

7/27/2019 Fall_Final_Report VOICE2.pdf

1/20

Table of Contents

I. Abstract....................................................................................................................... 1

II. Project Final Design Plan ..................................................................................... 1

II.1. Introduction.................................................................................................................. 1

II.2. Design Requirements ................................................................................................... 2II.2.1. Design Objectives .............................................................................................................. 2II.2.2. Functional Requirements ................................................................................................... 5II.2.3. System Parameters............................................................................................................. 6II.2.4. Design Constraints............................................................................................................. 7

II.3. System Design............................................................................................................... 9II.3.1. Design Approach ............................................................................................................... 9II.3.2. Critical Components ........................................................................................................ 10II.3.3. Test Procedures................................................................................................................ 12II.3.4. Anticipated Risks............................................................................................................. 13

II.4. Financial Budget ........................................................................................................ 14II.5. Project Schedule......................................................................................................... 16

III. Summary............................................................................................................... 17

IV. References ............................................................................................................ 19

Figure 1: General configuration of system..................................................................... 10

Figure 2: General outline of project ............................................................................... 10

Figure 3: PDA to be used ................................................................................................ 11

Figure 4: Breakdown of Tasks........................................................................................ 16

Figure 5: Gantt Chart for Project ................................................................................... 17

Table A: Cost of Parts ................................................................................................. 14

Table B: Cost of Project .............................................................................................. 15

- i -


2/20

1

I. AbstractThe Voice Activated Remote Control project will address the need of people who

do not like to search for the remote control or do not have the energy to walk up to the

television or any device which makes use of a remote control. This project will aim to

create a device which can accept audio input and will send a corresponding signal to

another device atop the instrument wishing to be controlled to perform the required task.

We will develop an application which will run inside a device, such as a computer or

PDA, which will send the signal to a set-top device which we will create. At the

conclusion of this project, we will have a set-top device which will receive Bluetooth

signals from any device which supports Bluetooth and our software which will enable

Bluetooth-enabled PDAs to take voice commands and transfer them to our device. By

creating a separate set-top box, we will be able to enable the product to be compatible to

future devices which may integrate Bluetooth.

II.Project Final Design PlanII.1. Introduction

Our project is a voice-activated remote control, it entails putting together a device

that will be able to control a television set using voice commands. Instead of the

traditional infrared remote control, we are planning on extending its transmit range by

adding a set of Bluetooth receiver/transmitter to the system. Some type of processor,

either that of a PDA or a DSP, will be used to analyze the voice commands given by the

user. It will then send the command via its attached Bluetooth transmitter. At the other

end, by the television there will be a customized Bluetooth receiver to receive the signal.


3/20

2

Finally it converts the RF signal into compatible infrared signal to be sent on a modified

remote control.

Although our project scope will only focus on controlling a television set, the

project can be modified for a numbers of applications. One example is a voice activated

garage door opener. The driver will no longer have to take his/her eye off the road to

press a button to open his garage door. Another application would be a voice-activated

VCR programmer, just to name a few.

Currently, the group aims to develop a prototype using two laptops connected via

Bluetooth. We will develop an interface for users to speak to and use a program to

analyze the voice. The command will then transfer to a module on the TV, which then

converts the command to infrared. After a working prototype has been successfully

developed, we will move towards a PDA. Finally, if time permits, we will build a

remote control using a DSP chip. The technical and financial details of this project will

be discussed later in the report.

II.2. Design RequirementsII.2.1.Design Objectives

During Design VI last semester, our group did a good job of getting ahead by

choosing and finalizing on a design project. It helps us a lot by giving us plenty of time to

finalize our objective. We also had a lot of time to do research on the resources thats

available to do our job. As our advisor predicted, there are a plethora of ways to

accomplish our design goals. As we foresaw different problems and how we can

overcome them, we have changed some of the items that we agreed upon earlier in the

semester and our objectives are now fairly clear.


4/20

3

Our first objective is to create a voice accepting program that is user independent.

We want to remove the concept of user training. Another objective is to have high

fidelity. We do not want the user to say Channel 5 ten times before it actually changes

the channel. We also want the Bluetooth sender to successfully recognize the receiver. If

the sender finds several Bluetooth devices, it should successfully distinguish the receiver.

The software cannot be processor intensive because if it is going to run on the users

PDA, it cannot hog up all of the resources. We want it so that another program on the

PDA can run parallel to ours. The set-top device that we create will have to have low

power consumption. We want it to be small and at the same time not have the user

change batteries ever week.

Our final objective for this project is to create software for a PDA that accepts

voice commands to control a device. The PDA is to have a Bluetooth module. The

Bluetooth module will communicate with another Bluetooth module on the receiving end.

The receiving end will be a set top device that will receive the Bluetooth signals and

convert them to infrared.

While working on this project, the group had to overcome many technical

problems. Some of the technical problems that we ran into were how to actually have

software that does not require the user to go through voice training. To overcome this

problem we decided that we will use a user-independent speech SDK. This led to yet

another problem, actually finding an SDK. This took a very long time. We asked

various people as well as did extensive searches on google.com. We finally found a

company that let us use the demo version of the SDK.


5/20

4

Before porting the project to the PDA level, we decided to do the project on two

laptops. A major technical problem that we ran into was to actually get the Bluetooth

devices to actually handshake with each other. We are using the SDK that came with the

Bluetooth modules. They provided us with samples of programs that we can successfully

run. The code of the samples, however, is very, very complicated. We are still in the

process of breaking down the code and understanding various components of the

program. We hope to finish understanding the SDK by the end this month.

After speaking to our advisor, Prof. Hong Man, we have two approaches on

overcoming this problem. We plan to either create our program at the TCP level,

assigning static IP addresses to the Bluetooth modules. While this still requires the

handshake phase, it makes it easier to create the program since we have a better

understanding of programming at the TCP level. Another approach to this is to fully

understand the SDK and use the functions given to us. This approach is more difficult to

follow because of the complexity of the SDK.

Finally, another major problem that the group faced is to determine the format of

the infrared. We are still looking at documentation that we downloaded from the

Internet. We plan to continue our research for this portion into next semester. A

finalized solution for this problem will be devised then.

We foresee problems with the set-top device. We will have to find a DSP with a

TCP stack in order for us to use the Bluetooth modules at the TCP level. While

achieving our objective, we plan to minimize any problems that we run into. We plan to

do this by conducting research as well as asking other professors on what they think is the

best approach to resolving the problem. If at the end of next semester, we cannot


6/20

5

complete building the set-top device, we plan to use two PDAs for our project. One of

the PDAs will be used to send and the other to receive the Bluetooth signals. We can

also use two laptops to demo the idea.

II.2.2.Functional RequirementsOne of the main features of the prototype is the ability to interpret voice

commands and translate them to commands the television or other set-top device can

understand. This feature enables the unit to provide convenience for users because it

avoids the hassles of searching for a remote, especially with the lights turned off. With

the voice recognition recognizing the command no matter the speaker, no training is

required.

The Bluetooth module also provides benefits. With infrared, a line of sight is

required and a close distance in necessary to transmit the command. Bluetooth, however,

eases both these restrictions. Bluetooth, because it is like a radio technology, eliminates

the line of sight requirement. This enables the user to place the device in a not-so-

obvious location. In the future, if the part of our device is moved from the PDA to a

standalone unit, it can be placed underneath a desk or couch. With a range of 10 meters

for the current standard of Bluetooth, this device can be placed away from the television

or set-top device and still be fully functional. Also, this standalone device can be placed

in another room and still control a device that is up to 10 meters away, provided there is

no outside interference.

Another feature is that when a set-top device is created to be placed on top of all

devices employing infrared, it will allow the set to become Bluetooth-enabled. This

allows other devices, such as Bluetooth-enabled cell phones, to control the device. This


7/20

6

would allow functionality in the future such as muting the television or pausing the VCR

when answering or making a phone call.

A requirement for our voice recognition application is to work on a PDA which

uses the PocketPC operating system. Also, because of the limited power resources for

PDAs, our application must not consume too much power. Further, because the PDA is

used for much more than controlling a television set, our application must work while in

the background of the operating system. While it is not required to work while the user is

watching a movie on the PDA or using some other processor intensive task, it should

work while a moderately processor intensive task is running. The application also must

be such that it will always run in the background. That is, the user need not always click

on the program to activate it. The user should have the option, though, to deactivate it

when it is not required. This is similar to the way wireless devices on a PDA operate;

they are on by default but the user can deactivate them when not needed. Also, the

Bluetooth card should operate in the same manner so as to conserve power.

For the set-top device, the requirement is that it must be efficient in its power

consumption. We have not tested a DSP, so we are not completely aware of its power

requirements. That said, we hope to have the set-top device consume power at a level

such that two AA batteries would suffice. This number will be revised when we see the

actual power usage by the IR transmitter, DSP, and Bluetooth chip; however this is the

power usage we are aiming for.

II.2.3.System ParametersThe functionality of the project basically remains true to the original goal, a

voice-activated remote control. This remote control will in essence have no line of sight

restriction witnessed in other remote controls, this is done via Bluetooth. The fidelity of


8/20

7

this is expected to be 100% accurate. We will also have module that converts Bluetooth

into infrared. This will allow compatibility with modern devices such as television sets.

The conversion from Bluetooth to infrared is expected to be 100% accurate as well

because this is a simple enough procedure.

Another feature is the recognition of the remote control of any device that

contains Bluetooth. This will enable the remote to automatically configure itself to any

nearby devices. This will eliminate the need for a user to program in every device.

The remote control will also have a voice-activated portion as well. To this

section of the project we will attach a 90% success reliability. Most voice-activated

software is not perfected enough for an almost perfect track record.

II.2.4.Design ConstraintsOur design basically has two alternatives. One alternative would be to use a PDA

as the receiving device while the other is to build a set-top device which consists of a

Bluetooth IC, microcontroller and an infrared transmitter. There are tradeoffs for each

alternative in terms of the amount of resources that will be utilized. For example the PDA

approach would take a shorter amount of time to build and implement while the set-top

device approach would prove to be more cost effective. The following paragraphs will go

over the constraints that we anticipate.

Since both alternatives use a PDA as a transmitter, some of the constraints which

stems from the transmitter are shared amongst the two alternatives. The first constraint

that we have is the interference of background noise with our voice-recognition module.

The voice-recognition module is expected to work when the TV is on which brings noise

to the environment. In order to overcome this problem, we had designed the system to

recognize a keyword before accepting commands. In our case, we have used the keyword


9/20

8

TV. To give a command, one would say TV followed by a command such as

Volume up. The other constraint would be to be having the voice-recognition module

readily available to accept command. This contradicts with conversation of the power if

the device was to be on at all times. One way that we have thought of would be keep the

device in extremely low power usage mode where although the device is on, it is not

using more energy than needed to waiting for commands to be given by the user. Another

way to solve this problem would be to always have the device sit in a charger.

By using the PDA alternative, two PDAs will be used in the system; one for the

transmitter which is responsible for the voice-recognition function and the transmission

of Bluetooth commands. The other would be used as a receiver which is responsible for

processing the packet sent via Bluetooth and then sending the appropriate command that

was intended to control the television via the infrared transmitter. The biggest concern for

this design is cost since a PDA would be too expensive to be used as a remote control.

However, we have two personal PDAs that we can do the project with and we are

planning to use this alternative as a prototype for our design. Nevertheless, the approach

has some of constraints that we are aware of and must be overcome. Besides cost being

an obvious constraint, placement of the receiver next to the TV would be another. With

the PDA, it would be difficult to mount the receiver onto the TV while the set-top device

would solve this problem.

With the set-top device alternative, one of the constraints that will be faced is the

amount of time we need to design and build it. The set-top device requires the research of

the suitable components on the market, designing a circuit board that will integrate all the

components together and building the circuit board. We fear that we might not have


10/20

9

enough time to get all of this done within the allotted time. Our assumption is that the

components that will be ordered will be delivered on time, if the vendors do not deliver

the components within a reasonable time frame it will certainly add to our burden of time

constraint. The other major constraint is the compatibility of components; we are

assuming that the components we obtain will work with each other which it should. But

many a time manufacturers produce products that are not conformed to standards. If we

are unfortunate, we might not be able to get the set-top device built due to this constraint.

One way we can overcome that is to look at several alternatives in terms of the

components. Another way would be to purchase (if possible) all the components from

one vendor to minimize the possibility of incompatibility.

II.3. System DesignII.3.1.Design Approach

The design approach is simple, yet structured. Our first goal was to simulate the

final prototype, in essence make a prototype for the prototype. The final project will

have a PDA taking the voice command on one end and sending it over via Bluetooth to

another end where it will be received by a DSP and converted to infrared via

microcontroller.

We intend to substitute a laptop computer for the PDA. This will be simple to

downscale. However, we also have to substitute the DSP with a laptop. In fact the laptop

will keep the function of the DSP, microcontroller and the infrared output device. Once

we get the system of two laptops connected via Bluetooth to correspond and change

channels we will downscale the components.

This downscaling of the components is the final design strategy. We will have a

PDA taking the command, which will have a built in Bluetooth transmitter and an


11/20

10

onboard microphone. The voice-recognition software will convert the voice into a

command that will be sent over to the receiver end via Bluetooth. This command will be

stripped from the Bluetooth and converted to infrared using a DSP, microcontroller, and

an infrared transmitter. The figure below illustrates the basic concept.

Figure 1:General configuration of system

II.3.2.Critical ComponentsThe general outline of our project is pictured below.

Figure 2:General outline of projectThe transmitter end will reside on a PDA, which will be the most expensive

component of our project. This cost will not be necessary to incur because we will be

using our personal PDAs in the prototype. The PDA we will be using is the Toshiba

e740, pictured below.


12/20

11

Figure 3:PDA to be usedBecause of the available Compact Flash slot in the PDA, we will be able to insert

a Bluetooth card. One example of such a card we may use is an IOGEAR Bluetooth

CompactFlash Card available at Amazon for approximately $60. The link to the device

is: http://www.amazon.com/exec/obidos/tg/detail/-/B00008KA6P/qid=1070735459/br=1-

13/ref=br_lf_e_13//104-5547436-0877507?v=glance&s=electronics&n=3525271.

Another component we will require is a voice recognition SDK that we can

incorporate into our program on the PDA. The program we have been considering is

from Sensory, Inc. and is available as a demo version. This program is user independent

and will run on a PDA using PocketPC, which our Toshiba model uses.

The Bluetooth chip we will purchase has not been fully determined yet. We plan

to purchase one that will have the Bluetooth protocol stack already built in because there

is no reason for us to redevelop a part which will not be the most important component of

our project.


13/20

12

For the Bluetooth to infrared converter part, we will use a DSP. One requirement

of the DSP is that it should already have a TCP stack built in so we will not have to

program it in ourselves. Again, it is not a very important part of the project, so we will

look for a chip which already has it incorporated because it will also avoid errors in our

programming. An example of a chip we will use is the Voyager TCP/IP v4/v6 by Elmic

Systems.

We have not investigated into the type of infrared transmitter we will require,

however we believe a generic infrared transmitter will suffice. This is because we plan to

implement much of the details of infrared transmission inside our DSP. The DSP will

take care of details such as the hold time for a 1 or a 0. Because the data transmitted

via Bluetooth will be the raw bits to send to the IR transmitter, there will not be much

processing required by the DSP.

II.3.3. Test ProceduresNeedless to say, thorough testing is the key to building a perfect system. In our

testing procedures, we will test not only for functionality and correctness but also system

performance to meet design objectives. We are doing preliminary testing every step of

the project which will be followed by more intensive testing later on. For the preliminary

testing step, we have tested the functionality of the Bluetooth transmission, voice-

recognition software and the software to convert a command to its hexadecimal code.

Once the prototype is up and running, we will be testing the system based on

functionality and performance. Some of the things we will be testing are whether it is

user independent, low power, high fidelity and processor utilization.

One of the features that will be incorporated in our voice-activated remote control

is user independency. Any user should be able use this device without having to first train


14/20

13

it. The way we plan to test this feature is to have testers of different gender, age, voice

pitch and accent to try the device.

Another aspect we have to test is its power usage. Obviously the less power it

consumes the better. With the device on and initially fully charged. We are planning to

test the device when it is being fully utilized, used regularly, used sparingly and not used

at all. We will record the amount of time the battery will last for each of those scenarios.

Based on the result, we will either be satisfied with the battery length or seek alternative

to improve on this aspect.

High Fidelity implies accuracy, a voice command should be given only once for it

to work. To test this part, we will once again have testers of different gender, age, voice

pitch and accent to give command to the device.

For processor utilization, we will obtain a free utility to be run on the PDA and

record the processor utilization history while the device is on. We will run the device

regularly, sparingly and not at all. We will then analyze the recorded log to see how

processor intensive our application is.

II.3.4. Anticipated RisksWhile conducting research and designing the project, we anticipate few major

design risks. One major risk that we might face, is to synchronize with the correct

Bluetooth device. When we demonstrate our project, it will have to synchronize with the

receiving Bluetooth device. If there is anyone within 10 meters with a Bluetooth cell

phone or PDA, our device will it pick up and try to synchronize. A workaround to that is

when the sending device finds a list of devices, it will have to check if there is a server

running on the other device. If we use the TCP approach, we can assign static IPs to our

device and specify it on the sending end.


15/20

14

For the first stage of the project we plan to do our project on our laptops. Then

we will port it over to the PDAs. Finally, we plan to create the set-top device and

eliminate the receiving PDA. Another anticipated risk is not finishing the set-top device.

This portion is very difficult because it runs at a very low level. If this happens then we

cannot finish our project. In this situation, we plan to use our high-level prototypes. We

will use two laptops or two PDAs to demo our concept of a Voice Activated Remote

Control.

II.4. Financial BudgetThe average price of a voice activated remote control in the market is about $70. The

estimated retail cost of our voice activated remote control is projected to be

approximately $60. The breakdown of the costs is shown below.

Table A: Cost of PartsName of Part Cost DescriptionMicrophone $10 The microphone will used to input the voice commands.

Microphones are usually built into PDAs.

Speaker $3 The speaker is necessary to output any interactivecommand to the user, also usually built into PDAs.

Microprocessor $20 This will be used to convert the BluetoothInfrared Sender $5 This piece will be used to send infrared signals to the

controlled device.

Bluetooth Modules(2)

$60 We will need two Bluetooth modules, one to send andanother to receive.

Bluetooth Chip $8 Final chip on the reciever

Total Cost of Parts: $166

The cost calculated above is the approximate material cost of building the voice activated

control. It does not include the cost of labor. The estimated amount of time invested into

researching, building and testing the remote control is 231.

The group is composed of four members. Each member is expected to put in an

equal amount of time into the project. Each member put in approximately 57.75 man


16/20

15

hours into developing this product, costing about $1740. Assuming that each engineer is

paid approximately $30 per hour, the total labor cost for the project is $6930.

Research has taken about 96 hours or about 2880 dollars. The testing phase is

approximately 16 hours long, costing about 480 dollars. The group is expected to spend

61 hours on documentation.

Table B: Cost of ProjectTask Total Man Hours CostResearch 96 $2880

Building and Development 58 $1740

Testing Phase 16 $480

Documentation 61 $1830Cost of Parts -- $178

Final Cost of Senior Design Project 231 $7108

In a real world engineering project there are more costs associated to the final project.

The cost of the support staff, rent, utilities, overhead, profits, traveling and

accommodation costs are just a few examples of what needs to be taken into account.


17/20

16

II.5. Project Schedule

Figure 4:Breakdown of Tasks


18/20

17

Figure 5:Gantt Chart for Project

III. SummaryThe aim of this project is to create a device and software which will allow a user

to simply speak the command they wish performed and the device the command is aimed

at will perform it. That is, the user will speak into our program, whether in a PDA or

another device, and the command will be transferred to a set-top device which will send

the command to the television, for example. Essentially, our device and software will

save people time and effort when doing a very mundane task, whether it be changing the

channel, the volume, or when pausing or forwarding a tape. While this may seem like a

novelty product, it can be very helpful for those who are constantly misplacing remote

controls or are too tired after coming home from a long day of work, for example. In the


19/20

18

future, our set-top device will be able to communicate with other Bluetooth devices that

will be around the house.

The system is meant to tie in various technologies and eliminate the line of sight

restriction. It will be developed using a test method of two laptops before moving on to

the final design which will consist of a PDA, a DSP, a microcontroller, and an infrared

transmitter device.


20/20

19

IV. Referenceshttp://www.bluetooth.com

http://www.innotechsystems.com/voicefire.htm

http://www.itsc.state.md.us/ITSC/delvrbles/C-5-1/C_5%20Speech%20Recognition%20in%20the%20SESA%20Call%20Center%20-%20White%20Paper.pdf

http://www.niad.sussex.ac.uk/ezine_issue.cfm?eZineID=5

http://www.sensoryinc.com/html/products/vetoolkit.html

http://www.techextreme.com/perl/story/15196.html

http://www.troygroup.com/wireless/products/wireless/docs/TROY%20TI%20DSP%20Bluetooth.pdf

http://www.voicemethods.com/

http://www.lirc.org

http://focus.ti.com/catalog/docs/appsoftwarebyapplication.tsp?applicationId=2&documentTypeId=1&templateId=5681&navigationId=9426

http://focus.ti.com/catalog/docs/thirdpartysoftwarefolder.tsp?softwareId=4070

http://winlirc.sourceforge.net/technicaldetails.html

Tutorials:

Bluetoothhttp://www.tutorgig.com/searchtgig.jsp?query=bluetooth

Infraredhttp://www.tutorgig.com/showurls.jsp?query=infrared

Remote Control Boardhttp://www.rentron.com/remote_control/remote1.htm

Remote Control Schematicshttp://www.rentron.com/IR-TRX.htm

Fall_Final_Report VOICE2.pdf

Documents

Transcript of Fall_Final_Report VOICE2.pdf