Automatic Pouring Robot

Akilah Harris-Williams, RPIAdam Olmstead, RPI

Philip Pratt-Szeliga, RPIWill Roantree, RPI

ECSE-4962 Control Systems DesignFinal Project Report

May 3, 2005Rensselaer Polytechnic Institute

Abstract

This report contains our final design of a prototype system to smoothly pour water froma bottle into a cup using closed-loop control. A complete physical system is explored fromconception to modeling to testing and completion. The design and verification of eachsubsystem is discussed in its entirety from initial idea to implementation. The system consistsof the pan/tilt mechanism that the physical system is built on, a sensor subsystem with awebcam for image processing, and computer hardware with analog outputs on an amplifierto implement the controller.

Contents

1 Introduction 1

2 Professional and Societal Consideration 3

3 Design Procedure 43.1 Mechanical System Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.2 Model Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.2.1 Tilt Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.2.2 Pan Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.3 Trajectory Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.4 Control Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.4.1 PID Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.4.2 Lead-Lag Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.5 Sensing Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4 Design Details 114.1 Mechanical System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.1.1 Bottle Mount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.1.2 Webcam Mount . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4.2 Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2.1 Tilt Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124.2.2 Pan Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.3 Trajectory Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.4 Control Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.4.1 Tilt Control Design: Trajectory Following . . . . . . . . . . . . . . . 234.4.2 Pan Control Design: Disturbance Rejection . . . . . . . . . . . . . . 26

4.5 Sensing Subsystem: Webcam . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.5.1 Image Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.5.2 Image Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5 Design Verification 36

6 Costs 42

7 Conclusions 44

iii

A SolidWorks Models and Pictures 47

B Simulink Diagrams 50

C MATLAB Code 54C.1 Final Operation Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54C.2 Pixel to Volume Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . 57C.3 Image Acquisition and Processing . . . . . . . . . . . . . . . . . . . . . . . . 57C.4 Forward Trajectory Generation . . . . . . . . . . . . . . . . . . . . . . . . . 58C.5 Return Trajectory Generation . . . . . . . . . . . . . . . . . . . . . . . . . . 59C.6 Friction Identification Script . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

D Statement of Contribution 63

iv

List of Figures

1.1 Block Diagram of Final System . . . . . . . . . . . . . . . . . . . . . . . . . 2

4.1 Velocity Data for Various Input Torques . . . . . . . . . . . . . . . . . . . . 154.2 Friction Identification Data for Tilt Axis . . . . . . . . . . . . . . . . . . . . 154.3 First Pan Model: a1 = 32.935, a2 = 157.088, a3 = 227.737 . . . . . . . . . . . 164.4 Second Pan Model: a1 = 1.862, a2 = 0.966, a3 = 5.646 . . . . . . . . . . . . . 174.5 Final Pan Model: a1 = 1.908, a2 = 6.066, a3 = 8.443 . . . . . . . . . . . . . . 184.6 Experimental Trajectories . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.7 Simple Trajectory for 500 mL Initial Volume . . . . . . . . . . . . . . . . . . 194.8 Simple Trajectories for Various Initial Volumes . . . . . . . . . . . . . . . . . 204.9 Polynomial Trajectories for Various Initial Volumes . . . . . . . . . . . . . . 204.10 Simple Return Trajectories for Various Return Positions . . . . . . . . . . . 214.11 Polynomial Return Trajectories for Various Return Positions . . . . . . . . . 224.12 Sample Trajectories for Various Volumes and Return Positions . . . . . . . . 224.13 Uncompensated Closed Loop Step Response . . . . . . . . . . . . . . . . . . 234.14 Simulated Closed Loop Step Response with PID . . . . . . . . . . . . . . . . 244.15 Actual Closed Loop Step Response with PID . . . . . . . . . . . . . . . . . . 254.16 PID Sine Wave Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.17 Closed Loop Step Response of Final Tilt Controller . . . . . . . . . . . . . . 264.18 Open Loop Frequency Response of Pan Axis . . . . . . . . . . . . . . . . . . 274.19 Root-Locus of Lead Compensated System . . . . . . . . . . . . . . . . . . . 284.20 Root-Locus of Lead-Lag Compensated System . . . . . . . . . . . . . . . . . 294.21 Frequency Response of Compensated System . . . . . . . . . . . . . . . . . . 304.22 Step Response with Original Design of Lead-Lag Controller . . . . . . . . . . 304.23 Step Response with Final Design of Lead-Lag Controller . . . . . . . . . . . 314.24 Graphical Flow of Image Processing Algorithm . . . . . . . . . . . . . . . . . 34

5.1 Results for Gravity Testing: Simulated and Actual . . . . . . . . . . . . . . . 365.2 Pan Open Loop Chirp Response . . . . . . . . . . . . . . . . . . . . . . . . . 375.3 Pan Open Loop Sine Response . . . . . . . . . . . . . . . . . . . . . . . . . . 385.4 Pouring Trajectory Tracking During Pour . . . . . . . . . . . . . . . . . . . 385.5 Webcam Data for 500mL Pouring 300 mL . . . . . . . . . . . . . . . . . . . 395.6 Webcam Data for 300mL Pouring 250mL . . . . . . . . . . . . . . . . . . . . 405.7 Webcam Data for 100mL Pouring 100mL . . . . . . . . . . . . . . . . . . . . 41

v

A.1 Webcam Mount: SolidWorks . . . . . . . . . . . . . . . . . . . . . . . . . . . 47A.2 SolidWorks Model of Mechanical System . . . . . . . . . . . . . . . . . . . . 48A.3 Picture of Mechanical System . . . . . . . . . . . . . . . . . . . . . . . . . . 49

B.1 Simulink Diagram of Tilt Gravity Simulation: Complete System . . . . . . . 50B.2 Simulink Diagram of Tilt Gravity Simulation: Tilt Dynamics Subsystem . . 50B.3 Simulink Diagram of Tilt Gravity Simulation: Equation of Motion Subsystem 51B.4 Simulink Diagram of Tilt Gravity Simulation: Gravity Load Subsystem . . . 51B.5 Simulink Diagram used with Tilt Friction Identification Script . . . . . . . . 51B.6 Simulink Diagram for Pan Data Collection . . . . . . . . . . . . . . . . . . . 52B.7 Pan Non-linear Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52B.8 Simulink Diagram of Final System . . . . . . . . . . . . . . . . . . . . . . . 53B.9 Final System: Trajectory Generation Block . . . . . . . . . . . . . . . . . . . 53

vi

List of Tables

3.1 Physical Meaning of Coefficients . . . . . . . . . . . . . . . . . . . . . . . . . 6

4.1 Inertia Data (in g-m2) at Various Tilt Angles . . . . . . . . . . . . . . . . . 134.2 Center of Mass in Z-Direction (in m) at Various Tilt Angles . . . . . . . . . 144.3 Identified Friction Data for Tilt Axis . . . . . . . . . . . . . . . . . . . . . . 144.4 Final PID Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.5 Webcam Timing Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.6 Image Processing Threshold Values . . . . . . . . . . . . . . . . . . . . . . . 344.7 Pixel to Volume Correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.1 Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.2 Raw Materials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.3 Labor Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

vii

Chapter 1

Introduction

The function of the Automatic Pouring Robot is to smoothly pour a specified amount ofliquid contained within the bottle into a cup. In order to help facilitate the completion of theproject, the system was divided into different subprojects. These included the mechanicalsystem, pan and tilt modeling and control, trajectory generation, and sensor development.

The mechanical system supports the bottle, and allows it to move in a controlled manner.The pan and tilt systems were modeled independently of each other, using different methods.The controllers were also designed independently, again, with separate methods, due to thedifferent requirements for each. Trajectory generation was used to give the bottle a smoothpath to follow when pouring, and was used in conjunction with the sensor to give the bottle acomplete path. The sensor subsystem, consisting of a webcam, allowed the entire system toaccurately pour specific amounts of liquid. Our original specifications stated that the systemwould be able to pour at a rate of approximately 25 mL/s with an accuracy of ±10mL. Thefinal system pours at about 125 mL/s, and is within 10 mL of the desired volume on average.

For the tilt mechanism, accuracy is much more important than speed, for precise pouring.We wanted a smooth, accurate following of the trajectory. Because of this, our specificationswere less than 0% overshoot, a rise time of less than 0.75 seconds, and less than 1% steady-state error. In testing, our results were calculated to be -0.675% overshoot, a rise time of0.316 seconds, and a steady state error of 0.675%.

For the pan mechanism, used for disturbance rejection, speed was more important thanaccuracy. As a result, our specifications were less than 5% overshoot, a rise time of less than0.4 seconds, and a steady state error of less than 2%. In testing, the actual performance wasfound to be an overshoot of 1.55%, a rise time of 0.134 seconds, and a steady state error of0.016%.

1

PictureStop?

Webcam

In1 Traj

Traj Generator

−K−

Torque toVoltage

In1 Out1

Tilt PID Controller

2*pi/(2048*4)

Tilt Encoder

Saturation1

Saturation

Tilt

Pan

Theta Tilt

Theta Pan

Pan−Tilt Dynamics30(s+1.266)(s+6.493)

(s+0.9)(s+19.486)

Pan Lead−Lag Controller

2*pi/(1024*4)

Pan Encoder

0

Holding Position

Figure 1.1: Block Diagram of Final System

Figure 1.1 is a block diagram showing the overall flow of the system. Both pan and tilt haveclosed-loops with encoder data feeding back information to the input so that the controllercan track the desired positions. The tilt has an additional outer loop containing the webcam.The volume currently in the cup, which is a function of the bottle’s tilt position, is constantlymonitored by a webcam. When the actual volume reaches a threshold value, which is a setfraction of the desired volume, the webcam triggers the return trajectory in the trajectorygeneration.

2

Chapter 2

Professional and SocietalConsideration

As our system had no internal wiring, and is only required to support the weight of a 500mL bottle, it was not required to conform to any set of codes or standards. A great deal ofresearch was performed to find systems similar to the final system, and none were found tomatch what we had constructed. Although other systems exist that perform the same task,pouring liquid into a cup, such as the D&A101 Autopour [5], they do so in a completelydifferent manner, such as compressed nitrogen, and thus, our system is not in violation ofany patents or copyrights.

The system could pose a safety threat if it were pouring hazardous material, and the con-trol system, for whatever reason, strayed from the planned trajectory, and started movingindependently. The material it contains, or the speed of the bottle itself, could injure some-one; however, there are safety precautions in place that prevent anything like this from everhappening. Our system presents no environmental concerns, as it has no byproducts, anddoes not affect the surrounding environment by its use.

If this system were ever mass produced and sold, it could bring about ethical dilemmas. Oneof the potential uses of this system is to mix dangerous materials. However, an extension tothis use is to use the system to create dangerous materials, such as Sarin Nerve Gas, AgentOrange, or Strychnine. Whether or not to sell this device to groups who would make suchchemicals is a great ethical dilemma. As the uses of this system are very specific, and lendthemselves to commercial applications more than residential, this system would not have adiverse economic impact.

