The antenna manager periodically receives dynamic (i.e. non-repeatable) corrections from a thermal model implemented in the antenna characterization manager. These updates have the potential to place a 'step' in position if the new value is incorporated immediately. This MR describes the changes to add code to integrate new dynamic correction values smoothly over a period of time.
The antenna pointing model uses data provided by the antenna characterization manager. The values are correction offset values in az1 (azimuth), az2 (cross-elevation) and elevation. These three values must be merged into the command stream incrementally, so that velocity spikes are minimized. Note that the antenna characterization manager also provides Y-axis focus corrections, however, this value can be integrated into the command stream as soon as it is received.
It should be noted that the quantities vary rather slowly, however updating the az/el values in a smooth fashion is critical to producing smooth trajectories.
Upon receiving a new azimuth, cross-elevation or elevation correction, the values shall be incrementally integrated into the command stream over a period of N-seconds.
The update interval 'N' shall be a configurable value. A value of zero shall effectively disable the merging mechanism. The maximum allowed merge interval should be less than the update interval of the AntennaCharacterization manager.
The algorithm used to transition from one correction value to the next is:
Where:
- oldvalue - is the correction value for a given axis prior to receiving the new correction
- newvalue - is the target correction value
- tanh(x) - is the hyperbolic tangent
- x - is a value which ranges from -4 to 4 as the correction period progresses
The keyword PointingProcessor.dynamic_merge_interval in the antenna.conf file specifies the transition interval (i.e. N in paragraph 3.1)
What has to get done to integrate this completely into the system. This checklist must be completed before Cycle Integration Testing begins.
- Communication with Computing group needed? No
- What documentation needs to be updated? Antenna fits documentation, release_notes.
- Training Needed? Is this being released to staff astronomers or everyone right now? General release.
- Notification Needed? via release notes
Most if not all testing can be performed using the antenna simulator, using the Antenna AntennaManager azElCommands monitor stream to evaluate performance.
Using the simulator, follow these steps to acquire the test data:
- Using taskmaster, stop the antenna characterization process. (ignore messages from cleo about corrections not updating)
- Confirm the antenna.conf file has the following keyword-value:
-
PointingProcessor.dynamic_merge_interval := 0.0;
- (successive tests use values of 4.0 and 9.0)
- Disable az/el axes and put the antenna in the 'Off' state.
- Put the antenna into the 'On' state
- Using the antenna cleo control screen, turn on dynamic pointing updates
- Set operation mode to 'GetControl' on antenna cleo control screen and issue a prepare
- Set operation mode to 'DoScan', click 'Update' button, and enable axes
- Start a logger:
-
sampler2log -t 20 Antenna AntennaManager azElCommands
- setup a python environment by sourcing the appropriate files
- cd to /home/gbt/apps/AntennaCharacterization (or add that directory to your PYTHONPATH environment variable)
- Start the attached script:
- Let run for about 60 seconds, then kill the python script and sampler2log programs.
- Repeat steps 2-11 using dynamic_merge_interval values of 4.0 and 9.0
- Restart the antenna characterization program using taskmaster
- Using the antenna cleo control screen, turn off dynamic pointing updates.
The simulator was used to re-create the problem, and demonstrate the revised system performance. Figures 1-4 below shows the velocity profile when an az1 correction of 1.0 arc-seconds was applied and removed. Figures 3 and 4 illustrates the improved velocity profile (note scale difference). The spikes have been transformed into smooth curves which are much wider, and about 50 times smaller in magnitude. Figure 5 illustrates the relative amplitudes of the spikes shown in figures 2,3 and 4.
 |  |
| Figure 1. Original velocity spikes during 1 arc-second az1 updates. | Figure 2. Profile during a 1 arc-second on/off update with the interval set to zero seconds. |
 |  |
| Figure 3. Improved profile during a 1 arc-second update with the interval set to 4 seconds. | Figure 4. Improved profile during a 1 arc-second update with the interval set to 9 seconds. |
Repeat tests in section 7.1 to verify proper operation. Repeat tests using the real antenna. Verify proper operation.
- Data stored under Project Id TINT_042808
- Scans 1-4: (xband pointing)
-------------------------------------------------
pazCE1: -0.451 dazCE1: 0.034 tazCE1: -0.417
pazCE2: -0.435 dazCE2: 0.051 tazCE2: -0.384
pel1: 5.009 del1: -0.132 tel1: 4.877
pel2: 5.044 del2: -0.134 tel2: 4.910
-------------------------------------------------
OldAz2: 0.000 OldEl: 0.000
dAz2: 0.043 dEl: -0.133
NewAz2: 0.043 NewEl: -0.133
- Scans 5-8: (xband pointing)
-------------------------------------------------
pazCE1: -0.407 dazCE1: 0.018 tazCE1: -0.389
pazCE2: -0.392 dazCE2: 0.004 tazCE2: -0.388
pel1: 4.879 del1: -0.034 tel1: 4.844
pel2: 4.913 del2: -0.023 tel2: 4.889
-------------------------------------------------
OldAz2: 0.043 OldEl: -0.133
dAz2: 0.011 dEl: -0.029
NewAz2: 0.054 NewEl: -0.162
- Scans 9,10 and 11 are 120, 240 and 240 second Daisy pedal scans.
- Dynamic merge tests with merge interval set to 0, 4, 8 seconds respectively, data recorded with
sampler2log Antenna AntennaManager azElCommands
- Zero seconds in file 2008_04_29_02:28:07.fits
- 4 and 8 second merge interval in 2008_04_29_02:34:08.fits (also includes a Daisy with dynamic correction test script running)
- Results plotted below:
 |
| Az velocity plot with merging interval=0.0 |
 |
| Az velocity plot with merging interval=4.0 |
 |
| Az velocity plot with merging interval=8.0 |
Repeat tests in section 7.1 to record data files for later confirmation by module author.
APPROVED: I acknowledge that to the best of my knowledge, my request is fully contained in this MR.
ACCEPTED: I acknowledge that I have validated the completed code according to the acceptance tests, and I am happy with the results.
Symbols:
- Use
%X% if MR is not complete (will display 
)
- Use
%Y% if MR is complete (will display 
)
CCC Discussion Area
-- JoeBrandt - 21 Feb 2008
Revision r1.14 - 01 May 2008 - 16:20 GMT - JohnFord
Parents: PlanOfRecordC22008
|
Content copyright © 1999-2007 by the contributing authors.
All material on this collaboration platform is the property of the contributing authors.
|
| |
nomerge.png 
test_dyn_merging.py 
dyn_0.gif 
