THE FUTURE OF ROCK CLIMBING SmartWall 9/8/2009

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Logistics - Schedule 9/8/2009 Steve

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

Questions 9/8/2009

Bibliography 1. Xbee – o.php?products_id= USB Board - o.php?products_id=19 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