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 didnt 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 Dijkstras 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 Dijkstras 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 lt kn 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 Dijkstras algorithm
• Before
• Relaxation step takes O(n) time
• for(i 0i lt Number_of_Nodesi)
• 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
• Dijkstras algorithm runs in O(nk) 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 (Dijkstras 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/3n)

47
(No Transcript)
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