1. Spring 2005 Design Review Advisors: Prof. David Ebert and Kirk Riley TA: Steve Gunawan

2. Agenda  Adjustable Bookshelf (ABS)  GPS Device for the Visually Impaired (GPS- DVI)  Interactive Campus Map (ICM)  Discussions to follow each project presentation

3. ODOS - Adjustable Book Shelf Manish Handa

4. Presentation Outline  Problem Definition  Concept Generation  Concept Evaluation  Current Progress  Modifications  Expected Semester Outcome  Overall Project Plan

5. The Dorm Desk and Bookshelf

6. Problem Definition  Bookshelf unit in dorm rooms do not follow the guidelines set by ADA (Americans with Disabilities Act).  Height range of 9” to 48”: Lowest point of current shelf is approximately 50”.  Front reach maximum of 25”: The current shelf unit is located at exactly 25”.  Goal: To design a shelf unit that is within the guidelines set by ADA, within the limited space available in a dorm room. *User must not insert more than 5 lb of force to access the bookshelf.

7. Concepts Generated  Sliding Down Bookshelf  Bookshelf will be placed in existing bookshelf in dorm, lowered and raised onto desk  Side of Desk – Low  Bookshelf placed underneath desk, moved in and out  Side of Desk – High  Bookshelf placed on side of desk. Above desk such that there is no need for it to move  Swing Shelf  Placed underneath desk, swings towards user.

8. Concept Evaluation  Evaluation was done using decision matrix  Evaluated each concept against customer requirements such as Reachability, Ease of Access, Cost.  Compared each concept with the existing bookshelf, and the prototype.  Side of Desk – High, was chosen for its reachability and use of space.

9. Current Progress  Dimensions of shelf unit and platform complete  Force analysis on the prototype complete. Result modification needed on prototype.  Preparing design modification.  Designing support system.  Designing moving mechanism and switch

10. Current Progress

12. Modifications  The prototype had only a single shelf, but the new prototype will have three shelves, which would distribute the weight of the books and hence prevent failure.  The prototype didn’t have any support system, the new one will have support.  The prototype was not constructed as to dimensions, reconstruction will be enforced.

13. Force Analysis  Stress Analysis  Plywood structure is strong enough for the bookshelf  Weight of motor mechanism to be determined  Acceleration of shelf  0.13 ft/sec 2 for movement in 5 seconds  This number determines force needed by the motor.

14. Expected Semester Outcome  Complete Design  Finish designing moving mechanism  Choose materials, parts  Complete Prototype  Complete as designed  Test

15. Overall Project Plan  Prototype completed this semester  Start testing prototype, continue testing in Fall  Delivery in December, 2005

16. Discussion

17. EPICS-ODOS: GPS-DVI Jay Gengelbach Rohit Vankipuram Jonathan Timura

18. Overview  Introduction  Fault tolerance – improving usability by recovering from common mistakes  Forward mobility – make code maintenance simpler for the future  Scalability – improve asymptotic performance  Data Formats – allow for extensibility

19. Introduction  GPS-DVI: Global Positioning System Device for the Visually Impaired  Goal: To create a device that blind students can use to find their way around on campus

20. Introduction (cont.)  Current Device:  HP iPAQ PDA with CF GPS receiver  Current Data:  22 nodes around the engineering mall  Implementation:  Map stored as a weighted graph  Paths calculated using Dijkstra’s shortest path algorithm

21. Fault Tolerance  Before:  Power-cycling would cause failure  Running the program twice (accidental double-click) caused failure  Now:  Device recalibrates after a power cycle  Only one instance of program can run (token file)  Future:  More stable way to detect program instances

22. Forward Mobility  Before:  Power PC 2002  Now:  Power PC 2003  Change is easily removable for backwards compatibility  Future:  Future versions will be more similar to PPC 2003 than 2002, so further upgrades will be simpler

23. Forward Mobility (cont.)  Before:  Few files (newgui.cpp, newguiDialog.cpp)  Unclear what tasks each file performs  Generally poor comments: /* Implements Dijkstra’s Algorithm */ void DoDijkstra(…)

24. Forward Mobility (cont.)  Now:  Many files (Dijkstra.cpp, path.cpp, AdjacencyVector.cpp)  Files perform a few specific tasks and are well- documented: /* Path.cpp: * This file contains various functions required to perform path calculation, etc. * The data in this file is specific to our implementation. This file employs * Dijkstra.cpp, which contains generalized pathfinding code. * Jay Gengelbach - February 27, 2005 */

25. Forward Mobility (cont.)  Conclusions:  Code sharing will be simpler with logically separate files  Finding the code that performs X will be easier due to specificity of each file

