KPO

Automation
KPO Home
Phase 2: Automating A Scratch-built 12" Telescope
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  ).