3

Chapter 3

Design Procedure

3.1 Mechanical System Design

In order to pour liquid from a bottle, a mechanical system must first be constructed thatmeets specific criteria. These criteria include being a rigid system, allowing only movementin the desired directions, as well as an extremely large degree of movement. In its initialstages, the mechanical system went through a number of different iterations. The optimaldesign would minimize the inertia of the system, and thus, the placement of the motors andencoders was crucial. The final design for the system can be seen in Figure A.2.

A second part of the mechanical system also had to be designed. The webcam needed asolid mount, with a constant view of the cup into which the bottle was pouring. Here, thesimplest design possible was taken, using white foamboard, with just a mount, a base, abackdrop, and gussets to hold everything together. The design for this part of the systemcan be seen in Figure A.1.

3.2 Model Development

3.2.1 Tilt Modeling

The modeling of our system is particularly unique. Rather than modeling an object withconstant properties, our system has variable properties. This is due to the fact that thewater moves around in the bottle as the tilt angle is changed. In addition to this, as liquidis poured out of the bottle, the volume of water, and therefore overall mass, changes. Thisresults in a system with both variable values of inertia and center of mass.

To model our system, the below equation, representing the system dynamics, is implemented

4

in Simulink.

θ̈ + Fvθ̇ + Fcsgn(θ̇) = (Ixx + N2Im)V + mg cos(θ) (3.1)

To implement the varying system properties, an automated program written in Visual Basicextracts the properties from SolidWorks and outputs the results to a file, using the Solid-Works API [2]. These results are inserted into lookup tables in the Simulink diagram. Onecontains the inertia around the tilt axis at various tilt angles, and the other contains thelocation of the center of mass. Once the location of the center of mass is known in thez-direction, the parallel axis theorem is used to find the inertia about the tilt axis.

To complete an accurate non-linear model of the tilt axis, the friction values must be iden-tified. Friction exists between all moving parts in the system, such as the axle and thebearings, the belts and the pulleys, and even inside the motors. If accurately determined,this friction can be accounted for and canceled in the model. There are three types of frictionin the system: static, coulomb and viscous.

Static friction, sometimes referred to as “stiction,” is the force that exists between any twoobjects at rest. This friction must be overcome before the object(s) can move. For oursystem, static friction exists between the bearing mounts and the bearings, the balls and theinner and outer race of the bearing, the axle and the bearings, and the bottle mount and theaxle. In our case, the rolling resistance of the balls within the bearing must be overcome. Forthe final system, static friction values were not identified, as they change greatly dependingon the current tilt angle of the bottle and the amount of liquid in the bottle. This is becausethe inertia of the heavy bottle is the dominant force preventing motion.

Coulomb friction is a frictional force that exists between two objects that are in contact.The close proximity of their surfaces act to prevent the motion of the objects. This is anon-linear quantity that acts as a disturbance impulse to the model. Therefore, it is notpresent in the linear model of the system.

Viscous friction is a frictional force that resists objects in motion. The viscous friction isactually a property of the medium in which the motion of the object is occurring. Any fluidmedium, such as the grease in the bearings or the air, has an internal resistance to flow,which is represented by the viscous friction.

A script was run to determine both the coulomb and viscous friction values. This scriptattempts to approach steady-state velocities at various input torques, as one can infer thefriction values from the relationship between these quantities. However, the main problemwith this method of friction identification on the tilt axis is that the gravity loading is verysignificant for our system, since the full bottle has significant mass. This gravity loadingcauses oscillations around the steady state velocity. To try and remove this oscillatory effect,the system was placed on its side to remove the gravity effect. After finding the forwardand reverse friction values, the average of the two values is computed and inserted into the

5

Simulink model.

3.2.2 Pan Modeling

The model for pan is not as complex as the one needed for tilt, as it does not have any of thechanging inertias and centers of mass. Therefore, the full parameter identification methodwas used to determine the model. This method uses exclusively experimental data, and fitsthe coefficients of the standard joint equation, shown in Equation 3.2, to that data.

θ̈ + a1θ̇ + a2sgn(θ̇) = a3V + a4sin(θ) (3.2)

Coefficient Meaninga1 Viscous Frictiona2 Coulomb Frictiona3 Input Gaina4 Gravity Loading

Table 3.1: Physical Meaning of Coefficients

Table 3.1 shows the physical meaning of each of the four coefficients of the joint equation, allof which are normalized to the systems inertia. In our case, we can ignore the coefficient a4,as it represents the gravity loading, which only applies to the tilt axis. If this above equationis solved for θ̈, multiplied by θ̇ and then integrated over one sampling period, we can writethe equation [6]:

(θ̇2k+1 − θ̇2

k) = −a1(θ̇2k + θ̇2

k+1)ts − a2(∣∣∣θ̇2

k

∣∣∣ +∣∣∣θ̇2

k+1

∣∣∣)ts + 2a3Vk(θk+1 − θk) (3.3)

For each sampling period, the position is known from the encoder data, and the velocityinformation can be inferred. Therefore, the number of data samples far exceeds the numberof unknowns (3). We can find the least-squares error by placing all of these data points intoa matrix such that the θ̈ estimate is the product of the system matrix and the vector ofunknowns.

Ax = b (3.4)

A =

−(θ̇20 + θ̇2

1)ts −(∣∣∣θ̇2

0

∣∣∣ +∣∣∣θ̇2

1

∣∣∣)ts 2V0(θ1 − θ0)

−(θ̇21 + θ̇2

2)ts −(∣∣∣θ̇2

1

∣∣∣ +∣∣∣θ̇2

2

∣∣∣)ts 2V1(θ2 − θ1)...

......

−(θ̇2N−1 + θ̇2

N)ts −(∣∣∣θ̇2

N−1

∣∣∣ +∣∣∣θ̇2

N

∣∣∣)ts 2VN(θN − θN−1)

(3.5)

6

x =

a1

a2

a3

b =

(θ̇21 − θ̇2

0)

(θ̇22 − θ̇2

1)...

(θ̇2N − θ̇2

N−1)

Using these matrices, the minimum norm solution can be solved for, where the norm is theerror ||Ax− b||, as follows:

x̂ = A−1 (3.6)

x̂ = (AT A)−1ATb (3.7)

The vector x̂ represents the minimum error estimates for the coefficients a1, a2 and a3. Thepseudo-inverse (shown in Equation 3.7) must be used, as the number of data points is muchgreater than the number of unknowns, meaning that the A matrix is not invertible. Ourcoefficient estimates were obtained by placing experimental data for an arbitrary input intothe A and b matrices, and then solving for them using the pseudo-inverse.

Several different inputs were tried, and the one producing the lowest condition number(ideally 1) was used. To verify the model, the open loop response of the simulation wascompared with the actual open-loop response of the system. If the model was insufficient,then the process was iterated until an appropriate model was formed.

3.3 Trajectory Generation

Trajectory generation is a crucial part of this project. In order to successfully pour liquidfrom a bottle, the bottle can not simply be tipped at an extreme angle for a long periodof time; the bottle must be sent through a planned path. To tackle this problem, the firstsolution that was examined was fuzzy logic. This solution was dismissed for a number ofreasons however. The time involved in creating such an algorithm would have been too muchfor the time allotted. Secondly, the fuzzy logic algorithm would have depended greatly ondata from the webcam, and unfortunately, the data from the webcam is not of the qualitythat would allow us to get the fuzzy logic to work properly, even if time was not a factor.Instead, a much simpler design was implemented. Experimental data was taken, and fromthat, algorithms to create trajectories were created.

7

3.4 Control Design

The controllers for the Automatic Pouring Robot were designed with specific criteria inmind. The tilt controller needs to follow a smooth pouring trajectory, and therefore willneed a relatively slow response with high damping. Due to very specific requirements forthe tilt controller, a PID controller was implemented, primarily for its ease of tuning. Thishas changed from the lead-lag controller that we were originally planning to implement,primarily because we needed an easily tunable controller to account for any dynamics not inthe linear model, such as coulomb friction and a changing volume. The pan controller, onthe other hand, will be used for disturbance rejection, which requires quick response withlittle error. For this situation, a lead-lag compensator was used to give more design controlover the location of the closed-loop poles, which dictate the system response.

3.4.1 PID Design

The design process for a PID controller is a simplified one. It consists of three gains, pro-portional, integral, and derivative that can all be tuned. A PID can be generalized as thefollowing:

K(s) = KP +KI

s+

KDs1ps + 1

(3.8)

In a combined form, a PID controller takes the form:

K(s) =(KP

p+ KD)s2 + (KP + KI

p)s + KI

s(1ps + 1)

(3.9)

The derivative term above is implemented as a washout filter to keep the system proper(the order of the denominator is greater than or equal to that of the numerator) [1]. Theparameter p is the time constant of the washout, which determines both noise amplificationand the quality of the estimation.

The design of the PID controller simply consists of changing the three gains to achieve thedesired response. Increasing the proportional gain decreases the rise time and increasesovershoot. The integral term controls steady state error, but reduces the damping as it isincreased. Finally, the derivative terms smooths out the response by adding damping. Theinitial value testing was done in both linear and non-linear simulation, and then applied tothe final system when the simulation met the specifications.

8

3.4.2 Lead-Lag Design

The design for a lead-lag compensator is more involved than that of a PID controller. Itbegins by determining the allowable ranges for the undamped natural frequency, ωn, andthe damping ratio, ζ, based on the controller specifications. This is done using the followingrelationships:

Mo = e−π ζ√

1−ζ2 tr =1.8

ωn

(3.10)

Knowing the desired overshoot, Mo, and rise time, tr, one can solve for the allowable rangesof ωn and ζ. These are considered later, when looking at the root-locus. Then, the open-loopfrequency response of the system is examined, and the gain and phase margins determined.Knowing the desired margins, one can design a lead compensator, which follows the form:

D(s) = Ks + z

s + p|p| > |z| (3.11)

Since the pole is further from the origin, the phase shift added to the system will be positive.The phase can be added to the system such that the margins can be increased to thedesired levels. The center frequency for the added phase will be located at

√zp. The lead

compensator also pulls the root locus more towards the negative s direction in the s-plane,which allows for a higher ωn. As a result, a lead compensator has the tendency to speed upthe response of the system [1]. Therefore, the rise time and overshoot requirements must beexceeded before moving on to the lag compensator, which has the following form:

D(s) = Ks + z

s + p|z| > |p| (3.12)

Once the desired response is achieved, a lag compensator is added to the system to slowdown the response that was sped up by the lead compensator. The lag compensator also cantune the margin that was changed by the lead compensator. A lag compensator is one wherethe pole is closer to the origin than the zero, introducing a negative phase shift. The zerolocation is chosen such that it is about a decade below the frequency where the open-loopsystem has the desired phase margin plus 5◦. Then, the pole is located so that the desiredDC gain is met.

