|
Fabulous Four |
|
Max Harper, Alvin Li, Tao Yang, Jeff Chonko |
|
An embedded system that will track the arc of a basketball foul shot intended as a training device to raise free throw percentage. Our system will track the basketball using an array of sonar range sensors. Using these data points, we will extrapolate a parabolic curve, analyze this curve, and give immediate audio feedback to the player. |
|
The current commercial product that utilizes computer vision that is comparable to our project costs $6000, which is out of the price range of all except the richest of high school/ college basketball programs. Our product will cost substantially less and could be a viable option for even an average high school. High school students and even younger athletes can have access to a tool that could dramatically increase their shooting ability. |
|
Noah Select System - $5,798 Our product is more affordable, portable, gives immediate feedback, and does not require a laptop to operate.
feedback, measures complete shot arc, and gives more accurate and valuable feedback.
Our product can be used with everyday basketballs while giving immediate audio feedback and not changing the characteristics of the basketball. |
|
Hardware · Robostix/Gumstix · Audiostix2 · LV Maxsonar EZ0
Software · C and Assembly Languages
Protocols · RS232 Serial communications or Universal Asynchronous Receiver/Transmitter communications
|
|
· Provide player with valuable audio feedback within 2 seconds of the shot going through the hoop · Measure the shot arc degree within 5 degrees · Remember keep record of the last 100 shots and provide more in-depth feedback |
|
Risk: Balls landing or people stepping on sensors
Strategy: Mount each sensor in a small enclosure with an opening (less than an inch across) in the top.
Risk: Noisy sensor data
Strategy: Use a simple bounds check to filter data in real-time.
Strategy: Only pulse a sensor if an adjacent sensor detects the ball (default is pulse the first sensor).
Strategy: Collect a large amount of data to facilitate detection of erroneous data.
Risk: Ball travels fast enough to avoid sensor pulses
Strategy: High frequency sensors used in the system.
Strategy: Sensors with a non-negligible beam spread used.
Strategy: All data analysis done after all data collection. During data collection simply record entries with a distance reading, sensor number, and time of reading.
Risk: Sensor beam spread provides inaccurate position data
Strategy: Calculate each ball position by triangulating two adjacent sensors’ distance readings in a small time interval and the known distance between sensors.
Risk: User does not place sensors in required locations
Strategy: Entire system is attached at the proper relative locations to a slightly stiff strip of cloth or plastic weave. The user will be able to simply secure one end under the hoop and unroll the system, eliminating any significant user setup.
Risk: Sensory interference from the shooter or hoop
Strategy: All sensors will be offset from the shooter and hoop towards the middle of the shot arc. |
|
-Bad Readings will be handled by prompting the user to shoot again. -User errors will require a manual reset by the user -Errors noticeable through code execution will result in a restart by the program
|
|
Implementation Details |
|
Test Cases |
|
Test plan
Power On/Off why: most basic sanity check how: repeated tests where we simply turn on and off the system(gumstix) result:fault free
Roof why: make sure each sensor produces consistent data how: position the sensor toward the ceiling, it should produce a consistent reading(with minor noise). Then move the sensor down, its reading should go up accordingly. result: TBD
Throwing the Basketball why: verify the accuracy of each sensor. how: setup all 4 sensors, space them apart and throw a few passes across them. We will video tape the process, so we can approximate the actual distance and use it to verify the sensor readings are accurate. result:TBD
Free Throw why: verify the correctness of the system how: The user will shoot 20 free throws. We will video tape the process, analyze the shot arc from the video, use that to verify the shot arc we extrapolated from the sensor readings are correct. result:TBD
I/O Device why: make sure the I/O devices are working correctly how: verify the audio output from the speaker matches the input we sent result TBD
Memory why: make sure the system can record shot statistics correctly how: pull the memory card after a few trials and read it using a computer, it should still have the data for last 20 shots result:TBD
Useless Data why: If the user shoots so far off the target(or the sensor data is corrupted somehow) that we can't reconstruct an arc that makes sense with the data collected, the system should tell the user to shoot again rather than calculating with useless data how: shoot the ball wide left/over the backboard, and check the system output result TBD
Sensor/Audio Connection Dies why: The system should stop and the users should be notified if such events occur how: disconnects one of the sensors during the operation, error should be reported result:TBD
Power Outage
why: The system should act reasonably when the power is lost and restored(restart correctly,no lingering effects etc). The data recorded before the power went out should still be there how: yank the power line. See what happens result:TBD |
|
More detail will be provided soon... |
|
More detail will be provided soon... |
|
More detail will be provided soon... |
