Final Year Project - Robot plays air hockey

Hi, This blog will cover the results gained from testing the accuracy of the robot successfully hitting the puck at varying angles for both sides. Below is a graph of the results. Relationship between successfully hitting the puck at varying angles for both table sides. The robot had the most success hitting the puck when it bounced off the right side of the table greater than the left side for all three categories. Each category had a sample size of 10. The performance of the robot decreases with increasing angle. However, as the speed was not taken into consideration when conducting this test, some of the results may be a result of the robot not having enough time to react. For both sides, the robot had the most success of hitting the puck at an angle less than 50 ° a s the puck bounced multiple times, reducing its velocity and allowing the robot enough time to react with 83% success rate at right side and 50% on the left side. A possible reason for the difference betwee

Hi, This blog will cover the results gained from testing the accuracy of the robot successfully hitting the puck at varying speeds. Below is a graph of the results. Relationship between successfully hitting the puck at varying speeds The robot couldn't hit a moving puck with a velocity of over 250 cm/second as it didn't have enough time to react. Increasing the speed of the robot will not solve this problem as there will always be an initial delay before executing every motion commands due to the download approach that the ROS-Industrial driver provides for the ABB IRB 120. Although, the system prefers slower puck to allow enough time for the robot to react, a puck moving at a velocity of less than 50 cm/seconds reduced success rate to 16.6% with sample size of 6. A valid reason could be that as the puck cannot get enough acceleration to avoid being affected by physical properties like warping of the table, the direction of the puck is affected. The robot moves to th

Hi, I implemented the bounce trajectory that I developed in simulation to the final system. Bouncing the puck against the table sides reduced its velocity and thus gave the robot more time to react. Although the algorithm is far from perfect, I am glad that I developed this algorithm as the robot would at least move to an estimate future puck position. Possible reason for the error could be the bounce trajectory algorithm which assumes that there is no velocity lost after the puck hits the sides and thus would not alter the direction of travel. Another reason could be the vision of not localising the centre point of the puck properly in some areas of the table. Anyways, below is a video of the robot moving to a predicted future puck positions after a bounce(s). Video of bounce trajectory on final system Immanuel

Hi, I decided to use function compute_cartersian_path despite the results from comparing the duration of trajectories between this function and using the go function. Although, the go function generated shorter trajectory duration and removed the need of planning, both functions applied in the physical system produced similar results and was not capable of compensating with the the initial delay of the robot's motion. From testing time events from the previous posts, I figured that the robot averaged 1242ms from the the time that the puck is moving towards the robot and the time the robot gets to the predicted position. However, as I was using the go function, the average length of the trajectory points is 12 which the robot has to move to before reaching the prediction position. I figured that the current ROS drivers for the robot is to download all trajectory point-by-point before starting the robot's motion. Therefore, I explored ways to reduce the number of trajectory

Hi, This blog will showcase the design of the end-effector that will be used in the final system. The picture below shows the two-part end-effector for easy mounting on the robot's tool flange. It was inspired from the original mallet that came with the table. The top part holds the 6 mm nut and has 4 mounting holes whilst the bottom part holds the screw. The total length of the end-effector is 118 mm and the bottom part has a diameter of 60 mm. Felt is also attached to the bottom of the end-effector to avoid scratching on the table's surface. End-effector Immanuel

Hi, I have discovered a behaviour that the ABB makes when attempting to hit a moving puck as shown in the video below. This behaviour is caused by having multiple predictions in one puck motion. Video of ABB attempting to hit the puck multiple times The logic of my current system is to take three puck positions, predict a future position and move the ABB to the predicted position. If there are still pre-recorded puck positions, the ABB will attempt to move. There are two ways that I explored to fix this problem: 1. Take more than three positions to reduce number of predictions in one puck motion. Although, this would delay the start of the robot's motion as more positions has to be recorded which is not ideal as using three positions would often yield the same predicted position as recording ten positions. Also, considering the delay I have encountered when sending a command to the ABB, I want to predict and move the ABB as soon as possible. 2. The second op