Once the lead and lag phases of the compensator are in place, the gain is determined usingthe root-locus. The gain is chosen such that the values for ωn, which is the distance betweenthe pole and the origin, and ζ, which is the cosine of the pole location with the real axis, arein the desired ranges calculated above.

9

3.5 Sensing Subsystem

A key portion of our overall goal is to be able to pour a user-specified amount of liquid intoa cup. For this to be possible, a form of feedback needs to tell the system how much wateris in the cup at any given time. Since the accuracy of the pour is dependent on how well thevolume feedback is, we want a source of feedback that is quick and accurate. After lookingat the alternatives, such as water level probes, weight sensors, and a webcam, the webcamwas chosen due to availability, as well as its ability to provide the desired feedback.

For the webcam to provide useful information, it needs to provide that information at aregular interval that is considerably quick compared to the flow rate of the liquid out of thebottle. To maximize the speed of image acquisition from the webcam, MATLAB’s ImageAcquisition Toolbox was used to save individual frames of a video stream at the highest ratepossible. As these images are grabbed from the webcam, they are run through an imageprocessing algorithm that was developed to tell how much liquid is in the cup.

The webcam was placed in a fixed location relative to the cup on a mount, which is describedin further detail in Chapter 4.1.2. For the webcam to be able to look at the cup and tellhow much volume is in it, there needs to be a contrast between the background and theliquid. Therefore, we used red liquid (first dyed water, and later Powerade) in all of ourexperiments. The mount was made entirely of white foam board, which created the neededcontrast between the red liquid and the white background. The algorithm to detect theamount of water in the cup was therefore a color detection algorithm. This algorithm usesthe color information from the captured frame to return the highest pixel row containingliquid.

The final step in the webcam feedback subsystem is to correlate the pixel information thatis returned from the webcam to the actual volume in the cup. This was done experimentallyby recording the readings for several known volumes.

10

Chapter 4

Design Details

4.1 Mechanical System

4.1.1 Bottle Mount

Having placed the motors and encoders in every conceivable location on the mechanicalsystem before arriving at the final locations, their placement was easily the most difficultpart of the design of the mechanical system. The system was to be able to stand on its own,on a flat surface, which again limited our options. Whereas the other systems have the panmotor protruding underneath the mechanical system, ours is integrated into the system, sothat the complete system can stand on its own, on its base. The pan encoder lies directly ontop of the base of the pan mechanism, and is the closest of all the components attached to thesystem to interfering with the bottle as it arcs 360 degrees. The tilt motor was attached tothe left side of the mechanical system, just outside of the arc that the bottle moves through.The tilt encoder was attached to the tilt axle, on the opposite end as the gears.

To meet the rigidity requirement, the additions to the mechanical system were cut from 1/4”aluminum plate. The height of the sides of the mechanical system was chosen specifically toallow the bottle to tilt 360◦, while keeping the bottle as low as possible. When the systemwas designed in CAD, there was approximately 1/8” between the lowest point on the bottlesarc and the top of the pan encoder, and after construction was finished, this gap was exactlyas it had been designed.

Another difficult aspect of the design was attaching the bottle itself to the tilt axle. Theoriginal design had a tilt axle that was in 2 pieces that connected around the bottle allowingthe bottle to rotate around its own center. In speaking with the TA, this design was altered,as the TA did not believe that the tilt axle could withstand this kind of force. Instead, thebottle was to be mounted directly adjacent to the axle, in order to keep the inertia as lowas possible, while maintaining a one-piece axle. The sides of the bottle taper in near the

11

middle, and then back out. At its maximum, the diameter of the bottle is 3”. A 3” exhaustclamp was purchased from a local auto parts store, to become the main piece that wouldmount the bottle to the axle. A small block of aluminum was machined to mount to theaxle, with set screws, and to the exhaust clamp, with socket cap screws. Once all thesepieces were assembled, they were very secure and rigid, however, the bottle itself could stillmove from left to right within the clamp itself. Upon adding a 1/8” layer of rubber betweenthe bottle and the clamp, the bottle was completely secured, moving only in the pan andtilt directions with the motors.

4.1.2 Webcam Mount

The webcam mount was designed with simplicity in mind. First, a material was to beselected. The webcam works best with a white background, that isn’t reflective. Whitefoamboard was chosen, because it has these characteristics, but is also rigid, unlike construc-tion paper. As part of the design, the webcam was mounted at a height equal to half thatof the cup that was poured into, minimizing the distance between the cup and the webcam.The webcam was mounted as close as possible to the cup while still having a small buffer ontop and below the cup. This placed the webcam approximately 111

2” from the center of the

cup. For the webcam to work properly, the cup was to be set against a white background. Inthe interest of conserving materials, the maximum viewing area was calculated 1/2” behindthe cup, and a piece of foamboard was cut to this size. The area was calculated to be 8”x8”.At its set distance from the cup, the webcam could not see past the edges of this backdrop.For ease of construction, the base that would connect the backdrop to the webcam mount, aswell as the webcam mount itself, were also cut to 8” wide. These three pieces were assembledwith foamboard gussets, and the final design can be seen in Figure A.1.

4.2 Modeling

4.2.1 Tilt Modeling

A Visual Basic program automates the extraction of center of mass, mass and moment ofinertia properties from Solidworks. The program steps through the angles 1◦, 10◦, 20◦, 30◦,40◦, 50◦, 60◦, 70◦, 80◦, 89◦, 91◦, 100◦, 110◦, 120◦, 130◦, 140◦, 150◦, 160◦, 170◦ and 179◦. Foreach of these angles, the program finds the height of water that will match a volume of 100mL, 200 mL, 300 mL, 400 mL and 500 mL. Based on these one hundred data points, theprogram generates three matrices corresponding to the moments of inertia about the x (tilt)axis, shown in Table 4.1, the centers of mass in the Z direction, shown in Table 4.2, andmass.

The three matrices are were inserted into Simulink lookup tables. Simulink will interpolate

12

Tilt Angle Volume100 mL 200 mL 300 mL 400 mL 500 mL

1◦ 2.05 2.75 3.18 3.46 3.7410◦ 2.06 2.77 3.19 3.48 3.7520◦ 2.08 2.78 3.21 3.5 3.7730◦ 2.08 2.79 3.23 3.53 3.7940◦ 2.08 2.8 3.25 3.56 3.8150◦ 2.06 2.79 3.26 3.59 3.8360◦ 2.03 2.76 3.27 3.62 3.8670◦ 1.98 2.68 3.23 3.63 3.9280◦ 1.90 2.57 3.11 3.6 4.0689◦ 1.77 2.46 3.07 3.62 4.0891◦ 1.74 2.44 3.06 3.60 4.05100◦ 1.66 2.34 2.93 3.44 3.88110◦ 1.69 2.17 2.67 3.19 3.70120◦ 1.69 2.09 2.47 2.95 3.56130◦ 1.68 2.05 2.37 2.79 3.45140◦ 1.67 2.01 2.31 2.71 3.36150◦ 1.66 1.98 2.27 2.66 3.30160◦ 1.65 1.96 2.24 2.63 3.26170◦ 1.64 1.94 2.21 2.60 3.23179◦ 1.63 1.92 2.19 2.58 3.21

Table 4.1: Inertia Data (in g-m2) at Various Tilt Angles

any values between the known values if that volume is given to the model.

Next, friction values must be identified. A script was run that measures the velocity withfor a range of input torques. An initial, high-torque (10 V for 0.25s) pulse is given to themotor to break static friction, and then the desired torque was applied. Then the velocityvalues are recorded for 10 seconds, as the motor to settles to its steady-state velocity.

For each constant input torque, the recorded velocity values are passed through a lowpassfilter to remove noise, and then a steady-state value is determined by averaging the last 10%of the values together. A tenth order butterworth filter was used to filter the data. Althoughsuch a high order filter adds some lag, that is allowable for this data, as we are only lookingfor the steady-state value of the velocity. The filtered velocity data is shown in Figure 4.1.

As can be seen, the velocity values never approach a steady-state value. This is due mostlyto the changing inertia of the water as the bottle rotates. The sloshing of the water inthe bottle also prevents the steady-state from being achieved. Therefore, the friction valuesidentified in this experiment obviously have some error.

Figure 4.2 shows the torque vs. steady-state velocity plot used to determine the frictionvalues. The coulomb friction is the first torque value at which the steady-state velocity is

13

Tilt Angle Volume100 mL 200 mL 300 mL 400 mL 500 mL

1◦ 0.03286 0.03585 0.03784 0.0393 0.0404210◦ 0.02742 0.02918 0.03112 0.03314 0.0351720◦ 0.02065 0.02098 0.02279 0.02537 0.0283130◦ 0.01341 0.01226 0.01386 0.01692 0.0205840◦ 0.00597 0.00339 0.00469 0.00809 0.0122550◦ -0.00139 -0.0051 -0.00422 -0.00075 0.0036260◦ -0.00849 -0.01231 -0.01205 -0.00918 -0.0049170◦ -0.01465 -0.0174 -0.01763 -0.01638 -0.0125380◦ -0.01833 -0.02052 -0.02081 -0.01919 -0.0165889◦ -0.01922 -0.01977 -0.01833 -0.01713 -0.0166191◦ -0.01888 -0.01843 -0.01732 -0.01663 -0.01701100◦ -0.01093 -0.01153 -0.01384 -0.0173 -0.02078110◦ -0.00887 -0.00994 -0.01511 -0.02042 -0.02527120◦ -0.01235 -0.01408 -0.01831 -0.02383 -0.03007130◦ -0.01705 -0.01903 -0.02271 -0.02797 -0.03436140◦ -0.02172 -0.02387 -0.02729 -0.0321 -0.03784150◦ -0.02589 -0.02824 -0.03143 -0.03558 -0.04034160◦ -0.02932 -0.03192 -0.03481 -0.03815 -0.04176170◦ -0.03186 -0.03474 -0.03722 -0.03962 -0.04198179◦ -0.03331 -0.03641 -0.03846 -0.03995 -0.04111

Table 4.2: Center of Mass in Z-Direction (in m) at Various Tilt Angles

non-zero, within a specified tolerance. The viscous friction is the slope of the least-squaresbest fit line of torque vs. steady-state velocity for all nonzero values of the latter. [6] TheMATLAB code and Simulink model used to generate the friction data is shown in AppendicesC.6 & B.5, respectively.

The results for the initial friction testing on the tilt axis are summarized below in Table 4.3.

Forward Reverse AverageCoulomb 0.130Nm 0.175Nm 0.153NmViscous 5.275x10−3 Nm s

rad 4.687x10−3 Nm srad 4.981x10−3 Nm s

rad

Table 4.3: Identified Friction Data for Tilt Axis

14

0 1 2 3 4 5 6 7 8 9 10−15

