Inspiration would provide a helpful feed for how the waves are looking on a particular day prior to surfing, gauging how many people are surfing that day etc.

Surfline provided a helpful solution prior to driving to a beach and seeing the results. The ZotCourt+ system replicates the same sort of behavior, but instead of surf activity, we are monitoring basketball playing activity on the courts. While more people surfing might not be an attractive sight to see given how busy it can get, for basketball it provides the opportunity to play pick up basketball with other talented players.

After spending hours on the court practicing my basketball skills, I wanted to put them to the test.

Hey, wanna play a game of pick up in a few?

I would typically ask my friend.


They would respond.

But what about those days when you are excited to try those new skills but everyone around is busy?

The next best thing is hoping a player is already playing on the court. Getting a chance to ask them for a game.

A game begins. A competition ensues. A Friendship is born.

What it does

ZotCourt+ uses real time sensing technology to detect ball activity on the basketball court, providing this information to players via a website interface, providing a solution for those who may be interested in playing a few rounds of pick up basketball with others players who are already on the court prior to arrival.

How we built it

In order to provide real-time usage data for basketball courts, we organized the application into three different modules. The IoT Edge layer application is running on a Raspberry PI, a Node.js (Express.js) server that implements endpoints for the raspberry PI, and the user-facing page. The Node.js server is deployed to Heroku. Lastly, the frontend React application is deployed to Netlify, a CDN publish service.

The raspberry pi, the server, and the client web page.*

  • Using a Raspberry pi and SW-420, we were able to detect vibrations at high sensitivity built using a python script. The vibration data will be sent to the server-side.

  • The server for handling requests from the Raspberry PI and the frontend application is written with Node.js. It implements 3 GET and POST endpoints for the frontend and 2 POST endpoints for the scripts running on the Raspberry PI

  • The React application displays the current usage for courts nearby. It keeps sending requests to the server to grab the basketball court data and provide them in real-time. Users can also check themselves into a court.

Challenges we ran into

  • Working under remote conditions was challenging due to the physical constraints we faced, but luckily we were able to control versions of our system via GitHub.

  • Communication at a time fell short because we all trying to balance our HackUCI project and our school projects.

  • I (Andre) could have used my time better. Instead of spending time focusing on building the model, I could have jumped onto the server or client-side code. As a result, it placed a lot of pressure on my other teammates. lesson learned

  • Trying to accomplish the logic for the detection system was challenging when it came to no activity coming out of the pi. Accounting for this took many hours. Along with some of the post request info.

Accomplishments that we're proud of

  • Building a minimum viable product that displayed the basic functionality of the system

  • Each of us learning at least one thing every step of the way. Whether this was about our project or about ourselves and our teammates.

  • Learning how to send a pull request on git hub and using git actively on the command-line interface (CLI) was very impactful for the project and for our futures.

  • Working on a repository collaboratively for the first time!

  • Understanding how GET and POST requests work

What we learned

  • We learned that our friendship and our sanity are more important in the long run. Giving each team member space and trusting one another makes for a pleasurable experience.

  • Never underestimate the amount of time it takes to establish a back-end server connection.

What's next for ZotCourt+

ZotCourt+ technology can be seen on restaurant dining tables to speed up turnaround time for seating tables. Usually, people who dine in at a restaurant spend an avg of 45 minutes to an hour at a table. A discrepancy occurs however when the customers are done eating, walk away from the table, and leave the restaurant. At that point, the server sees the visual cue (dirty and vacant tables). Has the table cleaned up, walks to the host stand to tell the host/hostess that the table is now empty and ready for use. If the server does not update the host, they will avoid seating the table assuming the table is still being used. Without ZotCourt+ technology, the discrepancy creates longer wait times at the restaurant, fewer tips in the pockets of the restaurant workers, and angry/impatient customers...

Share this project: