This is an old revision of the document!
Focuser API
Focuser presents various variables to the end user. They may look confusing on a first look, so here is a small description. You may find it also in man rts2-focusd.
- FOC_POS This variable show actual focuser position. If set, it will cause focuser to move to set position. If focuser is moved to position, it shows the actual focuser position.
- FOC_TAR Focuser target position. This shows desired focuser position. If set, it will cause to move focuser to set position.
- FOC_DEF Default focuser position. This is used together with FOC_FOFF and FOC_TOFF for autofocusing. If it is changed, target position is set to sum of FOC_DEF, FOC_FOFF and FOC_TOFF.
- FOC_FOFF Focuser offset found during focusing. This is used to temporary shift focus. If focuser driver is restarted, it is moved back to FOC_DEF position.
- FOC_TOFF Focuser temporar offset used during focusing. You should use this variable during focusing script to probe focus at different offsets.
If your focuser is named F0, and you would like to probe focusing range 100 steps bellow to 100 steps above default focuser position, the focusing script should look like:
F0.FOC_TOFF=-100 for 20 { E 10 F0.FOC_TOFF+=10 }
When script is finished, RTS2 will change FOC_TOFF to 0, which will cause focuser to move to default value. You can change either FOC_FOFF or FOC_DEF to set new focusing position.
The following equation should be true when you change focus with FOC_DEF, FOC_FOFF and FOC_TOFF:
FOC_TAR = FOC_DEF + FOC_FOFF + FOC_TOFF
Focusing in RTS2
There is no discussion about the fact, that the correct focus is essential in obtaining a high-quality images. Normally, it is the responsability of the observer to keep the telescope well focused. In RTS2, however, the observer is replaced by a computer program, so also the focusing should be, optimally, solved by an automat.
Manual focus
There are two ways of getting the telescope focused in the manual way - with and without looking at the actual image.
rts2-(x)focusc
A direct camera-to-image display tool is rts2-xfocusc
. It commands the defined CCD (or more) to perform the exposure and displays the visualized image on an X-window screen. Please refer to its manual page to get the full usage information.
Where the screen is not available, rts2-focusc
can be used. It is based precisely on the same kernel as xfocusc, but has no X-window capability - can save the image for remote inspection, and can run an external processing script. In some sense it is a precursor to the autofocus described later. Also, can be used as a simplest image acquiring program in RTS2.
Technically, with an appropriate script, if there is an electronic focuser, rts2-(x)focusc
could be used with the FWHM-minima search developed for the autofocus.
RTS2 and Autofocus
The autofocus subsytem is not yet definitively solved, but we have got already very far while getting there.
Search of FWHM minima
Getting the FWHM
Images in RTS2 are normally processed using /etc/rts2/img_process
to find for an astrometric solution.
Generally we need a program to measure and store the image FWHM (optimally as a fits header keywork for an easy access).
A working solution is to set up the object detection (with detect.advanced
) so that it tries to determine the optimum aperture and stores it in the fits image keyword DET_APE
. detect.advanced
normally does this, so just make sure that it is used. If you use detect.sexonly
to gain speed, you may restrict detect.advanced only to the focusing target.
Automatic focusing in RTS2 is solved using a combination of observation scripts and observation processing. In particular, there is a special target which needs to be executed in order to (re)focus the telescope.
Getting the minima
The search for minima is executed from /etc/rts2/obs_process
after termination of the focusing target script. There is a small external program which is performing this search - foc
.
The program fits parabola, hyperbola and absolute value function to the data, comparing the obtained chisq with linear and constant fit. If an improvement is encountered against the constant, and if linear is not the best, the best fit of these three functions is proposed as a solution.
obs_process integration
set up a focusing target
We are using NGC188 as a high density spot on the sky which is always accessible on the north. If focuser name in RTS2 is F0, the script looks like that:
''tempdisable 1700 F0.FOC_TOFF=-350 for 46 { E 0.5 F0.FOC_TOFF+=15 }''
the known good focus position may be set upon start of this script, (F0.FOC_DEF=3500) to make sure the focus will always start at a reasonable place - even when the previous focusing run failed and provided a stupid position. Now it was not there because the result - an improved position - could not have been uploaded anyway.
Setting tempdisable and a reasonably high priority would cause scheduling of the focusing run every now and then (30min here) - in my case to construct a temperature/focusposition relation.
img_process
If the local imgprocess calls detect.advanced
,
this call can be omitted during the execution of the focusing
script, thus saving some precious time. detect.advanced
calls
phot
for various apertures and saves the aperture with least
predicted scatter into the fits keyword DET_APE
.
obsproc.sh
/etc/rts2/obs_process
is the basic script called to process the observation. It identifies the images which belong to the given observation and tries to execute /images/…/archive/…/object/obsproc.sh, with all the images on it's command line.
set the position
To set the position computed from the data, one has to execute the following commands:
''rts2-xmlrpcclient -s <FOCUSER> FOC_DEF <POSITION>'' ''rts2-xmlrpcclient -s <FOCUSER> FOC_TAR <POSITION>''
The other imaginable ways like rts2-scriptexec -d <CAMERA> -s “FO.FOC_DEF=<position>”
works as well, but XML-RPC interface is the prefered way how to solve the problem.
on-target focusing
If anyone wants to reach a perfect focus for a particular target, then he has no other option than doing that manually as described above (i.e. setting up this target completely same as the special above PLUS the exposures needed to perform the observation – which is for sure annoying),
There may be other ways to solve this:
- by a defining a focusing macro somewhere in the configuration and referring to it in the script in a short way. The script would then look like: “filter=B .focus E 60”. Corresponding care would have to be taken in the
obs_process
.
- by some internal mechanism (which would make the executor even more problematic, but if well done, the user would not have to know about focusing at all).
Generally, we have no telescope which would have the optic unstable enough to care about on-target focusing.
Known Issues
- the way of feeding back the computed position is not definitively solved
- there was a bug related to scheduling of a command to move the focuser, which resulted in incorrect values in the fits headers. (i have no idea if this is already solved or it just happens randomly)
- we do not care if the astrometry is successfull, but obsproc mechanism by default does and does not provide a way to give us all images without complications. Disabling the astrometry and performing only object detection would improve the speed and overall processing. → disable the astrometry in the processing script? → How many things would this break?