Seeing Stars – The Automated Way, Part 1

I’ve never considered myself a full-blown astronomy enthusiast, but I can’t deny that I have always enjoyed gazing up at the celestial bodies and admiring their artistic beauty. Over the past couple of years I have been involved with a project that combines the world of astronomy with something we all love, technology. The project is called ASCOM.

Intro to Automated Observing

Before I get into the guts of ASCOM, let me first share a bit of background information. There are a great deal of people out there who take astronomy very seriously. They are basically split into two groups, the scientists and the photographers (a.k.a “The Pretty Picture Guys”). Regardless of what the end goal is, all types of observers have found that their work can be made much more enjoyable by automating the observing process. For some people, observatory automation allows them the convenience of simply getting out of the cold, others utilize it to capture hours of data and images while they get much needed sleep. Automated observing also opens the door to remote observing which enables people to setup an observatory in an area that may have less light pollution or fewer cloudy nights. This maximizes their chances of capturing prized images from a telescope located on the other side of the country or the other side of the planet.

In order to to take part in the fascinating world of automated observing there are a few basic components that you must have. First is an automated telescope mount. The mount is the base which holds the telescope and usually contains servo motors used to adjust the pointing direction in two axes of motion. The second critical component is the camera; without it you won’t be capturing many images. Many gurus also outfit their scopes with an automated focuser, and and a camera-field-rotator which rotates the camera around the optical axis. The final critical piece is a software package that ties everything together and provides a friendly interface to the end user so that they can easily find stars (or other objects) and capture images.

The Need for Standardization

During the mid 1990’s, more and more astronomy equipment manufacturers began selling automated devices which used a wide variety of communication protocols and command syntaxes. This posed a major problem for software developers attempting to put together a universal Observatory Control Program. They literally had to know how to “talk” to every device by every manufacturer that they wanted to support. Two particular software companies, DC-3 Dreams and Diffraction Limited began working together to create a standardized way of communicating with all devices which eventually evolved into the ASCOM platform.

The ASCOM Platform

Quoting from the ASCOM website mission statement, the number one goal of the project is to “Establish a set of vendor-independent and language-independent interface standards for drivers that provide plug-and-play control of astronomical instruments and related devices.”  Many of you will likely utter curses under your breath at this next statement, but ASCOM is currently only usable with Windows operating systems. The reason for this is because ASCOM is built on the Windows COM service in order to provide the language-independent aspect of the mission statement. The name ASCOM stands for AStronomy Component Object Model. A typical ASCOM driver is a COM object that can be loaded into the process of the client application and used as a medium to communicate with the desired device. The driver’s API is part of the standard so that all languages accessing the object will have the same member names and calling parameters available to them. Currently, ASCOM has been used with at least the following languages:

Notice that Haskell and Ruby are not in this list… any takers?!?

The Chooser

One important tool provided by the ASCOM platform is named “The Chooser”. When a compliant driver is installed onto the PC, the drivers identity is entered into the Windows Registry (Don’t worry, there is a standard approach to driver registration so every developer doesn’t have to go editing registry keys manually!) The Chooser (shown to the right) is a form based tool that provides a simple interface for users to choose which driver to use with their software. The chooser detects all of the ASCOM drivers registered on the PC and lists them in a combo-box. Once the user selects a driver and clicks ‘OK’ the Chooser returns the selected driver’s ID to the client application which can then create an instance of the driver.

The Chooser in the image shown above is being used to select a rotator device. The ASCOM platform provides interface standards for the following devices: rotators, focusers, cameras, telescopes (mounts), domes, and filter-wheels.

Who Works on ASCOM?

The ASCOM platform is open-source. While the project was originally started by two business owners, intentional efforts have been made to maintain no affiliation between any business and the project. Anyone can pull down a local copy of the code and poke around in it. The code is currently being hosted in an SVN repo which is located at the home of one of the primary contributors. External backup copies are made daily to ensure the data is not lost in the event of a disaster. The server uses Team City for continuous integration and build management. There is currently a core group of about a half-dozen developers (mainly from the UK and the United States) who maintain and continuously improve the platform code. The team participates in a weekly video conference to discuss current work. They are very open to new contributors and are always looking for bright minds. If you are interested, let me know, and I can provide you with contact information.

Check Out Part 2

You now have a basic knowledge of ASCOM and what it provides. Read the follow-up post to see some code examples of driver implementation, as well as client-driver access.