Sequencing and Automation

The mainstream image acquisition applications have varying degrees of automation, of which simple sequencing is the backbone. This, like an intervalometer, takes a series of exposures, adding various options of filter selection, binning, exposure length and camera angle. From here things start to get interesting; other activities are needed for extended sequences in real conditions including autofocusing, dithering, guiding and meridian flips. Very soon, what started off as a simple set of exposures becomes a complex interaction of multiple device controls and conditional activities and intelligent logic.

At this point, the acquisition applications take two different paths: The long established ones have mostly side-stepped advanced automation by offering an application interface (API) that allows third-party developers to manage the logic and the image acquisition application for basic equipment control. A combination of Maxim DL or TheSkyX with CCDAutopilot, CCDCommander or ACP offer programmable control options within the logic boundaries set by the application and use scripting to extend them. ACP also offers a controlled remote control environmental via a web application. This is useful to prevent inadvertent issues caused by the more intrusive operating system access offered by Microsoft Remote Desktop, TeamViewer and the like. Some remote imaging companies use a modified version of ACP to provide the user interface to their customers. SGP, which originally started as an automation front end to Nebulosity, has developed into an image acquisition suite in its own right, but uniquely offers a high level of intelligent automation within the application that is ideally suited for modest amateur observatories. It too has an expanding API, allowing access to camera and mount controls.

Each of these applications require updates to keep abreast of hardware and ASCOM developments. In the heavyweight external applications the user has extensive controls at their disposal, including the ability to further customize functionality through scripting. In the case of Sequence Generator Pro, the automation logic within the application is a careful trade-off between feature content and user interface complexity. In any sophisticated application, it is a fine balance between ease of use and providing multiple options, not all of which will be relevant for any particular user.

Drawing direct comparisons between the applications is difficult. The automation features are broadly similar and mostly differ in their detailed implementation and the user experience. These differences are further blurred by the possibilities brought about by scripting. Automation features basically fall into several categories:

• target planning

• acquisition automation

• observatory control

• remote control

Some go further and additionally do image calibration and stacking. Although convenient, these are crucial stages of linear imaging processing and ones that benefit from dedicated tools, judgement and discrimination.

Planning

At its simplest level, planning involves selecting an object, ensuring it is visible during the imaging window and setting its coordinates. Most planning tools can selectively choose objects from a catalog, based on type, visibility and so on and export into a proprietary file format. The nearest thing to a standard is the Open-AstronomyLog XML format. From here things quickly become more exciting: The advanced planning tools that work with planetariums help one to compare the object outline with the sensor field of view, determine the optimum angle and check for an available guide star. A catalog’s object RA/DEC coordinates are a useful starting point but this may not be the optimum position for image composition. When the object extent reaches beyond the field of view, mosaic-planning is required. Graphical tools that overlay image Field Of Views (FOVs) over the image are invaluable in these cases. It is overkill for a single imaging object that takes several sessions to complete, as the setup time in an application such as SGP only takes a minute to adjust the framing and then plate-solve and record the coordinates. It becomes more useful though as things become more complicated; an object with limited visibility, may be partnered with a secondary object in an imaging sequence to make the most of a clear night. At the extreme, this is essential for supernova hunters who image hundreds of objects (typically galaxies) each night using a single exposure for each. The better planning software sorts the targets to maximize the number that are visible during any one night.

fig.1 CCDAutopilot, showing a two-target sequence, acquires focus, guiding and images through either Maxim DL or TheSkyX applications. It optionally allows focusing with FocusMax (which CCDWare recently acquired and now offers as a commercial product). For the full effectiveness of FocusMax to be realized, telescope control is required to slew to stars of sufficient magnitude for short autofocus exposures.

Acquisition

With the target(s) defined, image acquisition takes over. Here automation goes beyond a simple sequence of exposure times and filters to include:

• model building to reduce pointing errors and polar misalignment

• closed loop target centering, using plate solving to issue small corrections to the mount

• slew, solving and re-centering target to within a few pixels

• camera rotation (manual and motorized)

• handling meridian flips, including camera flipping and re-centering.

• exposure determination for each filter, based on sky noise and read noise

• image acquisition using time and/or altitude attributes to choose between multiple targets

• complex exposure sequencing for each target

• autofocus, automation logic and adjustment for each filter

• autoguider automation, including calibration, settling parameters and selective disabling during certain non-imaging activities

• automated calibration file acquisition (for example, sky flats)

• managing equipment and sequence configurations

• logging

• error and poor imaging condition recovery protocols

These are the mainstream activities that allow an exposure sequence to progress without constant intervention. They are variously described elsewhere in the book with a few exceptions:

