This automation phase had three main objectives:
This phase never really reached completion before moving to phase 3 but anyway...
The Telescope
After the opportunity arose to remove the C14 from the observatory it
was time to build a really good custom telescope without all the
compromises that are inevitible in a commercial instrument. An f/12
cassegrain was rebuilt from optics that had been in storage for a while
and using an optical glass window instead of a traditional spider to
hold the secondary.
The mount was built by a friend who is retired engineer and is quite
capable of carrying a telescope larger than the 12". Better to
over-engineer in this case than deal with the problems of the
under-engineered commercial mount.
The mount is a German equatorial which needs special consideration in
an automated environment because of its movement restrictions and its
inability to track through the meridian. This only requires the
software to be aware of these restrictions and and should not pose too
much of a problem. |
 |
The Drive
The electronics to drive this is a custom designed microprocessor
controlled drive unit designed to interface with the observatory's bus
and provide a good compromise between stand-alone operation and
computer control. It is effectively the realisation of a wish list
arising from the frustrations of controlling the Celestron box. This
has its own (sordid) story here . |
The Software
While all the other changes were going on in phase 2 some thought had gone into how the software should work. The phase 1
software was highly specialised and operated in a less than ideal
environment (DOS). It was redesigned from scratch to be a full
observatory automation system with generic hardware support and modular
observing technique. The phase 2 version was designed exclusively for
RISC OS mostly as a matter of convenience and reliability.
To do this right required a totally different architecture from the
previous lame attempts. To start with it needed to use a GUI to have
more versatile control over all the subsystems it would control. It
would also have to be modular and be based on abstract drivers. The
result of actual software planning was the specification for ROC.
(Robotic Observatory Controller, not to be confused with the slightly
manic computer in Airplane 2!) Some of its notable features are:
- Observatory
control and monitor including power system, UPS, roof/dome,
environmental data, precision clock (oven quartz, GPS, cesium beam,
etc).
- Instrument control and monitor including telescope, CCD camera, photometer and video camera (so far).
- Modular observing methods including differential single
channel photometry and CCD exposures (again, so far). These can operate
at various levels of automation.
- Distributed operation allowing multiple telescopes and
observatory functions to operate from several computers or just one.
All display operations are decoupled from the control so that remote
monitoring and control is quite practical.
- Observing scheduler allowing prioritised automatic allocation of targets on multiple telescopes.
- Access to on-line catalogues allowing object searching, local
circumstance information and drag and drop observing programme
creation. The star chart software is a separate program (ROCchart
which as been released as freeware) but designed to coordinate with the
main software allowing on-chart telescope following and point-and-click
telescope control.
|
Of course there are some ragged edges in the visual design still and the screen shot only shows a few of its functions.
This version was reasonably successful but suffered from some
architectural design flaws which were difficult to overcome, most
notably the poor separation of the front-end from the back-end. Also,
techniques learned from other projects meant that this version, like
its DOS predecessor, was also doomed. |
RISC OS software in the middle of a test photometry run of W Crucis. (Click image for full size version ).
|
|
