University of Calgary Webdisk Server - Robotic...

Robotic Object Acquisition and Camera Handler

ME 4451 Robotics

Fall 2009

December, 2009

Zakaria Elahmadi

Ajeya Karajgikar

Jason Kulpe

Andrew Turner

I. INTRODUCTION

The purpose of this project was to

camera. A TrendNet camera is

tracks the motion of an object. The object will be slowly

motors will adjust the position of the camera by reeling in or out the cables

The idea was inspired by Skycam, a trademark brandname of a patented, computer

cable-suspended camera system, often used to broadcast live matches to bring video

camera angles. The goal of the project was to envision a Skycam system that would be able to

perform automatically without the aid of a human controller.

a. Initial Plan

The initial plan was to build a rectangular wooden supporting structure with four columns as

shown in Figure 1. The dimensions of the field given by length, width and height are 3’, 2’ and

2.5’ respectively. There would be four columns (one in each corner) to support the m

attach the pulleys for the cable to reel on

supported by the four cables. As shown in the figure, the red triangle represents the object that

the camera must follow as the object moves along the playing field. If the object stays at one

position for a defined period of time, then the camera must attempt to lower itself in order to get

a magnified view of the object as it rests.

Figure 1: a.) Side view of the proposed model b.)

1

of this project was to build a 3 dimensional, cable-suspended,

is suspended via cables above a ‘playing field’. It

tracks the motion of an object. The object will be slowly moved around on the field, and servo

motors will adjust the position of the camera by reeling in or out the cables at determined speeds

The idea was inspired by Skycam, a trademark brandname of a patented, computer

em, often used to broadcast live matches to bring video


perform automatically without the aid of a human controller.

was to build a rectangular wooden supporting structure with four columns as


’ respectively. There would be four columns (one in each corner) to support the m

attach the pulleys for the cable to reel onto. The camera would hover over the playing field



defined period of time, then the camera must attempt to lower itself in order to get

a magnified view of the object as it rests.

a.) Side view of the proposed model b.) Top view of the proposed model

, motion tracking

above a ‘playing field’. It automatically

moved around on the field, and servo

at determined speeds.

The idea was inspired by Skycam, a trademark brandname of a patented, computer-controlled,

em, often used to broadcast live matches to bring video-game-like


was to build a rectangular wooden supporting structure with four columns as


’ respectively. There would be four columns (one in each corner) to support the motors and

. The camera would hover over the playing field



defined period of time, then the camera must attempt to lower itself in order to get

Top view of the proposed model

2

b. Implemented Plan

The implemented plan was very similar to the initial plan with slight modifications. The

base of the wooden structure was 36” in length and 24” wide. Three additional planks of wood

were attached in the middle for added support. All the wood used for the base was held in place

with the help of metal brackets. Four columns (poles) each of 28” in height were attached to each

corner of the base. A hook was attached one inch below the top of each pole facing each other on

the inside of the support structure. This support acts as a cable holder. Fishing line was used as

cable, which ran through the pulleys and into the hook that directs it to the camera hanging over

the playing field. Figure 2 shows the basic outline of the structure on the left and the use of

brackets on the right. Figure 3 shows the attached hook on the pole which acts as a cable holder.

Drawings of parts are included in Appendix II.

Figure 2: Left- Base structure of the final robot. Right- Metal brackets were used to maintain the

position of the wooden planks

3

Figure 3: The cable runs from the pulley to the metal hook which directs it to the camera

The pulleys were manufactured in the machine shop out of high density polyethylene

(HDPE). Two clear plastic discs were attached on either side which served as the flanges.

Modified servo motors were connected to the pulleys as they rested on edges of each of the

wooden planks as shown in Figure 4. The motors were held in place using a metal sheet that was

modified to act like a bracket. A shaft was inserted through a support pole and into the pulley.

This held the pulley in place and provided an axle for it to rotate on.

Figure 4: Motors were connected to the pulleys and were mounted on the base by a metal

bracket

4

The top region of the robot was covered by a playing field which was a hole-patterned

particle board. The field was cut at the four corners to make room for the motor-pulley-pole

assembly. Another cut was made towards one corner of the field to put the control box in place.

A metal sheet was placed under the wooden base which held the control box in place. This is

shown in the figure below.

Figure 5: Left- Holder for the control box attached to the base of the structure. Right-

Bottom view of the playing field showing where the control box is held in place.

When the control box was switched on with all the motors connected to their respective

pins, the motors would start to rotate uncontrolled until it received a command from the

MATLAB program. In order to get proper co-ordination from each of the motors, it was decided

to switch each one of them individually without having to unplug and re-connect each of the

motors. This was solved by using one pole single pole single throw switches, which were

connected between the motor and the control box. The motor had three wires – PWM, power and

the ground. The power wire from the motor was directed to the switch, which was routed to the

control box. Figure 6 demonstrates the setup of the motor-switch-control box assembly.

Figure 6: Set-up of the switches connecting the motors to the control box

5

The wires were tied and taped to the base so that the order of the connections was

maintained and troubleshooting problems later were made easier. Figure 7 shows a more

organized set-up of the switches. It also provides a top view of the switches.

Figure 7: Left- The wires were tied and taped. Right- Top view of the control box and switches.

Using the set-up as shown in Figure 8, the camera was made to move to different

locations using MATLAB code. The computer sent a signal to the control box, which in turn sent

a signal to the motors, which made the camera move in three dimensions.

Figure 8: Final implemented plan with the camera held in position by the cables

Finally, the set-up was painted to represent a Georgia Tech football field. This is shown in Figure

9 below.

6

Figure 9: Final implemented plan displaying the colored robot

