RoBOP-a-Mole - helix

RoBOP-a-Mole 

Julia Barry 

Patrick Chang 

Ryan Stewart 

Alex Choi 

ME 4451: Robotics 

Fall 2007 

December 7 th , 2007

Table of Contents 

INITIAL PLAN .................................................................................................................. 1 

KINEMATICS.................................................................................................................... 4 

PROBLEMS ....................................................................................................................... 5 

SOLUTIONS ...................................................................................................................... 7 

ACHIEVEMENTS/RESULTS ........................................................................................... 9 

WHAT WE LEARNED.................................................................................................... 10 

IMPROVEMENTS ........................................................................................................... 10

INITIAL PLAN 

Goal: 

The intention of this project was to robotically simulate the game “Whack-a-Mole.” 

The “Whack-a-Mole” game consists of a platform with several holes drilled into it. A small 

object, or “mole,” appears randomly from one of these holes and remains there for a small 

period of time. The object of the player is to force the individual moles back into their holes 

by hitting them directly on the head with a mallet. If the player does not strike the mole 

within the time limit, it will eventually sink back into its hole. The player’s goal is to hit as 

many moles as possible before the game ends. 

Materials and Construction: 

In this project, instead of a human player, a robotic arm played the game. The robot 

that was used was the ROBIX serial robot kit provided in laboratory. A plastic mallet 

provided by the team was placed in its end-effector. The robot was placed in front of a square 

platform with edges of length 30 cm. Nine 5 cm diameter holes were drilled into the platform 

in a 3x3 grid formation (Appendix A). The platform was constructed from a black foam 

board by the team. Above the platform was a DVT camera provided by the laboratory. The 

camera was set high enough above the platform so it could see the entire platform, but low 

enough so that only the platform could be seen. The camera was connected to a computer. 

The computer was then connected to the robotic arm. The computer was simultaneously 

running “MATLAB” and the “DVT Vision System” program. The mole was a small, white, 

stuffed bulldog provided by the team. The entire setup and configuration are shown in 

Appendix B. 

1

Overall Procedure: 

The robot began in an initial position that did not obstruct the camera’s view of the 

platform. The game began once one of the team members pushed the mole through one of the 

holes of the platform. The mole was a white color and appeared clearly against the black 

color of the platform and holes. The camera began scanning each hole on the platform for a 

white color. Once the camera found the white color, it returned which hole that the color 

appeared. The holes were numbered 1 through 9 using the convention shown in Appendix A. 

Afterwards, MATLAB read in the value of the hole. It then passed the hole number to a final 

function. This function moved the robot to a predefined set joint angles corresponding to each 

hole. Finally, the function used the end-effector’s motor to rotate the end-effector, causing the 

mallet to rotate downwards and “whack” the hole that the mole was located in. After the 

procedure was completed, the arm moved back into its initial position and the process started 

over. If more than one mole appeared on the platform, the robot would whack all the moles 

before moving back into its initial position. The moles were whacked in numerical order, 

starting with the first hole and moving to the ninth hole. 

Detailed Procedure: 

Platform and Mole: 

The platform was placed roughly three feet underneath the camera. Since the camera 

position was fixed at a height of roughly four feet above the ground, the platform and the 

robot were placed one foot above the ground. The mole was pushed through the hole by a 

team member who was wearing a long, black glove. The member had to wear this glove to 

prevent the camera from detecting the skin color of the team member. 

Camera: 

The camera was used because it has the ability to detect “blobs” by color. The 

platform, the holes, and the member’s arm were all colored black to make sure that the only 

2

non-black object that the camera detected was the white dog. The camera’s DVT Vision 

System program contained a program called “blob detector” that could detect color changes 

in a defined area of the camera’s view. Nine different “blob detectors” were placed over each 

hole of the platform. When the mole appeared in one of the holes, the blob detector would 

detect a white blob. A function created in the DVT program called “findTheBlob” performed 

a binary check on each blob detector by using the “NumBlobs” function. If “NumBlobs” 

returned a value greater than “0,” then “findTheBlob” would then return a value of “1,” 

meaning that it had detected a mole. If, on the other hand, “NumBlobs” returned “0,” then 

“findTheBlob” would return a “0” as well, meaning it had not detected a mole. 

“findTheBlob” checked all nine holes and returned a “0” or “1” corresponding to whether 

