1 / 5

18-549 Team 1: Reflex Project Presentation

This presentation discusses the testing and evaluation process for the Reflex glove, a gaming device that allows users to play games using hand movements. The presentation covers performance tests, testing process, and future challenges.

douglasa
Download Presentation

18-549 Team 1: Reflex Project Presentation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 18-549 Team 1: ReflexProject Presentation Testing and Evaluation http://www.ece.cmu.edu/~ece549/spring07/team1/index.html Inbae Lee (inbaelee@cmu.edu), Paul Thurlow (pthurlow@andrew.cmu.edu), Ryan Frishberg (frish@cmu.edu), Siva Srinivasan (siva@cmu.edu)

  2. Test Cases • Reflex: glove that allows users to play games • Unable to get Wii devkit until May • Can control the mouse using Java • Test Cases • Performance: response in 20 ms • Respond to each axis movement (x, y, z) • Test flex and force sensors • Check power on/off stages

  3. Performance Tests • Metric is real-time response: 20 ms • The amount of time before humans notice lag • Plan • Grab current time and send test message • Round trip test message to all parts • At end read current time and compare to time before sending the test message

  4. Testing Process • #define for performance testing • Physical movement by user for axial testing • One user, but can change tester to see if works for different people • Test automation difficult, but not too many parts to test

  5. Looking Ahead • Getting real-time performance data is difficult • Exception testing is risky (delicate equipment) • Failure recovery is dependent on code not written by us • Test automation difficult, but not too many parts to test • Ambition is good, Reality is better

More Related