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....