each hole had a mole or not. 

Computer: 

The computer was running the MATLAB and DVT Vision System Program 

simultaneously. Once the values of “1” and “0” were returned by the DVT Vision System, 

MATLAB ran the “robopamole.m,” function, which read the values into a vector of size nine, 

with each entry corresponding to the appropriate hole on the platform. For instance, the first 

entry corresponded to the first hole on the platform and contained a “1” or “0” depending on 

whether there was a mole at the hole. The “robopamole” script would then call the 

“gotohole.m” function with the vector as an input. The “gotohole” function checked the 

vector; for each entry that contained a “1,” “gotohole” would call the “RRR_go_angles.m” 

with the appropriate joint angles provided. The joint angles defined in “gotohole” were found 

using the method described in the “Kinematics” section. The “RRR_go_angles” function 

moved the ROBIX serial arm to the joint angles of the target hole. After calling 

“RRR_go_angles,” the “gotohole” function would then call the “whack.m” function. The 

“whack” function actuated the 5 th motor of the robot, causing the hammer in the robot’s 

gripper to swing downward, resulting in the head of the hammer hitting the mole. The 

3

“whack.m” function then reset the position of the hammer. Finally, “gotohole” reset the arm 

back to its initial position. A summary of the functions that MATLAB utilizes are provided in 

flow chart in Appendix C. 

KINEMATICS 

A ROBIX robot arm was adopted as serial RRR robot with links of 9.5cm, 13.3cm, 

and 7.6cm in lengths. A small plastic hammer was attached at the arm’s end effecter to whack 

a mole as the end effecter would rotate on desired trajectory. First, calibrations between rotor 

angles to counts were needed given the ranges of angles of each rotor and counts that servo 

takes. Acknowledging that the counts from 0 to 255 corresponds to angles from 0 to 180 for 

the first motor and from -90 to 90 for the other two motors, four different sample counts of 0, 

40, 80 and 120 were tested and corresponding rotor angles were recorded manually. The 

measures were then plotted and angles to counts calibration table was obtained from trend 

line shown in Appendix D. Once the calibrations were coded into the program with proper 

conditions, adjustments were performed from trial and errors to obtain precise conversion 

property as shown in RRR_go_angles.m and angles2counts.m. 

After the calibration, the origin of the system was determined as the arm was attached 

onto the top of the platform, and positions of nine holes were configured in accordance with 

the system. Both reverse and forward displacement analysis of RRR serial robot were used to 

enable the system to whack onto a designated hole. 

First, given the coordination of nine holes with offset of 10.6cm applied for the length 

of the hammer, joint angles for all coordination were derived from reverse displacement 

analysis. Then, using forward displacement analysis the end effecter could move to the 

desired point, rotate itself to whack onto the hole. For the consistency, elbowplus value was 

set as 1. Next step was to input the hole coordination read from the DVT sensor. Initial 

4

attempts included defining the origin and distinguishing coordination of nine holes 

accordingly. The sensor should constantly scan the platform for any changes in gradient, 

record the coordinates to the register so the program could read them. However, challenge 

arose during the mole detection, that finding centroid of the white region did not result in fine 

consistency. The problem was resolved using rather simpler method, by assigning precise 

rotor angles for each hole. Also each hole was assigned as a blob region which detects for any 

blobs or white region. The code used for the DVT sensor was encoded as shown in Appendix 

E, which recorded values for 9 assigned registers that a program roBOPamole.m could read. 

An array of corresponding numbers was then created as input to a program gotohole.m, 

which initiates movement of the arm and whacking. All programs mentioned are shown in 

Appendix F. 

PROBLEMS 

Throughout the course of the assignment, many obstacles arose that were not 

accounted for in the initial plan for the project. These problems are classified into three 

types: calibration problems, logic problems, and programming problems. The first 

complications arose during the calibration of the RRR robot. The robot was calibrated by 

specifying motor counts to achieve a position. Next, this position was fed into a RRR reverse 

kinematic algorithm to supply corresponding joint angles. From this method, a linear fit was 

used to relate the motor counts to real world joint angles; however, there were two notable 

hurdles in this approach. First, the joint angles calculated from the reverse program would 

sometimes return values greater than 360. This was troubling because the individual motors 

had only 180 degrees of motion. Additionally, upon completion of the calibration, there was 