−10

−5

0

5

10

15

Time (s)

Vel

ocity

(ra

d/s)

Velocity vs Time for Various Input Torques

Figure 4.1: Velocity Data for Various Input Torques

−15 −10 −5 0 5 10 15−0.25

−0.2

−0.15

−0.1

−0.05

0

0.05

0.1

0.15

0.2

0.25

Steady−State Velocity (rad/s)

App

lied

Tor

que

(Nm

)

Torque vs. Steady−State Velocity

Figure 4.2: Friction Identification Data for Tilt Axis

15

4.2.2 Pan Modeling

To identify the model for the pan axis, the full parameter identification method describedin Chapter 3.2.2 was used. Various inputs were used starting with a sine wave at 6 rad/swith an amplitude of 3 V. This gave a negative a1 coefficient, which results in an unstablesystem. Other inputs were tested, but the one that ended up being used was a chirp signalwith a 2.5 V amplitude and that changes from a frequency of 0.25 rad/s to 5 rad/s over 10seconds. This data yielded a condition number of 10.2 for the AT A matrix, which was thebest of all inputs used.

When using the chirp input, the coefficients returned by the pseudo-inverse were a1 = 32.935,a2 = 157.088, and a3 = 227.737. Simulating the system with these coefficients yielded theresponse shown in Figure 4.3, which shows the simulated and actual responses to the chirpinput. The Simulink diagram used to simulate the pan model is shown in Appendix B.

0 1 2 3 4 5 6 7 8 9 100

1

2

3

4

5

6

7

Time (s)

Ang

ular

Pos

ition

(ra

d)

Actual vs. Simulated Chirp Response

SimulatedActual

Figure 4.3: First Pan Model: a1 = 32.935, a2 = 157.088, a3 = 227.737

As can be seen, the simulation travels much faster than actual. This points to the fact thatthe velocity estimation, which was done with an unfiltered discrete derivate, needs to beimproved. Also, looking at the error vector shows a very noisy error, similar to an unfilteredvelocity. Therefore, the velocity data was filtered before populating the A matrix. The filterused was a simple averaging FIR filter that considered the four most recent values at equalweights. Doing so resulted in the coefficients a1 = 1.862, a2 = 0.966, and a3 = 5.646. Thisradically changed the values of the coefficients, and made the response closer to the actual,as shown in Figure 4.4.

This response matches much closer to the actual response of the system. The steady-stateerror of the model is now less than 1 rad, and the amplitude of the steady-state oscillations

16

0 1 2 3 4 5 6 7 8 9 100

0.5

1

1.5

2

2.5

3Actual vs. Simulated Chirp Response

Time (s)

Ang

ular

Pos

ition

(ra

d)

SimulatedActual

Figure 4.4: Second Pan Model: a1 = 1.862, a2 = 0.966, a3 = 5.646

is much closer to the actual. This makes sense given the change in the coefficients, as thegain on the input, a3 was lowered considerably, which was not lowered as much as boththe coulomb (a2) and the viscous (a1) friction values. This prevents the simulation fromovershooting as much as it did in the first attempt, and keeps its speed much closer to thatof the actual.

To further improve the estimation, the filtering needs to be improved. However, the bettera filter is at removing noise, the more delay it usually adds. To account for this delay, notonly was the velocity filtered, but also the position, as well as the A and b matrices beforeperforming the pseudo-inverse. This allowed for the use of a 15th order butterworth lowpassfilter to smooth out the data nicely. Performing the pseudo-inverse on this data, and thenusing MATLAB’s optimization toolbox with Professor Wen’s help, yielded the coefficientsa1 = 1.908, a2 = 6.066, and a3 = 8.443. The response is shown in Figure 4.5.

This response matches much more closely. The steady-state error is now only 0.08 rad, andthe simulation does not overshoot the simulated too much. The change in coefficients makessense. The viscous friction, a1 stayed essentially the same, as the steady-state oscillationsmatched well before. The coulomb friction increased the most, dampening the overshootthat the model had. The input gain changed somewhat, but not to the degree that thecoulomb friction changed. This final model will be used for the control design.

17

0 1 2 3 4 5 6 7 8 9 100

0.5

1

1.5

2

2.5

3

Time (s)

Ang

ular

Pos

ition

(ra

d)

Actual vs. Simulated Chirp Response

SimulatedActual

Figure 4.5: Final Pan Model: a1 = 1.908, a2 = 6.066, a3 = 8.443

4.3 Trajectory Generation

The first step in creating the trajectories is understanding them. To do this, experimentaldata was taken of pouring from the bottle by hand, while the bottle is still in the system,so that encoder data can be taken. This experimental data can be seen in Figure 4.6.

0 1 2 3 4 5 6 7 8 9 10−2.5

−2

−1.5

−1

−0.5

0

Time (s)

Ang

ular

Pos

ition

(ra

d)

Encoder Data from Experimental Pours

Figure 4.6: Experimental Trajectories

18

Ignoring small fluctuations in the data, the pour consists mainly of 2 lines. The first, with asteep slope, tilts the bottle until it starts to pour. The second, which is much less steep thanthe first, pours liquid from the bottle at a constant rate. These 2 lines create the pouringtrajectory, but not the trajectory to return the bottle to its original position smoothly. These2 lines can be seen in Figure 4.7.

0 2 4 6 8 10 12 14−2.5

−2

−1.5

−1

−0.5

0

0.5

Time (s)

Ang

ular

Pos

ition

(ra

d)

500mL Simple Trajectory

Figure 4.7: Simple Trajectory for 500 mL Initial Volume

The point at which the bottle starts to pour, when the bottle is moving at a constant angularvelocity, is dependent on the amount of liquid in the bottle. More experimental data wastaken, and a linear function was created, which will tell the forward trajectory the point atwhich the bottle will start to pour, given the amount of liquid in the bottle to begin with. Tomake the pouring more uniform, regardless of the amount of liquid in the bottle originally,the forward trajectory starts on the same line every time, only changing to the pouring linewhen it starts to pour. The pouring line, regardless of how much liquid is in the bottle at thestart, always has the same slope, and the same vertical endpoint. Because of this, the lessliquid in the bottle at the start of the pour, the less time the pour will take. This data canbe seen in Figure 4.8. Although the lines shown are at set intervals, because the trajectorygeneration is based on linear functions, any amount of liquid between 0 and 500mL can beentered.

The system does not respond well to sharp changes in angular velocity, and so the trajec-tories are smoothed out by fitting the lines to a polynomial. Specifically, for the forwardtrajectories, the simple trajectories are fit to a fifth order polynomial. The same simple tra-jectories shown in Figure 4.8 are shown as smooth polynomials in Figure 4.9. The Simulinkmodel that uses these polynomials ignores forward trajectory data that is greater than 1, soalthough the polynomial forward trajectories pop up before 2 seconds, in actual execution,this does not happen.

This system is designed to be able to pour any amount of liquid less than or equal to the

19

0 2 4 6 8 10 12 14−2.5

−2

−1.5

−1

−0.5

0

0.5

Time (s)

Ang

ular

Pos

ition

(ra

d)

Simple Trajectories

500mL400mL300mL200mL100mL

Figure 4.8: Simple Trajectories for Various Initial Volumes

0 2 4 6 8 10 12 14−2.5

−2

−1.5

−1

−0.5

0

0.5

Time (s)

Ang

ular

Pos

ition

(ra

d)

Polynomial Trajectories

500mL400mL300mL200mL100mL

Figure 4.9: Polynomial Trajectories for Various Initial Volumes

amount in the bottle at the start, into a cup. To have open loop algorithms compute everypossible outcome would be absurd, and so the system depends on the webcam to determinewhen the bottle should return to the original position. The forward pouring trajectories arethe same for each specific volume of water. If there is 500mL of water in the bottle everytime, it will follow the same pouring trajectory each time.

Where the trajectories differ is the return. Once the water level in the cup has reached athreshold level, related to the desired amount of liquid, the system is told to return the bottle.At this instant, a return trajectory is created, based on the current position of the bottle,

20

the bottle stops following the forward trajectory, and instead follows the return trajectoryback to the original position. These return trajectories really only consist of 1 line, a straightline from the current position to the original position, over the span of 2 seconds. Some ofthese simple return trajectories can be seen in Figure 4.10.

0 0.5 1 1.5 2 2.5 3 3.5 4−2.5

−2

−1.5

−1

−0.5

0

0.5

Time (s)

Ang

ular

Pos

ition

(ra

d)

Simple Return Trajectories

Return Position = −0.5Return Position = −1.0Return Position = −1.5Return Position = −2.0

Figure 4.10: Simple Return Trajectories for Various Return Positions

As with the forward trajectories, the return trajectories are smoothed out by fitting themto a polynomial, only this time, it is a fourth order polynomial. The same simple returntrajectories can be seen in polynomial form in Figure 4.11. Once the return trajectoryreturns the bottle to the original position, in this case, 0, the Simulink model stops usingthe trajectory, and instead just holds the bottle. Because of this, the small sinusoid at thetail end of the return trajectory is ignored by the Simulink model, and the bottle is heldsecurely once it returns to 0.

The forward and return trajectories are used in conjunction with the webcam data to producea continuous, smooth trajectory for each pour. Some complete sample trajectories can beseen in 4.12.

21

0 0.5 1 1.5 2 2.5 3 3.5 4−2.5

−2

−1.5

−1

−0.5

0

0.5

Time (s)

Ang

ular

Pos

ition

(ra

d)

Polynomial Return Trajectories

Return Position = −0.5Return Position = −1.0Return Position = −1.5Return Position = −2.0

Figure 4.11: Polynomial Return Trajectories for Various Return Positions

0 2 4 6 8 10 12 14−2.5

−2

−1.5

−1

−0.5

0

0.5

Time (s)

Ang

ular

Pos

ition

(ra

d)

Full Sample Trajectories

500mL stopped at 10s300mL stopped at 7s200mL stopped at 5s400mL stopped at 9s

Figure 4.12: Sample Trajectories for Various Volumes and Return Positions

22

4.4 Control Design

4.4.1 Tilt Control Design: Trajectory Following

The controller for the tilt axis is designed to smoothly follow the pouring trajectory. As aresult, we want to meet the following specifications:

Mo < 0% tr ≤ 0.75s ess ≤ 1% (4.1)

As mentioned before, we are using a PID controller due to the ease with which it canbe tuned to meet the desired response. This is important for us, because the model isconstantly changing, so tweaking is constantly needed. The first phase of controller designwas linear control design. This is based on a linear model that was generated using thelinmod command. The model was linearized about a tilt of 90◦, because this is the locationin the tilt trajectory that has the highest inertia. Doing so yields a plant transfer functionof:

θ

τ=

79.2

(s + 2.77E − 5)(s + 1.21E6)(4.2)

