Debrina’s Status Report for March 23, 2024

This week I am on schedule, but there are some issues we faced in integration this week that may slow down progress in the coming week. This week our team focused on integration to begin testing the full system – from object detection to physics calculation and trajectory projection. Our testing helped us classify some bugs in our implementation caused by certain cases. These bugs led to some unexpected interruptions and sequences in our backend system. Hence, this week I helped to work on the physics model to add more functionality and to improve some existing implementations to account for edge cases. 

In the physics model, I implemented a method to classify the wall that a trajectory line collides with. Furthermore, I fixed some bugs related to division by zero, which would occur whenever a trajectory line was vertical. This case would happen if a user points the cue stick directly upwards or downwards. Next, I tried to fix some bugs related to the wall reflection algorithm since I noticed that it only worked as we expected on specific orientations of the pool cue. I began implementing a few more features to this algorithm so that it would account for walls that are not purely horizontal or vertical. I also modified the return value of this function to return a new trajectory (after the wall collision) instead of a point. This is crucial as this new trajectory is required for the next iteration of our physics calculations. With this new implementation, there are still a few bugs that cause the function to encounter errors when a collision occurs with the top or bottom walls. I will be consulting my teammates to address these errors during our team meeting tomorrow (Sunday, March 24th). 

The edge cases that we discovered during our preliminary testing led me to realize that we could introduce more standardizations for our backend model. I added a few more objects and specifications to the API that Tjun Jet had designed in prior weeks. In particular, I added a new object called ‘TrajectoryLine’, which will allow us to explicitly differentiate between the starting point and the end point of a trajectory. This is helpful to use in some components of our physics model where the direction of the trajectory is crucial. 

In the coming week, I will work on modifying parts of our backend that need to be updated to meet the new standardizations. I will continue to help work on the physics model implementation and conduct testing on trajectory outputs to ensure that we have covered all possible cases of orientations of the cue stick and locations of the pool balls. With regards to our project’s object detection model, I hope to improve the ball detections by using different color masks to better filter out noise that may be caused by different lighting conditions.

Image from our one of our test cases. Trajectory of cue ball as it reflects with the left wall. The cue stick is represented as two red points on the canvas.

Leave a Reply

Your email address will not be published. Required fields are marked *