Plate Solving, Pointing Correction &
Auto Mapping (A laymen's explanation)
Plate Solving
Plate solving is a technique by which a
computer and a catalog of known stars are compared to a CCD image of the
sky. If a pattern of stars is matched (a solution is found), the plate is
consider "solved". The term plate referrers to a photographic plate that is used to capture
an image of the sky. The plate glass is covered with a emulsion of silver salts
that is light sensitive. Plates for the most part are no longer used in professional
observatories, the images are captured using CCD
chips.
After the digital image is acquired
it is downloaded
from the camera in to the computer, and the solving process can begin. In
order for the plate solving software to be successful some parameters must be
defined:
- The telescope's focal length
- The camera's pixel size (x, y)
- The image's bin
factor
Once these parameters are known the image's
scale can be computed. A correctly defined image scale is one of the key
parameters required for successful pattern
matching. Software is used for the process of comparing the scaled image against
a catalog of stars the computer has access to. The more catalogs the computer
has access to the better the chances of the software finding a match. The more
stars used in the solution the more accurate the match will be. The
time and date the image was taken along with the longitude and latitude of the
where the image was taken are usually embedded in the header of image.
This software uses the header info in order to help
speed up the time it takes to find a solution. By using the time and location data
the software only has to search the areas of the sky
that were visible to the scope's location at the time and date the image was acquired. The sky is
a big place so not having to search all of it is a real time saver.
Since the catalogs contain the stars
positions, once a good plate solution is found, the computer now knows
the coordinates of the center of the image. The center of the image corresponds to the
exact location
in space the scope was pointing when the image was taken. That coordinate data is inserted into
the image. That location data is known as the World Coordinate System (WCS).
The WCS data along with the image scale and pixel size allows the computer to assign coordinates
to each of the pixels. That in turn allows the computer to know the coordinates of
any location in the
sky captured by the image.
Pointing Correction
Now that the system has a process for acquiring knowledge of sky that process can be used
any time to
determine exactly where the scope is pointed. If the system determines the
scope's plate solved position is different from where it was commanded, the
computer will slew the scope to where it should be pointed based on the previous
plate solve. It will then capture another image, perform a plate solve and again compare the
coordinates at the center of the image to the scope's commanded position. It
will continue the process until the plate solved coordinates and the commanded
coordinates are within the user's specified tolerance.
There are a number of reasons the scope might
not end up pointed to the targeted position. Generally the most common reason is
poor polar alignment. Other reasons are unbalanced mount or optical tube assembly
(OTA), misalignment between the mount and the OTA, or flexure within the system components.
While the plate solving process does work to
correct the mispointing, it is inefficient as a stand alone tool because it
has no knowledge of the particulars that caused the scope's pointing, issues. Therefore it has to repeat the iterative
pointing correction process every time the scope is commanded to a new position.
A better
solution would be to correct the telescope's pointing errors at the time the
scope is pointed. That correction would take into account issues mentioned
above, poor alignment, imbalance, cone error, as well as other mechanical issues that contribute to
mispointing. Only repeatable errors can be correct. pointing error caused by
things like mirror flop on SCTs can't be corrected because mirror does not
always shift to the exact same position. To correct the pointing errors the
computer needs to know exactly how far from the commanded location the scope
actually is. To do that a
telescope pointing model of the sky needs to be made. The model is made with the
help of the pointing correction software. The process involves the scope being slewed to a
target in the sky such as a star. Hopefully the scope is capable of placing the object within the field of view (FOV) of the eyepiece
or the CCD chip before the
correction. The target is then centered and the delta between the commanded
location and the centered location are measured and the corrected point is mapped by
the correction software. The next time the scope is commanded to that location
in the sky, the software will automatically correct the pointing so the scope is
slewed to the proper location. The pointing and centering process is repeated until
the scope's visible sky is mapped. Now when the scope is commanded to slew to a point, the
map of the correct sky is used to make an adjustment to scope's final
location.
In order for the correction map to be
effective it needs cover the area of the sky in which the scope will be used
and, the point density of the model has to be enough to capture any pointing
issues the scope may have. Obviously the better aligned and the more mechanically
stable and reliable the mount is the less dense the model needs to be.
However it
is not uncommon for a model to contain hundreds of corrected points.
The problem is many astronomers make this model
manually, as previously
described by pointing the scope at a star and then centering the star in a
reticule eyepiece. If you are only modeling a few points (less than
20 or so) performing this task manually might be a viable option.
But if you need to build a model that contains a few hundred points performing
that task manually would be rather time consuming .
Auto Mapping
The most efficient way to build a
dense pointing correction model is by using a CCD camera and a software program
that automates the process. The procedure performs the initial slew of the scope
to a set of coordinates. After the slew is complete the auto executes the plate solving
to determine the scope's exact location, it then calculates delta from
current location and the commanded position just as the manual process above
did. The offset is then mapped into the pointing correction software. The
process continues until all the predefined list of coordinates have been mapped.
This automated process is called auto mapping.
I know of a couple of software packages that can
perform the auto mapping process. They are MaxPoint
by Diffraction Limited Automapper
II by
Ron Wodaski and AAG TPointMapper by
AAGWare. The last 2 programs are free. Automapper II is free courtesy of the Software Bisque. AAG TPointmapper free,
courtesy of the author.
Automapper2 was designed to use TPoint,
CCDSoft and TheSky6. It has the ability to either use mapping points created
with TheSky6 and then imported as a file, or it can generate is own lists.
AAG TPointMapper was also designed (as the
name implies) to use TPoint, CCDsoft and TheSky6, but it also supports MaxImDL
4 and 5. This is a plus for users that don't own CCDSoft. Another major
difference is TPointMapper requires the use of the full version of
Pinpoint as the astrometry engine instead of the Bisque astrometry engine.
The downside of this is the full PinPoint version is not free and costs
around $149US just for the license. (This assumes you are going to download
the pinpoint program and already have a star catalog).
Summary
I have used both programs and
have had a better results with AAG TPointMapper. One of the problems I
have experienced with Automapper2 is frequent "out of memory errors".
When that occurs the run is aborted and the remainder of the points to be mapped
are lost. Since my system is operated
mostly without user interaction a failed mapping run in the middle of the night
is unacceptable. The other issue is if you have a slow rotating dome and
don't use the Bisque's dome control program (Automadome) you will have to add a
delay to the start of each image taken. This needs to be done to allow time for the dome to be
positioned before the image acquisition begins. That delay can be as high
as 60+ second on some systems. AAG TPointMapper avoids this by commanding
the dome's position at the same time the scope is commanded and then waits for
the dome slew to complete. I have executed runs of 200+ points with only about 2 to 3 errors on the first pass.
AAG
TPointMapper will make up to 3 passes all of my errored points were successfully
mapped on the second pass. The only time that errored points were not
successfully mapped on the initial or subsequent run is when the sky was
obscured by clouds.
The image below is a screen shot of
an automated mapping run using the TPointMapper
software in use on my system. The screen is rather busy as I am monitoring a
number of things while the software is running.
A larger screen capture is available by
either clicking on the image above or clicking here
.
Description of the windows above:
Upper left - This the dome control
software, which monitors both the scope and dome's position.
Upper
middle - The TPointMapping program as it steps thought the points to be mapped.
It tells you where the scope was slewed to, if the plate solve was successful,
and if the point was mapped.
Right side - Grey area: The scatter of the points mapped from the TPoint model
within TheSky6. As more points are mapped and the scopes pointing is corrected
the radius of the circles should decrease. The lower area on the right
side represents the virtual sky. The darker gray star filled area is the
plate solved image that was taken with CCDSoft. It has been linked, scaled and overlaid
into TheSky's virtual display.
Center Middle - This window is the target
information window. It give details of object where the scope is pointing or
cursor is. It this case the cursor and scope position are the same.
Lower middle - The partially blocked window is camera status window from
CCDSoft. The blue progress bar is showing the time left in the image
download from the camera. During the image acquisition the bar will show
the time remaining in the exposure.
Lower left
- Display from the scope mounted camera. It keeps an eye on the dome's slit and
allows me to see where in the sky the scope is currently pointing. For the
mapping run it lets me know if there are any obstructions such as trees or a
house that might be blocking the object and cause failed points.
Go to the
JATObservatory
Home page
Updated
07/04/2009
- Please report broken links
webmaster@jatobservatory.org