still error when specifying robot positions. 

5

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

procedure of having the camera system return the coordinates of centroids to the robot which 

would, in turn, perform a reverse analysis to reach these points proved computationally 

taxing and creating difficulties in relating the camera space to the platform space. To avoid 

these problems the group decided it is best to completely abandon this approach and try 

something new. Instead of having the camera search for blobs and centroids inside a large 

space encompassing the entire platform, the camera now searched within nine separate spaces 

each containing a single hole. If a camera sensed any number of blobs within a hole, it would 

record a “true” for that hole. Once all the holes are checked, the program returns a vector 

containing 9 “true” or “false” values corresponding to each hole. This method avoids the 

need for a complicated transform to relate coordinates in the camera space to the coordinates 

of the platform, which would additionally reduce daily setup times. On the robot side, 

instead of using a reverse analysis to locate the holes, the group hard coded a specific 

orientation for the robot for all nine holes. When the camera returns a “true” for a hole, the 

robot will call upon its stored orientation to reach the specified hole. By doing this, there was 

no longer a need to develop a complicated reverse kinematic algorithm to account for the 

additional degree of freedom of the hammer. This solution proved very simple to program 

and quick to implement. 

Near the completion of the project, a few smaller problems arose from specific 

programming of the robot. The most significant of these problems resulted in camera 

outputting false positives for the holes. In other words, the camera would identify a mole 

when, in actuality, no mole was present. Adjusting the threshold and requiring a more 

significant blob to appear in order for the camera to count it corrected this problem. Next, the 

MATLAB loops iterated significantly faster than both the refresh rate of the camera, and the 

time required for the robot to complete a whack. Additionally, the DVT sometimes produces 

an error when there is a change over one of the holes, which would cause MATLAB to return 

a terminal error. Both of these problems were corrected by adding in a pause in the loop. 

8

The iterative loops now wait for a user input to begin a search for a new game state. Lastly, 

the small problem of the camera not being able to see moles underneath the robot is solved by 

both the pause in the program and having the robot return to a position off of the platform 

after whacking. 

ACHIEVEMENTS/RESULTS 

The initial goal of the project was achieved, although the final methods deviated 

greatly from the initial plan, which was to read the coordinates of the mole into Matlab and 

send the arm and the hammer to those coordinates. Because this approach would require the 

definition and calibration of several coordinate systems, within the DVT program and within 

Matlab, a simpler approach was used. Instead of using one blob softsensor to encompass the 

entire board and reading in the centroid coordinates of any blob sensed, nine blob softsensors 

were placed, one around each hole. The vision program then wrote a boolean for each hole to 

Matlab. As for Matlab, it was determined that predetermining the orientation of the robot 

arm at each hole and hard coding these positions into the program was more efficient than 

creating and interpreting a coordinate system. The script, roBOPamole, reads in the boolean 

values from the vision program and sent the arm and hammer to each hole with a boolean 

value of one, calling upon the whack function as well. 

Overall, the project was a success, and all design parameters were met. The DVT 

camera successfully detected the moles without identifying false positives, such as reflection, 

the arm of the team members, or the actual arm itself. The robot hit all the moles squarely on 

the head. The system was robust enough to handle more than one mole. There were no 

recorded failures. 

9

WHAT WE LEARNED 

In this project, the team became accustomed to applied robotics, mainly learning to 

autonomously extract geometric information from the camera’s image and use that 

information to perform a particular task. The team members acquainted themselves with the 

provided equipment and learned that it is important to work within the parameters of the 

equipment; for example, the pause function stopped the Matlab script from advancing ahead 

of the arm’s movements. It was found there were many ways to approach a problem, as was 

the case with the vision system. As with the vision system and the predetermined robot arm 

orientations, the best solution was usually the simplest and the quickest. Considering the 

equipment itself, it was found that the camera had a slow refresh rate and had difficulties 

handling glare. Fortunately, the problem of glare was easily solved by lowering the threshold 

percent. The robot arm, although difficult to calibrate, proved to be fast and simple to 

control, perfect for the whacking motion needed to simulate a person swinging a hammer. 

Finally, the group learned how to integrate multiple hardware and software components to 

create a functional robotic system. 

IMPROVEMENTS 

Although the system was completely functional, there are several possibilities of 

improving the overall performance. For instance, instead of hitting the moles in a numerical 

