1. THE FUTURE OF ROCK CLIMBING SmartWall 9/8/2009

2. Team Members Anil Damle Matanya Horowitz Kirk Liu Mark Vankempen Steve Wilson 9/8/2009

3. Presentation Outline Problem  Market  Solution Implementation  Handhold  Controller  Computer Logistics  Schedule 9/8/2009 Mark

4. Problem - Market Popularity of rock climbing is exploding  Indoor gyms face limited resources  Changing routes is difficult and time consuming  How frequently should routes be changed?  How many beginner vs. advanced routes?  Market is segmented Weekend warriors vs. Hard-core vs. Beginners  Personal rock climbing solutions haven’t been established  Gauging route difficulty is problematic No solution addresses needs of all these groups 9/8/2009 Mark

5. Problem - Solution SmartWall  Use modern technology on the antiquated rockwall Hardware  Output  Light-up handholds  Dynamic route creation  Input  Pressure sensors  User-programmable routes  User specific memory 9/8/2009 Mark

6. Problem - Solution Software  Data logging  Offline judging  Analysis of ascent  Real time scoring possible  Integration with camera data  Interpolation and calculation of climbing technique  Replay possible  Tutorial  Compare to Pro’s  Path Planning  Use historical data  User preferences  Dynamic difficulty adjustment 9/8/2009 Mark

7. System Overview Host Computer Controller Handhold Flash DriveUser Input 9/8/2009 Mark

8. Implementation - Handhold Utilize the MSP430 microprocessor and RF unit Controller will communicate bidirectionally via sub 1-Ghz frequencies to a host controller LED’s used to light up handholds as output Sensors used to detect input PCB must be small enough to fit inside a handhold 9/8/2009 Mark

9. Implementation - Handhold Handholds will be fabricated or bought  Modeling Clay / Polyurethane  Bondo Fiberglass Resin  Capacitive Polymers Fabrication allows convenient placement of:  Development boards  Pressure sensors  Anything else Handholds will be affixed to a custom built wall 9/8/2009 Mark

10. How much power do we need to run the wall? LEDs, MicrocontrollerXbee Antenna 9/8/2009 Kirk Handhold Power Supply

11. Power Requirements 9/8/2009 Kirk Miniature LEDs (1 mA to above 20 mA) MSP430  sleep mode ~ <1uA,  Active ~ 200uA Wireless  1 mW  Wake from sleep in 15 msec

12. Battery Solution Polymer Lithium Ion Batteries - 2000mAhEach cells outputs a nominal 3.7V at 2000mAh! 9/8/2009 Kirk

13. The output current ranges from 500mA to 1.3A. Lithium Ion, Lithium Polymer Charger, 1.3A - Wall Plug In Cell count: 1-7 cells Handhold Charging 9/8/2009 Kirk

14. Power Supply Handhold Power  4 Lithium Ion Batteries per hold  Wall power of handholds for debugging  Keep components in low power as much as possible  Rechargeable on wall, or by removing batteries  Aim for >1 month between charges Controller  Wall Powered 9/8/2009 Kirk

15. Implementation - Controller Microcontroller (MSP430, etc.) Antenna Zigbee Interface USB Host LCD DisplayNumeric Keypad USB Storage Host Computer 9/8/2009 Matanya Camera

16. Controller Software Flow Diagram Initialization Acquire camera Broadcast wake- up message Receive handhold identification Capture photos of handholds Correlate handhold location-id Standby User detected Load profile Create route Broadcast handhold lighting data Interaction Receive handhold/video data packet Log packet Detect end of climb 9/8/2009 Matanya

17. Implementation – Handhold Controller Communication Handhold communicates through controller  No handhold-handhold communication  Broadcast pressure data  Receive initialization, lighting data Hardware – Zigbee  Low power mesh networking XBee 1mW Chip Antenna  Sparkfun supplied  $20.66  Serial interface 9/8/2009 Matanya

18. XBee Antenna Well established Protocol  Constructs low-speed ad-hoc network All nodes are End-Nodes.  Beacon-enabled network  Handholds can sleep Periodic, less frequent waking for input from controller More frequent transmission of sensor data  Controller remains awake  Allows for data to be both sent and received  Arbitrary number of nodes 9/8/2009 Matanya

19. Implementation – Handhold Controller Protocol Communication protocol required  Must be scalable over arbitrary number of nodes Asynchronous packet broadcasting  Node -> Controller  Unique identifier  Pressure data  Current status  Controller -> Node  Destination node ID  Desired status (sleep? Polling sensor? Broadcast frequency? Light or error on sense?)  Desired lighting mode 9/8/2009 Matanya

