Guide Algorithms
Guiding Theory
Guide Algorithm Parameters
Guiding Theory
The default guiding
algorithms in PHD2 are well-established and should work well for most
users. Unless you already have some experience with guiding and
understand the basics, you should probably be cautious about changing
algorithms. However, you may have some special circumstances that
require changes or you may simply want to experiment with the different
algorithm choices. The Advanced Dialog settings in PHD2 make it
easy to do that. Each algorithm has a set of parameters that
controls how observed changes in guide star position (star deflections)
are translated into guiding commands that are most likely to restore
the star to its initial position.
Before
discussing the
details of these parameters, it is worth reviewing a little guiding
theory and looking at what these algorithms are trying to accomplish.
Setting aside
adaptive optics devices, which are entirely different, conventional
guiding faces enormous challenges. The problem at hand is how to
move machinery that weighs tens or even hundreds of pounds with a level
of precision that will not cause streaked or oblong stars. This
type of guiding can only hope to deal with tracking errors that are
"slow and steady", not "fast and random." Sources of slow and
steady (correctable) errors include the following:
- Certain kinds of mechanical imperfections in right ascension gears, including those that cause periodic error.
- Smalll errors in the sidereal tracking rate of the mount
- Atmospheric refraction - stars appear to move more slowly as they near the horizon
- Limited kinds of mechanical deflection and flexure - but not differential flexure
- Mis-alignment of the right ascension axis on the celestial pole
So
what isn't included in the above and isn't correctable by conventional
guiding? Unfortunately, it's a very long list, of which a few
are:
- Atmospheric seeing ("turbulence")
- Gear noise, roughness, and vibration
- Differential flexure - relative movement between the imaging scope and the guide scope
- Wind gusts, cable snags, grit in the drive gears
- And lots more...
The
common denominator shared by the guide algorithms is the need to
somehow react to the slow and steady deflections while ignoring the
rest. This is a difficult problem at best because any given guide
star
deflection is likely to have contributions from many of these sources.
And if that isn't hard enough, remember that real-world
mounts are never perfect - so the move you ask for will not be exactly
the move you get. Usually, the most important requirement
for any algorithm is
to avoid over-correcting, wherein the mount is being pushed back and
forth and the guiding never stabilizes. A typical
approach in these algorithms is to apply "inertia" or "impedance" to
the guiding
corrections. That means making corrections that follow a pattern
and are generally consistent with corrections that have been made
before, while being reluctant to make corrections that require a big
change in direction or amplitude. Resistance to changes in
direction is particularly important in declination, where gear backlash
is a common problem. Hopefully, this background will give you
enough insight into the basics of guiding so that the various guiding
parameters used in PHD2 will make sense.
Guide Algorithm Parameters
In
PHD2, the various guide algorithms can be applied to either the right
ascension or declination axes. Most of these algorithms
include a minimum move
parameter. This is used to avoid making guide corrections that
are overly small, are unlikely to have any effect on star shape, and
are mostly due to transient seeing effects. These values are
entered in units of pixels, so you need to think about them in the
context of how large your star images are. The default values
work well for short-to-medium focal length systems, but you may
need to increase them if you are working at long focal lengths and
expect stars to have larger diameters.
The hysteresis
algorithms keep a history of the guiding corrections that have been
made in the recent past, and these are used to help compute the next
guide correction. The hysteresis
parameter, expressed as a percentage, specifies the "weight" that
should be given to this history as opposed to looking only at the
star deflection in the current guide frame. Consider an example
where the hysteresis parameter is 10%. In that case, the next
guiding correction will be 90% influenced by the star movement seen in
the current guide frame and 10% by the corrections that have been made
in the recent past. Increasing the hysteresis value will smooth
out the corrections at the risk of being too slow to react to a
legitimate change in direction. The hysteresis algorithms also
include an aggressiveness parameter,
again expressed as a percentage, that is used to reduce
over-correcting. On each frame, PHD2 computes how far it thinks the mount
should move and in what direction(s) it should move. The aggressivness
parameter scales this. For example, take a case where the star deflection
has been evaluated and a corrective move of 0.5 pixels is warranted.
If the aggressiveness is set to 100%, a guider command will be
issued to move the mount the full 0.5 pixels. But if the
aggressiveness is set to 60%, the mount will be asked to move only 60%
of that amount, or 0.3 pixels. If you find your mount is always overshooting
the star, decrease this value slightly (say, by 10% steps). If you find PHD2 always seems to be lagging
behind the star's motion, increase this by a little bit. A little can
go a long way here.
The ResistSwitch
algorithm behaves much as its name implies. Like the hysteresis
algorithms, it also maintains a
history of past guide corrections, and any change of direction must be
"compelling" in order to issue a reversing guide command. This
is appropriate for declination guiding, where reversals in
direction are both suspect and likely to trigger backlash
in the gears. For that reason, ResistSwitch is the default
algorithm for declination but not for right ascension, where valid
direction reversals are expected. Starting with Release 2.4.1,
two additional parameters are available for fine-tuning the
ResistSwitch algorithm. The first is "aggression", a percentage
amount that controls how much of the computed guide correction will be
issued. Reducing this parameter can help to avoid over-shooting
with mounts that have little or no backlash. The second parameter is a
checkbox labeled "Fast switch for large deflections." If this is
checked, PHD2 will react immediately to a large change of direction
rather than waiting for three consecutive deflections in the new
direction, which is the normal behavior. This can help to more quickly recover
from large excursions in Dec, perhaps caused by wind, cable snags, or
other mechanical shifts The definition of a "large deflection" is
3x the minimum-move value. So if PHD2 is over-reacting to
direction changes, you can tune the behavior with the min-move
parameter or disable the "fast switch" option altogether. It is
worth remembering that "less is usually better" when it comes to Dec
guiding, so don't try to over-tune these parameters.
The LowPass algorithms
also employ a history of recent guiding corrections in order to compute
the next correction. The starting point for the computed move
is the median value of the guide star deflections that have
occurred in recent history. This means that the star deflection
seen in the current guide frame has relatively little impact on
calculating the next move and the algorithm is very resistant to quick changes. But the history accumulation also
includes a calculation to determine if deflections are trending in a
consistent direction. The slope weight
parameter, expressed as a percentage, determines how much influence
this should have in calculating the actual guider movement - it is
there to keep the algorithm from being overly sluggish. If you
set a slope weight of zero, the guide pulse will always be just the
median value of the recent history. If you set a non-zero slope
weight, that median value will be adjusted either upward or downward
based on the recent trend of guide star movements. Because
the low-pass algorithm is so resistant to quick changes, it is probably
most applicable to declination guiding.
The LowPass2
algorithm is a variation of the original LowPass algorithm with
somewhat different behavior. It also maintains a history of
guiding corrections, but the next correction is simply a linear
extension of the commands that have come before it (i.e. a slope
calculation). This continues until a significant change in
direction is seen, at which point the history is cleared. The
algorithm has two adjustable properties: minimum-move and
aggressiveness. Minimum-move has the same effect as it does in the
other guide algorithms, and aggressiveness (percentage) is a way of further
dampening the size of the guide corrections. LowPass2 is a very
conservative, high-impedance algorithm that may be a good choice for
users with good seeing conditions and well-behaved mounts with little or no declination backlash.
PHD2 Predictive PEC Guide
Algorithm (PPEC)
Overview
The PPEC algorithm is different from the others in PHD2 because
of its modeling and predictive capabilities.
The algorithm analyzes the tracking performance of the mount in
real-time and once that analysis is complete, it will compute guiding
corrections even before a repetitive error is actually seen. Issuing proactive guiding corrections reduces
the time delay inherent in traditional guiding and can significantly improve
performance. With the other algorithms,
which are completely reactive, guide corrections are issued only after the
error has been seen on the camera sensor.
Once guiding has begun, the algorithm analyzes the
performance of the mount and looks for tracking errors that are repetitive and
thus, predictable. The algorithm employs
a sophisticated Gaussian process model developed by a research team at the Max
Planck Institute in Germany. The mathematical details can be found in a
paper referenced here:
http://ieeexplore.ieee.org/document/7105398/?reload=true
The PPEC algorithm will normally be used for RA, where
residual periodic error and other gear-related errors often reduce tracking
accuracy. The algorithm uses separate
time-scales for characterizing the behavior of the system:
· Short-term: for high-frequency errors such as
those caused by gear roughness or seeing
· Medium-term: for residual periodic errors, typically occurring
at intervals less than or equal to the worm period
· Longer-term: for steady drift and for lower
frequency (longer time interval) harmonics that can be caused by the
interaction of multiple gears in the drive train
The short-term behavior is used to identify the
unpredictable noise in the system, which is essentially filtered out in order
to identify components that are predictable.
For most mounts, the medium-term component is likely to be the most
important. If you’re following best
practices, you will have programmed periodic error correction in your mount (assuming
that feature is available to you). Doing
this reduces the amount of work that needs to be done by PHD2, and the PEC
correction in the mount is normally saved permanently. This approach is preferable to having to
measure and infer the periodic error behavior every time you set up your
equipment. That said, PEC in the mount
is never perfect, and you will often see residual repetitive errors even when
PEC is active. These often arise when
the tracking errors occur with a frequency that is not a harmonic (integer
fraction) of the mount’s worm period – most PEC implementations can’t deal with
those. You can also get residual
periodic errors if they are dependent on the mechanical loading of the mount or
if the mount’s behavior has changed since the PEC was programmed. The PPEC algorithm can be quite effective at
identifying and reducing these errors because it doesn’t depend on the worm
period and is always doing a fresh analysis of the mount’s current behavior.
The PPEC algorithm will also detect and proactively correct
for drift errors. Although drift is
typically handled well by any of the guide algorithms, the corrections will
always lag the error by some amount. For
some use cases – perhaps spectroscopy, photometry or comet-tracking – this
might be a problem, in which case PPEC may deliver better results.
Since PPEC employs a learning process, it will usually take about
2 worm periods to model the mount and become fully effective. During this training period, the algorithm
will behave more like the ‘hysteresis’ algorithm, so you won’t normally see a
performance penalty while the internal model is being built. Instead, you’re likely to see a steady
improvement in tracking as the model is refined and the algorithm shifts seamlessly
from hysteresis to predictive-mode. This improvement can usually be seen even before the medium-term mount behavior is fully modeled.
Since the PPEC model is implicitly tied to the state of the
gear train, it must be re-learned if the mount is slewed to a new target. For the same reason, it can’t be retained
across different guiding sessions, which is why conventional PEC is
important. However, the PPEC model will
remain intact during dither operations and while guiding is paused (via
automation) for activities like focusing.
For the most common use-case, namely imaging the same target for
multiple hours with periodic dithering, the PPEC model will remain valid. In any case, the learning process and
transition from one mode to the other is handled automatically, so you won’t
need to pay it any attention.
Algorithm Details
Once the training period is completed, the PPEC algorithm
computes the guide correction using two factors. One is reactive, based on the displacement of
the guide star in the most recent exposure.
The second is predictive, based on the output from the Gaussian process model
constructed during the training period.
Each of these terms includes a separate gain or aggressiveness factor,
so the final guide pulse amount is a sum:
Guide-correction = (predicted amount * predictive gain) +
(recent displacement * reactive gain)
The ‘predictive gain’ and ‘reactive gain’
parameters are exposed in the Advanced Dialog, and their default values for
these parameters should work well for most mounts. You should be conservative about changing
them because bad choices for these parameters can definitely make your guiding
worse.
During the training period, the algorithm needs to identify
periodic errors in the observed guide star movement. For initial trials, you can use
the worm period of your mount as the starting point for the ‘period length’. This gives the
algorithm a good starting point, but you should also leave the ‘auto-adjust
period’ option checked. This
tells the
algorithm to adjust the period as needed to better control whatever
periodic
errors it finds. Once you have run the altorithm multiple times
and are happy with the results, you can leave this field set to
whatever value was computed in the previous sessions.
The ‘min-move’
parameter affects only the reactive component of the algorithm. If the measured star displacement is less
than this amount, the reactive component will be set to zero. However, the predictive component of the
algorithm will still be computed and applied.