Abstract
The Telescopi ROBotic de ARas (TROBAR) is a new robotic facility built at Aras de Los Olmos (Valencia, Spain). This is a 60 cm telescope equipped with a optical camera, corresponding to FoV, and it will be primarily used for a systematic search of Ha emitting stars in the Galactic Plane to a depth of 14 mag. Both data acquisition and reduction will be performed automatically. The robotization of data acquisition is now entering its final coding phase while the development of the data reduction pipeline has just started.
1. Introduction
Galactic H emitting objects are tracers of pre- and postmain-sequence stars as well as of nebulae, cataclysmic variables, Be stars, and other more exotic objects like Luminous Blue Variables (LBVs) and Wolf-Rayet stars. IPHAS [1–4], the most complete survey of the galactic plane carried out so far, is complete in the magnitude range to for . The classical surveys, mostly based on objective-prism photographic observations, are complete up to magnitude 9 (see, e.g., [5, 6]). In this context, the main aim of our project is to carry out a photometric survey covering the existing gap down to 14 with observations and data reduction automatically performed.
2. Telescope and Location
TROBAR is located at the Observatori Astronomic de Aras (OAA), approximately 100 Km north-west of Valencia, at an altitude of 1330 m, in a region of low light pollution. The telescope, realized by Teleskoptechnik Halfmann, has a main mirror of 60 cm in diameter, with a classical Ritchey-Chrétien optical scheme; a Nasmyth focus is present, to which an optical camera is attached. The telescope can slew as fast as 10 deg/sec allowing to point any region of the sky in less than a minute. A filterwheel hosts standard Sloan Strömgren plus two H filters (one narrow and one medium-band). Table 1 lists the main features of the telescope.
Low level control of telescope pointing capabilities is done by the Pilar software provided by Systems Gmb company, which supplies a socket interface to the TCS commands.
The optical detector is a Fairchild Peregrine 486 back-illuminated CCD, providing an array of pixels of 15 m 15 m read by four amplifiers; the readout noise is .
The telescope can be both remotely controlled and robotically operated and a set of commands also allows to perform almost all the operations via scripting procedure. Here we will outline its robotic capabilities.
3. System Description
The operations which can be performed by the telescope comprise the acquisition of calibration frames (bias, darks, sky flat field, and focus) and the observation of scientific targets.
All the software is written in python, with the Object Oriented paradigm. All astronomical calculations are performed through the pyephem libraries (http://rhodesmill.org/pyephem/).
The routine operations are managed by a set of 3 main programs, in communication one with the other through TCP/IP connection. The adoption of the TCP/IP paradigm allows a complete independence of the software from the running machine, hence allowing fast replacing of hardware in case of problems. These high level programs communicate with low-level processes managing the corresponding device (see Figure 1).
The organization into three main programs directly reflects what are the main duties an autonomous observatory should accomplish, namely, check meteorological conditions, safely manage the dome opening and, when all the conditions are good enough, send an observation to the telescope. In the following sections the realization of each one of these processes will be described.
3.1. Meteorology Manager
Meteorological information is collected by a DAVIS Vantage Pro meteorology station, installed on a pillar located 10 m away from the dome; it is equipped with sensors for measuring air pressure, inner and outer air temperature and relative humidity, wind speed and direction, solar radiation and rain rate.
Meteorological data is collected by a dedicated process, called meteo_man. This program reads the meteorology station every 5 minutes during the day and every minute during the night. Apart from reading data, it also checks if current meteorological conditions are to be considered safe for operations; this requirement is achieved when all the following conditions are satisfied
(i)External humidity must be below 85%.(ii)Difference between the dew point and current external temperature as absolute value must be grater than 3 degrees Celsius.(iii)Wind speed must not exceed 15 m/s. If the speed is between 12 m/s and 15 m/s then an azimuth limitation flag is raised, meaning that the telescope should avoid to point directly into the wind and to the 180 degrees around it.(iv)Atmosferic pressure must be above 870 hPa.(v)Rain rate must be equal to zero.If any of the above conditions is not satisfied, then the bad meteo condition flag is raised. Since the evaluation of safe meteorological conditions is a very delicate task for any autonomous robotic telescope, particular prudence has been implemented in the algorithm evaluating the meteorological conditions. Thus, when conditions are not satisfied, in order to consider meteorological conditions good again, these must satisfy for 30 minutes the above rules with stronger constraints, namely, humidity must stay below 80%, wind speed below 12 m/s, pressure above 880 hPa and, of course, no rain.
3.2. Dome Manager
The enclosure of the telescope is a classical hemispheric dome with two vertical sliding doors. The dome can rotate at a maximum speed of 6 degrees per second, which, during the pointing, translates to an average delay of 30 seconds respect to the telescope, so that the pointing of the telescope is poorly affected by the dome and it is not a concern at all for the scope of the scientific project.
The program dome_man, which is in charge of managing the dome has two main duties.
(i)To provide a socket interface to the dome actions: although for robotical operations the dome is kept synchronized to the telescope position, so that it is not necessary to reposition the dome before each observation, its status is continuously monitored by another process, running on a different machine, which detects malfunctions and informs the team accordingly.(ii)As autonomous process, it continuously acquires the meteorological conditions and decides to open or close the dome depending on meteorological conditions and sun altitude. Currently, the dome is allowed to stay opened when the sun in below degrees of altitude.3.3. Observation Manager
The third main process, obs_man, is the one which is in charge of managing the observations. Figure 2 shows the diagram of the main activities. The system continuously checks if there is a target suitable for observations, if meteorological conditions are fulfilled and if the dome is open. If this is the case, then the observation process starts. This is composed of two threads, one checking the tracking status of the telescope during all the exposure and the other checking that all the environmental conditions are valid during the whole observation.
Due to a limitation in the low level software controlling the camera provided by the camera company, it is currently not possible to interrupt an ongoing observation. The information collected by the two threads is then used at the end of the exposure for validating the observation; if at least one of the two threads reported an error, then the target is ingested back into the archive for subsequent reobservation.
Although the scheduling software already takes into account constraints whose dissatisfaction can reveal dangerous for the telescope, the observation manager, before starting each target, performs a bunch of checks which prevent the telescope from directly pointing towards the sun, the moon and towards those directions which cannot be reached by the telescope and would thus send the telescope to its limit switches.
Each one of the above processes is coupled to an isAlive program. This is a crontab regulated job periodically checking that the corresponding process is running and, if this is not the case, restarting it.
3.3.1. Target Archive and Scheduling
The set of targets is organized in a MySQL table. Each target can be associated to a user-defined priority value with the logic that the lowest is the value, the highest is the priority; in addition the definition of all the most common constraints under which each target should be observed, such as the maximum moon fraction and distance, minimum and maximum airmass, and periodicity of observation is implemented.
The fundamental idea behind the scheduling algorithm is to try to observe each target when it is closest to its minimum airmass (either because it is transiting through the meridian or because the user set a greater value in the minimum airmass field). This is achieved in the following two steps:
(i) the scheduling software makes a first pass through all the targets, selecting only those whose constrains are satisfied from that moment and through all the exposure time;
(ii) a figure of merit (FoM) is then applied to each of the selected targets. This FoM is a generalization of the mathematical function, where here stands for the whole set of parameters. This is done in order to have a strong peak when all the conditions are best satisfied. The complete adopted function is
where is an integer number specifying the priority, with the value of denoting the highest priority; the normalized difference between the current and the minimum airmass is given by
where is the airmass at the time of the computation and is the maximum between the minimum airmass the object can reach on the sky and the user requirements for the minimum airmass; is the ratio between the total time an object is above its horizon (as define by the airmass constraints) and the required exposure time. Finally is the normalized distance of the object from the celestial pole. Explicitely, the expression for is
Here is the declination of the object, is the minimum declination which is visible from the site for a given airmass, and is a factor to reduce values to a suitable range of values of the whole function.
The term has the effect of giving higher priority to those objects with low declination, which typically are the objects whose time for observation is shorter than that of objects at higher declinations. Finally, the exponent to the argument of the exponential function has been introduced in order to smooth the wings of the FoM.
Figure 3 shows the value of the result of applying the FoM described above to three targets with the same Right Ascension but with Declination , , and , respectively.
Note that targets with will always have the lowest value of (in fact independently of the value of the other constraints), which translates into allocating the -priority target as soon as possible.
The FoM expression can of course be generalized by introducing multiplicative parameters with the effect of shifting in time the points where the FoMs of targets with the same RA but different intersect (cf. Figure 3), in order to better suite arising scheduling needs. This optimization will be done during the commissioning phase.
3.4. Hardware
All the software runs on almost of the shelf hardware, without any particular need for high-speed processing, with a total number of three computers. The only exception is the machine with the obs_man program which is running on a quad-core linux. This is due not because of the supposedly high demanding software of the observation manager, but because this machine is shared with another experiment which need real-time data analysis.
In addition, each machine has its own UPS system granting power supply to the computers in case of shortages. A UPS for the dome is also foreseen to be installed in the near future.
4. Current Status and Future Prospects
The coding is now complete at the 80% level and we foresee to complete it by the end of the year. In particular one of the tasks we still need to implement is the procedure of automatic focusing. This will be achieved by a single exposure, tentatively at the beginning of the night, on which a bright star is imaged with different focus offset and by slightly moving the telescope between one acquisition and the next. The image will then be analyzed using SExtractor [7] and the fwhm of the star fitted by a parabola.
In parallel we started to develop a pipeline for the reduction of the survey data. This will make extensive use of the pyraf environment for the prereduction processes (bias subtraction, flat field correction, etc.). Detection of the objects on each image will be managed by SExtractor; its mag_auto value will be used as a first estimation of the flux, which will then be used by DoPhot [8] to derive psf magnitudes.
5. Conclusions
We described the software for the robotization of TROBAR, with the aim of performing a survey of the Galactic Plane, looking for H emitting objects. The system is able to allocate and observe the targets in a MySQL archive when they are best visible and depending on observing constraints. The code is now almost complete and we foresee to start robotic operations by the end of the present year.