20. Implementation – Controller Computer Protocol Controller -> Computer  Sequential, timed data logging  Snapshot of handhold status Computer -> Controller  Initialization step containing status for each handhold  Provides identification for handholds between controller and computer It is the controller’s responsibility to translate to the actual ID’s of each handhold Sequential lighting up of handholds so computer can provide information for correlation between handhold and ID  Asynchronous update packets  Only communicates changes 9/8/2009 Anil

21. USB Controller interface - Already existent solution  28 Pin PIC Development Board with USB  Sparkfun  $30.95 Stage 1  Initialization information received from computer  Input is received only during initialization  Data is written to computer Stage 2  Computer is replaced with USB Stick  Initialization data is stored  Data, in same format, written to USB stick 9/8/2009 Anil

22. Implementation - Computer Puts the Smart in SmartWall  Route planning algorithm  Handhold type, reach, route length, etc.  New route every time  Video input  Analysis of stance  Correlation with pressure data  Climber improvement  Comparison of climbing technique with ‘Professionals’  Scoring  No longer simple ‘can or can’t do’ or time-based  Possible to gauge pressure, finesse, time on holds  More elaborate competitions possible  Tracking  User profiles  Progress 9/8/2009 Anil

23. Implementation - Computer Initialization Climbing modeInput mode Recognize user Control Hold lighting Adapt Difficulty Process Video Process Flash Drive Display Performance Create Routes 9/8/2009 Anil

24. Route Planning Based on Switching Time Optimization research  Trajectory is integrated over rock wall instead of time Each handhold presents a switch and changes the mode of the system, i.e. the climber By evaluating the effects of taking each hold, we can find the path that the climber would take We can then optimize the path according to input parameters  Reach length, route length, difficulty, distance between centers of mass and contact points  Parameters are input as a cost function  Requires a set of handholds to use. These can be picked by taking a straight line up the wall and picking the handholds ‘nearby.’ Solve with algorithm in (3) 9/8/2009 Anil

25. Video input Use to initialize hold locations  Automatically detect holds for route creation algorithms Analyze climber movement to rate climb  Develop an algorithm for rating climbs  Superimpose climb over recorded professional climber  Determine if a climber is stuck and adapt difficulty  Possibly show/determine next move for a climber 9/8/2009 Anil

26. Budget ItemEstimated Cost Wall200 Physical Handholds100 Host PCOwn Handhold Components (each)~100 Microcontroller / Wireless10 LED’s4 Pressure Sensors40 Batteries40 Charger20 Controller~200 Microcontroller / Wireless20 USB module / RFID40 PCB30 Camera50 Wall Plugs50 Total (10 Handholds)~1500 9/8/2009 Steve

27. Risks Insufficient battery life  Allow for wall power Limited sensor placement options  Functionality limited to contact detection Wireless  Wires Writing to USB Camera data flow  Connect camera to computer Insufficient # of handholds given current budget  Mix in dumb handholds 9/8/2009 Steve

28. Milestone - CDR Completed handhold prototype  PCB Layout  Physical Design  Sensor Placement Completed Wall  With non- smart handholds installed Wireless protocol Completed Controller PCB layout complete 9/8/2009 Steve

29. Milestone #1 Controller talking to multiple handholds Initialization Sequence  Handhold placement analysis Light up handholds for routes Preliminary algorithm results  Video analysis  Route creation 9/8/2009 Steve

30. Milestone #2 Data logging to USB drive Algorithms complete and tested Preliminary user interface  Ability to view data Basic functionality completed 9/8/2009 Steve

31. Logistics - Schedule 9/8/2009 Steve

32. Individual Tasks Matanya Mark Steve Kirk Anil Route Planning Video Processing Handhold construction Controller Design & PCB Power Design & Optimization MSP430 Programming Handhold Wireless Interface User Programmable Interface User Recognition Battery Charging Wireless Protocol Wall Construction Controller logging & input 9/8/2009 Steve PCB Design

33. Questions 9/8/2009

34. Bibliography 1. Xbee – http://www.sparkfun.com/commerce/product_inf o.php?products_id=8664 2. USB Board - http://www.sparkfun.com/commerce/product_inf o.php?products_id=19 http://www.sparkfun.com/commerce/product_inf o.php?products_id=19 3. Johnson, E. & Murphey, T. (2008). Second-Order Switching Time Optimization for Non-Linear Time- Varying Dynamic Systems. 9/8/2009