This model obviously hides some of the dynamics, as it is essentially a system with a single-pole at the origin. The response of the closed-loop system with no compensation is extremelyslow, and has a steady-state error of 0.3 radians. This response is shown in Figure 4.13.

0 1 2 3 4 5 6 7

x 104

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8Step Response

Time (sec)

Am

plitu

de

Figure 4.13: Uncompensated Closed Loop Step Response

To speed this system up, we will add to the proportional gain. Likewise, we need to improve

23

the steady-state error, which is accomplished by increasing the integral gain. Finally, wewant a smooth, damped response, so we will have a relatively high derivative term. Initialvalues chosen with these in mind are KP = 14.5, KI = 3.75, and KD = 9.8. The simulatedresponses of these values is shown in Figure 4.14.

0 2 4 6 8 100

0.2

0.4

0.6

0.8

1

1.2

1.4

Time (s)

Am

plitu

de

Step Response

LinearNonlinear

Figure 4.14: Simulated Closed Loop Step Response with PID

The overshoot of the non-linear system is 2.87%, the rise time is 0.327s, and the steady-state error is 0.812%. Both the rise time and error specifications are met with these values.However, the overshoot is out of spec. Before further tuning was performed to reduce thisovershoot, the controller was run on the actual system to see how it performed. When puton the actual system, it responded with very high frequency oscillations. This was quicklyresolved by lowering the derivative gain to 10% of its original value. Although the derivativeterms is supposed to slow down the system, the velocity estimation on the washout filtercaused the derivative term to behave unexpectedly. The step response of the system withthe new controller is shown in Figure 4.15.

When placed on the actual system, the controller met the design specifications. The over-shoot was -0.138%, the rise time was 0.104s, and the steady-state error was 0.138%. Furthertweaking of the controller was done on the actual system. The response of this controller isactually faster than we want. The additional tweaking was done to smoothly follow a sinewave, rather than a step, to give a better idea of how it will follow the smooth trajectory.When tuning on the sine wave, the proportional and integral gains were both lowered, ef-fectively adding some damping to the system. This provided the slower response. The sinewave tracking with the final values is shown in Figure 4.16.

The final KP , KI , and KD values chosen are summarized in Table 4.4.

24

0 1 2 3 4 5 6 7 8 9 100

0.2

0.4

0.6

0.8

1

Time (s)

Ang

ular

Pos

ition

(ra

d)

Step Response

Actual

Linear

Nonlinear

Figure 4.15: Actual Closed Loop Step Response with PID

0 0.5 1 1.5 2 2.5 3 3.5 4−0.4

−0.3

−0.2

−0.1

0

0.1

0.2

0.3

0.4

Time (s)

Ang

ular

Pos

ition

(ra

d)

Sine Wave Tracking

Figure 4.16: PID Sine Wave Tracking

Now that we have modified the controller, we need to go back and make sure that thespecifications are still met. The step response of the final PID controller is shown in Figure4.17. The overshoot is -0.675%, the rise time is 0.316s, and the steady-state error is 0.675%,all within spec.

25

Gain ValueKP 7.5KI 2.5KD 0.75

Table 4.4: Final PID Values

0 1 2 3 4 5 6−0.2

0

0.2

0.4

0.6

0.8

1

1.2

Time (s)

Ang

ular

Pos

ition

(ra

d)Step Reponse

Figure 4.17: Closed Loop Step Response of Final Tilt Controller

4.4.2 Pan Control Design: Disturbance Rejection

The controller for the pan axis is used for disturbance rejection. Again, this means thatwe want a very fast response with small steady-state error. To achieve this, a lead-lagcompensator was designed. Our design specifications for this controller are

Mo < 5% tr ≤ 0.4s ess ≤ 2% (4.3)

A linear model of the pan axis must be developed before the controller can be designed.As described in Section 4.2.2, the coefficients of the joint equation for the pan model area1 = 1.908, a2 = 6.066, and a3 = 8.443. Since there is no gravity loading, and coulombfriction is treated as a disturbance input for the linear model, the transfer function of thepan axis can be written as the following transfer function.

θ

V=

8.443

s(s + 1.908)(4.4)

26

Since we want to design for a specific phase margin (ideal is around 45◦), the open loopfrequency response of the system is viewed. Figure 4.18 shows this frequency response, andthat the phase margin of the uncompensated system is 36.2◦.

−80

−60

−40

−20

0

20

40

Mag

nitu

de (

dB)

10−1

100

101

102

−180

−135

−90

Pha

se (

deg)

Bode DiagramGm = Inf dB (at Inf rad/sec) , Pm = 36.2 deg (at 2.61 rad/sec)

Frequency (rad/sec)

Figure 4.18: Open Loop Frequency Response of Pan Axis

The first phase of the control design for the lead-lag controller is to add a lead controllerto speed up the response of the system. Using the controller specifications in conjunctionwith Equation 3.10, the desired range for ωn is greater than or equal to 3.6 rad/s, and thedesired range for ζ is greater than or equal to 0.591. The center frequency for the leadcompensator was chosen to be 11.25 rad/s, so that it would add phase to the upper portionof the frequency response where it is close to −180◦. The desired pole-zero ratio was chosento be 3, giving a relatively large 30◦ of phase shift at the center frequency. Solving these twoequations yields the following:

√zp = 11.25

p

z= 3 (4.5)

p = −19.49 z = −6.493

The addition of this lead compensator boosts the phase margin to 64◦. However, whenlooking at the root-locus of the lead compensated system, shown in Figure 4.19, it can beseen that desired damping ratio can never be achieved. Therefore, we need to add a lagcompensator to boost the damping of the system.

Adding the lag compensator will cut down on the phase margin. However, the phase marginis well above the desired value, so that is acceptable. The poles and zeros of the leadcompensator are placed much closer to the origin than those of the lead compensator. The

27

Root Locus

Real Axis

Imag

inar

y A

xis

−12 −10 −8 −6 −4 −2 0−20

−15

−10

−5

0

5

10

15

20

0.591

0.591

Figure 4.19: Root-Locus of Lead Compensated System

rationale behind this is that we don’t want the lag compensator to interfere with the fastresponse that was achieved by the addition of the lead compensator.

Since the ideal phase margin is around 45◦, the zero was placed at one tenth of the frequencyof the location of the frequency at which a 53◦ phase margin exists, which is at 12.6 rad/s.For lag compensators, the offset of the the desired phase margin frequency is usually between5◦ and 10◦. The pole was then located such that the DC gain of the compensated system is1.4. The zero and pole locations were then found using the following equations

z = 0.1ωc Ks + z

s + p|s=0 = 1.4 (4.6)

z = −1.26 p = −0.9

The zero located closer to the origin has the effect of pinching the root-locus down so thatthe desired damping ratio can be met. However, this control design is entirely on the linearmodel. The non-linear model takes coulomb friction into account, which greatly reduces anyovershoot. Therefore, for the non-linear model, we are going to design out of the overshootspec in hopes that the non-linearities will reduce it. Figure 4.20 shows the root-locus of thecompensated system and the chosen gain of 7.25.

28

Root Locus

Real Axis

Imag

inar

y A

xis

−20 −18 −16 −14 −12 −10 −8 −6 −4 −2 0−40

−30

−20

−10

0

10

20

30

40

System: untitled1Gain: 7.23

Pole: −2.03 + 4.33iDamping: 0.424

Overshoot (%): 22.9Frequency (rad/sec): 4.79

Figure 4.20: Root-Locus of Lead-Lag Compensated System

This results in a controller of the form:

D(s) = 7.25(s + 6.493)(s + 1.26)

(s + 19.49)(s + 0.9)(4.7)

The frequency response of the system compensated with this controller is shown in Figure4.21. As can be seen, the phase margin is barely above the desired 40◦.

The simulated step response for this controller for both linear and non-linear simulation isshown in Figure 4.22. The response on the actual system is shown as well. This shows thatthe non-linearities, do in fact take care of the excessive overshoot. On the actual system,the overshoot was Mo = 5.23%, tr = 0.133s, and ess = 0.936%.

Final tweaking of controller gain was done when placed on the actual system. This resulted inthe step response shown in Figure 4.23. The new overshoot is 1.55%, the rise time is 0.134s,and the steady-state error is 0.356%. The settling time of the response is an importantfactor. Although no settling time requirement was initially set forth, the response of thissystem settles rather slowly despite the quick snap to the desired location. The settling timeto a value within 2% of the steady-state value is 0.356s. However, the settling time to avalue within 1% of the steady-state value is a much longer 1.548s. For large disturbances,therefore, it takes longer to cut down on all the error and return to the desired position.

29

−100

−80

−60

−40

−20

0

20

40

60

80

100

Mag

nitu

de (

dB)

10−2

10−1

100

101

102

103

−180

−135

−90

Pha

se (

deg)

Bode DiagramGm = Inf dB (at Inf rad/sec) , Pm = 40.1 deg (at 4.83 rad/sec)

Frequency (rad/sec)

Figure 4.21: Frequency Response of Compensated System

0 1 2 3 4 5 6 7 8 9 100

0.2

0.4

0.6

0.8

1

1.2

1.4

Time (s)

Ang

ular

Pos

ition

(ra

d)

Pan Controller Step Response

Linear

Nonlinear

Actual

Figure 4.22: Step Response with Original Design of Lead-Lag Controller

30

0 1 2 3 4 5 6 7 80

0.2

0.4

0.6

0.8

1

1.2

1.4

Time (s)

Step Response

Ang

ular

Pos

ition

(ra

d)

Figure 4.23: Step Response with Final Design of Lead-Lag Controller

31

The final disturbance rejection controller is:

D(s) = 30(s + 6.493)(s + 1.26)

(s + 19.49)(s + 0.9)(4.8)

4.5 Sensing Subsystem: Webcam

4.5.1 Image Acquisition

Several systems that have tackled the pouring problem have all done so with an open loopcontroller. However, we are providing feedback to the system with a webcam to determinethe volume currently in the cup. This will allow us to know when to stop pouring, so thatthe desired volume is poured into the cup.

The first step of the sensor development is to acquire images from the webcam. To do so,we are using MATLAB’s Image Acquisition Toolbox. A video input object is created, andit is configured to continually take images as fast as possible with logging enabled. [3] Assoon as an image is ready, it is grabbed from memory and sent to the image processingfunction, which returns the highest row of pixels filled with water. This data is comparedto the desired volume. This process is repeated continually. The script used to do this isshown in Appendix C.3.

The speed at which images can be grabbed and processed is a key factor in how close we canget to the desired volume. Therefore, the timing of the sensing is very important. Timingtests were done to see how well the webcam performs in comparison to its nominal framerateof 30 fps. First, the framerate was measured with no other operations performed. Then,the camera was continually polled in MATLAB. Next, image processing was added to thetest. For each case, the experiment was repeated 10 times, with each run acquiring 100frames. The average period and its standard deviation were determined. The timing resultsare summarized in Table 4.5.

