The first tests showed 3 arcminute peak error in elevation and about 1 arcminute in azimuth. Sean remembered that the servos were set back to default for that, so he retuned the position loops back up to 0.5Hz and we repeated the test. Elevation and azimuth both came down to about 1 arcminute.
Next we started looking for excitation of resonances. On turnarounds, where velocity goes to zero, we often see resonances at 2-5Hz; the frequency doesn't seem stable. We also see some of the lines we saw in the accelerometer out at 20 and 40Hz. To simplify the problem we switched to purely azimuth or elevation scans, and saw a little bit of coupling between az and el - the servo which isn't being driven sees a wobble of about 0.01 arcmin peak.
At this point we noticed something really strange - a glitch in the encoders. For one sample, the rror jumped by about 1.5 arcminutes, which is mechanically unlikely. In the raw data coming back from the ACU, it looks like the old encoder value held over one sample. The ACU sequence ID, which counts the 100Hz clock which synchronizes all of our readout, increases correctly, so the software buffers are behaving. Later, in another chunk of data, we saw a big string of these glitches:
This plot is sinusoidal scan in elevation at fixed azimuth. From 50s to 150s, the drive appears to behave correctly: peak error of 1 arcminute and a small spike where velocity goes to zero, maybe from momentary static friction. At 150s, the behavior changes dramatically. The values from the encoder appears to occasionally fall behind for 1 sample and then catch up. After a few more seconds it falls behind by 1 sample for a duration of several samples. After 25s it's permanently locked into falling behind and contributes an error proportional to the elevation velocity.
No comments:
Post a Comment