# Compare the controller track Array and ramp modes

#### 04dec14

The 12meter controller software (provided by mark Godwin) has two different modes that can be used to track objects:
• TrackArray mode:
• The user sends a timed stamp position (az,el or ra,dec) to the controller.
• The controller can buffer up to 1000 locations
• When the time for the  time stamp arrives the controller will:
• compute the velocity for  time T using:
• vel[T]= (pos(T+1) - pos(T-2))/(2)
• The next point velocity computation means you need to send points about 2 seconds in the future to the controller.
• Ramp mode:
• This was added for ed himwich.
• The user sends a position,velocity, and timeStampl
• The controller will compute a path::
• theta = position + vel*(Tm - TmpStamp).
• The new ramp is applied on the next 2.5 millisecond cycle after receipt of the new point.
• I use horizon coordinates (az,el) and 1 second updates for both trackarry and ramps.

## Doing pointing crosses with TrackArray and Ramps:

A number of crosses were done to get data for  a pointing model for the telescope.
A cross consists of:
• While tracking a source do
• Az strip:
• -3 deg great circle offset in az , then .1 deg/sec rate in az  for 60 seconds
• el offset is 0.
• El Strip:
• -3 deg offset in el then .1 deg/sec rate in el for 60 seconds
• azoffset is 0.
• It takes a few seconds to move from the end of the az strip to the start of the el strip.

The first plots show a cross using trackArray (.ps) (.pdf):
The 2nd plots show a cross using Ramps (.ps) (.pdf):
• Page 1:
• Top: the great circle offsets for cross vs time in seconds.
• black: azimuth offsets
• green: elevation offsets
• Middle plot: azimuth positions:
• black: the requested azimuth positions
• red: The measured azimuth positions.
• Bottom: elevation positions:
• Green: requested elevation positions
• red: measured elevation positions:
• Page 2: Blowup showing end of azimuth strip
• top: azimuth requests(black) and measured(red) positions
• Note: these are little circle offsets: great circle = littleCircleOffset*cos(el)
• bottom: position error: Measured - requested:
• blue: azimuth
• purple: elevation

### Track array accelerates and overshoots at the end of  each strip:

• You can see this clearly on the 2nd page of the track array plots
• This acceleration is easily heard if you are close to the telescope.
• What is happening:
• The problem is the velocity computation that the controller does for each point (nextPnt-previousPnt)/tmDif
• For the end of the az  strip, the azimuth  is moving from an offset of  3.8 to 0 deg azimuth.
• The computed az velocity for point 60 is then:
• (0offset - 3.8Offset)/2. = -1.9deg/sec
• So the controller will try to arrive at point 60 (Azoffset=3.8) moving at -1.9Deg/sec. It still needs to move .1 degrees between pnt 59 and 60.
• To do this the controller splits the 59 to 60 gap in half.
• first half (high velocity)
• 2nd half (-1.9 deg/sec)
• so distTraveled=.1dec = .5sec * vel1 - .5sec*1.9deg/sec
• vel1=2.1 deg/sec for the time 59.0 to 59.5 secs
• The antenna can not accelerate to 2.1deg/sec from .1 deg/sec during this1/2 second, so the track profiler kicks in to generate a smooth path.
• My measured positions have under sampled the overshoot (since it only samples at 1 hz).
• How could we get around this accelerate, overshoot problem:
• We want to cover the last 59-60 points  in .1 deg/sec
• we need to add a point at say 60.5 that continues the .1deg/sec velocity
• If we add a point at 61 equal to the position of 60.
• this would give us 0 deg/sec at 60.5 (if the telescope could de accelerate that fast)
• We could then start sending the points for the new position at offset 0.
• This behavior is explained by mark Godwin in the users manual  under using  track array.
• Fixing a cross wouldn't be too hard, but:
• we can generate generalized paths using tcl scripts
• finding a general solution to this problem would not be so simple
• inserting extra points when the acceleration direction changes might work (although low velocity small acceleration changes may be a problem).

### Ramp mode does not have an overshoot problem:

The ramp blowup at the end of the azimuth strip shows that there are no overshoots
• Listening to the drives i don't here any funny velocity changes at the end of the strip.
Drawbacks to ramp  mode:
• The track Array does a nice job of  generating a smooth path (as long as no acceleration direction changes occur).
• Ramp mode will rely on the user to send it reasonable points (tracking most objects does generate reasonable points).
• For large  changes, both methods reply on the controller profiler to make large moves.
processing: svn/aosoft/p12m/chkout/trArRampCompare_dec14/ crossPosTrkAr.pro, crossPosRamp.pro

Ps: i'd like to thank ed himwich and mark godwin for straightening me out on how ramp mode works....

12meter page
home_~phil