II. ROBOT KINEMATICS

The kinematics of the cable robot is three dimensional position control of the camera, which

is modeled as a point. The forward kinematics problem is to determine the camera position as a

resultant of the controlled cable lengths. Given an XYZ position, the four cable lengths necessary

to reach the position are calculated utilizing progressive applications of Pythagorean Theorem,

which is a simple solution to the reverse kinematics problem. Then, using physical specifications

and motor calibration data, motor velocities are calculated and executed in order to reach the

specified position.

7

Equation (1) is the simple solution to the length problem and the figure listed in Appendix V is a

graphical representation of the solution process.

Cable Length, = √�� + �� + �� (1)

Note that the input XYZ position is a global coordinate that must be adapted for each cable. The

control code calculates the specific cable lengths given the X, Y, and Z coordinates. The solution

to this problem is given by the following equations (2-5) listed below. The variables are

presented in Figure 10 and Figure 11 along with the column locations and the coordinate system.

222

1 )( zHyxL −++= (2)

222

2 )()( zHyxSL −++−= (3)

222

3 )()()( zHyWxSL −+−+−= (4)

222

4 )()( zHyWxL −+−+= (5)

Figure 10: Top view of column number scheme and co-ordinate system

Figure 11: Side view of co-ordinate system

SSC control box

Columns

1

2

3

4

x

y

y

z

H

S

W

8

The cable displacements, the only controllable parameters, are calculated as the

difference between the cable lengths at each position. With the required cable displacements

calculated for initial and final positions, it is possible to move the camera between the two points

with a calculated motor velocity. Given a time T, which can be optimized within the program,

and the cable diameter D, rotational speed is determined by Equation (6)

DT

ntDisplaceme

πθ =& (6)

This velocity value, θ& , is input into the calibration equations which equates a range of

motor rotations per second (RPS) to count values. The program attempts to minimize movement

time to place the resultant speed within the linear response range of the motors.

With this system there is no feedback. Therefore, to reduce error the initial position of the

camera must always be manually measured. This is needed because the camera motion is both a

function of cable displacement and initial position. For this reason, error plays an important role.

Once enough error accumulates, position control becomes perpetually inaccurate. The MATLAB

programs written for the system are documented in Appendix I. Also, Appendix VI describes the

process implemented by the code.

III. CHALLENGES

a. Servo motors

The initial challenge of the project was applicable servo motor torque and rotational

displacement. The first problem faced was the weight of the TrendNet camera and the

uncertainty that the servo motors would not be able to support the weight or not produce enough

torque to lift the weight of the camera at a variety of camera positions. The second issue with the

servo motors was that they only rotate a maximum of 180o and this would limit the range of

motion of the camera in the workspace. To increase reachable distance, pulley size would have

to increase. An increase in pulley size leads to an increase in motor torque, which decreases lift

capacity. These two issues, servo motor power and displacement, led to an optimization problem

of reachable workspace positions. Even with large reels of 10” diameters, the movement would

be significantly limited and errors in rotational displacement would amplify, increasing with

increasing diameter, to errors in camera position. Servo motors with large spools would also be

unwieldy and hard to package. Looking for different motion solutions, stepper motors (used in

ME 2110) were considered. The prebuilt control box used for the stepper motor was compatible

with only PBASIC and not MATLAB. The TrendNet camera was programmable with MATLAB

and not PBASIC and hence creating an interface between the two languages would be an overly

9

complex and time consuming procedure not primarily dealing with the scope and needs of the

project. The budget and schedule put restrictions on buying a circuit as a controller for the

stepper motors. Designing a circuit to do the same was not in the scope of the project. It was also

observed that adjusting the motor speed too quickly would cause errors with MATLAB’s serial

communication causing stop signals to not be transmitted. This factor influenced our decision to

find a constant motor velocity, as described by Equation (6).

b. Calibration

The solution to increase range of motion was to use servo motors physically converted to

velocity control motors. This led to a need to devise a unique way to calibrate the motors of the

robot in order to determine the speeds for particular counts (ranging from 0 to 255). There were

many challenges to the calibration. In order to obtain accurate distance control, both count and

time had to be considered for calibration. For short operation time, acceleration has a noticeable

influence. An ideal calibration procedure needed to be found that took into account the time

dependency of velocity control.

c. Position control

Once the final version of robot was built, operational errors occurred within the system. The

errors resulted from the physical motor control, which diverged from the calibration determined

response, and from inaccurate initial position determination. The result was inaccurate position

control. To maintain accurate position control throughout motions, each cable must remain in

tension. The system has three degrees of freedom, but four constraints. Therefore, any position is

reachable using only a combination of three cables. This means that three system cables can

converge for a specific point while the third cable diverges. Once moving to the next point, if the

divergent cable becomes a depended variable, the system jumps to a large error. The initial

position determination posed a challenge simply because it is difficult to measure the location of

a point in three dimensional space.

d. Pan and tilt motion of camera

Apart from the initial weight concerns, another problem faced was with the motion and

direction of the camera once it was suspended over the field. The three dimensional rotational

position of the camera was arbitrary and erratic. The cables mounted to a single point above the

camera therefore the camera was not fixed in a particular direction. Further complicating the

camera direction, the tension from the camera power cable greatly dictated the position and

motion of the camera when it was moved from one point to another. The field of view of the

camera did not cover the intended football field but instead tilted up and spanned a horizontal

view of the entire room. Furthermore, the lack of controllable pan and tilt provided a poor image

10

to perform motion tracking. Also, the orientation oscillations of the camera resulted in fuzzy

images.

Figure 12 presents a view of how the cables were connected to the camera. It was noticed

that the cables connected higher had more tension because they took most of the initial load. All

the cables could not be connected at the same height because it would cause them to slip around

one another and entangle.

Figure 12: Cables holding camera in place

IV. SOLUTIONS

a. Servo motors

With the initial idea of using servo motors to manipulate the camera, torque was a key

trouble. To test this, a ROBIX arm was attached to a servo motor while the camera was hung

from the end of the arm. With a 4” arm, the single servo motor was able to lift the camera. This

simple test showed that the motor torque would be sufficient for our application. Next was the

issue of adequate range of motion. On the 3’x2’x2.5’ field, a displacement of at least 2’ of cable

was desired. With a rotational range of 180o, the required reel radius would be 7.5”. A pulley this

large in diameter, yet thin enough to adequately couple with the motor shaft, would be

impossible to find commercially and exceedingly expensive to manufacture.

The ultimate solution was to physically modify the servo motors to create velocity control

motors. To do this, a connection ring was removed that coupled a gear to the servo’s

potentiometer. This potentiometer supplied the feedback for the servo motor. Also, a plastic

retaining block was removed from the top of the gear. This block physically limited the rotation

to 180o. Figures 13-17 show the layout and modification of the servo motors.

11

Figure 13: Standard ROBIX servo motor

Figure 14: ROBIX servo motor with exposed gearbox

Figure 15: Overall motor disassembly and potentiometer coupling

12

Figure 16: Gear retaining block and potentiometer coupling removal

Figure 17: Potentiometer shaft

With these two components removed, the servo motors were converted to velocity control

motors with no feedback. Given a count value and a potentiometer setting, the motor would set

to a specific velocity. The potentiometer was manually adjusted and set to achieve a zero

velocity point at a count value of 100. The resulting motor speed range is around 0.8 revolutions

per second, in both directions. For velocity control motors, infinite rotation range was achieved;

the need for an excessively large reel was gone but the need for a reel all together was still

present. Using the school’s machine shop, 1.27” radius plastic spools with connection cutouts

were manufactured to transmit motor rotation to pulley rotation. The unrestricted rotation proved

to be a significant achievement on the project.

b. Calibration

Although actual motor response is time dependent, it was determined that full calibration

would be too difficult and time intensive to pursue. A procedure that leads to steady state data

was chosen. To easily measure speed the motor was fixed to a table with a lever arm indicating

position. The motor was run at different counts and the time it took for it to complete 10

13

revolutions was recorded using a stopwatch. The initial point was marked as the point

perpendicular to the base of the motor. The number of counts and the time it took was entered

into a spreadsheet and the velocity was determined through linear interpolation. Initially, the

results obtained included the time dependency because the measurements started from the initial,

zero velocity state. This was later corrected by letting the motor run for the first few times, until

it reached steady-state. This ensured a better database of time independent points. Sample

calibration data for all the motors is attached in Appendix III. The interpolated values could be

accessed quickly for each motor.

c. Position control

Error in position control was never eliminated. Motors exhibited random error depending on

direction, time of move, and camera position. The random nature of the error was a problem that

could not be solved with a simple solution. A multi-dimensional error correction is needed, but

this was a very time consuming and difficult task. For example, one motor always had an error

noticeably greater than other motors. An experimental scalar was multiplied to the calculated

velocity in an attempt to fix the error. Results showed no improvement. For position

measurement, a base with a grid pattern was used. This allowed for more accurate locating and

allowed for quick, no tape measure, position correction. The robot’s workspace was limited, via

code constraints, to X, Y, Z within [1, 21], [1, 33], [3, 22], respectively.

d. Pan and tilt motion of camera

Motion tracking was found to not be useable. In order to get a field of view of the playing

field, weight was initially added to the front of the camera in order to make it tilt downwards.

However, added weight increased the load on each of the cables and increased the directional

oscillatory behavior of the camera. Another method in which a bent hook was used to connect to

cables also did not succeed. Slippage of the cables would result in the camera returning to its

equilibrium state. It was found that the camera would not be useable for motion control. Future

iterations of this project should involve a method to better control the motion of the camera in

order to implement motion tracking on the field.

V. ACHIEVEMENT/RESULTS

The cable robot achieved moderate position control with an open-loop controller. No camera

or motor feedback was used. Given an initial position and waypoints, the camera can be moved

through the waypoints with a random, compounding error. Maximum initial error range is ±1.2”.

However, the normal error experienced for the first position change is less, at ±0.5” These errors

compound and begin to increase error if the position is not recalibrated periodically. A Graphic

User Interface (GUI) was created to interface the user with the source code. The GUI, shown in

14

Figure 18, displays the camera’s view and a graphical representation of the camera movement

through the workspace. The GUI allows user input of waypoints and then executes the motions.

The GUI incorporates functions to make the robot move in a circle (along the XY plane) and in a

helix (in the XYZ plane).

Figure 18: GUI used to control the system

Thin metal brackets of different heights which acted as obstacles were placed at different

locations on the field. The robot was commanded to collide with the obstacles and turn them

over. This allows error observation and emphasized the compounding error. The coordinates to

complete these tasks was predetermined and the data is attached in Appendix IV. It was noted

that the measured coordinates of the obstacles was not the same as the coordinates that the robot

theoretically moved to when programmed to move using MATLAB. Therefore, the pseudo

coordinates of the obstacles were determined and fed into the program. On doing this, the robot

was able to hit all the obstacles with good consistency.

15

VI. LEARNING EXPERIENCES

When dealing with the problem at a detailed level, it became more complex and there were

many unforeseen problems that were faced during the duration of the project. A lot of time was

spent building the robot and trying to analyze the problems that we had to overcome. Critical

thinking and problem solving were the key elements to finishing the project. Since most of the

project deals with cable robots, we had to widen our scope of understanding of the subject from

what was taught in class. A consensus opinion of the group was that kinematics of cable robots

taught in lecture would have been helpful.

A major learning experience was with error. It was determined that feedback is of ultimate

importance. In hindsight, it was decided that the unmodified servo motors with large reels should

have been used, with the caveat of unlimited rotation angle. If not servo motors, encoders should

have been used on the velocity control motors. Error for such a complex model proved to be

elusive to describe and quantify. With so many aspects of control, including physical and

programmatic, error was difficult to correct. Motor error was never successfully corrected.

A secondary experience was coping with limited resources; this includes time. The solution

began with using the supplied servo motors. This defined lift capacity, response, and accuracy.

Money and time lead to building a wooden frame, which reduced tolerances, and using a slack

camera support, which made the camera unusable. At least 100 hours was spent, but to solve this

problem correctly, it would take much more time.

APPENDIX I. MATLAB CODES

Motor calibration:

function out=speed_data(motor,speed,count,motortype) % out=speed_data(motor,speed,count,motortype) % % Function with motor speed data used to interpolate to find the counts % matching the desired speed. Depending on the value of motortype % the function can work in reverse to give the speed for a desired count % value % % % The speed value must be within the motor limits are given by: % % motor1: [-0.7690, 0.7170] % motor2: [-0.8570, 0.8440] % motor3: [-0.7650, 0.7480] % motor4: [-0.8050, 0.7960] % % INPUTS: % motor: 1-4, integer identifying which motor % speed: desired speed in rev/s % count: desired count % motortype: = 1 speed -> counts % = 2 counts -> speed % % OUTPUTS: % out: interpolated count or speed value to be passed to ssc controller % % Jason Kulpe % 11/15/09

% Motor calibration data count1=[0 60 80 85 90 95 100 105 110 115 120 140 255]; speed1=[0.7140 0.7170 0.6420 0.5680 0.4180 0.1760 0 -0.2190 -0.4610 -0.6160

-0.7020 -0.7690 -0.7620]; count2=[0 20 40 60 80 85 90 95 100 105 110 115 120 140 160 180 200 220 240

255]; speed2=[0.8430 0.8431 0.8440 0.8400 0.7690 0.6600 0.5040 0.2450 0 -0.2451 -

0.5210 -0.6880... -0.7820 -0.8520 -0.8560 -0.8570 -0.8540 -0.8561 -0.8550 -0.8510]; count3=[0 60 80 85 90 95 100 105 110 115 120 140 255]; speed3=[0.7390 0.7480 0.6780 0.5910 0.4310 0.1800 0 -0.2800 -0.5320 -0.6620

-0.7200 -0.7650 -0.7540]; count4=[0 60 80 85 90 95 100 105 110 115 120 140 255]; speed4=[0.7880 0.7960 0.7390 0.6770 0.5320 0.2890 0 -0.2630 -0.5130 -0.6750 -

0.7420 -0.8050 -0.7880];

% Motor speed -> counts if motortype==1 if motor==1 out=round(interp1(speed1,count1,speed)); elseif motor==2

out=round(interp1(speed2,count2,speed)); elseif motor==3 out=round(interp1(speed3,count3,speed)); elseif motor==4 out=round(interp1(speed4,count4,speed)); else error('Motor must be 1,2,3, or 4') end end

% Counts -> motor speed if motortype==2 if motor==1 out=interp1(count1,speed1,count); elseif motor==2 out=interp1(count2,speed2,count); elseif motor==3 out=interp1(count3,speed3,count); elseif motor==4 out=interp1(count4,speed4,count); else error('Motor must be 1,2,3, or 4') end end

% Check for NANs if isnan(out) error('Interpolation value is a NAN which means speed out of range') end

Drive motors for a selected time:

function drive_motors_time(ssc,T,count) % drive_motors_time(ssc,T,count) % % Drive all motors for time T at a level given by counts. After time has % elapsed all motors are stopped. % % INPUTS: % ssc: serial controller object % T: drive time, seconds % counts: 1x4 vector of motor counts

% Current time time=clock;

% Drive each motor at its count value until the elapsed time = T sscservoset(ssc,1,count(1)) sscservoset(ssc,2,count(2))

sscservoset(ssc,3,count(3)) sscservoset(ssc,4,count(4))

while etime(clock,time)<=T end

% After time has elapsed stop all motors stop_all_motors(ssc)

Find motor speeds and drive time:

function [T count]=optimize_motor_drive_time(p1,p2) % [T count]=optimize_motor_drive_time(p1,p2) % % Optimize the motor drive time to move from points p1 to p2. The motor % time T is chosen to be the lowest time such that the associated motor % speeds are within the physical motor limits. % % INPUTS: % p1: [x y z] coordinates of point 1 % p2: [x y z] coordinates of point 2 % % OUTPUTS: % T: motor drive time, seconds % count: [c1 c2 c3 c4] motor count values

% Model variables model_parameters

% Calculate cable length change dp=cable_move(p1,p2);

% Initialize variables dt=.005; T=dt; check=1; iter=1;

% Gains a1=1.1; a2=.75;

% Iterate through loop to find the time that when speed is calculated, all % motor speeds are within bounds

while check speed=dp/(pi*D*T); % Compute speed, assumed to be constant

% Choose a gain for motor 2 to compensate for errors? gain based on % direction if sign(speed(2)) speed(2)=a1*speed(2); else speed(2)=a2*speed(2); end

% Check to see if the speeds are within limits speed_check=prod(double(speed <= ub)) && prod(double(speed >= lb));

% If so terminate the loop, else, increment the time if speed_check check=0; else T=T+dt; iter=iter+1; end end

% Find count values from the associated speed for i=1:4 count(i)=speed_data(i,speed(i),[],1); end

Find cable lengths from camera position:

function L=cable_lengths(p) % L=cable_lengths(p) % % Calculates the cable lengths for the camera, at point p. % NOTE: World coordinate center is at tower 4, on the floor % % INPUTS % p: [x y z] = camera posistion % % OUTPUTS: % L = [L1 L2 L3 L4] : cable lengths, inches

% Find model parameters model_parameters

x=p(1);

y=p(2); z=p(3);

% Compute lengths L1=sqrt(x^2+y^2+(H1-z)^2); L2=sqrt((S12-x)^2+y^2+(H2-z)^2); L3=sqrt((S34-x)^2+(W23-y)^2+(H3-z)^2); L4=sqrt(x^2+(W14-y)^2+(H4-z)^2); L=[L1 L2 L3 L4];

Find cable displacement:

function dp=cable_move(p1,p2) % dp=cable_move(p1,p2) % % Calculate the change in cable lengths between points 1 and 2. % % INPUTS: % p1: [x y z] coordinates of point 1 % p2: [x y z] coordinates of point 2 % % OUTPUTS: % dp: [d1 d2 d3 d4] change in lengths for cables 1-4

dp=cable_lengths(p2)-cable_lengths(p1);

Simulation plot of system:

function cable_plot(varargin) % h=cable_plot % h=cable_plot(pts) % % Function to plot the simulation of the camera on a figure with handle h. % The number of points can be any size. % % INPUTS: % pts: n x 3 vector of X Y Z points % % OUTPUT: % h: figure handle of plot

% Model parameters model_parameters

% La=cable_lengths(p1);

% Lb=cable_lengths(p2);

% Draw field and frame S=mean([S12 S34]); W=mean([W14 W23]); H=mean([H1 H2 H3 H4]);

% Draw the lines hold on col='k'; wid=2; % Field h(1)=fill3([0 S S 0],[0 0 W W],[0 0 0 0],'g');

% Columns h(2)=line([0 0],[0 0],[0 H1],'color',col,'linewidth',wid,'linestyle','--'); h(3)=line([S S],[0 0],[0 H2],'color',col,'linewidth',wid,'linestyle','--'); h(4)=line([S S],[W W],[0 H3],'color',col,'linewidth',wid,'linestyle','--'); h(5)=line([0 0],[W W],[0 H4],'color',col,'linewidth',wid,'linestyle','--');

% Add in coordinate axes h(6)=quiver3(0,0,0,5,0,0,'color',col,'linewidth',wid); h(7)=quiver3(0,0,0,0,5,0,'color',col,'linewidth',wid); h(8)=quiver3(0,0,0,0,0,5,'color',col,'linewidth',wid); axis([-1 S+1 -1 W+1 -1 H+1 0 1])

% plot all the points if nargin>0 pts=varargin{1}; for i=1:size(pts,1); h(i+8)=plot3(pts(i,1),pts(i,2),pts(i,3),'ko','markersize',5,... 'markerfacecolor','k','markeredgecolor','k'); end end

% Create parent handle h_all to contain all object handles h_all=hggroup; rotate3d('on'); set(h,'Parent',h_all) ;

Parameters of model:

% Model parameters, inch % Pulley properties R=1.27/2; D=1.27;

% Frame properties W14=34+1/8; W23=34+3/16; S34=21+7/16;

S12=21+1/8;

% Column properties H1=23+7/16; H2=23+3/16; H3=23+3/16; H4=23+3/8;

% Motor speed limits (rev/s) ub=[0.7170 0.8440 0.7480 0.7960]; lb=[-0.7690 -0.8570 -0.7650 -0.8050];

Custom waypoint selection:

function [run_time count_list]=custom_waypoint(p) % [run_time count_list]=custom_waypoint(pt_list) % % Compute the times and counts necessary to move through different % waypoints in the list pt_list. Assumes the minimum size of pt_list is % 2 x 3. % % INPUTS: % pt_list: n x 3 matrix where n describes the number of waypoints, % and 2 <= n <= 6 % % OUTPUTS: % run_time: n-1 vector of times to go between waypoints i-1 and i % count_list: n-1 x 4 matrix of motor counts to be used

n=size(p,1);

% Find the run times to go between each point for i=2:n % Move the camera between points p(i-1) to p(i) [run_time(i-1) count_list(i-1,:)]=optimize_motor_drive_time(p(i-

1,:),p(i,:)); end

Move in a circle:

function p=move_circle(ssc) % pts=move_circle(ssc) % % Make the camera move in a preset circular path %

% INPUTS: % ssc: serial controller % % OUTPUTS: % pts: [x y z] points in space

% Pause time tp=2;

% Initial point p0=[11 20 6];

% Points n=20; tt=linspace(0,2*pi,n); r=3; for i=1:n p(i,:)=[r*cos(tt(i))-r r*sin(tt(i)) 0]+p0; end

% For each find the motor run time and associated counts for i=2:n % Move the camera between points p(i-1) to p(i) [run_time(i-1) count_list(i-1,:)]=optimize_motor_drive_time(p(i-

1,:),p(i,:)); end

% Drive if ssc is listed if nargin>0 % Run motors n=length(run_time); for i=1:n T=run_time(i); count=count_list(i,:); drive_motors_time(ssc,T,count); pause(tp) end end

Move in a helix:

function p=move_helix(ssc) % pts=move_helix(ssc) % % Move the camera in a preset pattern of a helix. % % INPUTS: % ssc: serial controller % % OUTPUTS:

% pts: points of helix

% Pause time tp=2;

p0=[10 15 3]; % initial points n=50; t=linspace(0,4*pi,n)';

% Helix radius a=3;

% Helix pitch b=8/(4*pi);

% Helix coordinates x=a*cos(t)+p0(1); y=a*sin(t)+p0(2); z=b*t+p0(3); p=cat(2,x,y,z);

% Make coordinates and find motor drive times and counts for i=2:n % Move the camera between points p(i-1) to p(i) [run_time(i-1) count_list(i-1,:)]=optimize_motor_drive_time(p(i-

1,:),p(i,:)); end

% Drive if ssc is listed if nargin>0 % Drive motors for i=1:n-1 drive_motors_time(ssc,run_time(i),count_list(i,:)); stop_all_motors(ssc) pause(tp) end end

Collide with obstacles:

function p=object_collision(ssc) % pts=object_collision(ssc) % % Drive the camera in a pre-selected pattern designed to hit obstacles % % INPUTS: % ssc: serial servo controller % % OUTPUTS: % pts: points of trajectory

% Pause time tp=1;

% Initial point p0=[11.5 16.5 3.5];

% Obstacle points p1=[6 8.25 6]; p2=[20 9 6]; p3=[20 20.5 3]; p4=[6 24.5 2];

% Find the counts and times between each poitns [T01 count01]=optimize_motor_drive_time(p0,p1); [T12 count12]=optimize_motor_drive_time(p1,p2); [T23 count23]=optimize_motor_drive_time(p2,p3); [T34 count34]=optimize_motor_drive_time(p3,p4);

% Form p p=cat(1,p0,p1,p2,p3,p4);

% Drive motors if ssc is listed if nargin>0 % Drive each motor %P0 to P1 drive_motors_time(ssc,T01,count01); stop_all_motors(ssc); pause(tp)

%P1 to P2 drive_motors_time(ssc,T12,count12); stop_all_motors(ssc); pause(tp)

%P2 to P3 drive_motors_time(ssc,T23,count23); stop_all_motors(ssc); pause(tp)

% P3 to P4 drive_motors_time(ssc,T34,count34); pause(tp)

% Stop all motors stop_all_motors(ssc) end

APPENDIX II: MODEL SKETCHES

36.000

.750

3.375

16.500

3.000

8.000

TOP VIEW

24.000

28.000

FRONT VIEWSIDE VIEW

1DO NOT SCALE DRAWING

WOODEN STRUCTURE

SHEET 1 OF 9

AJEYA

AJEYA

AJEYA

AJEYA

UNLESS OTHERWISE SPECIFIED:

SCALE: 1:12 WEIGHT:

REVDWG. NO.

ASIZE

TITLE: ENTIRE SETUP OF WOODEN (PINE) PLAYING FIELD

NAME DATE

COMMENTS:

Q.A.

MFG APPR.

ENG APPR.

CHECKED

DRAWN

FINISH

MATERIAL

INTERPRET GEOMETRICTOLERANCING PER:

DIMENSIONS ARE IN INCHESTOLERANCES:FRACTIONALANGULAR: MACH BEND TWO PLACE DECIMAL THREE PLACE DECIMAL

APPLICATION

USED ONNEXT ASSY

PROPRIETARY AND CONFIDENTIALTHE INFORMATION CONTAINED IN THISDRAWING IS THE SOLE PROPERTY OFGEORGIA INSTITUTE OF TECHNOLOGY. ANY REPRODUCTION IN PART OR AS A WHOLEWITHOUT THE WRITTEN PERMISSION OFAJEYA KARAJGIKAR IS PROHIBITED.

5 4 3 2 1

ISOMETRIC VIEWS


WOODEN STRUCTURE

SHEET 2 OF 9

AJEYA

AJEYA

AJEYA

AJEYA


SCALE: 1:12 WEIGHT:

REVDWG. NO.

ASIZE

TITLE:

NAME DATE

COMMENTS:

Q.A.

MFG APPR.

ENG APPR.

CHECKED

DRAWN

FINISH

MATERIAL



APPLICATION

USED ONNEXT ASSY

PROPRIETARY AND CONFIDENTIALTHE INFORMATION CONTAINED IN THISDRAWING IS THE SOLE PROPERTY OFGEORGIA TECH. ANY REPRODUCTION IN PART OR AS A WHOLEWITHOUT THE WRITTEN PERMISSION OFAJEYA KARAJGIKAR IS PROHIBITED.

5 4 3 2 1

1.500

1.750

.500

1.250

R.250

.750

SIDE VIEW REAR VIEW

TOP VIEW

MOTORS


MTRS ASS.SHEET 3 OF 9

AJEYA

AJEYA

AJEYA

AJEYA


SCALE: 1:1 WEIGHT:

REVDWG. NO.

ASIZE

TITLE:

NAME DATE

COMMENTS:

Q.A.

MFG APPR.

ENG APPR.

CHECKED

DRAWN

FINISH

MATERIAL



APPLICATION

USED ONNEXT ASSY

PROPRIETARY AND CONFIDENTIALTHE INFORMATION CONTAINED IN THISDRAWING IS THE SOLE PROPERTY OFGEORGIA INSTITUTE OF TECHNOLOGY. ANY REPRODUCTION IN PART OR AS A WHOLEWITHOUT THE WRITTEN PERMISSION OFAJEYA KARAJGIKAR IS PROHIBITED.

5 4 3 2 1

1.600

.650

.500

1.600

R.625

1.146

.375

.050

PULLEYS


PLLS ASS.SHEET 4 OF 9

AJEYA

AJEYA

AJEYA

AJEYA


SCALE: 1:1 WEIGHT:

REVDWG. NO.

ASIZE

TITLE:

NAME DATE

COMMENTS: MADE IN MACHINE SHOP. NOT PROVIDED BY UNIVERSITY

Q.A.

MFG APPR.

ENG APPR.

CHECKED

DRAWN

CARBON PLASTICFINISH

MATERIAL



APPLICATION

USED ONNEXT ASSY


5 4 3 2 1

1.500

.055

.125

1.400

1.400

1.000


BRK ASM.SHEET 5 OF 9

AJEYA

AJEYA

AJEYA

AJEYA


SCALE: 1:1 WEIGHT:

REVDWG. NO.

ASIZE

TITLE:

NAME DATE

COMMENTS:

Q.A.

MFG APPR.

ENG APPR.

CHECKED

DRAWN

FINISH

MATERIAL



APPLICATION

USED ONNEXT ASSY


5 4 3 2 1

BRACKET

BRACKETBRACKETBRACKETBRACKETBRACKET

3.0008.000 4.500

1.500

4.5001.500

16.500

4.500

1.500

4.500

1.500

36.000

.300

PLAYING FIELD


PLFLD ASM.SHEET 6 OF 9

AJEYA

AJEYA

AJEYA

AJEYA


SCALE: 1:12 WEIGHT:

REVDWG. NO.

ASIZE

TITLE:

NAME DATE

COMMENTS:

Q.A.

MFG APPR.

ENG APPR.

CHECKED

DRAWN

FINISH

MATERIAL



APPLICATION

USED ONNEXT ASSY


5 4 3 2 1

8.000.250

5.000

R.100

.250

HOLDER FOR CONTROL BOX


CNRT HLDR.ASM

SHEET 7 OF 9

AJEYA

AJEYA

AJEYA

AJEYA


SCALE: 1:4 WEIGHT:

REVDWG. NO.

ASIZE

TITLE:

NAME DATE

COMMENTS:

Q.A.

MFG APPR.

ENG APPR.

CHECKED

DRAWN

FINISH

MATERIAL



APPLICATION

USED ONNEXT ASSY


5 4 3 2 1

.970

.200

.097R.083

.085

.166

CABLE HOLDER


CBL HLD.ASMSHEET 8 OF 9

AJEYA

AJEYA

AJEYA

AJEYA


SCALE: 2:1 WEIGHT:

REVDWG. NO.

ASIZE

TITLE:

NAME DATE

COMMENTS:

Q.A.

MFG APPR.

ENG APPR.

CHECKED

DRAWN

FINISH

MATERIAL



APPLICATION

USED ONNEXT ASSY


5 4 3 2 1

A

DETAIL A SCALE 1 : 2

DETAILED VIEW OF MOTOR PULLEY SYSTEM


MTR-PLY.ASM

SHEET 9 OF 9

AJEYA

AJEYA

AJEYA

AJEYA


SCALE: 1:12 WEIGHT:

REVDWG. NO.

ASIZE

TITLE:

NAME DATE

COMMENTS:

Q.A.

MFG APPR.

ENG APPR.

CHECKED

DRAWN

FINISH

MATERIAL



APPLICATION

USED ONNEXT ASSY


5 4 3 2 1

APPENDIX III. CALIBRATION DATA

Figure A3-1: Calibration data for motor 1 (attached to pole 1)

Rev 10

Motor Stop Value Motor 1

Counts Time 1 Time 2 Time 3 Average time Speed (RPS)

1 100 0 14.06 13.9 14.06 14.007 0.714

60 14.06 13.97 13.81 13.947 0.717

80 15.66 15.57 15.5 15.577 0.642

85 17.59 17.63 17.63 17.617 0.568

90 24.28 23.9 23.66 23.947 0.418

95 56.84 56.78 56.81 56.810 0.176

100 0 0 0 0.000 0.000

105 46.19 45.65 45.16 45.667 -0.219

110 21.6 21.78 21.75 21.710 -0.461

115 16.31 16.19 16.22 16.240 -0.616

120 14.22 14.28 14.25 14.250 -0.702

140 13.06 12.97 12.97 13.000 -0.769

255 13.12 13.15 13.12 13.130 -0.762

-1.000

-0.800

-0.600

-0.400

-0.200

0.000

0.200

0.400

0.600

0.800

0 50 100 150 200 250 300

Sp

ee

d (

RP

S)

Counts

motor 1


Rev 10


Counts Time1 Time 2 Time 3 Average time Speed (RPS)

2 100 0 11.84 11.85 11.9 11.863 0.843

20 11.81 11.9 11.87 11.860 0.843

40 11.81 11.84 11.9 11.850 0.844

60 11.9 12 11.81 11.903 0.840

80 12.97 13.1 12.93 13.000 0.769

85 15.19 15.07 15.19 15.150 0.660

90 19.87 19.78 19.84 19.830 0.504

95 40.81 40.72 40.91 40.813 0.245

100 0 0 0 0.000 0.000

105 41.25 40.81 40.53 40.863 -0.245

110 19.28 19.21 19.06 19.183 -0.521

115 14.56 14.5 14.54 14.533 -0.688

120 12.82 12.75 12.81 12.793 -0.782

140 11.78 11.72 11.72 11.740 -0.852

160 11.71 11.66 11.68 11.683 -0.856

180 11.66 11.63 11.72 11.670 -0.857

200 11.68 11.75 11.68 11.703 -0.854

220 11.62 11.69 11.75 11.687 -0.856

240 11.78 11.69 11.62 11.697 -0.855

255 11.69 11.78 11.79 11.753 -0.851

y = 2E-06x6 - 0.0001x5 + 0.0033x4 - 0.0399x3 + 0.2001x2 - 0.4093x + 1.1026R² = 0.9994

-1.000

-0.800

-0.600

-0.400

-0.200

0.000

0.200

0.400

0.600

0.800

1.000

0 20 40 60 80 85 90 95 100 105 110 115 120 140 160 180 200 220 240 255

Sp

eed

(R

PS

)

Counts

Motor 2

Motor 2


Rev 10



3 100/101 0 13.65 13.56 13.41 13.540 0.739

60 13.4 13.34 13.35 13.363 0.748

80 14.81 14.75 14.72 14.760 0.678

85 16.78 17.03 16.94 16.917 0.591

90 23.28 23.16 23.16 23.200 0.431

95 55.94 55.25 55.91 55.700 0.180

100 0 0 0 0.000 0.000

105 36.03 35.72 35.28 35.677 -0.280

110 18.84 18.81 18.78 18.810 -0.532

115 15.03 15.15 15.16 15.113 -0.662

120 13.84 13.91 13.94 13.897 -0.720

140 13.06 13.09 13.09 13.080 -0.765

255 13.31 13.25 13.22 13.260 -0.754

-1.000

-0.800

-0.600

-0.400

-0.200

0.000

0.200

0.400

0.600

0.800

1.000

0 50 100 150 200 250 300

Sp

ee

d (

RP

S)

Counts

motor 3


Rev 10



4 100 0 12.75 12.65 12.69 12.697 0.788

60 12.56 12.57 12.56 12.563 0.796

80 13.62 13.43 13.53 13.527 0.739

85 14.78 14.78 14.75 14.770 0.677

90 18.81 18.78 18.85 18.813 0.532

95 34.34 34.47 35.03 34.613 0.289

100 0 0 0 0.000 0.000

105 38.09 37.97 37.88 37.980 -0.263

110 19.47 19.53 19.47 19.490 -0.513

115 14.87 14.78 14.81 14.820 -0.675

120 13.47 13.47 13.5 13.480 -0.742

140 12.47 12.37 12.44 12.427 -0.805

255 12.71 12.63 12.72 12.687 -0.788

-1.000

-0.800

-0.600

-0.400

-0.200

0.000

0.200

0.400

0.600

0.800

1.000

0 50 100 150 200 250 300

Sp

ee

d (R

PS)

Counts

APPENDIX IV: Data to make the robot move from one co-ordinate to another

Note: All dimensions are in inches

OBSTACLE COLLISION DATA: DATA TO MAKE THE ROBOT MOVE IN A CIRCLE:

X Y Z

X Y Z Point 1 11 20 6.1

CENTER (p0) 11.5 16.5 3.5 Point 2 10.8375 20.9741 6.1

Point 3 10.3674 21.8426 6.1

Actual points (when measured) Point 4 9.6408 22.5115 6.1

X Y Z Point 5 8.7365 22.9082 6.1

Point 1 7 16.5 3 Point 6 7.7523 22.9898 6.1

Point 2 17 9.5 4 Point 7 6.7949 22.7473 6.1

Point 3 17 20.5 3 Point 8 5.9682 22.2072 6.1

Point 4 5 23.5 2 Point 9 5.3616 21.4278 6.1

Point 10 5.0409 20.4938 6.1

What the robot thinks its at: Point 11 5.0409 19.5062 6.1

X Y Z Point 12 5.3616 18.5722 6.1

Point 1 (p1) 6 8.25 6 Point 13 5.9682 17.7928 6.1

Point 2 (p2) 20 9 6 Point 14 6.7949 17.2527 6.1

Point 3 (p3) 20 20.5 3 Point 15 7.7523 17.0102 6.1

Point 4 (p4) 6 24.5 2 Point 16 8.7365 17.0918 6.1

Point 17 9.6408 17.4885 6.1

Point 18 10.3674 18.1574 6.1

Point 19 10.8375 19.0259 6.1

Point 20 11 20 6.1

DATA TO MAKE THE ROBOT MOVE IN A HELIX:

X Y Z

Point 1 13 15 3

Point 2 12.3674 16.8426 3.4211

Point 3 10.7365 17.9082 3.8421

Point 4 8.7949 17.7473 4.2632

Point 5 7.3616 16.4278 4.6842

Point 6 7.0409 14.5062 5.1053

Point 7 7.9682 12.7928 5.5263

Point 8 9.7523 12.0102 5.9474

Point 9 11.6408 12.4885 6.3684

Point 10 12.8375 14.0259 6.7895

Point 11 12.8375 15.9741 7.2105

Point 12 11.6408 17.5115 7.6316

Point 13 9.7523 17.9898 8.0526

Point 14 7.9682 17.2072 8.4737

Point 15 7.0409 15.4938 8.8947

Point 16 7.3616 13.5722 9.3158

Point 17 8.7949 12.2527 9.7368

Point 18 10.7365 12.0918 10.1579

Point 19 12.3674 13.1574 10.5789

Point 20 13 15 11

APPENDIX V. ROBOT KINEMATICS GRAPHICAL SOLUTION

Figure

ROBOT KINEMATICS GRAPHICAL SOLUTION

Figure A5-1: Cable length solution process

APPENDIX VI: PROGRAM FLOW CHARTS

Date post:	16-Aug-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

University of Calgary Webdisk Server - Robotic...

Documents