[RadioTelescope] Suggestions for safe operation

[Andrew Williams]

Harry McNally wrote:

> thing we found is that the local oscillator driver circuit causes the steppers
> to judder rather than step at some midrange step rates. So there may be issues
> with the interface board and it may end up being put aside. I'm wondering if
> we can't use a small computing device to clock the stepper driver modules
> directly using software. It hinges on the step rates that are needed which is
> early days.

Taking this back on-list...

Juddering at _midrange_ step rates sounds bad - if it works OK at higher 
and lower rates, I'm not sure why it would fail in the middle, except 
maybe at a specific resonant frequency?

> We'd welcome your experience with stepping large masses (aka telescopes)
> although after the resolution you've described in your longer email, the old
> gun mount is a tad rudimentary :-)

The motors on our telescope look about the same as the ones you have - 
not sure of the exact specs, but they are physically around the same 
size, 1.8 degree steps, and a 120V drive system (with large series 
resistors).

Our motors are geared down by a factor of 6480 to drive each axis, for 1 
arcsecond on the sky per step, and the controller is a 'microstepping' 
controller, that doesn't just switch the two phases to reverse polarity, 
it smoothly varies the currents in both phases in 20 'microsteps' per 
full step, so the motor is left hovering between the poles except at the 
full step boundaries. Microstepping controllers are very expensive, and 
I doubt yours can do that, but it doesn't need to.

Motion control in a moving reference frame gets interesting - the Earth 
is turning, so the position of every 'fixed' galaxy has an alt/az that 
changes with time. That means the final telescope position depends on 
how long it takes to slew from the original position (as well as what 
time you start slewing), but of course the slew time depends on the 
final position. Solving differential equations for every slew makes it 
particularly ugly if you want to work out an acceleration profile, a 
certain time at maximum speed, then deceleration, in advance. It also 
means you need to accelerate and decelerate not from/to a full stop, but 
from/to the sidereal track rate (accounting for the rotation of the 
Earth). The sidereal tracking rate for an alt/azimuth mount also depends 
on the position, with a singularity directly overhead where it has to 
move infinitely fast in azimuth to follow an object passing overhead.

What we did was split the motion control into two entirely separate 
streams. The sidereal track rate to follow the rotation of the Earth is 
calculated at a low level (for us, it was just a constant rate in one 
axis, because we have an equatorial mount, but it's not hard to work out 
a sidereal rate in alt/az). Every 50ms, that sidereal rate in each axis 
is then added to the velocity calculated for a ramp-constant-ramp slew 
between two 'fixed' points (fixed in the new, sidereal reference frame). 
Other velocities are added as well, for dynamic tracking (using a high 
speed camera on a bright star), telescope flexure (using a model of how 
the tube and other structures bend depending on position, etc, but you 
wouldn't need those.

You can probably get by without a lot of this, but at the very least, 
you'll need to calculate and apply a sidereal trackrate in both axes, 
handle transitions between slewing and sidereal rates, and deal with the 
singularity at the zenith...

Andrew