26. Scalability  Before:  n x n Adjacency Matrix  Takes n 2 space. BIG disadvantage  Lookup takes 1 or 2 indirections 123…n 13 …1 23 … 3 …2 ………… … n1 2…

27. Scalability (cont.)  Now:  Vector of linked lists  Space < k*n where k is the maximum vertex degree (4)  Maximum indirections = k 123…n 21n1 3321 n 1 3 2

28. Scalability (cont.) Analysis of Dijkstra’s algorithm:  Before:  Relaxation step takes O(n) time: for(i = 0;i < Number_of_Nodes;i++) if(distance(currentNode,i) != -1) relax(currentNode, i);

29. Scalability (cont.)  Now:  Relaxation step takes O(k) time: currentNode.reset(); while(currentNode.hasMore()) relax(currentNode, currentNode.next());  Closest node kept in sorted list, so next iteration can be determined in constant time  Dijkstra’s algorithm runs in O(n*k) time – essentially linear

30. Scalability (cont.)  Before:  Adjacency matrix recalculated every time a path is requested  Now:  Calculate adjacency lists at program launch  Prevents unnecessary file I/O

31. Data Formats  Before:  Node database file only allows latitude and longitude to be specified  Nodes are specified only by number  Adjacency matrix format assumes no node will ever be adjacent to 5 or more others  A node that borders more will require the format to change and every line to be altered  Adjacency matrix only stores edge weights

32. Data Formats (cont.)  Future:  Adjacency matrix stores only one edge per line, and additional data/metadata can be appended  Node database supports storing building names and other data alongside GPS data  File becomes a lot more human-readable  Both formats support addition of new flags without changing unaffected lines

33. Summary  Updates focus on extensibility  Code and data easier to maintain and update  More scalable code allows campus map to be expanded with minimal impact

34. Discussion

35. ICM Brian Eng Matteo Mannino Interactive Campus Map

36. Overview  Introduction  Semester Goals  ICM Overview  Node Database Software

37. Interactive Campus Map  Objective: To help students with physical disabilities locate the best accessible path between campus locations by drawing a map

38. Semester Goals  Prepare kiosk for use and place in MSEE  Collect user feedback  Make changes based on feedback  Deliver project  Create node database software

39. How does ICM work?  User gives start/end information on website  Calculate shortest path  Draw map  Encode image  Display map

40. Breakdown of Components  Node Database  Path Finding Algorithm (Dijkstra’s Algorithm)  File I/O, Image Manipulation  Web Interface  Today, we will only be discussing aspects of the node database

41. Nodes on the Map

42. Node Database  Uses pseudo GPS coordinates  Scaled pixel coordinates  Ability to swap map images easily  This assumes maps are to scale  Currently around 300 nodes in database

43. Database Example NodeCoordinatesNeighbors 0123,4561,3,4 Description 1213,5220,2,3 Description 2211,2221 Description 3887,8180,1 Description

44. Node Database Software  Justification for software  Several bugs in database from past semesters  Tracking down which node is faulty is many times difficult and very time consuming  The only nodes with meaningful descriptions are door nodes  Debugging gets harder as database grows with expanding campus

45. Node Database Software  Node software allows those who are maintaining ICM to:  easily update the map  add and delete nodes  debug paths  Interface is user-friendly and easy to learn  No technical background needed to operate  Point and click operation  No need to follow confusing input file format rules

46. Node Database Software  Data Structures  Quadtree - allows for point and click operation on map  Problem: user clicks on a node to modify its information  Solution: use a quadtree and descend it to determine if the pixel the user clicked on occupies a spatial partition, and if so, return which node it is  Advantage of trees: all essential operations are simple tree traversal or descent  Our implementation  Worst case number of traversals: O(lg(n)/2)  Worst case time complexity: O(n)  Worst case memory complexity: O(4/3*n)

48. Node Database Software  Data structures (cont.)  Linked list – allows for loading of existing database and output to text file ordered by node index  Easy to insert and delete data  Search time complexity: O(n)

49. Kiosk  Wheelchair accessible  To be placed in MSEE Atrium  Waiting on monitor support system

50. This Semester  Prepare kiosk for use and place in MSEE  Monitor support system to be completed by this weekend at the very latest  Collect user feedback  Prof. Jameison acting as Principal Investigator  Online certification completed  User feedback survey completed  Exemption form submitted to Purdue IRB  Waiting for kiosk to be placed

51. This Semester  Make changes based on feedback  Will occur once user feedback survey is administered  Deliver project  Delivery will occur immediately following installation of kiosk modifications  Create node database software  Basic functionality: load existing database, add nodes  Clean and easy to use GUI

52. Continuity  Delivery of ICM planned by week 12  Members of ODOS will maintain software  Adequate documentation from should problems arise  Node database software will allow for painless database debugging

53. Discussion