Team Status Report for 2/17/24

The most significant risks for the success of the project are hardware limitation concerns and lack of research on the difficulty of the problem we are trying to solve. Hardware limitations could result in project failure because we are buying multiple expensive cameras and if some or all are faulty, we would no longer have the budget to buy more. Further, there is a minimum resolution of the cameras required to achieve the project use-case requirements and design requirements. This risk is being managed by experimentation with whatever cameras we have available to determine a camera resolution requirement, and ordering and returning cameras so we can test them and see if they work. Lack of research on the difficulty of the problem we are trying to solve could result in project failure if the problem is inherently too difficult for us to achieve within our time-frame. This risk is being managed by getting advice from experts who have already done research into the problem. We are currently thinking of contingency plans but haven’t thought of any yet, though we have done initial research towards a pivot to another project idea involving auto-tracking and auto-generation of a stream following a car in case it is necessary.

Since the last status report, we received feedback from Professor Kim and TA Jean that resulted in a change of the use-case requirements, going from a pool foul detection system on most common fouls to a foul detection system on push shots and double hit fouls, two especially hard cases even for humans to identify. This change was motivated by the desire to focus on the most difficult part of the wider problem we were interested in addressing – detection of pool fouls – as the initial wider scope of the problem might have spread us too thin leading to an unfocused project direction. The costs of this change are a schedule setback as we have to begin again from the use case requirements, and these costs will be mitigated by scheduled work sessions in the afternoons. An updated schedule is in progress.

Part A was written by Jae Song.

In general, our product which helps detect double hits and push shots will not meet any specific needs In public health, safety, or welfare. In specific however, we can see how it may play an indirect role in these aspects. In terms of public health, since double hits and push shots are two of the hardest fouls to detect, it may help the players’ psychological health as they may be more at ease to know the line between right and wrong that will be drawn from the product. In terms of safety, the only safety issue our product may raise is the location of the cameras to capture footage to detect fouls, although the danger is minimal threat to the players. Lastly, in terms of welfare, our product emphasizes and highlights fairness, which is what most people consider should be a basic standard in life.

Part B was written by Thomas Li.

Our system addresses the social need of fair competition. In social groups, competition can promote many good things for the group, helping everyone get better and improving quality of life. An autonomous referee provides this need without needing a human to do the job.

Part C was written by Bhavya Jain.

On average new pool tables cost above 1200. Our system is a reasonable addition for any pool lovers who might be looking for a way to officiate their games. The product we will construct may cost around 300-400. If produced on a larger scale, the cost may be reduced. The costliest component of our product will be the multiple high shutter speed cameras. We will be working under the constraints of the budget allocated to us, but if better accuracy is required better cameras may be used with our system which may increase costs. While one odd disadvantage may be pool referees loosing employment, we believe our product would be a tool for them to have more information rather than a replacement product. We hope that the improvements in experience while playing the game might be beneficial to the pool industry.

Thomas’s Status Report for 2/17/24

This week I drafted a feature list defining the project’s problem scope and proposing initial ideas for the solution. Features were separated into pre-proposal and post-proposal and incorporated feedback from the proposal presentation and were discussed in a follow-up meeting leading to the project direction for the design review presentation. I also drafted a list of the project components that will be part of our solution approach as preparation for the design review presentation, along with a brief overview of what each project component will do and its input and output.

I am behind schedule. To catch up to the project schedule I’ll first need to schedule a meeting with my teammates for us to revise the schedule now that we have pivoted our project away from our proposal idea. Then I can schedule work sessions with one or both them outside of lab sessions to speed up my progress until I am back on track. Next week for deliverables, I hope to complete the design review document. In particular, I should have an explicit interface specified for each of the project’s code files and an overall project code file hierarchy.

Thomas’s Status Report for 2/10/24

This week, I worked with my team on the project proposal. While brainstorming implementation details for foul detection, I suggested that our team should add a new feature to our 8-ball referee system which allows pool players to “call” the pocket they are aiming for by clicking on one of the pockets of the table in the web app UI. This is necessary to keep track of whether a ball (especially the 8-ball) has been legally pocketed or not according to the rules of the game.

I am behind schedule because I should’ve finished organizing implementation details and edge cases by this point.  According to the schedule, I should begin writing code that relies on camera input next week. To catch up to the project schedule, I’ll do research on Sunday to finish up organizing implementation details and edge cases (finding out what sensor data would be needed if I had ideal sensors). Once I’ve caught up, I can focus on working on next week’s deliverables, which can be pseudocode for the foul detection system that assumes valid camera input.