Most planning programs can instigate a sequence at a certain time. Some, like CCDCommander additionally have the option to commence or abort a target sequence when it crosses a certain altitude. Automated calibrations (typically flats) are of particular interest to open reflector telescope users, since dust can find its way down to the optical surfaces close to the sensor between imaging sessions. The planning programs can insert a series of flat exposures at twilight (sky flats) or position the telescope or flat panel to capture a set of flats for the session. Re-fractor owners have an easier time and should not need to do this as frequently. I find that dark and bias frame exposures do not change appreciably over time and take many hours to expose sufficient frames to generate high quality master files for the common exposure times. For this reason, I update my library every six months. Recovery protocols are particularly useful: For example, SGP enters a recovery mode if the guider system has difficulty finding a star or settling. The recovery mode attempts to start the guider and image acquisition several times over a specified period. Similarly, if the autoguider reports a large tracking error, the exposure is automatically restarted. If unsuccessful, or if the ASCOM safety monitor trips, the sequence terminates. With a few simple options, termination also warms the camera up to ambient, parks the mount and closes the observatory roof. The other applications have similar protocols.

fig.2 The sequence window from Sequence Generator Pro controls the basic exposure automation, filter event and target order. It can do various activities at the beginning or end of each event as well as the overall end of the sequence. It records the progress for each as it goes along and can be changed dynamically when the sequence is progressing. It is normally minimized during sequencing, to display the equipment controls and various performance monitors.

Observatory Control

Observatory control is becoming increasingly relevant to many amateurs. Here the observatory is defined as the immediate environment outside the mount and telescope and includes such things as environmental measurements. For a physical observatory, it also includes dome and roof operation in harmony with the mount. The recent inclusion of environmental sensing within ASCOM set the scene for automatic update of sky refraction models for improved mount pointing and tracking accuracy. The automation and intelligence applies to specific circumstances, for instance detecting poor weather and shutting down the system in a controlled manner.

Part of the appeal of the automation programs is their tight control over the various applications. In some cases separate specialist applications perform at a higher level and although there is a good amount of interoperability between applications in general, there is always the danger that they do not work harmoniously with each other, or become incompatible as one or the other is updated. For that reason, the companies collaborate by publishing an application interface (API). For instance the three main automation programs, CCDCommander, ACP and CCDAutopilot all work with TheSkyX and Maxim DL as the camera and mount interface. Although these imaging applications have basic autofocus capabilities, FocusMax continues to thrive as a third-party application that again works through the imaging application’s API to optimize the process. These APIs are the enabler for all this interaction. They make use of the way that modern operating systems work and in a sense, ASCOM can be thought of as a generic API. In Windows for instance, what we traditionally called program subroutines and variables have become COM objects, methods and properties. When these are made available to outside programs (public) they can be called, read and written to by other programs and usefully, scripts.

fig.3 CCDCommander is another sequencing utility which relies upon a third-party imaging program. It has a simple functional interface that is easy to use yet has some useful features for starting and moving between targets. It has a convenient feature that imports targets from the planetarium program.

Remote Control

There are several levels of remote control sophistication: At its simplest, it is the simple remote operation of the imaging computer, by conveniently using a cable, Microsoft Remote Desktop or a similar program via an Internet link. If one is truly remote, further controls are needed, including power control and reset capabilities for all the observatory hardware. Lastly, you need eyes, or remote sensing. It is reassuring to see exactly what the telescope is doing and the environment. The increasingly popular IP cameras, which broadcast video over WiFi, are not only good as a security deterrent but provide key information on the relation of the roof and mount before something goes crunch or for an all-sky view for imaging conditions.

These software applications manage environmental sensing. In the case of remote electrical control, there are two aspects: the user interface and the hardware. Remote power control and USB resetting is a must for an unmanned observatory. Software does crash for any number of reasons and sometimes the only solution is to selectively or globally reset the USB or power system. An increasing number of USB switches, partnered with suitable drivers make this a reality, especially when tied into the observatory control applications. Ethernet-controlled power switches and video relays exist today and connect directly to the Internet router and operate via web-based applications using TCP or UDP (protocols). They are unlikely be integrated into the host PC applications as they need to be able to, among other things, forcibly reboot power to all the electronics in some circumstances.

Scripting Commands

Scripts are a simple way of automating repetitive tasks with ease. They make use of the public methods and properties made available by the various applications and the operating system. When you run a sequence, some automation programs build and run a script derived from the user settings.

There are various flavors, VBScript and JScript being the two one is most likely to encounter. In essence, they are mini programs, accessing and linking a vast library of code that already exists on your computer. As such, a few lines can accomplish something very complicated by accessing the ASCOM methods and properties referenced on the ASCOM.org website. An Internet search for “AS-COM telescope methods” locates them. Scripts can be really simple; here is a fragment to unpark a SkyWatcher telescope and set it tracking, written in Visual Basic Script:

fig.4 MaxPilote is a freeware application that originally automated Maxim DL and now also can control TheSkyX and PHD2. It has three main screens. This one is the setup screen. It is busy, but all the information is there in one place.