order, the robot could have hit them in a time-optimized order, thereby decreasing the amount 

of time needed to whack all the moles on the board. Also, instead of returning to its initial 

position after one pass, the robot could have continuously whack moles. In order to do this, 

the camera would’ve needed to ignore the robot arm while it was moving. In addition, a timer 

could have been utilized instead of having a person end the program. This could have been 

done in a while loop that kept track of time. Finally, a score system could have been 

10

implemented to better model the actual “Whack-a-Mole” game. These improvements are not 

vital to the overall success of the project, but would add to its overall appeal. 

11

Appendix A

Appendix B

Appendix C 

robopamole.m 

Description: Main script of the program. Runs everything necessary to 

make the robot function. 

Inputs: A “1” or “0” corresponding to each hole on the board. Reads 

from the DVT Vision System program. 

Variables: holes 

holes 

Description: A vector of size 9 containing a “1” or “0”, 

corresponding with whether each hole has a mole or 

not. For instance, if holes[1] = 1, then the first hole 

has a mole. 

gotohole.m 

Description: Moves the ROBIX robot to a hole and whacks it. 

Then moves back to the initial position. Does this for all nine 

holes. 

Inputs: holes, ssc 

(1) RRR_go_angles.m 

Description: Moves the ROBIX robot to a specified set of joint angles. 

Inputs: theta – a vector of size 3 containing the joint angles of the RRR robot. 

ssc. 

(2) whack.m 

Description: whacking function. Draws the hammer 

back, pauses, whacks, pauses, and then returns to an 

upright position. 

angles2counts.m 

Description: Converts joint angles to counts. The robot can only move 

counts, so the joint angles must be converted to a system that the robot 

can recognize. 

Inputs: theta – a joint angle. servo – which joint the joint angle 

corresponds to.

Appendix D. Calibration Factor 

Motor1 

140 

120 

100 

counts 

80 

60 

40 

20 

0 

y = -1.1641x + 240.14 

0 50 100 150 200 250 

angle 

Motor2 

counts 

140 

120 

100 

80 

60 

40 

y = 1.0131x + 120.58 

20 

0 

-120 -100 -80 -60 -40 -20 0 

angle 

*actual 

conversion factor 

applied was 

refined through 

trials 

Motor3 

counts 

140 

120 

100 

80 

y = 1.4489x + 162.85 

60 

40 

20 

0 

-120 -100 -80 -60 -40 -20 0 

angle