Mean Period Standard Deviation Average FPSNo Logging 68.3 ms 18.8 ms 14.63

Logging 70.9 ms 27.4 ms 14.1Processing 71.0 ms 25.4 ms 14.09

Table 4.5: Webcam Timing Data

As seen, the camera, even when only acquiring images and saving them to memory, runs at14.63 fps, less than half of its advertised framerate. When the data is continually saved tothe workspace, the average period does not increase much, but the standard deviation of thetimes increases drastically. Image processing has very little effect.

32

The primary implication of this slow framerate is that the pouring speed will have to belimited. If the system pours too quickly with a slow framerate, then there is a chance thatthe system will over pour before the sensing subsystem can tell it that it went too far. On asample run, the system poured 305 mL into a cup in 3.7s. The average flowrate for that pourwas then was 82.4 mL/s. Since there are, on average, 14 frames per second, we can see that5.9 mL were poured per frame interval. This adds a significant uncertainty to our system,seeing as we are aiming for accuracy within 10 mL of the desired volume. In all actuality,the unknown window is most likely greater, as the above analysis was done assuming aconstant flow rate equal to the average. The actual flow rate, however, increases with time,so the greatest uncertainty is at the end of the pour, where we are trying to stop the systemaccurately.

4.5.2 Image Processing

Once the images are acquired, they are sent to a function that determines the highest pixelrow, using color detection. This method finds the pixels that are red, as determined bya tunable threshold value for component intensities. The images taken from the webcamare conveniently stored in the RGB format, so we can look for pixels that have a high Rcomponent and lower G and B components. [4] To facilitate this, the water used in thisproject will be dyed red with food coloring, allowing the algorithm to search for red in theimage. A downside to color detection is a relatively high sensitivity to noise. Even a smallchange in lighting conditions will change the needed threshold values. For this reason, theviewing conditions are fixed and the algorithm tuned to it. The cup will be completelysurrounded by white to improve contrast for the webcam.

The function to find the highest row of pixels is rather straightforward. First of all, sincethe webcam has a better horizontal resolution than vertical resolution (288x352), the imageswill be rotated 90◦ clockwise from the upright position. A band in the middle of the cupthat is 30 pixels wide is focused on so that no pixels outside the boundary of the cup willbe considered. Then the average pixel value for each column within this band is found, andthat value is applied to threshold component color values. These values were determined ona sample setup.

The threshold values were determined using a sample image. If the viewing plane of thewebcam is above the water level (volume in cup < 200 mL), all the pixels above the waterline had a greenish tint due to the reflection of the light off the top of the water’s surface.If the viewing plane is below the water level, all of the pixels above the water line are whitedue to the background. Therefore, the key threshold color is the green one. The image hasvery little blue in it, so that threshold just needs to be set high enough that it accepts allred pixels. The green threshold, however, must be tuned to get a good reading from thewebcam. Table 4.6 shows the final threshold values determined. These values are good aslong as the lighting conditions in the lab remained relatively unchanged.

The image processing algorithm returns the highest pixel row in the webcam’s view that

33

Figure 4.24: Graphical Flow of Image Processing Algorithm

GT or LT Pixel ValueRed > 100

Green < 69Blue < 30

Table 4.6: Image Processing Threshold Values

has liquid in it. This was correlated to actual volumes through an experiment where knownvolumes were placed in the cup at 25 mL increments using a graduated cylinder. The volumesand the corresponding readings were placed in a Simulink lookup table with interpolationso that any values in between would be interpolated from the known data points. Table 4.7shows the pixel to volume correlation.

Volume Pixel Volume Pixel Volume Pixel0 0 150 117 300 20525 33 175 132 325 22150 55 200 147 350 23575 70 225 161 375 251100 86 250 176 400 267125 101 275 191 425 283

Table 4.7: Pixel to Volume Correlation

Looking at the data in Table 4.7 shows that it is much more linear than expected. Theviewing angle seems to have little effect on the webcam reading. Regardless of whether thewater level is near the top or near the bottom, each 25 mL increment almost always hasbetween 14 and 16 pixels. The above experiment was originally done in finer increments of5 mL. However, when using such small increments, the error in measuring the volume withthe graduated cylinder built up so that the actual volume in the cup was about 25 mL offfrom what was expected at the end. Increments of 25 mL was found to be reasonable forboth accuracy and resolution.

The webcam is used to trigger the return trajectory when enough liquid has been pouredinto the cup. This was done by setting a percentage threshold. When the volume in the cup

34

reaches a certain point, the return trajectory is triggered. Even after this happens though,more liquid will come out of the bottle. The threshold value, therefore, needs to estimatethe amount of liquid that will come out after the trigger to make an accurate pour. Allof this is based on the assumption that the system is at a reasonable flow rate at the timeof triggering. This is a valid assumption, though, since any trajectory generated will be asmooth one that maintains the flow rate.

The amount of liquid that comes out of the bottle after the return trajectory is a functionof the flow rate before triggering, the speed of the return trajectory, and the communicationtiming delay between MATLAB and xPC target. The threshold values were determinedthrough trial and error for various desired volumes. There are two separate thresholds,depending on whether we are trying to pour a large or small amount of liquid. The mainproblem with this method, however, is that it is very sensitive to noise. The return triggeris a one time event, and it can be prematurely initiated by a noise spike. This is especially aconcern at lower volumes, where the liquid sloshes around the cup a little bit before settlingdown into a an accurately readable state.

The webcam must be calibrated each time before use. The calibration consists of two steps.The first is to verify the threshold values in the current lighting environment. To do so,an image is grabbed with the webcam, and then the user must view the image using theImage Viewer. The threshold value for green and/or blue must be changed so that they arebetween the pixels values on either side of the water level border. Secondly, any movementof the webcam must be accounted for. The back flap of the webcam mount can move slighly,changing the angle at which the webcam is aimed. To account for this, an image is simplygrabbed from the webcam when a known volume is in the cup. Then, the bottom pixelof the picture segment that is analyzed can be changed such that the volume matches theknown volume in the cup.

The calibration procedure that is necessary before each operation adds to the uncertainty ofthe webcam feedback. If the known volume is slightly different than what is thought, thenthe webcam readings will all have an error corresponding to this difference. Likewise, anyshadows that are cast over the viewing area can alter the required threshold values. Finally,as the water is being poured into the cup, the water level is rarely parallel to the table. Thiswas partially accounted for by looking at only the very middle of the cup, around which thependulum-like motion of the water occurs. The middle stays relatively flat compared to theouter edges of the cup. These uncertainties, in addition to the relatively slow timing, arethe crucial flaws in the webcam feedback that hinder system performance.

35

Chapter 5

Design Verification

To verify the design, several different test were run on various parts of the project. Beforeanything else can be validated, the dynamic models of both the pan and tilt axes must beverified. The model for the tilt was verified by comparing actual and simulated data forthe system’s response to an input. Figure 5.1 shows a test where the bottle was held in theupright position, and then let go. The plot shows the actual and the simulated open loopresponse to gravity.

Figure 5.1: Results for Gravity Testing: Simulated and Actual

There are several discrepancies between the simulation and experimental plots shown inFigure 5.1. First, the mass values extracted from SolidWorks are incorrect by a factor of1.7. After adding this gain into the Simulink block diagram, the simulated plot matched

36

the experimental plot more closely (Figure 5.1 includes this gain already). Second, the finalresting point of the simulation and experimental differ. This difference is due to the absenceof a quantized encoder in the simulation and error in the friction identification. Overall, thetilt modeling is valid because the two plots nearly match.

Next, the pan model needs to be verified. To do so, several inputs were given to the system.The open loop response to that input was recorded, and also simulated. The two responseswere compared to see how well the model matches the actual response. Figure 5.2 shows theactual and simulated responses to a chirp input, as well as the error.

0 1 2 3 4 5 6 7 8 9 100

0.5

1

1.5

2

2.5

3

Time (s)

Ang

ular

Pos

ition

(ra

d)

Actual vs. Simulated Chirp Response

SimulatedActual

(a) Compared Response

0 1 2 3 4 5 6 7 8 9 10−0.3

−0.25

−0.2

−0.15

−0.1

−0.05

0

0.05

0.1

Pos

ition

Err

or (

rad)

Time (s)

Error of Pan Model: Chirp Input

(b) Error

Figure 5.2: Pan Open Loop Chirp Response

As seen, the model matches the input fairly well. The error is large initially, but cuts downto a steady-state error of around 0.08 rad, which is only about 5◦. The model does notperform as well for all inputs, however. Figure 5.3 shows the actual and simulated responsesto a sine input.

The error for this input is much greater than for the previous input. The pan model,therefore, definitely has some modeling error, which increases the control effort for the panaxis. The response of the controller is slightly better in one direction than in the other.This is largely due to an inaccurate model, that doesn’t account for the varying inertiain different directions. No better fit could be found using the full parameter identificationmethod. Therefore, to account for the differing inertia that was originally thought to benegligible for pan, an analytical model like the tilt model would have been more accurate.

37

0 1 2 3 4 5 6 7 8 9 10−3

−2

−1

0

1

2

3

Time (s)

Pos

ition

(ra

d)

Actual vs Simulated Open Loop Sine Response

Actual

Simulated

(a) Compared Response

0 1 2 3 4 5 6 7 8 9 10−0.7

−0.6

−0.5

−0.4

−0.3

−0.2

−0.1

0

0.1

Time (s)

Pos

ition

Err

or (

rad)

Error of Pan Model: Sine Input

(b) Error

Figure 5.3: Pan Open Loop Sine Response

The heart of the project is the tilt, which performs all of the pouring. Therefore, the tiltcontroller needs to be verified against an actual pouring trajectory. In the design phase, itsstep response was looked at as well as the sine wave tracking capabilities. However, we wantto see how well the controller performs during an actual pour, where it has to follow thetrajectory as the mass properties of the bottle are changing. Figure 5.4 shows the controller’stracking of a trajectory during an actual pour.

6 8 10 12 14 16 18 20 22 24−1

−0.5

0

0.5

1

1.5Response to Sample Trajectory

Time (s)

Ang

ular

Pos

ition

(ra

d)

Figure 5.4: Pouring Trajectory Tracking During Pour

38

As can be seen, the controller performs very well in following the desired trajectory as thewater is being poured out. The place where it deviates the most is at the very end of thetrajectory, since the actual is slightly behind the desired due to the high damping that wasadded for a smooth response. This is acceptable, since the pour is over at this point. Thehigher damping on the control response also helps smooth out the sharp transition when thereturn trajectory is triggered.

The final portion that needs to be verified is the webcam feedback system. To do so, we willlook at three sample webcam pours. The first starts with a full bottle (500mL) and poursto a high volume (300mL). Figure 5.5 shows the webcam data for this pour.

7.5 8 8.5 9 9.5 10 10.5 11 11.50

50

100

150

200

250

300

