Download
1 / 41
420 likes | 529 Vues
MMT Elevation Servos. D. Clark August/September 2008. Telescope Design History Drive System Hardware LM628 Servo System Review of Compliantly-coupled systems Using Simulink and xPC Target Data Collection and Analysis Tools with Custom Libraries for i/o Hardware and Simulink
E N D
MMT Elevation Servos D. Clark August/September 2008
Telescope Design History Drive System Hardware LM628 Servo System Review of Compliantly-coupled systems Using Simulink and xPC Target Data Collection and Analysis Tools with Custom Libraries for i/o Hardware and Simulink Control Design Methodology Elevation Controller Details: » Command preprocessor » Soft-start » Position/Velocity PID loops » Flexible mode filters » Disturbance decoupling » Gain fades for friction and disturbance decoupling Tracking data from archives Recent windup problem Proposed system improvements Final Thoughts Introduction
Telescope Design History • FEA, and other design studies led to an inverted-Serrier truss design • Friction drives selected with motor-shaft encoders and provision for on-axis tape encoders • Mandate for commonality with VATT, LBT projects drove early selection of LM628-based controller
Elevation Drive • 2 friction-drive DC brush motors preloaded against a curved truss • Heidenhain RON905 motor-shaft encoders • Heidenhain LIDA105C tape encoders • Inductosyn absolute encoder on-axis • Copley Model 262 PWM amplifiers.
Compliantly-coupled Drives Motor current divided by motor inertia, results in acceleration, which integrates once to velocity. Another integration gives the shaft position. The difference in the position of the motor and load winds up the spring, producing torque, and accelerates the load. The velocity differential likewise slows the motor and speeds up the load.
The Servo Development Cycle Collect open-loop input/output data Develop control strategies based on simulation of the closed-loop system Construct a mathematical model of the system No Measure the closed-loop system response Results meet requirements? Yes Chirp responses, slewing, tracking Deploy controller
Collecting Open Loop Data • We wish to a) excite the drives with known input signals, and b) measure the response from either analog (motor currents) or digital (encoder) sources. • The open-loop data must be correlated in time. • The data set can be large, minutes of data at kilohertz sample rates. • Good tools must be available for visualization and analysis of the collected data. Using Matlab, Simulink, and xPC Target running automatically-generated code from Real Time Workshop, we can do all these things.
Introduction to xPC Target • Think of Simulink as an “engine” to run C code. • Simulink supports data flow into and out of specific code blocks via an S-function API. • Simulink can either run the code in simulation mode, or generate an executable version with the help of Real Time Workshop. Soft targets are also available, as rapid-prototyping targets. • xPC Target is a lightweight realtime kernel for control system prototyping, with tight integration into the Mathworks tool family.
The Non-linear Command Preprocessor A nonlinear preprocessor smooths out the position command signal to avoid resonance excitation. Based on W. Gawronski’s work on the Deep Space Network antennas. In the xPC Target version, this command can be a test signal or position demand over a network connection to a Java GUI. The command can also be set via the GUI to be a tracking command at an arbitrary velocity. In the VxWorks version, the command is passed via an s-function that hooks to the legacy C code that runs the astronomy and operator GUIs. In either case this is where all acceleration and velocity limits are applied. This avoids artificially limiting the control bandwidth by having them in the controller’s signal path.
Absolute Encoder Angle Processing and Position Encoder Handler The raw coarse and fine encoder data (16 bits each) are meshed together and the resultant 25-bit angle is adjusted to form an absolute angle in degrees. The absolute encoder position is passed to a transparent latch, where the tape encoder output, which starts at zero and is scaled to degrees is added. The position loop feedback is then absolute tape encoder position, in degrees.
Position and Velocity PID Loops The position command is differentiated and fed forward as a rate feedforward signal, while the feedback position goes to the position PID loop. Differentiation of the feedback provides the velocity estimate to the velocity loop, and the torque demand is filtered by the filter chain in the Flexible Mode Compensation subsystem. In addition, a reset signal and 10s soft-start blocks provide safe startup when the controller starts running.
PID Loops Both the position loop and velocity loop are straightforward PID, with gain scheduling on the position integral for friction compensation.
Flexible Mode Compensation • We use these filters at present for modal suppression on the control loop – • 5.67Hz for the main truss bending mode. • 19.8Hz for the forward frame in-plane bending mode. • 35Hz for the motor mounts. • 65.43Hz for the tape head mounts (source not determined as yet). • Without these filters, the servo gains would have to be considerably less, • to the detriment of wind rejection and overall bandwidth.
Soft-start Soft start is accomplished by integration of a constant, when Reset is not active. The resultant ramp signal is saturated at 1.0 to smoothly bring the signal input from zero to full value on the output of the soft-start subsystem.
Integral Gain and Disturbance Decoupling Gain Scheduling Remarkably similar, the position loop Integral gets scheduled larger when the absolute position error (command minus feedback) is small, and the disturbance decoupling likewise, over different error ranges.
Wind Shake is a Non-trivial Issue Servo Progress Report #8 details this set of data, taken with a much earlier version of the xPC Target controller, shows that with the brakes set, the peak-to-peak motion of the drive arcs is still 0.83 arcseconds with winds in the 20s, and gusts to the low 30s. No doubt the motion at the other end of the telescope is proportionally larger, given the compliances and larger moment arm of the OSS.
Tracking Logs • We log tracking data for every object tracked during the night. A web interface makes the data available for routine inspection of the tracking performance. Here is some data from July 2008. Logs can be found at: http://hacksaw.mmto.arizona.edu/plots/tracking/ • Tracking data can also be triggered on an ad-hoc basis by the operator/engineer. • Data are archived to disk and can be reduced via Matlab scripts written by myself for detailed analysis – the web interface back-end is based on these. • There is certainly room for improvement in the logging facility: 1. Longer logging time (currently 120s for tracking data) at the full 1kHz servo rate. 2. Ensuring that the mini-server that handles uploading the logging data is robust and always running when data is queued. 3. Having good, correlated wind data for and a facility for quantifying wind angles and tracking error via database queries to build knowledge of best-, worst-, and median-case tracking quality. We recently re-located a wind sensor to improve the agreement of the wind sensors in different locations on the summit.
More Work to Do Room for improvement exists in the elevation servo hardware and software: • Optimize the Luenberger Observer/disturbance decoupling loops. • Implement 1/T counting for smoother velocity measurements. • Invest in better absolute encoders (Heidenhain 29-bit absolute units). • Ensure that both tapes are perfectly square to the rotation axis and the head alignments (new West mount) are the best possible. • Implement IK220 readout cards with online signal-quality adjustment for the tape encoders. • Investigate stiffening the motor mounts to eliminate the underconstraint and lost motion. • Azimuth and rotator axes could benefit from standardization and upgrade efforts, as well.
Final Thoughts • Issues in servo deployment have mainly to do with the wide gulf between the test environment and deployment environment. • Formal testing and checklists, consistently applied, would help in having a uniform approach to certification and deployment of controllers, and changes to the controller operation. • A formal performance specification, other than the very vague one of 0.1 arcsecond RMS tracking over a 10-minute period from the early 6.5m Upgrade documentation, has never been produced. The recent MMT Council specification is extremely ambitious, and certain portions of it cannot be achieved with the telescope we have. Case in point: the AO top-end flexible mode specification can easily be disproven by setting the brakes and capturing all the flexible-mode frequency output from the hub. Since the top end is unencoded, even feedforward of accelerometers down to the drives can’t cure it because there is no motor bandwidth available at those frequencies. • Followup and documentation from all tests should be done. It’s important to overlay results with one another, or with simulation results, to confirm the outputs are as expected. Further, the deployment environment should support all the same test modes as are available on the test system (e.g. chirp response closed- and open-loop, tracking and slewing, and simulated wind disturbance).
More Final Thoughts • System behavior and “what-if” scenarios should be checked via simulation to ensure proper operation of the system. Using simulation as a tool allows testing to proceed without endangering people or equipment, and advantage should be taken of those tools. • Software for both the controller and “other” parts, should always be tested and verified before release to the telescope. Modularization of the code, and testing via simulation, can help in this process. The Mathworks tool family supports several ways of generating reports, adding requirements to tests, and performing code-coverage testing.
