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

MEMBERS

• Ryan Frishberg - rfrishbe@andrew.cmu.edu
• Inbae Lee - inbael@andrew.cmu.edu
• Paul Thurlow - pthurlow@andrew.cmu.edu
• Siva Srinivasan - sivas@andrew.cmu.edu

PROJECT CONCEPT

Develop a glove that can be used as a controller for a game system such as the Nintendo Wii. Primarily using accelerometers, the glove will sense the motions that its user makes to allow for a more realistic interaction and gaming experience. The project is aiming for a successful demonstration of the concept and an implementation that could drive the future of gaming.

MOTIVATION

Most game controller systems involve the use of joysticks or some basic motion detecting capability to enhance gaming experience. Instead of holding a controller and pressing the buttons for input, users can wear the glove and perform comfortable, natural motions to provide more realistical input.

COMPETITIVE ANALYSIS

• A commercial gaming system with a remote control-like controller with motion sensors
• Requires a hand-held controller with a wrist band to strap on in order to prevent accidents

• Glove system that translates gestures into computer interpreted symbols
• Academic project that is not incorporated into gaming systems

TECHNICAL SPECIFICATIONS

• 3D Accelerometer: Analog Devices - ADXL330 + Breakout board (same as in Wii)
• Mote: moteiv - Tmote Sky
• Touch Sensor: Trossen Robotics - Force Sensing Resistor Kit
• Flex Sensor (with board): Electrotap - T303B
• Flex Sensor: Jameco Electronics - Odeg:1OK

• Java GUI to display accelerometer data
• TinyOS/NesC to program Telos Motes

• Zigbee for wireless communication between Telos Motes
• Bluetooth to connect to the Wii

• Extract accelerometer data and interpret it into movements
• Communicately wirelessly from Telos Motes to the laptop station
• Connect to Wii via Bluetooth and act as a controlling device for the Wii
• Detect finger movements/positioning with push buttons and flex sensors

Timing: Read and interpret data in under 50 ms

Portability: Glove and all gear should weigh under 2 lbs

Reliability: Glove and the embedded device should stay together under extreme Wii use

ARCHITECTURE

USE CASES (INTERACTION DIAGRAMS)

SYSTEM STATES & TRANSITIONS

RISKS & MITIGATION

• Data loss during communication: either disregard or extrapolate. Real-time performance and responsiveness matters over accuracy
• Failure to produce sufficient real-time performance and responsiveness:optimize coding and minimize functionality to produce the best work-around

• Failure to directly communicate with Wii: proceed with using the laptop station as the proxy for the Wii
• Failure to incorporate the flex sensor: substitute with the sensor with pre-made breakout board attached to it
• Sensor failure due to external causes: re-design the hardware system to protect sensors, or limit users from operating under extreme conditions

IMPLEMENTATION DETAILS

TEST CASES

• Fault-free
• Purpose: Ensure proper functioning of the system when powered on/off
• Method: Exhaustive user testing

• Fault-free
• Purpose: Test the basic functionality of the system
• Method: exhaustive user testing

• Fault-free
• Purpose: Determine the granularity of the control the system provides to users
• Method: Calculate the volume of messages sent per unit time

Wireless Communication Lag

• Fault-free
• Purpose: Determine the responsiveness of the control the system provides to users
• Method: Use round-trip delivery from a mote to the laptop station as lag estimate

• Fault-free
• Purpose: Ensure additional functionalities of the system working properly
• Method: Exhaustive user testing (after sensors mounted / incorporated into the system)

EXPERIMENTAL EVALUATION

• Hypothesis:
  To prove that the system lag time is under 20ms
• Test setup:
  1 telos mote + accelerometer ("Sender"), 1 telos mote + laptop + Java ("Receiver")
• Metrics:
  Round-trip time = Sender-to-Receiver-to-Sender time
  lag time ~= round-trip time / 2
• Workload:
  
• Parameters:
  Distance between motes, size of messages
• Test run:
  Keep size of messages constant (approx. equal to actual data message size)
  Vary distance (1 ft ~ 10 ft)
• Experiment:
  Number of test runs: 50
  Average round-trip time: 8ms
  Average delay: 4ms

• Hypothesis:
  To prove that the system throughput can handle regular data size
• Test setup:
  1 telos mote + accelerometer ("Sender"), 1 telos mote + laptop + Java ("Receiver")
• Metrics:
  # of messages / second
• Workload:
  
• Parameters:
  
• Test run:
  
• Experiment:
  Number of runs: 100
  Average message per sec: 250 msg/s

LESSONS LEARNED

• Learning the stages and implementations of product design/development was challenging and fun.
• Engineering is like conducting: making sure all parts work wonderfully together.
• Working with outside groups with differnt interests is perhaps the most challenging part of teamwork.

FUN STUFF

Professional Wii Bowling forms of Siva and Ryan

REFERENCES

• Project Proposal and Requirements, Team Project Presentation, January 31, 2007
• Design & Architecture, Team Project Presentation, February 14, 2007
• Mid-semester Project Status, Team Project Presentation, February 28, 2007
• Test Plan & Experimental Validation Team Project Presentation, March 28, 2007
• What's Done, What's Left Team Project Presentation, April 11, 2007
• Project Poster, May 4, 2007