350

Time (s)

Vol

ume

(mL)

Webcam Data of an Actual Pour

Figure 5.5: Webcam Data for 500mL Pouring 300 mL

As can be seen, the webcam feedback is very noisy, especially at lower volumes. This is thepoint at which the liquid is splashing all around from the initial impact with the cup. Astime progresses, the pour smooths out and the webcam data becomes a little cleaner. Also,the pour stopped at a volume within 5mL of the desired 300mL, measuring 305 mL. Thetiming delay between samples is seen to be pretty significant, as certain intervals have largeincreases in volume. Figure 5.6 shows the data from the next pour, which is 300mL initialvolume pouring 250mL into the cup.

39

7 7.5 8 8.5 9 9.5 10 10.5 11 11.50

50

100

150

200

250

300

Time(s)

Vol

ume

(mL)

300 mL Pouring 250 mL

Figure 5.6: Webcam Data for 300mL Pouring 250mL

Again, the final volume in the cup was within the original specification of 10 mL. This time,260 mL were poured into the cup when it was trying for 250 mL. Just as with the previouspour, the most noise occurred when the pour was starting, and began to settle out near theend. Also, the webcam proved to be accurate enough to trigger the stop within the necessarytime frame. Figure 5.7 shows a final pouring attempt where 100 mL was trying to pour allof its contents into the cup.

The webcam data here shows a couple of interesting things about the system. First of all,since this was a small pour, the overall data is very noisy, and never has a chance to smoothout. In addition, the return is triggered before it needed to be. The final volume in the cupwas 85 mL, which is outside of the original specifications. The system has a much hardertime accurately pouring specific amounts when the desired amount is below 200 mL. This isdue to the quick pour where the webcam noise never gets to settle, in addition to the flowrate never really reaching its maximum value. In this case, the webcam failed to providefeedback that was both clean and quick enough to meet the specification.

40

4 5 6 7 8 9 10 110

10

20

30

40

50

60

70

80

90

100

Time (s)

Vol

ume

(mL)

100 mL Pouring 100 mL

Figure 5.7: Webcam Data for 100mL Pouring 100mL

41

Chapter 6

Costs

As part of the costs, our group had to pay $35 for additional machining for the mechanicalsystem. This cost is somewhat unavoidable. The structural pieces of the mechanical systemwere cut using a computer controlled waterjet, ensuring incredible accuracy. Although thepieces could have been machined by hand, they would either not have been as accurate, orwould have taken much longer. These structural pieces are to support the tilt axle, andwhen supporting a rotating assembly, accuracy is essential. In a one-semester class, time isalso of the essence, and so, we chose the additional machining.

In testing our pan controller, we encountered trouble with the motor. Its response waswavering, and eventually, it would not respond at all. Several attempts were made to takeapart the motor and fix the problem. However, it remained inoperable. In the interest ofhaving a completely functional system, we purchased a new motor for $105, to replace thebroken one. The addition of the new motor enabled the system to work to its full potential,pouring in the tilt plane while rejecting disturbances in the pan.

42

Table 6.1: PartsItem Quantity Cost Total CostCup 1 $1.25 $1.25

Bottle 1 $1.45 $1.45Red Dye 1 $1.00 $1.00

Powerade (32 fl. oz. Bottle) 2 $1.68 $3.36Logitech WebCam 1 $29.95 $29.95

3” Universal Exhaust Clamp 1 $3.24 $3.24Pan Belt 1 $3.92 $3.92

Pan Gear A 1 $9.97 $9.97Pan Gear B 1 $22.02 $22.02

Tilt Belt 1 $4.00 $4.00Tilt Gear A 1 $7.95 $7.95Tilt Gear B 1 $22.02 $22.02

Pittman Motor GM9234S017 3 $100.00 $200.00Replacement Motor GM9234S017 1 $100.00 $100.00

Total $410.13

Table 6.2: Raw MaterialsItem Quantity Cost Total Cost

1/4” Aluminum Plate 500 in2 $0.16 /in2 $80.00Sand for Waterjet $5.00 $5.00White Foamboard 3/16” 32x40 $2.58 $2.58

Total $87.58

Table 6.3: Labor CostsDescription Hours Cost Total CostAkilah Harris-Williams (Engineer) 80 $25.00 $2000Adam Olmstead (Engineer) 200 $25.00 $5000Philip Pratt-Szeliga (Engineer) 128 $25.00 $3200Will Roantree (Engineer) 200 $25.00 $5000Jim Schatz (Waterjet Operator) 1 $30.00 $30.00

Total $15230

43

Chapter 7

Conclusions

The system was an overall success when comparing its actual performance to the originalspecifications laid out in the proposal. At that time, we were hoping to have a system thatcould pour water into a cup within 10 mL of a specified volume at a rate such that the cupcould be filled in 20 seconds. On average, we were able to meet the specification calling fora volume within 10 mL, with an occasional pour outside of the desired range. The secondspecification, however, we were always able to surpass. The rate at which we poured eachtime resulted in a cup that would be full in under 6 seconds. For the pour shown above inFigure 5.5, the machine poured 304.7 mL of water into the cup in 3.7 s, when the desiredvolume was 300 mL.

Several difficulties were overcome in the completion of this project. The modeling and controlwere particularly difficult due to the massive system with changing inertia. Additionally,geometry and weight distribution was not symmetric around either axis due to the largemotors. This ambiguity made the control design more difficult, because the controllers werebased off of models that were either ignoring certain dynamics or just otherwise inaccurate.

Although the system achieved the original goal, improvements can always be made. One arewhere enhancements are needed is the modeling, especially that of the pan axis. Cuttingdown on the error for various inputs and making a better model would enhance the controldesign. Another enhancement that could have been made is adding a third degree of motionfor the cup. Right now we are pouring into a stationary cup, and as a result, sometimeswater will hit the lip of the cup and trickle down the side. If we were able to move the cuptowards and away from the bottle, we could avoid those drips.

The control also could have been improved, particularly by adding in fuzzy logic controls.Right now, the controller follows a smooth trajectory based on experimental data. Althoughthis is the optimal solution given the time and equipment constraints, a more interestingcontrol problem is addressed by adding the fuzzy logic controls. This, however, would requirea quicker and cleaner form of feedback. The webcam has too many inaccuracies due to thewater splashing, the slow framerate, and the sensitivity to light. For the fuzzy logic to work

44

well, constant, accurate feedback is needed so that the pouring can be based off of it. Thewebcam data is currently too noisy for this. Overall, though, this project represents aninteresting problem with many layers, and is a window into more complex areas of modelingand control.

45

Bibliography

[1] Prof. Joe Chow. Course notes. Control System Engineering, 2004.

[2] SolidWorks Corporation. Api support. http://www.solidworks.com/pages/services/APISupport.html.

[3] The MathWorks Inc. Image acquisition toolbox user’s guide. http://www.mathworks.

com/access/helpdesk/help/toolbox/imaq/.

[4] The MathWorks Inc. Image processing toolbox user’s guide. http://www.mathworks.

com/access/helpdesk/help/toolbox/images/.

[5] Dana Advanced Automated Systems. Casting robot d&a101. http://www.novindana.

com/da101.shtml.

[6] Prof. John Wen. Course notes. Control System Design, 2005.

46

Appendix A

SolidWorks Models and Pictures

Figure A.1: Webcam Mount: SolidWorks

47

Figure A.2: SolidWorks Model of Mechanical System

48

Figure A.3: Picture of Mechanical System

49

Appendix B

Simulink Diagrams

theta

To Workspace1

tau

volumetheta

Tilt dynamics

original_volume

Original Volume

0

Input Torque180/pi

Gain2

Figure B.1: Simulink Diagram of Tilt Gravity Simulation: Complete System

1theta

1s

thetadot−>theta

1s

thetaddot −> thetadot

Saturation

tau

theta

thetadot

volume

thetaddot

Equation of Motion

2

volume

1tau

Figure B.2: Simulink Diagram of Tilt Gravity Simulation: Tilt Dynamics Subsystem

50

1thetaddot

u[1]/(u[2]+N2^2*Im2)

tau / (Ixx + N^2*Im) = thetaddot

Inertia Tensor − X Axis

thetavolume G(theta)

Gravity Load

fv2*u[1] + fc2*sgn(u[1])

Friction

4

volume

3thetadot

2theta

1tau

Figure B.3: Simulink Diagram of Tilt Gravity Simulation: Equation of Motion Subsystem

1

G(theta)

mB (u[2])

center of mass Z (u[1])

1.7

Gain1

−u[2]*g*u[1]

G2

2

volume

1

theta

Figure B.4: Simulink Diagram of Tilt Gravity Simulation: Gravity Load Subsystem

4

Out1

3

Pos1

2

Vel2

1Vel1

Step3

Step2

Step1

Step

Saturation1

Saturation PCIM−DAS1602/16ComputerBoards

Analog Output

1

2

PCIM−DAS1602 16 PCI−QUAD04Comp. BoardsInc. Encoder

Count

PCI−QUAD04 1

PCI−QUAD04Comp. BoardsInc. Encoder

Count

PCI−QUAD04

−K−

Gain3

2*pi/(1024*4)

Gain2

−K−

Gain1 2*pi/(1024*4)

Gain

K (z−1)Ts z

Discrete Derivative1

K (z−1)Ts z

Discrete Derivative

Figure B.5: Simulink Diagram used with Tilt Friction Identification Script

51

3

In

2

Pos1

1Vel1

Saturation

PCIM−DAS1602/16ComputerBoards

Analog Output2

PCIM−DAS1602 16

PCI−QUAD04Comp. BoardsInc. Encoder

Count

PCI−QUAD04

2*pi/(1024*4)

Gain

num(z)

1

Discrete Filter

K (z−1)Ts z

Discrete Derivative

Chirp Signal

0.5

Amplitude

Figure B.6: Simulink Diagram for Pan Data Collection

input

To Workspace2

theta_dot

To Workspace1

theta

To Workspace

1s

Theta_Dot

1s

Theta

Sign

a3

Gain2

a2

Gain1

a1

Gain

simin

FromWorkspace

Figure B.7: Pan Non-linear Simulation

52

4

theta_out

3

Out1

2

Out2 1

theta_out1

(s+1.266)(s+6.493)

(s+0.9)(s+19.486)

Zero−Pole

Traj

Traj Generator

−K−

T−>V Saturation1

Saturation

In1 Out1

PID 1

PCIM−DAS1602/16ComputerBoardsAnalog Output

1

2

PCIM−DAS1602 16 1

PCI−QUAD04Comp. BoardsInc. Encoder

Count

PCI−QUAD04 1

PCI−QUAD04Comp. BoardsInc. Encoder

Count

PCI−QUAD04

2*pi/(2048*4)

Gain2

30

Gain1

2*pi/(1024*4)

Gain

0

Constant

Figure B.8: Simulink Diagram of Final System

