Jeffrey S. Medkeff
Abstract: This paper reviews the recent history of small, generally self-funded robotic observatories, and details an operational mode designed at 701 and 933.
Since some of the terms used in this paper have different meanings in different fields, and since this paper discusses a cross-disciplinary technology from the perspective of a computer scientist, brief treatment of the definitions adopted here is in order. "Robotic" applied to telescopes and observatories refers to instruments which carry out full observing plans without the intervention of an observer present at the telescope, other than to begin the session and reduce the data. This means that remotely controlled telescopes are considered robots for the purposes of this paper.
There are two kinds of robots generally recognized within various computer science subdisciplines – intelligent robots, and unintelligent robots. Intelligent robots are here defined as being programmed with decision-making capabilities and gain their awareness of their operating environment through their own sensors. Currently machining, manufacturing, and space exploration are well known fields in which "intelligent" robots flourish. Unintelligent robots do not have any self-contained environmental feedback mechanism, and hence do not react to their operating environment, although they may be possessed of decision-making capabilities. The kind of robot most frequently discussed here, and the kind found at 701 Junk Bond Observatory and 933 Rockland Observatory, is an "intelligent" robot, as will be seen.
"Windows" here refers to the Microsoft Windows 32-bit kernel operating systems, with the Windows 2000 architecture as the exemplar. Consumer operating systems such as Windows 95 are compatible with some of the technologies discussed, but are not widely considered to be robust enough to serve as real-time robotic controllers.
"Unix-family" refers to a class of operating systems derived from AT&T’s Unix operating system. This broadly includes SunOS, Solaris, BSD, BSD/FreeBSD, Linux, and others. Although there are significant differences between these architectures – especially frequently unrecognized differences between Linux and "pure" implementations of Unix – these systems are classed as a unit due to certain fundamental characteristics they share.
The recent history of robotic observatories will be dated from the introduction of software, intended for the amateur astronomy market, which provided crude automation control of telescope and CCD camera. These were most frequently of a variety known as "list processors," in which a list of slewing and imaging commands with position and duration parameters was produced, the software reading the list serially and carrying out the commands. By early 1998, several such tools had been released and early experiments as to their use in astronomical research were being made1. This class of software has been taken to an extraordinarily high level of functionality by Brian Warner (Medkeff 2001).
Concurrent to this development, the implementation of robotic telescopes with relatively new Unix-family tools was taking place at several observatories. Tools such as Realtime Linux, SQL, and Tcl were favored by some innovators, such as Bakos 2001. Other developments include Project Rigel, an internet-controllable architecture described in Mutel 2000, a commercial version of which will be offered by Torus Technologies Inc. next year. It is not uncommonly noted that small robotic telescopes offer research observing opportunities for small or developing countries (Querci 2000, Mulherin et al 2000, etc) due in part to peculiar cost advantages. In recent years papers devoted to automated or robotic telescopes and their use have been ubiquitous.
Despite considerable interest in the professional astronomical community, deployed technologies have been considerably behind the state of the art as noted in Mutel 2000, Etzel et al 2000, and so forth2. In addition, although Unix-family technologies have been favored by the American and European scientific community, the few technologies made available by their developers have not been widely adopted, and a number of discreet systems have been independently developed – the wheel has, it seems, been invented many dozens of times over.
There are a number of reasons for the reluctance to adopt such systems widely, which include the Unix family3 not offering a fully real-time operating system, the use of aging technologies, the use of certain technologies in unsupported ways4, the poor documentation of open-source solutions developed academically5, the extremely limited flexibility of such software sources6, the relatively high skill cost7 of implementation compared to other architectures, and not least the reluctance on the part of small institutions to adopt an operating system which is not widely understood by significant proportions of the faculty and student population. Questions raised at AAS meetings in 1997 and 1998 inquired about the availability of robust tools for the much more common Windows operating system. This does not even consider the situation of self-funded facilities by wealthy individuals who "have little Windows and less Linux8," although some instances are documented in the literature (Medkeff 2000). Finally, at many institutional observatories, control and reduction software source code is seen as a competitive advantage in funding requests, meaning that many of the most desirable and functional systems are simply not available to users.
Into this environment of limited Windows tools meant for the amateur on the one hand, and Unix family tools meant for specific individual professional facilities on the other, Robert B. Denny offered a possible solution. Mr. Denny is a software developer noted for his development of a very robust and commercially successful web server and his background of many years of software development on many platforms. On September 8, 1998 Mr. Denny released the first piece of astronomical software that offered an open, standardized, scriptable interface via the Component Object Model9, an application for the control of Meade LX-200 telescopes called Astronomers Control Panel10. Mr. Denny opened this interface standard, called ASCOM, to participation by other software vendors and in short order the camera control and image processing program MaximDL/CCD was also a COM server. By early 1999, an astrometric and photometric reduction package called PinPoint was in open beta testing. These three tools together provided the first scriptable11 telescope and CCD camera control packages for the Windows platform12. Rapid expansion to professional level control systems such as PC-TCS insured the architecture’s deployment in both professional and amateur installations.
This development has driven a rapid expansion of robotic telescopes during the last year. One reason is that this architecture relieves the programmer of the necessity of writing low-level telescope and camera drivers, which are provided by component servers such as ACP and MaximDL/CCD, respectively. The programmer can therefore write a device-independent control application. For example, the author’s control software is currently in use at seven facilities, which use five different kinds of telescopes and eight different kinds of CCD cameras. No modification of the source code is necessary to accommodate this range of hardware.
Another reason for the sharp increase in the number of robotic telescopes using this architecture is that it delivers two desirable effects which usually are in conflict. The first such is the independence that the end user has from the software developer. The user is not limited to using the software in the ways the original developer envisioned the software being used. The objects’ methods can be used on the basis of logical tests, mathematical results, programmed randomness, arbitrary whim, or however the user desires. The second desirable effect is that technical support from the software developer is available should anything go amiss. In this way, the user is not ‘on their own’ in the event something doesn’t work as it should, as they are with publicly developed open sources. This provides an alleviation of the frustrations and tensions of being "locked in" to a monolithic architecture, without entirely cutting the user off from assistance. This is of tremendous advantage to users with limited skills in programming, Unix administration, and so forth, and indications are that this appeals heavily to observers and users in developing countries and to self-funded projects.
Finally, and perhaps most significantly, the sharp increase in the number of robotic telescopes inspired by ASCOM is likely a result of a large number of freeware, open-source scripts and other software that uses this architecture. Since this software is device-independent, the potential originator of a robotic telescope can simply download this material and put it into use the same night, which is not usually possible with the existing device-dependent Unix sources. In addition, if even this relatively simple process is beyond the user’s ken, free online support is available at the Robotic Observatory e-mail list.
Motivation for robotic observation is fundamental to the phenomenon here discussed. In the self-funded community, and in the case of many developing countries, the desire to increase the efficiency of observation appears to drive the decision to deploy robotic technology. Another consideration, especially prominent in the self-funded community, is the desire to reduce the amount of waking time spent engaged in tedious, repetitious acts.
That these strategies are effective when properly deployed can be illustrated with two cases:
Pre-Robot Robot
670 Camarillo
Obs 512 1067
701 Junk Bond Observatory13
Obs 72 1068
The success of such programs can only be insured by critical attention to operational needs. The operational needs of a robotic observatory are probably similar at any facility, varying only in matters of specific program, scale14, funding, and personnel. This section will relate in a general way some of the solutions to these needs that have been implemented at various observatories, and will concentrate heavily on the operations at 701 Junk Bond Observatory, an early and incomplete account of which can be found in Medkeff 2000.
The typically encountered operational problems and needs include but are not limited to:
Safety.
Overcoming a telescope’s deficiencies in tracking and pointing.
All-night (efficient) operation.
Mechanical deficiencies, and Dreaded Mirror Flop (in the case of SCT’s).
Thermal and mechanical effects on the position of the focal plane.
Keeping track of the telescope’s pointing location.
Scheduling the telescope’s use.
Dealing with error conditions.
Preventing mistakes – like taking a ten minute exposure of the moon, or pointing at the sun because we are still observing at ten o’clock in the morning, in the case of fully robotic facilities.
Safety is frequently considered a paramount issue in robotic facilities. The author considers the safety of instruments to fall under this category as well as the safety of personnel15. The technology here is relatively mature. Limit switches are frequently used on the telescope mounting to prevent the telescope from slewing or tracking to an unsafe location. Panic buttons or power cut-offs are commonly seen around observatories with automated operations16, and one such has been specified for Junk Bond Observatory’s 0.8 meter telescope.
Deficiencies in telescope tracking and pointing have historically been attacked through several means, including error modeling, pointing refinement algorithms of various complexity, and brute force via the use of a wide angle detector to insure targets land in the field. Another solution will be discussed below. Mechanical deficiencies are generally dealt with by professionals at the design stage, and are ignored or kludged over afterwards; similarly, after design thermal effects at the focal plane are similarly ignored or dealt with through the use of Invar compensators, etc. The solutions here can become quite expensive and are not options for those using off-the-shelf telescopes and mountings. They are also not possible to consider in the case of retrofits of existing hardware.
Scheduling telescope use is generally dealt with in professional circles by allocation committees for undedicated instruments. Robotic instruments which are scheduled to make large numbers of observations each night face a problem only slightly easier to deal with than an allocation committee, referred to in computer science circles as the "traveling salesman problem." Since millions of dollars have been devoted to solving the traveling salesman problem by airlines, railroads, shipping companies, and other such entities, it is unlikely that the astronomical community will enjoy a state of the art solution to this problem anytime soon. However granted certain assumptions, the traveling salesman problem can be solved to a point considered "good enough," and one such solution is discussed below. To be sure, this problem does not typically confront a self-funded single user facility.
We will now comment on the specific operations of a robotic observatory dedicated largely to the astrometry of minor planets. The experiences at 701 Junk Bond Observatory and 933 Rockland Observatory, with 0.4 meter and 0.3 meter telescopes, will be discussed, and from time to time some information learned as part of the continuing work to deploy the 0.8 meter telescope will be included. However the experiences and considerations are sufficiently broad as to be applicable to many other facilities. Most of the operational solutions adopted at 701 Junk Bond Observatory have also been adopted at 933 Rockland Observatory, except as noted.
701 Junk Bond Observatory houses a 0.4 meter Schmidt-Cassegrain telescope, a Kodak KAF-based CCD camera, and a highly developed information infrastructure including a distributed control system and a megalithic star catalog server. The telescope operates robotically most clear nights, however it is not dedicated full-time to minor planet observations. In the Winter/Spring of 1999, the telescope was used manually for minor planet observing. To make the telescope safe under error conditions, it has been fitted with aftermarket cable harnesses17 and wire races, however no limit switches have been installed. Since the telescope slewing can be stalled by hand, no panic buttons were felt necessary for this telescope.
The mechanical performance of the telescope is quite good, most of the time. The average actual pointing error is 53 arcseconds, measured over an average slew distance of 14 degrees during actual operation. There is some source of error in the pointing which occasionally results in pointing errors of up to several minutes of arc; these have proven resistant to mount error modeling such as T-Point. The tracking of this telescope is somewhat rough, limiting it to a two minute exposure, at the most, in unguided mode at an image scale of 2.7 arcseconds per pixel. Considering local seeing conditions, the author estimates that an image scale of 3.5 arcseconds and a front-illuminated detector would still be consistent with good astrometry.
The primary mirror of this instrument is fixed. On average, the focus drifts about 8 millimeters from the beginning to the end of a night during the high temperature delta seasons of late autumn and early spring in the high Arizona desert. Analysis and subsequent deployment of a temperature compensating focuser have shown that roughly linear thermal effects account for 97.5% of the shift, or 7.8mm on average. The effects of the remaining 0.2 millimeters (on average) of drift, at the 2.7 arcsecond per pixel scale, is brought to acceptable levels by the use of a focal reducing lens in a fixed relationship with the detector, which has the ancillary benefit of making the curve of focus very broad and shallow with thermally induced changes in the separation of the primary and secondary. The result is that a 0.2mm shift in focal plane changes our FWHM star image size by approximately 0.2 arcseconds on average – a result that may simply be an average of noise in the measurements.
The telescope is operated with closed-loop pointing updates. During the history of this station’s development, a software vendor told the author that "error modeling is inadequate compared to periodic updates" and that I should resign myself to closed loop operation. When that vendor began marketing one of the several error models available for telescopes the same vendor said "open-loop pointing with error modeling is superior to any other method." The experience at this station has shown that error models do little to improve the actual pointing characteristics of this telescope. Experience with other telescopes – generally ones which are better made than the Meade model in question – show that error modeling can have significant beneficial effects.
As a result of these operational circumstances, and in response to the desires of the collaborators on this project, several subsystems affect the telescope, including:
Low-level telescope control software.
Low-level camera control software.
Low-level ephemeris and NOVAS software.
Thermal focus compensation (continuous).
Pointing update subsystem.
Guide star acquisition subsystem.
Observation scheduling subsystem.
Error handling subsystem.
Ephemeris subsystem.
Stationary point and lunar avoidance subsystem.
Solar interference subsystem.
High level observatory control software, controls all subsystems and lower level components.
The low-level telescope control software in our case is Astronomer’s Control Panel 1.3. The low-level camera control software in our case is Maxim DL/CCD 2.08. The low-level ephemeris and NOVAS software is Kepler, and NOVAS-COM, which is freeware. The ephemeris subsystem is contained in a freeware ‘wrapper’ object that the author developed for Kepler and NOVAS-COM, called Widgets. The critical high level observatory control software was written by the author and developed in-house, but was based on a sample script that shipped with early versions of ACP. It is now in use at no fewer than 17 observatories on six continents, as it is available as open-source freeware.
A typical night begins with the observer providing the observatory control software with a list of scheduled targets for the night. The list of targets can be accompanied by RA and Dec positions, exposure times, and the number of time-separated frames to take. The time separation is also a configurable item, so fast moving objects can be imaged in rapid succession, while KBO’s can be imaged across multiple nights. Alternately, this list of targets can include only the target designation, exposure time, and number of images required. In this case, the topocentric position of the target will be computed in real time when needed.
The telescope refuses to observe until the end of twilight. When that time is reached, the observations can begin. An observer may focus the camera and sync the telescope, or the control software can do it18. The control software can also set the computer clock using one of several NBS SNTP servers on the internet. The control software then takes the list of scheduled targets and arranges them in observational order, so that it gets early setters early in the night and late risers late. It then sequences through the targets in a pattern designed to provide the specified time separation of images. For MBO’s, forty to sixty minutes has been found to be a convenient interval.
If exposures are short, the control software uses the astrometric images to determine pointing performance. An astrometric exposure is taken, and the telescope begins to slew. The image is downloaded concurrently with the slew. The astrometric exposure, once downloaded, is plate solved and the RA and Dec of the center point of the image is determined. If this exceeds a certain tolerance, the software will execute a subroutine which syncs the telescope after taking a brief pointing exposure. If the exposures are long, say eight minutes or longer, then the telescope may take an explicit pointing exposure prior to each astrometric image, to verify pointing – the philosophy here being that adding overhead is less detrimental when taking fewer but longer exposures. The pointing exposures in either mode utilize only a subframe of the camera, the dimensions of which are centered upon the center of the full array of the detector. The exposure time, download, and solution of this pointing exposure introduces 22 seconds of overhead each time it is executed.
Because of the limitations of unguided tracking at this station, we long desired the capability to acquire a guide star robotically. The guide star acquisition subsystem handles this task. The first steps toward implementing this were taken in the summer of 2000, and with further assistance from Brian Warner robust guide star acquisition source code was released as freeware in September 2000. This has allowed 701 to increase its exposure times by up to a factor of seven and has extended our reach to large numbers of potential targets that were beyond our capabilities before. We note that guided two minute exposures show fainter stars than unguided ones, suggesting that some of our increased magnitude depth is the result of keeping the star images on the same pixels through the exposure. The guide star acquisition subsystem is invoked before each observation, but only if the exposure time is long enough to warrant the increased overhead involved in acquiring a guide star. Currently, any exposure over one minute in duration is guided. Acquiring a guide star contributes an average of 30 seconds of overhead, but the average is artificially increased by the relatively rare cases in which the system must search a small area of sky for a guide star. Recently, John McClusky19 recently released source code which selects a particular guide star from stellar catalogs, which is being adapted to our control system.
During this process, several other subsystems may be invoked in addition to the guiding and pointing update subsystems. The error handling system will be invoked in case anything unexpected happens. Minor software errors and error conditions which can be anticipated or have known causes are handled explicitly, so that they do not disrupt observing. Severe errors cause the control software to take the conservative approach of parking the telescope and stopping all observing.
The observation scheduling system, in addition to arranging the scheduled observations at the beginning of the night, checks each target at the time of the observation to insure it is actually observable. If the object lies below 25 degrees altitude – which is the altitude of the observatory walls from the telescope’s point of view – then a decision making tree is invoked. If this object is in the west, it is simply skipped and the observing moves on to the next target. If the object is in the east, the telescope will wait for it to rise. If this waiting period is to be brief, then the telescope parks during the wait. If the wait will be substantial, the telescope does survey fields, as outlined below, before returning to the too-low target.
The ephemeris subsystem is used by the telescope control software to return positions of known target objects. Since 701 has specialized in the observation of high-uncertainty MBO’s20, a component to simply calculate the position of a target asteroid was highly desirable from the beginning. This has only recently been implemented and, while reliable so far, is still considered to be in testing.
The solar interference subsystem is invoked prior to each observation to see if we have run out of nighttime. If we have, then of course we stop observing. From time to time, the observer scheduling the telescope gets too ambitious, and the result is the scheduling of more minutes of exposures than there are minutes of dark time in the night. In this case, the objects which were not successfully observed are held over for observation on the next night.
After all scheduled observations are completed, the telescope operates in survey mode. It is not the motivation of the author to discover many asteroids; 701’s principal, however, is rather more motivated along those lines. Since the discovery of unknown asteroids is statistically as likely to happen in the field of a known asteroid needing observation as it is in a quasi-random, but ecliptic-favoring, survey field, known objects are scheduled liberally at 701. As of mid April, about three-fourths of the asteroids discovered at the station were discovered in fields with known targets needing observation.
Survey fields, however, are done at 701 primarily to keep the telescope busy. It is a waste to have such a telescope, and have it parked for half the night. Rather than allow that, the control software fills up the remaining time each night with survey fields.
The RA of these fields are calculated using a very simple algorithm:
Meridian + (survey duration * 0.5)
The observer has no input as to where the fields lie. First, the control software determines the RA of the meridian. It then calculates how long a set of fields will take, given the exposure time setting used, the time between observations of the same field, and the number of observations per field (which is almost never less than three). The resulting number of minutes is halved and added to the RA of the meridian, providing the "seed" RA for the survey fields21.
The control software then determines the declination of the ecliptic at that RA. If the galactic latitude is low, it moves the field in the direction of the opposition point to avoid the milky way. It then applies a random offset in declination; the survey fields are carried out at the declination of the ecliptic plus or minus ten degrees. The fields themselves are in number sufficient to separate the observations in time by the required amount, and are simply built each north of the last22, starting with the calculated RA and Dec.
If there is not enough time in the night left to complete an entire survey field, then the number of fields, or their exposure time, is trimmed so that the fields can be fit in before astronomical twilight.
The survey fields invoke the stationary point and lunar avoidance subsystems. The stationary points are simply avoided; if the survey fields lie within an hour of RA of the stationary points23, then they are shifted toward the opposition point enough to leave the region. 701 observes at any time of the lunation, and the control software is aware of the position and phase of the moon. Survey fields must be a certain number of degrees separated from the moon, this number being larger when the moon is closer to full. Since observing close to the moon is more catastrophic than observing at the stationary points, the moon test modifies any changes made by the stationary point subsystem.
The same code which provides us with survey fields can, with small modifications, return pseudo-random low-elongation fields for comet hunting, wide angle patrol mosaics, and so forth.
At the end of the night, the telescope is parked. Once the telescope is safely stowed, a series of dark frames are taken, typically nine of them of the length of the mean exposure time for the night. The taking of dark frames can continue even well after sunrise. These dark frames are later scaled and applied to the night’s astrometric exposures. A human being must close the roof in the morning, as that is not currently under automated control.
The number of observations taken by such a system can be substantial. In October of 1999, the robustness of an earlier version of this control software was tested by attempting to observe every asteroid brighter than 14th magnitude and that reached greater than 25 degrees altitude at the station some time during the night. The result was a successful run of 660 images, although three of the targets were nowhere to be seen in the fields24. A typical night’s run when doing real science, rather than engineering tests, can easily result in 90 images in need of reduction. If we were to lower our exposure time, the number would grow.
As a consequence, and since we are amateurs who cannot spend an entire workday reducing images, it is imperative that we use an efficient reduction engine. PinPoint provides pattern matching and performs a plate solution (in about 0.1 seconds with 150 stars on our ST-8 frame), saving the solution as WCS data to the FITs header. PinPoint also applies coefficients for image distortion. In addition, PinPoint detects moving objects, displaying each image with moving objects circled for the measurer’s inspection25. Since WCS information is available in the image header, the images are aligned by the software. Images with no moving objects – which are quite rare – are also presented for blinking. This provides the measurer with full endorsement/veto power over the automated detections, and allows the measurer to check up on the detection algorithms by manually specifying missed detections. The author has reduced images of 120 megabytes in size using PinPoint, suggesting the reduction pipeline is quite robust.
It is worth noting that many of the software subsystems which have been developed have been defeats of the hardware by the software. Poor pointing is under control by closed-loop monitoring. Poor tracking is handled by unattended acquisition of guide stars. Mount backlash characteristics are modeled in the control software so that the effects are taken out by programmed incremental turns of the motors (under software control – the telescope’s own backlash compensation is turned off). A pernicious source of internal reflection, which can look like a comet if arranged in a straight line, is forced into a triangular hopping pattern by small 120 degree offsets of the pointing position for each frame of the field. The demonstration that inexpensive software can overcome the limitations of inexpensive hardware has been a revelation to the self-funded community and has attracted considerable attention from observers in developing countries. An unanticipated result of this effect is that many projects have abandoned plans for commercially available high precision automated mountings in favor of more affordable mass production mountings, or of PC-TCS retrofits of older mountings.
It is also worth reflecting that the laziness of the observers has motivated a good deal of the development of the control software. The desire for operating robotically in the first place was the result of not wanting to stay up all night, sometimes in the cold nighttime temperatures of the Arizona high desert. The target scheduling and automated survey field positions spring from a dislike for having to manually schedule a full night’s observing. But other elements, such as lunar avoidance, the ephemeris system, and so forth, are the result of a forthright attempt to make robotic operation as smart, if not more so, than if an indefatigable observer were doing all tasks manually. The self-conscious goal of the developer of the control software has been to deploy a robot of as advanced capabilities as possible, and then proliferate such robots through free distribution of the software, and mentoring of the user community.
The short term prospect for small robotic observatories is good. In the last year at least 64 such instruments have been put into operation, many as a result of Medkeff 2000. As a result of that article, the author has received over 262 inquiries (as of mid-April) regarding small, robotic, Windows-based telescopes, mostly from amateurs and developing nations. This response has been somewhat dismaying26, and the result has been the development of a mailing list and website devoted to small robotic telescopes.
The future direction of robotic telescopes can be simply, and tritely, dealt with by saying that in the future there will be more of them, and they will use more up-to-date technology. Technologies currently considered current or developing will likely displace the older technologies favored at professional institutions. We can anticipate the increasing use of XML based data streams and the increasing use of the Component Object Model or its future architectural replacement, probably beyond its current Windows concentration, to bring device independence to Unix solutions. We also anticipate that it will become more widely recognized that the limitations of relatively crude, mass-produced hardware can be overcome with simple programming measures. It has already been observed that robotic observatory users, especially in the developing country market, increasingly favor cheapest-possible hardware, or much higher-end made-to-order hardware from OGS, DFM, Torus, and others, making the middle ground of high-precision telescope mounts increasingly less attractive for these applications.
In the longer term, as technology considers it, we can explore the future of robotic telescopes on two fronts. The first, software, is now in a state of relative maturity and stability in its core capabilities, and we will experience in the future an increase in its peripheral capabilities and flexibility. We will shortly see the release of a remote control program with an integrated web server offering active server pages providing high level telescope control, if that has not already happened by the time this paper is presented. We will likely see observation scheduling software which deals in a practical way with the notoriously difficult "traveling salesman" problem before long.
One of the significant problems surrounding the proliferation of robotic telescopes is, to my way of thinking, that an insufficient proportion of them are dedicated to astrometric, photometric, or other scientific observing programs, even excusing the large number of such telescopes that are devoted to educational uses. Most self-funded amateur robots are currently dedicated to hobbyist pursuits, as 701’s current instrument is some of the time. This is not a moral issue but it would be desirable to see at least some of these facilities used for research purposes some of the time. This issue is intimately connected with open fields for scientific participation and amateur perceptions of such pursuits. If the current growth in the number of such telescopes continues at present rates for two to five years, we can anticipate something between 1,000 and 3,000 small robotic-capable telescopes in operation at the end of that period. What these telescopes will do is something of a mystery. Since many observers have already failed to become attracted to astrometric and especially photometric work, professional astronomers do not seem to have done very well at leveraging the currently existing resources. Expanded professional collaboration – and in some cases personal professional collaboration that includes mentoring - with amateur and self-funded facilities may be essential if we are to derive the full potential of scientific benefit from these telescopes, and this collaboration should include the broadening of observing programs. It should also include a simplification of the observing and reduction process analogous to that which astrometry has enjoyed over the last ten years. Finally, it should include a recognition of observers’ contributions analogous to that which is in place in the minor body astrometric community and in certain variable star programs, such as the one run by the Center for Backyard Astrophysics.
1 Notable early uses of such tools were at Tenagra Observatories, a private facility which engages in supernova research in collaboration with Lick Observatory; and Junk Bond Observatory (701 Sierra Vista), which was converting to robotic operation in the Spring of 1999.
2 In fact, all of the cited systems so far use technologies that are beyond mature, and are flirting with obsolescence, in the opinion of many computer scientists.
3 Including Realtime Linux, in the opinion of many computer scientists. The scientific community, not known for a close understanding of the issues, appears to disagree in many respects. The author finds the issue is largely moot since sheer computing power renders almost any modern operating system capable of being a real-time controller given the glacial speed demands of telescope and CCD camera control.
4 The use of certain distributions of Linux for control of robots is prohibited by license agreements, for example – presumably due to liability concerns.
5 It is the author’s experience reviewing the publicly available source code that academic developers neglect to comment their code; something he also found true in his time as Computer Operations Manager at Ohio State University. Commercial developers, of course, always comment their code very extensively.
6 One set of such sources will only cause a telescope to slew to a position and take an image if a gamma ray burst coordinate is found in an e-mail less than ten minutes old in the inbox of a particular account on the same machine controlling the telescope!
7 "Skill cost" describes the necessity of paying geeks (such as the author) for their services. The Unix family has skill costs on average three times that of Windows.
8 It was said of Shakespeare that he had "little Latin and less Greek."
9 The Component Object Model is a means by which software on Microsoft Windows, MacOS, and UNIX platforms may accept external calls. The architecture differs from direct calls in that the operating system handles object references (providing configuration independence), and errors are passed back to the calling component so that they may be trapped if necessary. This should not be considered a full accounting of the COM architecture. More discussion of this will be found below, in the "operations" section.
10 Some discussion of this history can be found at http://www.ascom-standards.org/ and at http://acp.dc3.com/news.html, and also in Medkeff 2000.
11 Scripting is here defined in its computer science context. A script is an independent software program capable of executing on its own in the operating system environment, and which is either interpreted or JIT compiled. For the purposes of this paper, they differ from the list processors mentioned above in the sense that the list processor commands are not computer programs capable of executing outside their hosts.
12 See, e.g., Medkeff 2000
13 701’s telescope is not dedicated full time to asteroids, however in 2001 it has been dedicated mostly to asteroids. At the time of this writing, 701 is the 19th most active astrometric station on the planet for 2001.
14 It is noted that telescope technology is notoriously un-scaleable.
15 The author, having been hit several times by a slewing .4 meter telescope at 701 Junk Bond Observatory, does not wish to be hit by a telescope twice its size.
16 The three inch red buttons at the 3.5 meter telescope at Apache Point Observatory are colloquially called "Bloody Stump Buttons" by the telescope operators there. In view of high profile maiming accidents and deaths that have occurred at astronomical facilities, this term is not whimsical.
17 Plastic wire ties on the east fork arm which we installed.
18 The development of software auto-focusing at Junk Bond Observatory (701 Sierra Vista) and 933 Rockland Observatory was motivated by the fact that the author is pathologically incapable of focusing a CCD camera, and has always had to rely on his collaborator for that service. However it is clear that Larry Weber’s freeware autofocusing system is superior to what was developed here.
19 John V. McClusky, Ph.D. Associate Professor of Chemistry Division of Earth and Physical Sciences University of Texas at San Antonio 6900 N. Loop 1604 West San Antonio, TX 78249
20 It is here noted that this specialty is fraught with problems, not the least of which is that a one-sigma ephemeris uncertainty is often very conservative compared to reality. As a result, we fail to see over half the objects we attempt to observe. The problem is that there is no mechanism for the report of orbit constraining negative observations to the Minor Planet Center.
21 For those not following the algorithm, we start observing a number of degrees east of the meridian equal to the number of degrees west of it that our fields will attain at the end of the survey sequence. We thus insure we are observing the fields at the lowest possible airmass.
22 Each south of the last, in the southern hemisphere – the idea being to gain altitude.
23 The author prefers the term "fuzzy bands of slow moving asteroids," but defines the stationary points programmatically as a one and a half hour wide strip centered at + and - 8.5 hours of the RA of the Sun, since he doesn’t know any better.
24 Since the telescope was pointed properly for these fields, this suggests that positions for even bright numbered objects are from time to time required.
25 The author is aware that some variation on this protocol is in place at SpaceWatch and LONEOS, at least.
26 That is more than one inquiry per day since the article was published.
References:
Bakos, Gaspar; "Hungarian Automated Telescope," Publications of the Astronomy Department of the Eötvös University No. 11, Proceedings of the National Postgraduate Reunion in Astronomy & Astrophysics, 2000, p. 107
Etzel, P.; Braun, H.; High-Performance Wireless Internet Connection to Mount Laguna Observatory; American Astronomical Society Meeting 197, #15.02
Medkeff, Jeffrey S., "The ASCOM Revolution," Sky & Telescope, May 2000
Medkeff, Jeffrey S., "Automatic Asteroid Hunting," Sky & Telescope, August 2000
Medkeff, Jeffrey S., "" (Review of MPO Canopus/Connections/Observer), Sky & Telescope, September 2001.
New Mexico Variable Star Coalition, "General Proposal," November 2000
Mulherin, J.; Williams, R.; The Development of Advanced-Technology Automated/Robotic Telescope Systems for Astronomy Education and Research; American Astronomical Society Meeting 197, #120.01
Mutel, R.; "Project Rigel: A Robotic Observatory with Integrated Curriculum for Undergraduate Astronomy Education," American Astronomical Society Meeting 197, #120.02
Querci, F.; Querci, M.; Astrophysics and Space Science, v. 273, Issue 1/4, p. 257-272 (2000).
Turner, B. N. et al, "Developmental Cost Estimation," UTS Bulletin, June 1997