Rocket Pitch | Devpost

OLED on V1
V1 using conductive thread
Device components on V1
V2
V2
Tweets
V5 hardware

Team Rocket

Tianyang Cheng- tiche@seas.upenn.edu
Rishab Gupta- rishabg@seas.upenn.edu
Namneet Kaur- namneet@seas.upenn.edu

Inspiration

Children and adolescents represent the largest segment of the baseball playing population with more than 5 million kids playing in the United States alone. Studies have documented rates of upper extremity injuries as high as 30-50% in this age group over the course of a single season. Research has led to the implementation of pitching volume and rest time requirements, but these guidelines are seldom adhered to due to a lack of tracking mechanism. It becomes impossible for parents and coaches to enter the number of pitches delivered by each child, considering that most children play multiple games in a day. This problem is interesting to us since our team comprises of three people who love playing sports, understand the need for injury preventing devices and have a diverse set of skills required to drive the project to a completion.

What it does

We are prototyping a wearable device that tracks the number of pitches delivered by a child during the day. The number of pitches will then be compared with the pitching volume and rest time requirements. In addition, recommendations will be generated for the number of pitches that a child can safely deliver in the coming days. This data can be made available to both the parents and the coaches and warn them if a child is likely to get injured by pitching too many times via web or mobile interface.

How we built it

System Design: Depending on where the data collection is happening, the system is designed to work under different modes. During data collection in the field (where wifi is not available), the logging mode is activated with wifi disabled. This ensures maximum battery life and fast data collection for on-board machine learning algorithm. During the upload mode, which usually happens in user's homes, the device connects to a configured wifi network. Although this requires some extra one-time set-up procedures, it can be done using a web browser.

The micro-controller is chosen to be ESP8266 because it's popularity (just about right amount of IO and EEPROM), low power consumption, decent clock speed (80MHZ) and small size, which meet all our requirements as a wearable device.

The power consumption is a major concern during the development since the University doesn't allow any Lithum Polymer batteries due to safety concerns. The device has an onboard regulator and take in 3 - 6 V and the peak current consumption is around 250mA. The current draw limits our options to a bulky 9V battery. The coin cell can provide 6V but only 15mA nominal current. The 12V battery also can only supply 50mA on average.

Software Design: The system communicates with all the sensors at around 330Hz maximium. In order to ensure the data consistency, evey second of samples are written to the SD card. The buffered write process takes around 30ms, which means only one sample is lost. This is acceptable because we can just intropolate the missing sample. During huge acceleration, it's wise to write to the backing storage once a while since the connection of the SD card might become loose. The samples are saved into the memory in this pattern: accX, accY, accZ, gyroX, gyroY, gyroZ with two bytes each degree of freedom. Every 1024 samples, data will be flushed to the SD card for persistency and future research use. Some visualisation scripts were written in MATLAB to calibrate the sensors.

Modes WiFi: In the wifi upload mode, the user needs to press a button during the initialization and it will start a hotspot with a webserver. Users now can connect to it and navigate to 192.168.4.1 to see the user interface in which it can be configured to connect their own home wifi. Once the SSID and password are saved, it will try to connect to the same hotspot in the future. If, the same hotspot is not found, the system will go into the configuration mode again and connect to another wifi hotspot.

Game Mode: This mode keeps track of the number of pitches done while a player is pitching in a game as opposed to pitching in practice/ recess. This knowledge is quite crucial for the doctors since children usually over-exert themselves during games.

Challenges we ran into

Coin cells We thought of using coin cells to power the circuit, but the current supplied by them was not close to being enough! Coin cells can only supply 15mA on average while the 12V can supply 50mA. The circuit was drawing too much power so we decided to use a 9V battery and a 5V 7805 voltage regulator.

On average data logging mode, the system draws roughly 100mA when the OLED, SD card, and all sensors are running. And in data uploading mode where wifi is turned on, it can consume up to 250mA.

Conductive threads We stitched all components together to a band using conductive thread. It looked good, it was sturdy and flexible. It was originally used in sharing a I2C bus with multiple slaves, but some threads were shorting each other in the development of version one. So we decided on going ahead with the normal wires to connect the circuit and make a wider band, where all the components were laid flat. It turned out to be very successful and

Memory We started with an SD card to store our data and intended on transferring that data to the cloud, since we do not have enough memory on chip.

On-board processing Instead of doing machine learning on the cloud, it made more sense to do it on-board. So we threw out the SD card, made our code leaner and started throwing processed information to the dashboard generator.

Form factor We are now at V5. We were quite satisfied with all versions that preceded it, but never happy. We always had issues with lose connections, difficulty to wear, slipping of the band on the arm, inability to adjust to arms of different widths, bulkiness, etc. However, after taking all factors into consideration, I think we have managed to design a band that overcomes all previous shortcomings and is pretty, snug and comfortable. We are now happy and convinced with our design.

Accomplishments that we're proud of

Pretty accurate pitch predictions: We detect most pitches, but lose out on that one-odd pitch. We almost never confuse other events like running, walking, jumping with pitch events.

Real-time alerts: The device is smart. It knows how many pitches need to be done for a particular day, and let's the user know that it's time they stopped pitching!

Updates to the Unified Sensor libraries The default Unified libraries has many unnecessary code in the abstraction layer to modify data structures. We modified the library and created functions with minimal code for sensor interfacing.

Form factor compliance We think that V5 meets the product requirements and also looks pretty!

Range of metrics After multiple iterations with the subject experts, we have been able to close in on and deliver metrics both on the device and in the backend that are needed not only by the doctors for analysis and diagnosis, but also by parents/ users that allow them to keep track of pitching statistics with easy to infer visualisations.

What we learned

Product development: We are now at V3 of the device. Each iteration tried to find the sweet-spot between weight, flexibility, size and strength.

Writing lightweight, high performance code: The ESP8266 has 64KiB for instructions and 96KiB for data. We wrote code for writing to the SD card, for connecting and transferring data over WI-Fi and do real-time pitch detections, and we still have half the memory left! Oh and also, we did not compromise on our sampling speed. We still sample at 300 Hz.

What's next for Rocket Pitch

Usability(Completed!): One of the primary targets now is to improve the design of the band and the way components are placed to reduce any distracting factors while pitching. One approach is to add a better user interface, ease of use, reduce the size. (Completed!)

Backend dashboard generation(Completed!): We are still unsure of the kind of analytics we need to provide with our dashboards. We certainly need to display the number of pitches per day, and we also need to generate recommended pitches for the next few days. We also need to decide on the backend framework we want to use. (Completed!)

Additional Metrics(Completed!): Most of our data does not have velocities associated with the pitch events. We need to collect more data with associated pitch velocities and then try to figure out how we can estimate real-time pitch velocities on-board. The obvious way is to integrate accelerometer data over-time, but doing it on-board will not be that easy! Additionally, we need to figure out what other parameters we need to consider such as angular velocity for which we need to consult Dr. Greenburg.