Results and Conclusion

Poolbot was able to successfully locate, move to, and hit pool balls within its workspace. Poolbot would correctly identify all balls located on the table with 100% accuracy. It would sometimes identify objects not considered balls within its frame, but this was a worthwhile tradeoff. It then created ball poses, with respect to the base frame, for each ball. After a user selected a target ball, it would move into a hitting position based on the angle and power provided by users for a given shot. This was the most tricky part as even being a millimeter or two off would sometimes lead a lined up shot to not hit the ball at the correct angle. We did not have a single instance of it moving to an incorrect position relative to a ball though some movements would leave the shot off by a small margin of error. Once a user was satisfied with the shot parameters, it would then execute a straight shot. Due to the small size of the balls, and the margin of errors produced by movements, not all straight shots were successful. Typically they'd hit the ball, but due to the offsets, they wouldn't always hit it in the direction provided on screen by the gui. 

Video Demonstration: https://youtube.com/shorts/frBuYizAaBI?si=GCSgoclFLJ5G8eA9

Poolbot demonstrated strong performance in meeting its design criteria with particular excellence in accuracy and safety. The robot was able to reliably detect and map balls to its coordinate frames ensuring proper alignment between the vision system and robotic movements. For safety, all trajectories were visualized using software before execution with the ability to cancel trajectories if there were unexpected results. We also implemented a "bounding box" around the pool table so the end effector can only navigate to locations in its trajectory we deem as safe. 

While Poolbot generally met criteria for reliability and precision, there were occasional minor inconsistencies when striking balls from certain angles as the pool stick was at times misaligned by a few millimeters. This would affect the precision for shots, but despite these rare occurrences Poolbot was able to consistently repeat results from most angles.

Poolbot excelled in design criteria for accuracy and safety and generally was able to meet criteria for reliability and precision. The robot was able to hit balls relatively consistently. There were times where a certain angle would leave the pool stick a millimeter or two off from the intended target and that would mess with the shot, but otherwise it could consistently hit a shot. All trajectories executed by Poolbot were visible through a visualization software to ensure safety and we were able to accurately map coordinate locations of pool ball's seen by our cameras to Poolbot's coordinates frame.

Difficulties:

We encountered three main difficulties when working on the project: 

1. High amounts of Error for Linear Trajectories:  For linear trajectories along certain directions, our group found that when attempting to make pool shots away or towards the sawyer’s base frame, the controller would fight against gravity resulting in a “dip” in the end effector. Implementing gravity compensation in the controller was attempted, but proved not useful enough to completely solve this issue.

2. Nonoptimal Moveit Planning: The sawyer would often choose trajectories from inverse kinematics that were far too impractical for our project. 

3. Ball Pose: We found it to be extremely difficult to find the ball’s pose in the base frame, especially as we need to have a 2mm margin of error, and we ended up spending the majority of the project solving this problem. It turns out that the angle of the camera is extremely important as the Z value is given by the AR Tag.

In order to solve the dipping issue, we had to limit the sawyer arm's workspace in the directions that it would dip. As mentioned earlier, we implemented bounding boxes to deal with any non-optimal paths generated by the MoveIt planner. As for the solving the issue with the finding the ball pose in the base frame we solved this by using ar tags and the head camera. Once the AR tag was located in both the usb camera frame and head camera frame, we were able to get the transform between the two and calculate the ball poses with regards to the base frame. This is due to the fact that the transform between the base frame and the head camera is known by the Sawyer arm. 

Additional Improvements:

Theres a lot of directions that we could take this project if we were to further expand it.

1. We could implement crucial features for a game of pool. Poolbot functions primarily as a controller to interact with pool balls and sawyer currently. A more comprehensive implementation would naturally be the ability to hit a cue ball into a given ball into a given pocket or even give a ball spin.

2. We could expand the workspace for Poolbot to be able to accurately strike the ball from every direction. A large improvement would be the ability to fight against gravity for problematic directions, allowing Poolbot to have a greater range of motion. 

3. We could implement AI Pool Planning. Poolbot could utilize comprehensive game planning to play a ‘perfect game’ using AI in combination with its motion planning.