It could go on to set the guide rate to 0.2x:

In this manner, a script can access any public ASCOM object’s properties or methods, or those of any published API. Common scripts set up the mount device (ASCOM confusingly calls them telescope devices) without having to use the handset to park the mount or run a simple exposure sequence and close the roof. They do not need a development environment to generate; the Windows operating system provides the simple text editor and compiles these mini programs automatically when you run them. Scripts are functional and not pretty. They work in a linear way, one thing at a time with basic user input and output using simple dialog boxes. They do, however, have full access to the file and network system. If you want to have something more permanent with multiple possible functions and an on-screen presence, you will need to move on to fully-featured Visual Basic, C++ or C# programs. These in turn can generate more COM or .NET objects for other applications to access. Imagination is the practical limit.

fig.5 A selection of ASCOM methods and properties for four device types. This is in no way an exhaustive list, but does represent some of the many telescope controls compared to, say a filter wheel. These names will typically pass or return a parameter, for example a true/false or a coordinate. The ASCOM.org website lists all the methods and properties and their parameters. Other program APIs have similar lists, all of the public ones can be accessed by scripting or a third-party automation program. In recent months, environmental sensing was added, which provides useful information for atmospheric refraction modelling and weather warnings.

A script can be run directly by a mouse click action on a file or referenced by a program. For instance, a VBScript can be placed in the Windows startup folder so it runs as the computer boots. In this way, my weather system powers up with the PC and starts to record the cloud cover. Similarly, all the applications, including Maxim DL and Sequence Generator Pro offer the option to call a script at selected events (often before or after an exposure). For instance, it may be to check the altitude of the mount and decide if it is getting close to the horizon limit or send a notification that the sequence has completed.

Scripting is fun and not necessarily difficult. I started by studying some examples, a bit of bedtime reading with a book on VBScript (some recommendations are in the bibliography) and printed off the ASCOM methods and properties and those of my imaging applications. In a short while various patterns emerged and in a day or two, I could control my mount, filter wheel and so on. Although I was familiar with ASCOM programming after my observatory roof design, scripting appeared as another black hole. I was inspired to write my own after examining a few examples kindly provided by the ASCOM developer, Chris Rowland.

There are a few things to watch out for: Not all devices implement all methods and properties. (In general terms methods do something and the properties are a value that can be read or set. The lines blur, however, when the value of a property changes the behavior of a device.)

In the prior example, it tests to see whether the AS-COM telescope driver accepts guide rate commands before trying to change them. That is sound practice but managing errors is something else you will have to look into if you are going to do anything complicated. VBScript has no notion of throwing or catching exceptions like C#, but it has a global Err property that contains the results of the last operation performed. The line on error resume next will skip over the offending line and set the error property:

The math is sometimes confusing too; RA is typically quoted in hour angle and DEC in degrees. When one uses either to compute a move, you have to think about how the angle wraps around ( e.g. 15 - 23 degrees = 352 degrees). It is easy to overlook and sometimes things like this catch out professional software developers.

One of the useful aspects of ASCOM is that all the devices have simulators. You can play to your heart’s content with telescope and dome simulators without causing physical damage, during the day and in the comfort of the home. In fact some professional developers who do not have access to the equipment they are supporting, use simulators for proof of concept of device drivers and applications. In terms of what to use scripting for, there is not much point in trying to recreate the imaging applications but it is useful to augment your application’s capabilities. For instance, start-up and shut-down sequences that park the mount in a precise home position and avoids the telescope and the roof system becoming intimate.

In such a manner, I largely ignore the Synscan handset on my Avalon mount and use scripting to remotely set it up and automate the slews to deliver a polar alignment in under 5 minutes. (The mosquitos will go hungry again.) Simple message boxes and dialogs ask a series of questions and prompt for settings, allowing me to select the changes I require.

For example, if there is no GPS unit attached to a SkyWatcher mount, one has to use the SynScan hand control to enter in the time manually (and not particularly accurately at that). Using a utility like Dimension 4 to access a timer server on boot up, my PC clock is only 100 ms out or better. The script in fig.6, sets up the mount’s clock and date so it matches the PC.

Further example scripts are on the supporting website. One script tests a telescope mount’s response to guider pulses. In practice, setting up an autoguider is always a random affair as seeing noise and tracking issues mask the effectiveness of the settings. Running the autoguider with its guider outputs disabled provides a handy tracking log. The script independently sends alternating and long and slow guider commands and short and fast bipolar commands to see if there is appreciable lag, overshoot, backlash or stiction with a particular axis, guide rate and movement amplitude.

fig.6 This example Visual Basic script sets the mount’s clock to match that of the PC, with a prompt to the user to confirm if the PC clock is using daylight savings. This script, although intended for a SynScan-based mount (as my Avalon Linear is) can easily be adapted to connect to any ASCOM-compliant mount and accomplish the same thing.