Spring 2005 Design Review

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

11. 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/sec2 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 n2 space. BIG disadvantage • Lookup takes 1 or 2 indirections

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

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 Interactive Campus Map Brian Eng Matteo Mannino

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 Node Coordinates Neighbors 0 123,456 1,3,4 Description 1 213,522 0,2,3 Description 2 211,222 1 Description 3 887,818 0,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