BALL ON PLATE BALANCING SYSTEM Progress Report for ECSE-4962 Control Systems Design

Transcription

1 BALL ON PLATE BALANCING SYSTEM Progress Report for ECSE-4962 Control Systems Design Greg Andrews Chris Colasuonno Aaron Herrmann March 24, 2004 Rensselaer Polytechnic Institute

2 Abstract The goal of the ball-on-plate balancing system is to create a control system that can accurately balance a steel ball on a plate. To date, significant strides have been made towards the completion of said goal. The physical system, including a rebuilt yoke, axle and motor bracket, is nearly complete. The basic controller has been coded, and is currently capable of gravity compensation, friction compensation, and following a sine wave input. The ball coordinate system is also complete, and can generate plate coordinates for use in the controller. With regard to the originally proposed schedule, tasks are continuing to be completed ahead of schedule.

3 Contents 1 Introduction 4 2 Preliminary Results Model Development Control Development Friction Identification Friction & Gravity Cancellation Validation Subsystem Development Summary of Progress Plan Schedule Cost Unanticipated Challenges Forecast Statement of Contribution 27 A MATLAB Code 29 1

4 List of Figures 2.1 Simulink Diagram - Complete System State Feedback Control (LQR) - Step Response Simulink diagram for Observer Control State Feedback Control with Observer - Step Response Plate Frequency Response Ball Control - Root Locus Ball Control - Step Response Ball Control - Frequency Response Ball Position with Time - Circular Trajectory Absolute Ball Position in Meters Simulink Virtual Reality Diagram D Animation of The Ball on Plate System Pan Axis Friction Data Tilt Axis Friction Data Gravity Compensation Torque Data Open Loop Response for 2.1 N-m Torque, Actual and Simulated Step Response Tracking Error for 1.5 rad/sec sine wave Tracking Error for 3.0 rad/sec sine wave xpc Target Touchpad Interface xpc Target Touchpad Packet Conversion Touchpad Ball Test

5 List of Tables 2.1 Touchpad Controller Packet composition Remaining schedule List of parts List of raw materials Labor costs

6 Chapter 1 Introduction The goal of this project is to develop a ball-on-plate balancing system, capable of controlling the position of a ball on a plate for both static positions as well as smooth paths. We intend that the initially horizontal plate will be tilted along each of two horizontal axes in order to control the position of the ball. Each tilting axis will be operated on by an electric motor. Each motor will be controlled using software, with a minimum of position feedback for control. After an extensive search, few systems of similar scale were found. The ball-on-beam system, a 1-dimensional similarity to the ball-on-plate, however, is a classic control problem, and has been studied in great detail, and solved a great many ways; PID control, optimal control, fuzzy-logic controllers, etc. The fuzzy-logic controllers would seem to be the current state of the art, however classical approaches using discrete approximations are certainly adequate, if not preferred for their relative ease of implementation. Two ball-on-plate systems were uncovered during the search: one, developed at Rensselaer Polytechnic Institute by Professor Kevin Craig [6] using a similar method to that which we intend, and another at the University of Newcastle, Australia, which was developed using image processing techniques in conjunction with a textbook by Professors Graham Goodwin, Stefan Graebe and Mario Salgado [7]. While this would seem to be a short list, the ball and beam system seems to be a more popular and less structurally complex system to implement. The aim of this project will be to create a ball-plate system using a resistive touch sensor to allow the movement of a ball by means of automatic control. The system should have accuracy of < 2% in the placement of the ball on the screen, as well as the ability to move the ball from one end of the plate to the other in less than 2 seconds (long side). Overshoot should be minimal, to reduce the chances of losing the ball off of the plate or incurring damage to the touch element due to striking the physical structure of the system. Current progress to date has shown great strides towards the creation of a fully modelled, fully controlled balancing system. The modelling of the dynamics of the system have been completed, and the simulated model validated by means of comparison to the physical system. The friction of the system has also been identified through successive trials using varying torque inputs on both axes. A controller with full statefeedback and an observer has also been designed, and is currently undergoing testing and incremental tuning. The touchpad sensor interface is also complete, and waiting to be attached to the now completed mechanical system. 4

