RoBOP-a-Mole - helix

More documents

Recommendations

Info

The next set of problems arose from the logic developed to control the robot. The initial plan for the algorithm was to have the camera system return the centroids of the moles and the robot would perform a reverse analysis to determine how it needed to move to this point. It was soon discovered that the robot has extra degrees of freedom associated with rotating a hammer about an axis parallel to the plane of the platform that were no accounted for in the RRR reverse algorithm. Even if a complex algorithm to solve the reverse analysis were created, performing the calculation every time the robot sensed a mole would be very computationally taxing and could slow the response of the robot. In addition, while using a reverse analysis approach, singular configurations become a problem, because the robot can become unstable at these configurations. Aside from the extra degree of freedom of the robot, using the camera system to identify centroids presented another problem. The reference frame of the camera and the reference frame of the platform are different. In order for the robot to be able to whack centroids in the platform reference frame a very meticulous transform is required to relate the coordinates of centroids the camera sees to coordinates relative to the robot. Additionally, this transform heavily depended on the height of the camera which would make the daily setup of the project time consuming. Next, the project encountered smaller obstacles relating to the specifics in the robot programming. First of all the there was a small learning curve involved in controlling the timing of the program. When the robot is supplied an integer 1-9, telling the robot to whack the corresponding hole, the individual motor commands in MATLAB are not performed completely sequentially. In other words, when telling the robot to move first and whack second, MATLAB will begin the movement operation, and then begin the whack operation without waiting for the movement operation to be completed. This resulted in the robot whacking while it was translating to a hole. Another small complication arose in the communication between MATLAB and the DVT. The iterations of the program to have the robot play the whack-a-mole game happen faster than the camera can update; similarly, 6
MATLAB iterates faster than time required for the robot to move and whack a hole. This would result in the robot repeating the same motions over and over because it accrued a large stack of commands before the game state could be changed. Outside of MATLAB, the DVT software had its own difficulties. The camera system and algorithms ran smoothly when the whack-a-mole game was simulated by placing white pieces of paper over the platform while it was resting on the table. However, when implementing the whack-a-mole game in its entirety, the robot would falsely identify moles in all of the holes. Lastly, since the robot passes over the platform to perform a whack the robot arm blocks the view of the camera and the robot has no way of identifying moles underneath the robot arm. SOLUTIONS The project ran into a significant number of hurdles towards completing the task. Through brainstorming and lateral thinking the group promptly solved these problems and progress could again be attained. There were two main problems associated with the calibration of the robot. First, the reverse algorithm while relating motor counts to angles would return angles greater than 360. This small setback was quickly solved by creating additional logic in the algorithm to relate larger angles to the smaller workspace of the motors. In fact, the angles larger than 360 were still correct; however, the additional logic ensured the robot would not attempt to travel through the complete angle, but rather travel to resulting end effecter location. Although the calibration turned out to be a useful starting point, it did not provide the exact control that the problem required. In order to achieve more exact motions the coefficients in the linear interpolation between angles and motor counts were adjusted using through trail and error. As presented earlier, the initial logic in the solution lead to some unique hindrances that required the group to reanalyze the project and change the initial approach. The initial 7
Page 1 and 2: RoBOP-a-Mole Julia Barry Patrick Ch
Page 3 and 4: INITIAL PLAN Goal: The intention of
Page 5 and 6: non-black object that the camera de
Page 7: attempts included defining the orig
Page 11 and 12: The iterative loops now wait for a
Page 13 and 14: implemented to better model the act
Page 15 and 16: Appendix B
Page 17 and 18: Appendix D. Calibration Factor Moto
Page 19 and 20: Appendix F. MATLAB Code a. RRR_go_a
Page 21 and 22: d. gotohole.m % Project Whack-A-Mol

RoBOP-a-Mole - helix

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?