Command-induced Tracking Jitter Study I D. Clark November 24, 2009

Transcription

1 Command-induced Tracking Jitter Study I D. Clark November 24, 2009 Introduction Reports of excessive tracking jitter on the MMT elevation axis have lately been theorized to be caused by the input command signal to the servo loop having a velocity- and temporal-dependent quantized variance with an amplitude of order 0.1 arcsecond. In this report, some new tools were used to analyze nightly tracking log files to test this idea and come up with some new insights as to the cause of this issue. Tools and Data Reporting A new Matlab GUI was generated to facilitate quick generation of data plots from the standard mount-control rd files, which automatically store position and error data for all 3 axes of the telescope at 100Hz over 120s during operation. Since reports of the tracking jitter were suspected to come from the input command to the controller, this logging entry was recently added to the logging software so current position, position error, and commanded position for all 3 axes are now available in the logging files. The fig- and m-file to use this GUI for those who have Matlab and want to use it are posted at Copy both the fig- and m-file to your current Matlab directory and execute rd_plotter at the command prompt to bring up the GUI. Discussion of the actual GUI code is beyond the scope of this report, but briefly, use of the GUI consists of the following steps: 1. Click File from the menubar to bring up the native Matlab import data wizard, if you don t currently have a data set in the workspace. 2. Click Update to refresh the workspace variable list in the listbox. 3. Select the data and the header information garnered from the import operation. 4. Use the radio buttons to select the axis and signal of interest.

2 5. In the case of command signals, you will want to check Detrend to detrend the command signal to get correct FFT results. Remove Means is intended for future expansions of this GUI and does work, but isn t needed for rd tracking data. 6. Click plot to get a 3-paned plot of the data. The GUI uses the size of the selected data to overlay the logged command signal with the one calculated by addition of the error and position signals when the information is in the data array. Data from the array are plotted in red, while the logged command signals get overlaid in black. So the resulting plot will have the full length of the selected signals on the upper left, a 1s zoom of the data at the center, with tick marks at data points on the upper right, and the resulting PSD of the data across the bottom. Selected Data From examination of the nightly tracking data displayed on the MMT Engineering Tracking webpage, six tracking files were selected for analysis in this report. Three of the files are the old style logs without the command-signal column, but were from an LGS run in early October that had reported tracking jitter issues. The other 3 are recent logs that also exhibit the low-frequency jitter and have the new logging information. These files were: rd_ _ rd_ _ rd_ _ rd_ _ rd_ _ rd_ _ Each of these files was processed by the GUI to generate plots for a) elevation error, b) azimuth error, c) elevation command signal, and d) azimuth command signal, which produced a total of 24 plots. To keep this report a manageable size, I have chosen to present only azimuth and elevation error and command signal plots for one each of the October data and November data. The entire plot population is available as.png files at for study. October Data Following are plots of the error signal and back-calculated command signals for the elevation and azimuth axes from October. The command signals are detrended, and the remaining curvature is an artifact of the curved sidereal-object tracking path described by the telescope.

3

4

5 The first pair of plots shows the elevation error and command signals in arcseconds, and the low-frequency jitter is clearly visible, and in fact constitutes the majority of the tracking error. The second are the data for azimuth from the same file. Here also we see low-frequency jitter. Interestingly, the detrended command signal from azimuth results as we expect in a triangular pattern in the line, but it now shows discontinuities at 40ms intervals, which is not expected from the standard command-signal rate from astronomical calculations at 100Hz. November Data Below we have the same kind of plots, but now with an added black line overlay that is the logged command signal. The error signal is first, followed by the command signal data:

6

7 Consider the elevation error and command signal plots above. In each, we see a lowfrequency jitter at ~2.3Hz. However, the logged command signal exhibits none of this, and is indeed a flat line in the zoomed section. What if we zoom in a little further? Below, we have the full-length time series and zoomed 1s section both zoomed in xy so that more structure is visible in the signals. The back-calculated command signal (red) is clearly sinusoidal in character, with discontinuities at 20-40ms intervals. The command likewise has small discontinuities at variable intervals of 0.5 to 1s. Elevation is first, followed by azimuth data from the same file:

8

9

10 The discontinuities in red are each of order 40mas in magnitude, which is very close to the absolute encoder resolution (0.038 arcseconds). So it is to be expected, perhaps the the logging data here are from the absolute encoder. Is the Elevation Command Pre-processor at Issue? Since the logging files only record the command signal input to the elevation servo loop, the input signal from the log file was used to drive a Simulink simulation of the command pre-processor to confirm that its output was correct, for the rd_ _ file data. Given that the elevation servo runs at 1kHz and the input commands come from software running at 100Hz, the simulation holds the last value for 10 samples, so a staircase is expected from the simulation: The 100Hz quantization steps are ~0.045 arcseconds in height, consistent with the elevation velocity of 4.5 /s. The CPP output is delayed due to computation of the processed output signal, but exhibits no surprising temporal variation. A more complete visualization is provided by the following figure, which presents the detrended logged command signal, the detrended simulation output of the CPP, and the error signal for this same file (rd_ _042501). This clearly shows that the command signal has steps at 0.5-2s intervals that properly get smoothed by the CPP, and

11 nothing appears to be getting perturbed in the error signal, which happily keeps its sinusoidal character: Again, examination of the PSD of each of these signals via Matlab s sptool signalprocessing GUI results shows no corresponding frequency peaks between the command signal and the error signal. To cover the possibility that the steps in the command signal excite the sinusoidal jitter, the curved linear-fit residual command signal was subtracted with a quadratic fit and the residual signal that now contains only what I presume are offset and guiding additions is overlaid with the error signal below:

12 No temporal correlation appears to be visible at this point, which is confirmed by the PSD of the error signal and quadratic-residual command signal below:

13 Conclusion Logging of the command signal inputs to the servo is useful for determination of the controller response during operation. Back-calculation of the command signal from the older files without the logged command results in an error due to the fact that the error signal contains information other than the command signal tracking (noise, encoder quantization, disturbances, etc.) and so should not be used to make decisions about the servo behavior. Clearly, 100Hz steps in tracking profiles will have a velocity dependence that perhaps shows up in the tracking errror. For the elevation axis, I see here no conclusive evidence that the command signal quantization is leading to unwanted temporal oscillation. The azimuth axis especially shows the deleterious effects of both command and feedback signal quantization, as well as an odd 40ms interval feature that may vary with the velocity that should be studied further. The elevation command signal presented here also contains a lot of transitions that I can only presume are guider or observing offsets; there perhaps should be a way to separate those other inputs from purely astronomical tracking commands to make possible diagnosing bad command signal inputs from those other sources. The elevation command pre-processor (CPP) appears to be working as intended, smoothing sharp input transitions. More analysis and study will be needed to come to a final answer for this tracking jitter problem. Earlier work has shown that the disturbance decoupling loop in the elevation axis controller is winding up; more work on this is needed to track down the reasons for this unwanted behavior, and find where the observed velocity-dependent (and perhaps temporally intermittent) tracking jitter is happening in the control loop.