public void inspect() { //initialize vector to hold information on where blobs are. { 

means no blob, 1 means the hole is occupied. int A1, A2, A3, A4, A5, A6, A7, A8, A9; A1=2;A2=0;A3=0;A4=0;A5=0;A6=0;A7=0;A8=0;A9=0; //0 

statements to examine each hole. If hole is occupied, //output array 

(B1.NumBlobs > 0) {A1 = 1;} //if 

(B2.NumBlobs 0) {A2 if (B3.NumBlobs > 0) {A3 if 

(B4.NumBlobs {A4 (B5.NumBlobs {A5 (B6.NumBlobs {A6 if (B7.NumBlobs > 0) {A7 = 1;} 

(B8.NumBlobs {A8 = 1;} if (B9.NumBlobs > 0) 

Appendix E. DVT Sensor Code 

findTheBlob class 

RegisterWriteShort(86,A9); 

RegisterWriteShort(84,A8); 

= 1;} RegisterWriteShort(70,A1); RegisterWriteShort(72,A2); {A9 

RegisterWriteShort(76,A4); RegisterWriteShort(78,A5); RegisterWriteShort(80,A6); RegisterWriteShort(74,A3); 

RegisterWriteShort(82,A7);

Appendix F. MATLAB Code 

a. RRR_go_angles.m 

% Project Whack-A-Mole, ME 4451 

% 

% Created 11-09-07 by Patrick, Alex and Ryan (in lab) 

% 

% INPUTS: 

% 1. theta, a vector containing 3 angles for the motor to move to 

% theta(1) must be between 0 and 180 degrees 

% theta(2) must be between -90 and 90 degrees 

% theta(3) must be between -90 and 90 degrees 

% 2. ssc, the SSC Matlab interface, which has already been opened 

% 

% The function takes the form 

% function RRR_go_angles(theta,ssc) 

% This function moves the arm, using ssc, to the three angles 

defined in 

% theta. 

function RRR_go_angles(theta,ssc) 

% Put in constraints to make sure program doesn't get confused. 

if theta(1) < 0 | theta(1) > 180 

error('Input angle between 0 and 180 degrees for first 

angle') 

end 

if theta(2) 90 

error('Input angle between -90 and 90 for second angle') 

end 

if theta(3) 90 

error('Input angle between -90 and 90 for third angle') 

end 

% If passes constraints, convert angles to counts for each motor 

count1 = angles2counts(theta(1),1); 



% Move the robot arm to the specified configuration 

sscservoset(ssc,1,count1); 



b. angles2counts.m 


% 

% Created 10-19-07 by Julia, Patrick, Alex and Ryan (in lab) 

% 

% INPUTS: 

% 1. degrees, the angle at which the arm in question should end 

% 2. servo, the motor to be activated 

% 


% count = angles2counts(degrees, servo)

% This function transforms angles into counts to be used in the 

ssc 

% interface. The transforming functions were determined via 

% experimentation, reverse kinematics, and linear regression. 

function count = angles2counts(degrees, servo) 

if servo == 1 

count = degrees * (-1.1641) + 240.14; 

elseif servo == 2 

count = degrees * (1.16) + 150.58; 

elseif servo == 3 

count = degrees * 1.17 + 140.85; 

else 

Error('please input a real motor'); 

end 

c. roBOPamole.m 


% 

% Created 12-04-07 by Julia % This function is the mother script. 

Using an infinite while loop, this 

% script reads in the data for each of the nine holes from the 

camera into 

% the vector holes. This function is then inputted into the 

function 

% gotoholes. 

% 

% SSC Interface should already be open. 

clc; 

clear all; 

ssc = sscopen('COM1'); 

%start infinite loop 

x=0; 

while x < 1 

%dvtread 

for i = 1:9 

holes(i)=dvtread('130.207.153.170',68+2*i); 

end 

end 

holes 

gotohole(holes, ssc) 

pause(2) 

%this won't ever be read 

clear ssc;sscclose(ssc);

d. gotohole.m 


% 

% Created 11-02-07 by Julia, Patrick, Alex and Ryan (in lab) 

% Modified 11-09-07 to go to specific positions by Patrick Alex 

Ryan 

% Modified 11-30-07 to take in vector of holes, in light of new 

vision 

% system by Julia, Patrick, Alex and Ryan (in lab) 

% 

% INPUTS: 

% 1. holes, vector with 9 entries containing 0's (hole is empty) 

and 1's 

% (hole is occupied) 


% 


% gotohole(holes, ssc) 

% and moves arm to predetermined position to whack the mole in 

any position 

% which has been marked occupied in vector holes. 

function gotohole(holes, ssc) 

% initial position is set up, via experimentation, to not block 

the camera 

init = [0 44 46]; 

% optimal arm orientation is determined through experimentation 

hole1 = [0 19 90]; 

hole2 = [8 70 76]; 

hole3 = [51 72 56]; 

hole4 = [10 26 56]; 

hole5 = [12 60 44]; 

hole6 = [43 60 31]; 

hole7 = [24 34 7]; 

hole8 = [35 42 11]; 

hole9 = [62 30 10]; 

% go through the vector of holes. If occupied, go to the hole 

and hit it. 

if holes(1) == 1 

RRR_go_angles(hole1, ssc); 

whack(ssc); 

end 



whack(ssc); 

end 



whack(ssc); 

end 



whack(ssc); 

end 



whack(ssc); 

end



whack(ssc); 

end 



whack(ssc); 

end 



whack(ssc); 

end 



whack(ssc); 

end 

% go back to the initial position, out of the way 

RRR_go_angles(init, ssc); 

e. whack.m 


% 

% Created 10-26-07 by Patrick, Alex and Ryan (in lab) 

% Modified 11-30-07 by Julia, Patrick, Alex and Ryan (in lab) to 

draw back % and pause to keep things from being redundant. 

% 

% INPUTS: 


% 


% whack(ssc) 

% This function goes through the whacking motion. 

function whack(ssc) 

sscservoset(ssc,4,84); 

pause(.8); 


pause(1); 


pause(1);

RoBOP-a-Mole - helix

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

Delete template?

Save as template?