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 www.mmto.org/~dclark/Tools/rd_plotter . 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.
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_20091009_044501 rd_20091009_225501 rd_20091010_050501 rd_20091123_215501 rd_20091124_042501 rd_20091124_053501
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 www.mmto.org/~dclark/Reports/CommandJitter for study.
October Data
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
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_20091124_042501 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_20091124_042501). This clearly shows that the
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 signal-processing GUI results shows no corresponding frequency peaks between the command signal and the error signal.
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.