200 likes | 340 Views
Chatter Box. Daniel Dunham Nick Noack Mike Nelson. Overview. Project description Usage scenario Project components Important issues Division of labor Schedule and milestones. Project Concept. Interfaces to the personal server ‘Standard’ Visual display with keyboard/keypad
E N D
Chatter Box Daniel Dunham Nick Noack Mike Nelson
Overview • Project description • Usage scenario • Project components • Important issues • Division of labor • Schedule and milestones
Project Concept • Interfaces to the personal server • ‘Standard’ • Visual display with keyboard/keypad • Alternative • Audio based I/O via cell phone
Why Use Audio? • Speech is an easy, natural way for people to receive and provide input • Cell phones are commonplace • Cell phones already being built with Bluetooth capability
Project Goals • Simulate a cell phone for audio recording and transmission • Develop the personal server audio interface • Develop an application to exhibit the audio capabilities
Cell Phone Simulator • Ideal project would use a real cell phone • Cell phone software is proprietary • Hence, prototype using a tablet with microphone, speakers, number pad
Audio Development Audio support will be developed incrementally Along the way some basic useful applications are realized
Audio: First Step • Transmission to and storage of audio data on the personal server • Application: memo device • User records notes (speaking into phone) • At a later time user listens to notes – meetings, thoughts, etc
Audio: Second Step • Text-to-speech support • Important aspect of an audio interface • Application: book reader • Take a book in text format and read to the user with a synthesized voice
Audio: Final Step • Text-to-speech is one direction of the I/O • Other direction: speech-to-text • More difficult than text-to-speech • Settle initially for speech-command recognition
Application for the Audio • Numerous potential applications, as seen already • Our personal favorite: provide people with a tool to view dining options
Restaurant Selector • Restaurants broadcast menus over short-range radio link • Personal server receives menus, adding them to a database of menus • If the person is hungry, they access their personal server (via PDA, kiosk, phone, etc)
A Sea of Options • Application helps to narrow them down
Restaurant Selector Features • User can input dietary preferences/restrictions to narrow down the options they will be shown • On a diet? • Specify caloric limit, cholesterol limit, etc • Restaurant selector only shows you what you can (or should) eat • Remove temptations before you see them
Restaurant Selector Features • User specifies with spoken commands what he wants • “Find Italian please” • “Price limit seven dollars por favor” • Speech recognition matches request to a set of commands and displays restaurants meeting the specifications • May require training
Restaurant Selector Features • Add-on: GPS • Allows added search constraint based on distance of user from restaurant • If we get bored, add some navigational assistance
Usage Scenario • Joe the hip, happening college student • Owns a personal server (naturally) • Goes to the Ave looking for food • Dials up his personal server • Brings up a list of Thai restaurants • Joe’s allergic to peanuts • His personal server knows this • Later in Sieg, Joe’s friends are hungry too
Important Issues • Text-to-speech and speech-to-text still an untested black box • Restaurant search options: how much do we allow/require from restaurants • Example: Will restaurants have precise nutritional information? • Key: Allow easy change
Project Summary • Audio interface • Text-to-speech, command recognition • Restaurant selector • Dietary preference specification • Constrained searching • Project components • Hardware, audio, restaurant app
Project Summary • Major issues • Speech-to-text • Restaurant filtering specifics • Division of labor • Audio: primarily Nick • Restaurant filtering app: primarily Mike • Hardware: primarily Daniel