7 Comparing the progress with the proposed initial schedule, work is proceeding as planned. This week is the integration phase, and work is continuing on that front, with the physical system and sensors being married together. Then the controller can finally be tested on the complete system, aiming for ball balancing some time in the next week. The interface for the touchpad did have to be changed to using the serial controller that came with the touchpad itself, but it all functions as expected. There are concerns that the motor drivers cannot supply enough torque for our system with the current setup, and therefore might require tweaking. The prognosis for the remaining 5 weeks of development looks good. If the controller works as the simulation shows, the basic objective of balancing a ball seems plausible. Given all present indications, the further goal of tracing a path also seems possible. 5

8 Chapter 2 Preliminary Results 2.1 Model Development In order to design a control system that will accurately control the position of the ball, a highly accurate model must be developed. As the accuracy of the model increases, the control effort required will be less. To develop this model, Professor Wen s pantilt.m MATLAB script was run to find the equations of motion for our system. This script returns symbolic values for the mass-inertia matrix, velocity coupling matrix, gravity loading vector, and the total system energy. A SolidWorks model was developed, and from this, numeric inertia tensors were found for bodies A and B with respect to our defined coordinate systems. Unfortunately, using the linear control theory that we have learned thus far, it becomes difficult to develop a control system for our fully non-linear model. Because of this, the system must be linearized about an operating condition, ( θ, θ) = (0, θ d ). By doing this, we are left with the linearized equations of motion: The state-space realization of this system becomes [5]: [ ] x1 = x 2 M(θ d ) θ + G(θ d) (θ θ d ) + F v θ = Bu Fc sgn( θ θ) (2.1) M 1 (θ d ) G θ }{{} 2x2 y = M 1 F v }{{} 2x2 [ ] [ x1 x 2 ] ] + x 2 [ x1 Using this linearized system, a controller can be developed for the plate (2.2) 6

9 In addition to the plate system, a model for the ball dynamics must be developed as well. If we ignore coupling between the two modes of motion, as well as the friction between the ball and plate, a linear model and transfer function can be determined [3]. ( J r 2 b + m b )ẍ = m b gθ X(s) Θ(s) = mg s 2 ( J + m) r 2 b (2.3) Substituting numerical values into this equation results in the transfer function 7 s 2. This double integrator can be easily controlled with classical control approaches. 2.2 Control Development The design approach for this control consists of two feedback loops: an inner loop to control the position of the plate, and an outer loop to control the position of the ball [6]. A Simulink diagram illustrating this approach can be seen in Figure 2.1. Figure 2.1: Simulink Diagram - Complete System In order to successfully implement this design, the inner loop must have a much faster response than the outer loop. Since the inner loop can only be designed to be as fast as physical limitations allow (motor torque, etc.), we must intentionally design the outer loop to be slower. From the linearized system in Equation 2.2, a full state-feedback control can be implemented. For our system we decided to use a linear quadratic regulator (LQR) to determine the feedback gain matrix, K, such that the control becomes u = Kx. The Q matrix must be chosen to optimize the control to achieve 7

10 out desired result. Since we are interested in tracking θ 1 and θ 2, we place a high weighting on those states. In addition, the R function can be adjusted to either promote or penalize the control effort. After several design iterations, the current Q and R matrices are found to be: Q = R = [ ] (2.4) resulting in the feedback gain matrix: [ ] K = (2.5) With this gain matrix, the closed loop eigenvalues (A BK) are placed so that the damping ratio is ζ =.707 and natural frequency is ω n = 6.68 rad/sec. The step response of this closed-loop system can be seen in Figure 2.2. However, this response assumes that all states can be measured, when in fact we can only Figure 2.2: State Feedback Control (LQR) - Step Response measure position, not velocity. For this reason, we have implemented an observer to estimate the velocity states of our system [4]. To do this, the plant was first converted to a discrete system using MATLAB s c2d() command using the zero-order hold method for a sampling frequency of 10KHz. Then, observer poles are placed so that they are roughly five times faster than the closed-loop poles. To do this, we find the time constant of the closed-loop poles, and calculate our observer poles accordingly. Using MATLAB s place() command, the observer gain matrix L is found to place the poles in these desired locations. The observer is of the form: ˆx = Aˆx(k) + Bu(k) + L(y(k) ŷ(k)) (2.6) 8

11 ŷ(k) = Cˆx(k) P oles = 1e 3 [ j j j j] (2.7) 2 0 L = (2.8) where ˆx is the observer s estimate of the velocity states, u is the system input, y is the plant output, and ŷ is the observer output. The L matrix ensures that the observer error, ˆx(k) x(k) converges to zero [2]. This can easily be implemented as a controller of the form [8]: u(k) = Kˆx(k) ˆx(k + 1) = (A BK LC)ˆx(k) + Ly(k) (2.9) The Simulink diagram and response for this system can be seen in Figures 2.3 and 2.4. The observer Figure 2.3: Simulink diagram for Observer Control estimates the velocity fairly accurately, however this may be able to improve my moving the eigenvalues of the observer (2.7). The closed-loop frequency response as well as gain and phase margins for this system can be seen in Figure 2.5. It can be seen from this response that we should be able to track the plate at a velocity of 6.7 rad/sec, while at the same time suppressing high-frequency sensor noise. This meets our original specification of 1.36 rad/sec. The gain margin for the closed-loop plate system is 80.6dB at 138 rad/sec. At our desired speed, we should be able to position the plate with very little chance of instability. It should be noted that in Figure 2.1, that the gravity and friction terms are being added back into the control effort. This feedback linearization in effect cancels out the nonlinear terms within the plant, making the control effort required less. However, this does not come without cost. The feedback linearization increases computation time, as well as the torque requirement, though through both simulation and actual experimental runs, this does not seem to pose a problem. For the ball position control, a classical root-locus design methodology was used. Figure 2.6 shows the locus before and after compensation. It can be seen from the prior that the open-loop system is only marginally stable, and a purely proportional controller will not be sufficient to compensate for this. Instead a proportional+integral+derivative (PID) control will be used. A zero is placed at s = 1 2, and a pole to the far right at s = 100 resulting in a derivative gain of K d = 2. By using MATLAB s rltool(), a proportional gain of K p =1 was found. In addition, a small integral term was added to improve the steady state response. 9

12 Figure 2.4: State Feedback Control with Observer - Step Response Figure 2.5: Plate Frequency Response 10

13 Figure 2.6: Ball Control - Root Locus An integral gain of Kp = 1.05 was used to achieve this. closed-loop response can be seen in Figure 2.7. With these relatively low gains, our control is sufficiently slow to allow the plate dynamics to respond. 14s s s 4 + s s s (2.10) Equation 2.10 shows the closed-loop transfer function for the ball dynamics. The controller K p + K d s + frack i s can be converted to a digital controller using MATLAB s c2d() command. This emulation design approach can be used since the sampling time is sufficiently faster than the bandwidth of the closed-loop system. After the discretization at a rate of 10KHz with a bilinear transform, the digital PID control becomes: 199z 2 398z z (2.11) The frequency response and gain and phase margins can be seen in Figure 2.8. It can be seen that with this control, we should be able to track the ball at 12 rad/sec, and high-frequency noise should be suppressed. This meets our original design requirements. Now that controllers have been developed separately for both plate position and ball position, it is desirable to to combine the two, resulting in the diagram shown in Figure 2.1. By doing this, the plate control is commanded by the output of the ball control. A simple test is to command a trajectory for the ball, and see if the plate dynamics respond in such a way to follow that trajectory. For this test, we used two sine waves, both at 2 rad/sec and amplitude of 0.04, and one inverted and π 2 radians out of phase with the other. One sine wave commanded the ball s X position, the other, the ball s Y position. By doing this, the ball should essentially travel in a circle of radius 0.04m. This trajectory was commanded though a Simulink simulation, and the results were promising. Figure 2.9 shows the ball s response in a position vs. time manner. It can 11

14 Figure 2.7: Ball Control - Step Response Figure 2.8: Ball Control - Frequency Response 12

15 Figure 2.9: Ball Position with Time - Circular Trajectory be seen that initially, the ball has a 0.04m position error since it s initial position is at (0,0). This does not cause the system to go unstable, however there is some lag and overshoot while the ball tries to catch up to the commanded position. Once the ball has caught up to the desired position, it tracks it with very little error. Figure 2.10 shows the balls spatial position in an X vs. Y position plot. The ball initially overshoots the desired trajectory as mentioned before, but then settles into a near perfect circular trajectory in roughly 3 seconds. To better visualize this, a 3D animation has been created using MATLAB s Virtual Reality Toolbox. The model created in SolidWorks was exported as a VRML file, and a VR block was created in Simulink to move the model in accordance with the simulation results. The Simulink block diagram and a sample frame from the animation are shown in Figures 2.11 and A video file of this animation is available upon request. 2.3 Friction Identification Identification of the friction in the system was performed as prescribed in the design proposal. A Simulink model capable of measuring the encoder and outputting constant voltages was used in conjunction with a MATLAB script to repeatedly estimate the velocity of each joint. For each of 200 voltage increments from minus two volts to plus to volts, the motor was allowed to turn for ten seconds so that it would reach steady state velocity. The last four seconds were then averaged to obtain a single value for steady state velocity for that particular torque (voltage). In addition, a one second ten volt spike was added in the beginning of each run in order to overcome the stiction of the system. By plotting this data and finding a least squares approximation for the data, the coulomb and viscous friction were found as the intercept and slope of the regression line, respectively. The plots for each axis are shown in Figures 2.13 and

16 Figure 2.10: Absolute Ball Position in Meters Figure 2.11: Simulink Virtual Reality Diagram 14

17 Figure 2.12: 3D Animation of The Ball on Plate System 15

18 Figure 2.13: Pan Axis Friction Data Figure 2.14: Tilt Axis Friction Data 16

19 2.4 Friction & Gravity Cancellation Following the identification of the friction and gravity, a Simulink diagram was created to cancel out both within the system. When the program was run, the system could be positioned by hand at any position without falling and was very easy to move. A fairly light touch could rotate the system about an axis several times before it settled at a location and remained there. Through some simple hand calculations, the amount of torque required to cancel gravity in the system was found to be about 0.4 N-m. This value matched the torque value in both the model and the value recorded from running gravity cancellation on the actual system. The torque plot can be seen in Figure Figure 2.15: Gravity Compensation Torque Data 2.5 Validation Having completed the identification of the system s inertia from the SolidWorks model, friction, and gravity loading, the model of the system was completed. In order to verify the validity of this model, several experiments were run on the system. These experiments included testing of the open loop response, step response, and position tracking, for both the actual system and a simulation using the developed model. The results were very promising. The open loop response for both the actual system and simulation for an input of a 2.1 N-m torque are shown in Figure The plots for both are nearly identical. With a preliminary control system running, the system s pan axis was commanded to a 0.5 radian position using a step function input. The actual, desired, and simulated responses are shown in Figure While 17

20 Figure 2.16: Open Loop Response for 2.1 N-m Torque, Actual and Simulated there is some variation between the actual and simulated responses including rise time and error, they are a fairly close match as well. In addition to a step response, several sine wave inputs were made to the controlled system and several promising plots were generated. Sine waves with amplitude of one radian and for 1.5 rad/s and 3.0 rad/sec frequency were used as input. Upon viewing the plots it is easy to see that while some further work is required on the controller, the model is highly accurate when compared to the actual system. Some slight bumping occurs on the downward stroke on one portion of the sine wave. By doing such things as increasing the speed of the observer by moving its poles, this bumping effect can be removed. The plots are shown in Figures 2.18 and A simple tolerance analysis test to verify the gain and phase margins (qualitatively) is to give the system a disturbance while in operation. While the system was being commanded to follow a sine wave input, we held the yoke from moving by hand. After letting go, the system sped up to catch up with the desired trajectory, and then fell back into sync. No tolerance analysis has yet been done as far as sensor noise, however according to the frequency responses of both controllers, high-frequency noise should be sufficiently attenuated. 2.6 Subsystem Development The touchpad interface relies entirely on the capabilities of the 3M Dynapro SC3 serial interface controller for its operation. The touchpad is composed of 90 offset plates. Voltage is applied across one plate while reading voltage information from the other plane. When pressure is applied to the surface, an electrical 18

21 Figure 2.17: Step Response Figure 2.18: Tracking Error for 1.5 rad/sec sine wave 19

22 Figure 2.19: Tracking Error for 3.0 rad/sec sine wave connection is made, which results in a change of voltage at the output. This change corresponds to the distance between the contacts on the plate. One reading is made from each of the two plates to create an X-Y coordinate pair. The SC3 controller takes these X-Y coordinate pairs it generates and converts them into sets of three 8-bit packets which can be converted into coordinate pairs. The actual coordinate values are 10-bit values, that are actually spread across the three separate packets as shown in Table 2.1. Note that in the table, the P bit refers to the status of the pen, or the object touching the pad: 1 is pen down, 0 is pen up. Also note that x9 refers to the 10th bit of the 10-bit x coordinate number, and so forth for all x k and y k. [1] Table 2.1: Touchpad Controller Packet composition Packet/Bit # #1 (sync) 1 P x 9 x 8 x 7 y 9 y 8 y 7 #2 (data) 0 x 6 x 5 x 4 x 3 x 2 x 1 x 0 #3 (data) 0 y 6 y 5 y 4 y 3 y 2 y 1 y 0 All of these packets are sent asynchronously and without prompting: as soon as the touchpad receives sufficient pressure for the controller to register a touch, the system begins to send data. In order to process this data, and get the resultant coordinate information into the real-time computer, a serial interface needs to be created in MATLAB Simulink that can be compiled for the xpc Target system. The basic overall system utilizes the binary receive block in Simulink to retrieve data as sets of three 1-byte packets as described in the manual. The RS232 Setup block sets the link parameters as 2400 bps, and 8-N-1-8 bits per packet, no parity, and 1 stop bit. Normally, Simulink is unable to utilize binary numbers, however, 20

23 the communications toolbox allows conversion to and from binary. This makes possible the individual bit manipulation necessary to move the 8-bit packets from the controller into the 10-bit binary words that the controller s A/D converter creates. The Simulink diagrams can be seen in figures 2.20 and Figure 2.20: xpc Target Touchpad Interface Figure 2.21: xpc Target Touchpad Packet Conversion Testing of the system in real time using the steel ball as a touch source as well as the rubber membrane on the surface of the touch screen yields clear coordinate plots such as the one seen in Figure Further testing will have to wait until the physical system is completed, including approximated error calculations due to quantization and signal noise. 21

24 Figure 2.22: Touchpad Ball Test 22

25 Chapter 3 Summary of Progress 3.1 Plan The basic project plan remains unchanged: upon completion, the system should autonomously balance a ball on a plate. To that end, the system has been modelled and linearized, and a controller designed around the dynamics of the ball and the two-axis pan-tilt mechanism. Plans also remain in place to allow the system to put the ball into different planned paths, including for example a circle or a figure-eight shape. Further development could also involve a graphical user interface. 3.2 Schedule To date, progress has been as scheduled with only minor glitches or setbacks during the construction and development. Of note is the construction of the physical system in the RPI Student Machine Shop, which took significantly longer than originally thought. The end result is acceptable for our system, though it remains to be tested as a complete system. Other steps, however, proceeded as planned: model development, friction id, validation and control system development all on schedule, as evidenced by the results detailed previously in this report. The remainder of the schedule remains as originally planned, shown in Table 3.1. This week is devoted to sensor integration and control system testing and development. The real work now is focused on the completion of the physical system with sensors, and the testing of the simulated control system against a fully working real system. If things proceed as desired, ball balancing should occur within the next week or two, proceeding thus to planned ball trajectories. 23

26 Table 3.1: Remaining schedule Week Task Member Week 10 Integration of sensors Aaron Control system testing Greg Sensor testing Chris Week 11 Static ball balancing Team Week 12 Complex path following Team Week 13 Work on final report Team Final demonstration Team Week 14 Work on final report Team Final presentation Team Week 15 Final report Team 3.3 Cost Costs have remained as originally planned, mostly due to a large allowance for aluminum usage during construction of the yoke and axis. This previously conceived overestimate turned out to be quite accurate, due to errors made during machining. In fact, several pieces of the yoke and axle had to be completely remade due to errors. One item of mention not previously introduced in the project proposal is a Lexan panel. The touch pad sensor is constructed with a glass substrate, and while stiff, glass is not shatterproof. It was the consensus of the team members that during testing, a Lexan panel stand in as the sensor plate, so that the expensive and difficult to source touch sensor was not damaged. This plate will also serve as protection for the touch sensor during operation, and perhaps as a stiffener, providing structural support to the sensor. A new tilt axis belt was also purchased because of the changes made to the dimensions of the yoke. Due to the uncertainty of the outcome of the machining process, the belt purchase was put off until recently, to be certain of choosing the correct size. The new belt ties directly into the new tilt drive system, made possible by using a remanufactured tilt motor bracket from last year s project. This also saved significant machining time. 3.4 Unanticipated Challenges Several unanticipated challenges have come up during system development. Of particular concern involves the required torque for normal system operation. During testing, it was realized that the magnitude of torque required by the system was larger than expected, approaching or exceeding the saturation point of the motor drivers. Further testing is planned to ascertain if the system is feasible with the drivers configured as they are currently, or if the D/A+Motor driver system might have to be tweaked to generate more amperage. A further controller-related challenge is related to the observer design. Several initial implementations failed to work as well as the basic finite difference. This is obviously a problem related to the placement of the poles or the implementation in Simulink, and should be corrected upon further discussion on the topic with Professor John Wen. 24

27 Table 3.2: List of parts Item Qty Cost Total Source 1 1/4 diam. 440C stainless ball 1 $9.17 $9.17 McMaster-Carr Dynapro wire resistive touch pad 1 $39 $39 Ebay Pittman motor GM9234S017 (pan) 1 $97.59 $97.59 Supplied Pittman motor GM9234S017 (tilt) 1 $97.59 $97.59 Supplied Pan gear A 1 $9.97 $9.97 Supplied Pan gear B 1 $22.02 $22.02 Supplied Tilt gear A 1 $7.95 $7.95 Supplied Tilt gear B 1 $22.02 $22.02 Supplied Pan belt 1 $3.92 $3.92 Supplied Tilt belt 1 $3.55 $ Misc screws $5.00 $5.00 Home Depot Total $ Table 3.3: List of raw materials Item Qty Cost Total Source 1/2 aluminum stock 5 lb $4/lb $20 RPI Machine Shop 1/16 latex rubber membrane 1 $ x12 $9.38 McMaster-Carr.093 Lexan panel 1 $ x10 $5.00 Home Depot Total $34.38 Table 3.4: Labor costs Description Hours Cost Total Andrews, Greg (engineer) 300 $35/hr $10,500 Colasuonno, Chris (engineer) 300 $35/hr $10,500 Herrmann, Aaron (engineer) 300 $35/hr $10,500 Caskey, Ryan (machinist) 30 $35/hr $1,050 Total 930 $32,550 25

28 An unanticipated challenge presented itself during the machining of the yoke and axle. Despite a strict attention to detail for all of the dimensions of the parts, a simple detail was misunderstood with regard to the axle bearings. Upon discussion with TA Benjamin Potsaid, it became apparent that the holes for the axle bearings needed to be slightly smaller than needed, so as to press fit the bearings. However, the holes made are in fact exactly to size, yielding a loose fit. This isn t expected to impact the performance of the system simply because the system is not meant to spin, merely to rotate back and forth through small angular displacements. In the area of subsystem development, the expectation was that A/D conversion for the generation of touch pad coordinates would be done by the analog inputs of the xpc Target computer. However, comprehending the outputs from the touch pad itself proved difficult at best. Since the controller included with the purchased touch pad worked, an xpc Target based serial port interface system was created to interface with the controller and generate ball coordinates for the control system. Another challenge related to the touchpad is the configuration of the serial controller. Several attempts have been made to change the averaging, settling time and baud rate settings of the controller with zero success. Though the timing and format of the messages are known, the controller seems to ignore the settings. It is not yet known whether this is merely an error in the controller, or merely a failure to understand the message formats. However, successfully configuring the controller could yield a significant improvement in the sampling period of the ball coordinate generation system. A challenge that has recently come to light is the zeroing of the axes upon system startup. Simplicity dictates that development forego the usage of inclinometers, simply to make the work easier. However, it has proven difficult to get the axes initially perfectly zeroed for just a test of the pan axis. Once the system is physically completed and testing of the balancing system commence, finding a zero point could prove to be difficult. And if that measurement isn t correct, the error trickles through all of the systems: gravity compensation is wrong, encoder angles are wrong. Ultimately, the answer might very well be to create a jig for the inclinometers that allows a quick startup configuration and then the subsequent removal of the jig during a test. 3.5 Forecast A reasonable forecast for the remainder of the project suggests that at the very least, we will complete the balancing problem. Whether or not the system can be made to overcome the present challenges and track out a ball path is still unknown, though the group is willing to put in the time to make certain it can. All that remains to be seen is what the controller is capable of, and what it can be made to do with proper testing and tuning. 26

29 Chapter 4 Statement of Contribution For the progress report document: Greg completed the following sections: Model development Controller development Chris completed the following sections: Validation Friction Identification Friction & Gravity Cancellation Aaron completed the following sections: Abstract Introduction Subsystem Development Summary of Progress Greg Andrews Chris Colasuonno Aaron Herrmann x x x 27

30 Bibliography [1] 3M Touch Systems. SC3 Touch Screen Controller: User s Guide, 2nd edition, [2] Dr. Murat Arcak. Discrete time systems - lecture notes [3] No Author Available. Control tutorials for matlab: Modeling the ball and beam experiment. Available WWW: jzelek/matlab/ctms/examples/ball/ball.htm. [4] No Author Available. Control tutorials for matlab: State space tutorial. Available WWW: http: // [5] No Author Available. Digital control example: Inverted pendulum using state space method. Available WWW: jzelek/matlab/ctms/examples/pend/diginvss.htm. [6] S. Awtar, C. Bernard, N. Boklund, A. Master, D. Ueda, and K. Craig. Mechatronic design of a ball-onplate balancing system. Technical report, Rensselaer Polytechnic Institute, [7] Graham Goodwin, Stefan Graebe, and Mario Salgado. Control system design - ball-on-plate tutorial. Available WWW: sim.html, [8] C. Phillips and H. Nagle. Digital control system analysis and design, third edition. Technical report, Prentice Hall, Inc.,

31 Appendix A MATLAB Code % Greg Andrews % System Linearization and Control System setup % March 15, 2004 % Control System Design %Symbolic Variables syms ma mb g t1 t2 lca1 lca2 lca3 lcb1 lcb2 lcb3 Im1 Im2 N1 N2 syms IA11 IA12 IA13 IA21 IA22 IA23 IA31 IA32 IA33 syms IB11 IB12 IB13 IB21 IB22 IB23 IB31 IB32 IB33 %Gravity Vector G1= -ma*g*sin(t1)*lca1-ma*g*cos(t1)*lca2-mb*g*sin(t1)*cos(t2)*lcb1-mb*g*cos(t1)*lcb2-mb*g*sin(t1)*sin(t2)*lc G2= -mb*g*cos(t1)*sin(t2)*lcb1+mb*g*cos(t1)*cos(t2)*lcb3; %Gradient of the Gravity Vector partial_g=[diff(g1, t1 ) diff(g1, t2 ); diff(g2, t1 ) diff(g2, t2 )]; %Mass-Inertia Matrix M11= IA33+mA*lcA1^2+mA*lcA2^2+Im1*N1^2+IB11-IB11*cos(t2)^2+mB*lcB2^2+mB*lcB3^2-mB*lcB3^2*cos(t2)^2-2*sin(t2)* M12= -sin(t2)*ib12+sin(t2)*mb*lcb1*lcb2+cos(t2)*ib23-cos(t2)*mb*lcb2*lcb3; M21= -sin(t2)*ib12+sin(t2)*mb*lcb1*lcb2+cos(t2)*ib23-cos(t2)*mb*lcb2*lcb3; M22= IB22+mB*lcB1^2+mB*lcB3^2+Im2*N2^2; 29

32 M=[M11 M12; M21 M22]; % % Numerical Parameters g=9.81; Im1=11.5; Im2=11.5; ma = ; % mass of link A in Kg lca1 =.0016; % distance to COM lca2 = ; lca3 = ; mb = ; lcb1 = ; lcb2 = ; lcb3 =.0003; N1=2*11.5; N2=4*11.5; % total gear ratio IA11 = ; % inertia IA12 = ; IA13 = ; IA21 = ; IA22 = ; IA23 = ; IA31 = ; IA32 = ; IA33 = ; IB11 = ; IB12 = 0; IB13 = ; IB21 = 0; IB22 = ; IB23 = 0; IB31 = ; IB32 = 0; IB33 = ; fc1 =.097; % friction fv1 =.0019; fv2 = ; fc2 = ; t1=0; t2=0; G_lin=vpa(subs(partial_G)); M_lin=vpa(subs(M)); Fv=[fv1 0; 0 fv2]; Astuff1=-inv(M_lin)*G_lin; Astuff2=-inv(M_lin)*Fv; % State space representation A=[ ; ; Astuff1(1,1) Astuff1(1,2) Astuff2(1,1) Astuff2(1,2); Astuff1(2,1) Astuff1(2,2) Astuff2(2,1) Astuff2(2,2)]; A=subs(A); B=[0 0; 0 0; 1 0; 0 1]; C=[ ; ]; D=[0 0; 0 0]; sys_c=ss(a,b,c,d); sys_d=c2d(sys_c,.0001); % LQR w1=1000; w2=1000; w3=1; w4=1; Q=[w ; 0 w2 0 0; 0 0 w3 0; w4]; R=.5*eye(2); 30

33 K=lqr(A,B,Q,R); % Observer PL=[ ]; L=place(A,C,PL) ; Aobs=(A-B*K-L*C); Bobs=L; Cobs=K; Dobs=D; Obs=ss(Aobs,Bobs,Cobs,Dobs); Ts=.0001; Obs=c2d(Obs,Ts); 31