[mmaimcal]Re: [Almasci] Antenna Acceleration

[Richard Hills]

Dear All,

It would certainly be a good idea to check this with an expert on the control
side, but I think I can reassure you that this is not likely to be a problem.

I believe the telescope specification is as follows:

"The commanded position and rate apply at the second timing event after the
command is received. The ALMA computer will guarantee that the command is
available no later than 10 ms in advance of the next timing event. If no
position command is received between two timing events, the position and rate
applicable at the next timing event shall be derived by constant velocity
extrapolation of the most recently received command. In this way, there is a
commanded position and rate that applies at each timing event. At any time
between timing events, the commanded trajectory shall be determined by a fixed
interpolation rule chosen by the Contractor to produce smooth motion, taking
into account the response of the servo. The position and velocity command is
the primary control interface.

The servo shall attempt to make the actual trajectory of the antenna follow
the commanded trajectory. If the latter contains first or second derivatives
exceeding the maximum angular velocity or acceleration (see 3.4.4), the servo
shall drive the antenna so as to converge to the commanded trajectory as
quickly as possible while meeting the settling time requirements (3.4.4)."

I interpret this as saying that during each 48msec interval the ACU has 4
numbers to play with - the postion and velocity at the beginning of the
interval and the position and velocity at the end.  Although the contractors
are free to do as they choose, it seems to me that the only sensible thing to
do with these is to fit a cubic, e.g. x = a + b*t + c*t^2 + d*t^3.  Here d is
the jerk that Mark talked about.  So long as the contractor does this, and the
motion that is demanded can also be described by a cubic, then the
interpolated trajectory should be exactly that demanded.  

If the higher level software is perverse and tries to change things part way
through an interval (e.g. by reversing the jerk) then there will be an error. 
It is clear however that any such error will be small.  Remember that the rate
of the commands is one per 48msec, i.e. 20.8Hz, so that the position data is
fully sampled up to ~10Hz, whic is probably more than the servo bandwidth, and
we are giving it the velocity information as well.

I have done a little spreedsheet (attached) to make sure about this.  The plot
shows the required position and the interpolated position (using a cubic to
interpolate the position, given the position and velocity at the beginning and
end of each 48msec interval).  This is an extreme case with the jerk going
from +100 to -100 deg/sec^3.  The initial velocity and acceleration are chosen
to keep the excursions small.  

For the first two intervals the jerk is fixed for the duration of the
intervals and only swithces at the boundary.  It is seen that the
interpolation is good (the error that it is just visible is probably due to
the crude numberical integration).

For the second interval the jerk is changed and the mid-point, and one does
see some error, but it is not significant, espcially as this would presumably
not be a moment when one was expecting the full accuracy.  I imagine that the
limited servo bandwidth and the inertial forces in the structure would cause
much greater errors under these circumstances.

I hope this helps
  Best Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: interpolation.xls
Type: application/msexcel
Size: 197120 bytes
Desc: not available
URL: <http://listmgr.nrao.edu/pipermail/mmaimcal/attachments/20031116/ba11d807/attachment.bin>