SmartWall
THE FUTURE OF ROCK CLIMBING
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
Mark
9/8/2009
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
Mark
9/8/2009
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

Mark
9/8/2009
Problem - Solution
 Software

Data logging


Analysis of ascent


Offline judging
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

Mark
9/8/2009
System Overview
Handhold
Handhold
Controller
User Input
Mark
Host Computer
Flash Drive
9/8/2009
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
Mark
9/8/2009
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
Mark
9/8/2009
Handhold Power Supply
How much power do we need to
run the wall?
LEDs, Microcontroller
Kirk
Xbee Antenna
9/8/2009
Power Requirements
 Miniature LEDs (1 mA to above 20 mA)
 MSP430
 sleep mode ~ <1uA,
 Active ~ 200uA
 Wireless
 1 mW
 Wake from sleep in 15 msec
Kirk
9/8/2009
Battery Solution
Polymer Lithium Ion Batteries - 2000mAh
Each cells outputs a nominal 3.7V at 2000mAh!
Kirk
9/8/2009
Handhold Charging
Lithium Ion, Lithium Polymer Charger, 1.3A - Wall Plug In
The output current ranges from 500mA to 1.3A.
Cell count: 1-7 cells
Kirk
9/8/2009
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
Kirk
9/8/2009
Implementation - Controller
Camera
USB
Storage
Microcontroller
(MSP430, etc.)
Antenna
Zigbee
Interface
LCD Display
Matanya
USB Host
Host
Computer
Numeric Keypad
9/8/2009
Controller Software Flow Diagram
Initialization
Standby
Interaction
Acquire camera
User detected
Broadcast wakeup message
Load profile
Receive
handhold/video
data packet
Receive
handhold
identification
Capture photos
of handholds
Correlate
handhold
location-id
Matanya
Create route
Log packet
Broadcast
handhold
lighting data
Detect end of
climb
9/8/2009
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
Matanya
9/8/2009
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
Matanya
9/8/2009
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

Matanya
9/8/2009
Implementation – Controller <-> Computer
Protocol
 Controller -> Computer
 Sequential, timed data logging
 Snapshot of handhold status
 Computer -> Controller
 Initialization step containing status for each handhold


Asynchronous update packets

Anil
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
Only communicates changes
9/8/2009
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



Anil
Computer is replaced with USB Stick
Initialization data is stored
Data, in same format, written to USB stick
9/8/2009
Implementation - Computer
 Puts the Smart in SmartWall
 Route planning algorithm



Video input





No longer simple ‘can or can’t do’ or time-based
Possible to gauge pressure, finesse, time on holds
More elaborate competitions possible
Tracking


Anil
Comparison of climbing technique with ‘Professionals’
Scoring


Analysis of stance
Correlation with pressure data
Climber improvement


Handhold type, reach, route length, etc.
New route every time
User profiles
Progress
9/8/2009
Implementation - Computer
Initialization
Climbing mode
Input mode
Recognize user
Control Hold
lighting
Process
Flash Drive
Process
Video
Create
Routes
Display
Performance
Adapt
Difficulty
Anil
9/8/2009
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)
Anil
9/8/2009
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
Anil
9/8/2009
Budget
Steve
Item
Estimated Cost
Wall
200
Physical Handholds
100
Host PC
Own
Handhold Components (each)
~100
Microcontroller / Wireless
10
LED’s
4
Pressure Sensors
40
Batteries
40
Charger
20
Controller
~200
Microcontroller / Wireless
20
USB module / RFID
40
PCB
30
Camera
50
Wall Plugs
50
Total (10 Handholds)
~1500
9/8/2009
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
Steve
9/8/2009
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
Steve
9/8/2009
Milestone #1
 Controller talking to multiple handholds
 Initialization Sequence
 Handhold placement analysis
 Light up handholds for routes
 Preliminary algorithm results
 Video analysis
 Route creation
Steve
9/8/2009
Milestone #2
 Data logging to USB drive
 Algorithms complete and tested
 Preliminary user interface
 Ability to view data
 Basic functionality completed
Steve
9/8/2009
Logistics - Schedule
Steve
9/8/2009
Individual Tasks
Wireless
Protocol
Controller
logging &
input
Anil
Video
Processing
Matanya
Route
Planning
Controller
Design &
PCB
Wall
Construction
User
Recognition
Battery
Charging
Kirk
Steve
Power Design
&
Optimization
User
Programmable
Interface
MSP430
Programming
Handhold
construction
Handhold
Wireless
Interface
Mark
PCB
Design
Steve
9/8/2009
Questions
9/8/2009
Bibliography
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
3. Johnson, E. & Murphey, T. (2008). Second-Order
Switching Time Optimization for Non-Linear TimeVarying Dynamic Systems.
1.
9/8/2009