1

Traj

Subtract1

Subtract

0

StopTime

0

Start Time Merge

Merge

0

Initial Pos

if { }In1 Out1

If Empty

elseif { }In1 Out1

If Done

u1

u2

u3

u4

if(..)

elseIf(..)

else

If

0

Hold Pos

else { }In1 Out1

Hold

P(u)O(P) = 5

Forward Traj

12:34

Digital Clock

P(u)O(P) = 4

Back Traj

Add

Figure B.9: Final System: Trajectory Generation Block

53

Appendix C

MATLAB Code

C.1 Final Operation Script

% Adam Olmstead

% Team 1 ECSE-4692

% Final Script

% Create the video input object if it doesn’t exist

if exist(’vid’) ~= 1

vid=videoinput(’winvideo’,1);

end

% Create xPC Target object if not there

if exist(’tg’) ~= 1

tg=xpc;

load(tg,’final’);

end

% Causes videoinput to loop endlessly until stopped

set(vid,’TriggerRepeat’,Inf);

% Reset the simulation

tg.setparam(12,0);

tg.setparam(13,0);

tg.setparam(15,0);

ind=zeros(2);

pixrow=0;

time=[];

webcam=[];

54

stoptime=0;

starttime=0;

stoppos=0;

inbottle=0;

des_vol=0;

vol=0;

choice=0;

% Get the desired volume from the user

while (inbottle<=0 | inbottle>500)

inbottle=input(’Please input volume in bottle (0 <= vol <500)\n’);

end

% Set forward trajectory

for_traj=fortrajgen(inbottle);

tg.setparam(14,for_traj);

% Get the desired volume from the user

while (des_vol<=0 | des_vol>=425)

des_vol=input(’Please input desired volume in mL (0 <= vol <=425)\n’);

end

% Set the threshold

if des_vol <= 175

mult=0.58;

else

mult=0.695;

end

% Start motors

start(tg);

% Have the user position the bottle at zero

while choice ~= 3

choice=menu(’Locate Zero’,’Up’,’Down’,’Go’);

% Adjust the bottle’s position based on the user’s input

switch choice

case 1

tg.setparam(12,tg.getparam(12)+0.05);

case 2

tg.setparam(12,tg.getparam(12)-0.05);

otherwise

starttime=tg.ExecTime;

tg.setparam(13,starttime);

55

end

end

% Start taking data from the webcam

start(vid);

% Continue taking data from the webcam until the desired volume has been

% added to the cup

while( (vol<mult*des_vol)&(tg.getsignal(9)>=tg.getparam(12)-2.1) )

% Grab an image and process

[pixrow,t]=getimage(vid);

% Look up volume from table

vol=pix2vol(pixrow,pixvol);

% Log the webcam data

webcam=[webcam;vol];

time=[time;t];

if vol>0.25*des_vol & ind(1,1)==0

ind(1,:)=[vol t];

elseif vol>0.5*des_vol & ind(2,1)==0

ind(2,:)=[vol t];

flowrate=(ind(2,1)-ind(1,1))/(ind(2,2)-ind(1,2));

end

end

% Get the time that the cup was filled and the location that the cup was at

% to xPC target for the return trajectory

stoptime=tg.ExecTime;

stoppos=polyval(for_traj,stoptime-starttime);

% Call the function to generate the return trajectory and pass it to xPC

% target

back_traj=traj(stoppos)’;

tg.setparam(16,back_traj);

tg.setparam(15,stoptime);

% Wait for position to return to hold position

while tg.ExecTime<stoptime+2

end

% Hold at holding position

tg.setparam(13,0);

56

% Stop the video

stop(vid);

% Get remaining frames

[data,t]=getdata(vid,get(vid,’FramesAvailable’));

time=[time;t];

for i=1:size(data,4)

webcam=[webcam; howmuch(data(:,:,:,i))];

end

% Stop xPC target

stop(tg);

C.2 Pixel to Volume Conversion

function vol=pix2vol(pixrow,pixvol);

vol=pixvol(find(pixvol(:,1)==pixrow),2);

C.3 Image Acquisition and Processing

function [pixrow,time]=getimage(vid)

%[PIXROW]=GETIMAGE(VID)

% Takes in video input object VID and acquires frames

% Wait for a frame to be available (system bottleneck is the

% framerate of the webcam)

while vid.FramesAvailable==0

end

% Save the last acquired frame (if more than one)

[data,time]=getdata(vid,get(vid,’FramesAvailable’));

image=data(:,:,:,size(data,4));

time=time(end);

% Call the image processing function

pixrow=howmuch(image);

57

function pixrow=howmuch(I);

%PIXROW=HOWMUCH(I);

% Function takes in an RGB formatted image from the webcam. It analyzes

% this image and returns the highest pixel row that contains liquid. This

% is done using color detection of the red-dyed water

%

% Author: Adam Olmstead for ECSE-4692 Rensselaer Polytechnic Institute

% Set the boundaries for the pixels

leftbound=110;

rightbound=140;

bottombound=21;

topbound=335;

% Set color component thresholds

redthresh=100;

greenthresh=69;

bluethresh=30;

% Only look at the a certain portion of the cup. The image should be on its

% side (knob to left), as the horizontal resolution of our camera is better

% than the vertical resolution

I=I(leftbound:rightbound,bottombound:topbound,:);

avg=mean(I);

% Apply threshold values to the averages. Finding the max will find the

% rightmost pixel column whose average meets the threshold requirements.

% This corresponds to the highest point in the cup

pixrow=max( find(avg(:,:,2)<greenthresh & avg(:,:,3)<bluethresh) );

% If max returns the empty matrix, return 0

if length(pixrow)==0

pixrow=0;

end

C.4 Forward Trajectory Generation

function coeff=fortrajgen(vol);

ycoeff=[0.00125 -1.925];

58

ypos=polyval(ycoeff,vol);

x=[0 1 2 ...

ypos/-0.65+2 ...

ypos/-0.325+2 ...

mean([ypos/-0.325+2;-8*(ypos/2-1.1-ypos*0.8/1.3-1/4)]) ...

-8*(ypos/2-1.1-ypos*0.8/1.3-1/4) ...

mean([-8*(ypos/2-1.1-ypos*0.8/1.3-1/4);-8*(-2.2-ypos*0.8/1.3-1/4)]) ...

-8*(-2.2-ypos*0.8/1.3-1/4)];

y=[0 0 0 ypos/2 ...

ypos ...

mean([ypos;ypos/2-1.1]) ...

ypos/2-1.1 ...

mean([ypos/2-1.1;-2.2]) ...

-2.2];

coeff=polyfit(x,y,5)’;

C.5 Return Trajectory Generation

function P = traj(p_return)

%y_data(1)=p_return;

%y_data(2)=p_return;

y_data(1)=p_return;

y_data(2)=0.5*p_return;

y_data(3)=0;

y_data(4)=0;

y_data(5)=0;

%x_data(1)=0;

%x_data(2)=1;

x_data(1)=0;

x_data(2)=1;

x_data(3)=2;

x_data(4)=3;

x_data(5)=4;

P=polyfit(x_data,y_data,4);

59

C.6 Friction Identification Script

% Adam Olmstead

% Team 1 ECSE-4692

% Friction Identification Script

% 2/28/05

% Initialize Variables

vss_sat=0.25;

count=0;

tests=3;

% Torque and Time Vectors

torque=-vss_sat:0.005:vss_sat;

time=0:0.001:tg.get(’stoptime’);

% Hold average velocity values for each torque value

clear vels;

vels=zeros( tg.get(’stoptime’)/0.001+1,length(torque) );

% Hold velocity values recorded before averaging

clear temp_vel;

temp_vel=zeros( tg.get(’stoptime’)/0.001+1,tests );

%%%% Friction Testing Data Collection

% Only one set of motors being tested at a time

setparam(tg,31,0);

setparam(tg,32,0);

% Loop to gain data from motors at various torque values

for tor=-vss_sat:0.005:vss_sat

% Hit the system with an impulse to break coulomb friction

setparam(tg,24,sign(tor)*1.0557);

% Command the desired torque at 0.25 seconds

setparam(tg,25,0.25);

setparam(tg,27,sign(tor)*(1.0557-abs(tor)));

% Run the motors test number of times to reduce errors

for j=1:1:tests

% Begin the motor and wait for the motors to run

start(tg);

pause(1);

60

while tg.get(’ExecTime’)<tg.get(’stoptime’)

end

% Store data from that run

temp_vel(:,j)=tg.outputlog(:,1);

% Wait for motors to stop completely

pause(3);

end

pause(3);

% Store the average values into final

count=count+1;

vels(:,count)=mean(temp_vel’)’;

end

%%%% Friction Calculation

% Create a lowpass filter to remove noise

[num,den]=butter(10,0.04);

clean=filter(num,den,vels);

% Plot the family of filtered steady state velocity curves

plot(time,clean);

xlabel(’Time (s)’);

ylabel(’Velocity (rad/s)’);

title(’Velocity vs Time for Various Input Torques’);

% Find the steady state velocities for each run

vss=mean(clean(ceil(0.9*length(clean)):length(clean),:));

% Plot the torque vs. steady state velocities

figure,plot(vss,torque,’x’);

hold,plot(zeros(1,2),stat_fric,’x’);

xlabel(’Steady-State Velocity (rad/s)’);

ylabel(’Applied Torque (Nm)’);

title(’Torque vs. Steady-State Velocity’);

% Generate the best fit lines

ind1=min(find(vss>0.95*vss(1)))-1;

ind2=max(find(vss<-0.003));

ind3=min(find(vss>0.003));

ind4=max(find(vss<0.95*vss(length(vss))))+1;

61

fit1=polyfit(vss(ind3:ind4),torque(ind3:ind4),1);

fit2=polyfit(vss(ind1:ind2),torque(ind1:ind2),1);

% Add the best fit line to the plot

plot(vss(ind1:ind2+1),polyval(fit2,vss(ind1:ind2+1)));

plot(vss(ind3-1:ind4),polyval(fit1,vss(ind3-1:ind4)));

hold;

% Return the friction values

coulomb_fric=[polyval(fit2,0) polyval(fit1,0)];

viscous_fric=[fit2(1) fit1(1)];

62

Appendix D

Statement of Contribution

Akilah worked on the Abstract, Introduction and the Professional and Societal Considera-tions.

Adam worked on the friction identification for the tilt axis, the parameter identification forthe pan axis, the control design on both axes, and the webcam development. He also workedon the formatting of the report, the Design Verification section, and the Conclusions.

Phil worked on the modeling and simulation of the tilt axis. He also compiled and organizedall of the files for the CD.

Will worked on the mechanical system design and the trajectory generation. He also workedon the Introduction, Professional and Societal Considerations, Cost, and edited the all thevideos.

Akilah Harris-Williams Adam Olmstead

Phil Pratt-Szeliga Will Roantree

63