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.

There are two ways of getting the telescope focused in the manual way - with and without looking at the actual image.

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.

The autofocus subsytem is not yet definitively solved, but we have got already very far while getting there.

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 a observation scripts and observation processing. In particular, there is a special target which needs to be executed in order to (re)focus the telescope.

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.

We are using NGC188 as a high density spot on the sky which is always accessible on the north. The script looks like that:

''tempdisable 1700 focpos-=350 for 46 { E 0.5 focpos+=15 }''

the known good focus position may be set upon start of this script, (focpos=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.

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.

/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.

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.

• there is no way to feed the position back to the system

• there was 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?