Home-Built, Fully Automated Observatory
I make no claims for originality in the design of my observatory, just to say that it has been an interesting and rewarding exercise in getting all the components working in harmony.
In addition to astronomy, I have had a long-standing interest in what computers can do, and I don't mean just office type work. I guess it all stems from 40 years spent working in the design and maintenance of state-of-the-art flight simulators - devices that enable pilots to learn to fly without leaving the ground.
Why an automated observatory? As I mentioned above, partly out of interest in computer automation, but mainly out of frustration of the British weather. How many times have you thought about staying up way past your normal bed-time in the hope that the forecast is correct and that the sky is due to clear at 2 in the morning only to find out it doesn't?
With this in mind I started to investigate the possibilities of building a full automated system. I had for several years, been using a system that enabled me to write simple scripts to do telescope slewing to targets then take an image. This consisted of a 200mm Schmidt Newtonian on a Vixen GP mount with a COAA telescope controller 1 and AstroArt software for scripting and camera control. The problem was, the telescope drive used stepper motors in an open loop control system and so if the motor missed a beat, pointing accuracy was lost and meant that a lot of the images ended up off target.
It was clear that to progress to a fully unattended set-up I would need a much better telescope mount and a more accurate control system. After some research I came across Astronomy Control Panel 2 (ACP), a software package written by Bob Denny that claimed to put every target on the centre of the CCD chip every time. It does this by comparing the star field of the image taken with the corresponding (RA & DEC) star field of the Guide Star Catalogue (other star catalogues can also be used i.e. UCAC2 however I find that the precision of the GSC is more than adequate for this purpose and is small enough to be held on the computer's hard drive. Should I need more accuracy on a particular image I can always use Maxim to plate-solve again using a higher precision catalogue). (UPDATE - I now use the UCAC2 catalogue in place of the Guide Star Catalogue for all applications) Any error between the two are fed back to the mount as a slew command to nudge the mount to the correct position. Also, as it is doing these corrections the software is building up an error map of your mounts pointing errors so the next time you go to that part of the sky a correction is applied to ensure the telescope points to the required target. With this system, there is no need to 'teach' the mount prior to use, it is continually learning. I obtained a trial copy of ACP but it would not drive the mount via the COAA driver, it turns out that the COAA software is not 100% ASCOM compatible (more about ASCOM later). At this stage I decided to replace the mount with one that could be used with ACP and also allow me to upgrade to a larger 'scope in the future.
The mount I chose was a Losmandy G11 with a Gemini controller (this uses a closed loop servo system). This was a mount that was within my budget, and looked as if it would fit the bill.
Both ACP and the Gemini controller are fully Astronomy Common Object Module (ASCOM) 3 compliant. (This is in essence a standard for writing astronomy control programs so that they all talk to each other). Choosing to go down the ASCOM route means that one is not tied to a suite of programs from one particular manufacturer, an important point to consider when designing a complex system.
My observatory was a manually operated, run-off-roof (R o R) design so the next stage was to motorise the roof and look for a roof control system, again ASCOM compliant. The advantage of a R o R observatory over a dome is that it is relatively easy to construct and motorise the roof, the disadvantage is that you cannot just close the roof without first ensuring the 'scope is in a position that enables the roof to close without hitting it.
Also you must ensure the mount will not start slewing before the roof is fully open, so both hardware and software interlocks are used to ensure safe operation. The hardware interlocks I use consist of a miniature tilt switch and a micro-switch. The tilt switch is mounted on top of the telescope to provide a signal back to the computer when the 'scope is parked horizontal. The micro-switch is actuated by the mounts RA shaft to provide a signal when the 'scope is parked at the correct azimuth. Both signals must be true before the roof is allowed to move. Magnetic switches, the sort used in home security systems, are used to signal when the roof is fully open or fully closed.
With a dome these issues are not usually a concern, however the dome has the added complication of needing to be synchronized with the 'scope in azimuth.
My first attempt at motorising the roof was using a winch designed for fitting to Land Rover type vehicles etc. The problem with that was because the winch had only a single drum for the steel cable, any attempt to make the motor open and close the roof meant that the cable would bunch up on the drum and jam. I did make use of this system for some time just to close the roof after an observing session until I was offered a second hand cable-operated garage door opener. This had a spiral grooved drum that ensured that both the take-up and pay-out cables were kept in place on the drum.
The roof control system I chose was by Foster Systems 4. In addition to controlling the roof it also has an interface for a simple weather system. The heart of the weather system is an off-the-shelf IR thermometer (Extech RH405) which has an RS232 computer interface. By pointing the IR thermometer at the sky, the sky temperature can be monitored by the computer, it is surprising the difference the temperature of a clear sky is compared with a cloudy one. This difference is used to signal 'weather safe' or 'weather unsafe' to ACP. The temperature of a clear sky does vary throughout the year, typically around -20 deg C in summer to around -30 deg C on a cold winters night. Typical temperatures for very cloudy skies are between -10 and -15 deg C. The Foster Systems software allows these trigger temperatures for partly cloudy and very cloudy sky's to be adjusted to take this into account. This temperature adjustment also means you to can put the Extech instrument into a plastic case for protection, in this case the sky temperature seen by the instrument will be somewhat higher than the actual sky temperature due to the attenuation of the IR beam through the plastic, so the trigger temperatures need be set accordingly. You will 'loose' around 3-4 degrees when looking through very thin plastic such as cling film. One minor problem with this set-up is that because the cloud sensor is fixed looking vertically there can be situations where the sky overhead is clear but cloud elsewhere. If this is the case and it tries to image a part of the sky that is clouded out then the plate-solve will fail and ACPAutomator will not 'stamp' the target as completed and so will remain on the to-do-list for later when we hope the cloud has cleared fro that part of the sky.
The last thing to do was to automate the telescope focusing. This was done with a drive system from LakesideAstro 5. The software is again ASCOM compliant and is used in conjunction with FocusMax 6, a freeware program that links with MaximDL 8 to automate focusing.
With the system described so far i.e. ACP in conjunction with MaximDL to control the CCD camera, it offers a scriptable command interface that enables me to write a sequence of tasks to do virtually any type of observing.
My set-up has been further enhanced by using a software add on package, ACPAutomator 7, a freeware package written by John Winfield. This add-on allows me to create and select up to 3 text file, one for supernovae patrol, one for variable stars and one for asteroid / nova search. Each file is given a priority of between 1 and 100 so for example if I am concentrating on supernovae patrol I would give this file a high priority and the variable star file a lower priority. This will ensure all the supernovae targets are imaged before going on to the variable star file. I generally treat asteroid / novae search separately as this can take up a lot of observing time. Targets in the supernovae file are imaged only once per night and the file format is simply: TargetName, TargetRA, TargetDec. Values for exposure, binning and filter are globally defined on the applications dashboard. Targets in the variable star file can be imaged several times per night so the text file contains an extra line per target consisting of priority, interval, exposure, binning and filter. For asteroid / nova searching the text file is simply: StartRA, StartDec, EndRA, EndDec. The field of view is globally specified in the application's dashboard as is the number of images to be taken of each search field per night. From this information a mosaic is built up covering the area of sky specified, the image files produced are then ready to perform blink comparisons.
A typical sequence may go something like this, again all the parameters are adjustable, the only thing it doesn't do (yet!) is power up the computer and camera.
At a sun angle of +5 deg, open the observatory roof to cool every thing down to ambient.
At sun angle of -1 deg start taking a series of sky flats (the camera exposure is automatically adjusted to give the required ADU depending on sky brightness).
At sun angle -14 deg start the observing by first slewing to a bright star (magnitude 4-7) and do an automatic focus. This automatic focus procedure will be repeated every 30 minutes during the night to ensure perfect focus (no worries about temperature affecting telescope focus). ACPAutomator then selects a target in the west that is above my horizon (my observable horizon including all obstructions, house trees etc. is already programmed into the system), and sends it to ACP. ACP commands the 'scope to slew to the target and take a short exposure.
This initial image is checked against the GSC to make sure the target is centred, if not a slew command equal to the RA/DEC error is sent to the mount and then a full exposure is taken. Again the image is plate-solved to ensure the target is centred and the relevant information is added to the FITS header and the image saved. The saved image therefore contains all the information needed to carry out photometry and astrometry on any star in the field. ACP adds any RA/DEC error to the database to build up a mount vs sky error map. ACP now hands control back to ACPAutomator to select the next target (moving west to east).
The ACPAutomator target list can contain a full years worth of targets as it will calculate which target is visible on the day and above my observable horizon. If all the targets that are above my horizon at any time have been imaged, ACPAutomatory goes to 'sleep' for 5 minutes. After 5 minutes it wakes up and checks if a new target has risen above my horizon. If it has it will pass control back to ACP to take an image of that target. It will then go back to sleep for 5 minutes to wait for another target to rise above my horizon.
At sun angle -13 deg below true horizon, dawn flats can be taken prior to parking the 'scope and closing the roof.
All the time the system is running a check is made on the sky conditions. If any cloud is detected the 'scope will slew to its parked position and the roof closed, should the cloud then clear the roof will open and the observing session will continue from where it left off.
All the applications run on my laptop housed in the 'control room', a garden shed some 5 meters from the observatory. All mains and DC power is protected by an Uninterruptible Power Supply (UPS) and distributed from here to the observatory. Living in a village fed by overhead power we do get more than our fair share of power cuts, hence the UPS. A USB hub provides the 4 signal lines to the camera, weather monitor, focuser and roof controller. The RS232 to the Gemini telescope controller is fed from a USB to RS232 converter. The laptop is networked to my PC in the house via a wired LAN.
So how much did all this cost? (2007 / 8 prices) At the time of purchase the exchange rate was $2 / pound and ACP cost $400, Maxim was $500 and the Foster Systems controller was $200. The Extech instrument was £150 and I spent approximately £120 on UPS, relays, switches, cables and a second-hand garage door opener. So the total cost of the automation part was approx. £820.
Update - September 2011. Purchaced the Scheduler add-on to ACP.
This extends the operation of ACP to include a more advanced dispatch scheduling operation including the programming of constraints such as Moon avoidance, Air mass range, Horizon, Hour Angle etc.
It has also enabled me to automate the powering up of the observatory at Sun set and the powering down at dawn.
So the sequence now goes like this:
At 1 hour before Sunset, check for clear skies. If clear, switch on power to the telescope, camera, focuser, dew heaters and battery charger and open the roof
At Sunset take a set of sky flats for calibration.
At Sun angle -12 deg, slew the telescope to 70 deg Alt. and 100 deg Az. and do an auto focur run.
Now the Scheduler works out which targets are best for observing and sends them to ACP for imaging.
At dawn, park the 'scope, close the roof, disconnect all computer applications (except the weather server) and power down the hardware.
The observatory now 'sleeps' waiting for dusk.
The Scheduler package also includes a VOEvent receiver. This continuously monitors the VO network and will respond to triggers from GRB's, transient events, SN's, variable stars etc. The observatory will automatically respond the these events and take follow-up images.