8.9 Practical 7: The Speed of Light
131
8.9.5 Remote Observing
As discussed in Chap. 1, remote and robotic observing is becoming the standard
for many observatories due to the introduction of low-cost, high-quality GoTo
mounts and the standardisation of software driver formats via the ASCOM standard.
This allows observatories to mix dome controllers, mounts, cameras, and powered
focusers from different suppliers to meet their own needs. This has also led to a
wide array of software interfaces for robotic and remote telescope systems. Often in
robotic observatories, behind many robotic telescope interfaces lies a programming
language known as Robotic (or Remote) Telescope Mark-up Language (RTML).
RTML is very similar to HTML and is the actual code that the telescope control
computer uses to tell it what to do.
Hence, no two robotic observatories will be operated identically, and the discussion of an individual system falls outside the scope of this book. Among the main
reasons that many observatories have moved towards robotic and remote operation
are the cost of labour required to supply nighttime support as well as daytime maintenance and the reduction in travel costs to remote sites. To some extent, the benefits
of robotic and remote observing are offset by the loss of telescope time when a fault
develops, which is more common in these systems due to their complexity. In many
situations, these would be solved by an on-site astronomer, and simple reboots of
computer systems and cameras are possible to perform remotely, but hard resets (the
too common turn-it-on-and-off-again fix beloved by IT professionals) are not. A
minor problem for an on-site observer can often become a major one for an off-site
observer.
Service mode observing involves another astronomer or telescope operator (TO)
using the telescope on your behalf. Service mode is becoming increasing popular
amongst research-grade observatories such as Gemini and the VLT, where technical staff are always on hand to take the observations, and flying astronomers to
the observatory is becoming increasingly cost-ineffective (in addition to being bad
for the environment). As an undergraduate, you are unlikely to encounter service
mode operation. However, both remote operation and robotic operation are becoming increasingly commonplace.
As stated earlier in this book, remote observing means that a user has direct control
of a telescope, its camera, the dome, and any ancillary equipment such as the filter
wheel. This is often undertaken using either a secure remote desktop application built
into the operating system or an off-the-shelf package such as VNC. Robotic or queue
observing does not invoke direct access to the telescope as in remote observing.
In robotic obsesrving, instructions are fed to a computer system that directs the
operation of the telescope and runs the client’s observations, normally based on a
priory algorithm that may or may not have some human input.
For robotic observation, you will need to prepare a detailed plan for your observations and be able to translate that plan into a format that the telescope will understand.
This is typically done using user interfaces like the one used by the Liverpool Telescope or iTelescope. As each telescope operator has different interfaces, and even
131
8.9.5 Remote Observing
As discussed in Chap. 1, remote and robotic observing is becoming the standard
for many observatories due to the introduction of low-cost, high-quality GoTo
mounts and the standardisation of software driver formats via the ASCOM standard.
This allows observatories to mix dome controllers, mounts, cameras, and powered
focusers from different suppliers to meet their own needs. This has also led to a
wide array of software interfaces for robotic and remote telescope systems. Often in
robotic observatories, behind many robotic telescope interfaces lies a programming
language known as Robotic (or Remote) Telescope Mark-up Language (RTML).
RTML is very similar to HTML and is the actual code that the telescope control
computer uses to tell it what to do.
Hence, no two robotic observatories will be operated identically, and the discussion of an individual system falls outside the scope of this book. Among the main
reasons that many observatories have moved towards robotic and remote operation
are the cost of labour required to supply nighttime support as well as daytime maintenance and the reduction in travel costs to remote sites. To some extent, the benefits
of robotic and remote observing are offset by the loss of telescope time when a fault
develops, which is more common in these systems due to their complexity. In many
situations, these would be solved by an on-site astronomer, and simple reboots of
computer systems and cameras are possible to perform remotely, but hard resets (the
too common turn-it-on-and-off-again fix beloved by IT professionals) are not. A
minor problem for an on-site observer can often become a major one for an off-site
observer.
Service mode observing involves another astronomer or telescope operator (TO)
using the telescope on your behalf. Service mode is becoming increasing popular
amongst research-grade observatories such as Gemini and the VLT, where technical staff are always on hand to take the observations, and flying astronomers to
the observatory is becoming increasingly cost-ineffective (in addition to being bad
for the environment). As an undergraduate, you are unlikely to encounter service
mode operation. However, both remote operation and robotic operation are becoming increasingly commonplace.
As stated earlier in this book, remote observing means that a user has direct control
of a telescope, its camera, the dome, and any ancillary equipment such as the filter
wheel. This is often undertaken using either a secure remote desktop application built
into the operating system or an off-the-shelf package such as VNC. Robotic or queue
observing does not invoke direct access to the telescope as in remote observing.
In robotic obsesrving, instructions are fed to a computer system that directs the
operation of the telescope and runs the client’s observations, normally based on a
priory algorithm that may or may not have some human input.
For robotic observation, you will need to prepare a detailed plan for your observations and be able to translate that plan into a format that the telescope will understand.
This is typically done using user interfaces like the one used by the Liverpool Telescope or iTelescope. As each telescope operator has different interfaces, and even