• Concept
• Motivation
• Competition
• Tech Specs
• Requirements
• Architecture
• Use Cases
• System States
• Error Handling
• Implementation
• Test Cases
• Evaluation
• Lessons
• Fun Stuff
• References
• 18-549 Home

MEMBERS

• Dan Granahan [dgranaha at andrew dot cmu dot edu]
• Shen Li, [shenl at andrew dot cmu dot edu]
• Saagar Patel, [saagarp at andrew dot cmu dot edu]
• Rob Williams, [rwilliams at cmu dot edu]

PROJECT CONCEPT

Build a system that is capable of streaming video wirelessly to a handheld device in real-time. This system will serve as the basic framework upon which video sources can be added (e.g. live television, home surveillance, personal media).

MOTIVATION

Our project aims to integrate several key features that are not present in existing devices:

• Compress video as needed before transmitting it to the handheld device. Compression must be effective enough to allow uninterrupted viewing on the device.
• Provide a means by which the platform can be expanded. The software running on the desktop needs to be architected such that adding additional video sources is straightforward.
• Software must provide the ability for the user to select video inputs from the handheld device
• The software must provide a user-configurable priority list. The video feed with the highest priority will be displayed if the feed becomes active.
• The handheld can connect to the video server from any wireless access point

COMPETITIVE ANALYSIS

• Basic Home Security - Our project includes all functionality of traditional home security setups with the added convenience of providing notifications and monitoring in a handheld device.
• Slingbox - Our project will be able to relay stored data -- as Slingbox does -- as well as live data feeds (e.g. from television), which Slingbox does not.
• Baby Monitors - Traditional baby monitors provide only audio feeds. Those that also support video feeds do not provide the convenience of mobility when monitoring children.

TECHNICAL SPECIFICATIONS

• Nokia N800 or N770 Tablet
• Standard PC for information processing
  • TV Tuner Card
  • Network Connection
• Video Camera(s)
• Moteiv Tmotes

• Custom viewing and control software
• Existing camera support software and tuner drivers
• Custom software for localization and tracking
• MPEG encoding and decoding software

• 802.11 b/g for handheld device connectivity
• 802.15 for Tmote support
• 802.11 or proprietary wireless connecivity for cameras

REQUIREMENTS

Functional

• Compress video as needed before transmitting it to the handheld device. Compression must be effective enough to allow uninterrupted viewing on the device.
• Provide a means by which the platform can be expanded. The software running on the desktop needs to be architected such that adding additional video sources is straightforward.
• Software must provide the ability for the user to select video inputs from the handheld device.
• The software must provide a user-configurable priority list. The video feed with the highest priority will be displayed if the feed becomes active.
• The handheld can connect to the video server from any wireless access point.

Timing

• Live feeds are delayed no more than 5 seconds by the conversion and transmission processes.

Reliability

• The device attempts to reestablish connections following outages.

ARCHITECTURE

See attached.

USE CASES (INTERACTION DIAGRAMS)

See attached.

SYSTEM STATES & TRANSITIONS

See attached.

RISKS and RISK MITIGATION

CMU Network Usage

• Use separate wireless router or ad-hoc network

Latency

• Reduce video and audio quality

Devleoper Environment

• Alternate IDE

Algorithm

• Look up existing algorithms

Desktop Compatibilty

• Use different desktops

Memory

• Reduce quality of image and audio

Protocols

• Explore different protocols, i.e. Bluetooth, 802.11b/g

ERROR HANDLING

To be completed.

IMPLEMENTATION DETAILS

To be completed.

TEST CASES

• Device Boot
  • Device launches application, attempts to contact server.
  • Server waits for contact from device, spawns service thread.
• Device Shutdown
  • Device sends termination message to server, kills processes.
  • Server kills service thread, waits for new clients.
• User Toggles Input Source
  • Device sends request to server.
  • Server feeds new source into stream.
• User Pauses Stream
  • Device sends request to server.
  • Server pauses stream (buffering new data).
• Device / Server Side Failure
  • If server is widowed, kill service thread, wait for new clients.
  • If client is widowed, display error, attempt to reconnect.

EXPERIMENTAL EVALUATION

• Measured Durations:
  • Source toggle to display
  • Initial contact to display
  • Failure or brief outage to recovery
• Why They Matter:
  • Some streams are relatively time-sensitive (baby-monitor)
  • Some streams are extremely time-sensitive ("24")
  • Most users are impatient
• How They'll Get Measured:
  • Run "source-toggle" script on the device to trigger N source swaps, measure total time, divide by N.
  • Create and tear-down connection from device to server, measure time from intiial contact to feed display in each (then average).
  • Simulate failures from either end by intiionally dropping messages, closing connections, and killing streams.

LESSONS LEARNED

To be completed.

FUN STUFF

To be completed.

REFERENCES

• Project Proposal and Requirements, Team Project Presentation, January 31, 2007
• Design & Architecture, Team Project Presentation, February 16, 2007
• Mid-semester Project Status, Team Project Presentation, Date TBD
• Test Plan & Experimental ValidationTeam Project Presentation, March 28, 2007
• What's Done, What's LeftTeam Project Presentation, April 11, 2007
• Final Project Presentation, Team Project Presentation, Date TBD
• Project Poster, May 4, 2007