Control System for Amateur Telescope Experience

Transcription

1 Control System for Amateur Telescope Experience Departamento de Informática, Universidad Técnica Federico Santa María, Avenida España 1680, Valparaiso, Chile

2 Agenda Introduction Scientific/Technological Novelty System Architecture Deployment Experiences Conclusions

3 What is CSAT? A Telescope Control System (TCS) Generic software for amateur telescopes Based on ALMA Common Software (ACS) Developed by ALMA-UTFSM Group First step towards professional generic TCS

4 The Problem Observatories reimplement their TCSs over and over again Reusing old telescopes Reduce cost of academic observatories Robotic and distributed telescopes Common patterns between telescopes Specific instruments of each one Integrate, port and deploy wide spectrum of external software

5 The Solution gtcs: generic Telescope Control System Bazaar paradigm: community development Advantage: there are not so many telescopes Problem: almost every telescope is different Step-by-step: show that is plausible First step: A prototype for amateur telescopes

6 CSAT Goals General objective To have first-hand case study to feedback in the gtcs design, and use the telescope for first prototype of gtcs usage.

7 CSAT Goals General objective To have first-hand case study to feedback in the gtcs design, and use the telescope for first prototype of gtcs usage. Specific objectives The system must:

8 CSAT Goals General objective To have first-hand case study to feedback in the gtcs design, and use the telescope for first prototype of gtcs usage. Specific objectives The system must: be capable to decide if the object is or not in the visible field of the sky.

9 CSAT Goals General objective To have first-hand case study to feedback in the gtcs design, and use the telescope for first prototype of gtcs usage. Specific objectives The system must: be capable to decide if the object is or not in the visible field of the sky. provide Presetting.

10 CSAT Goals General objective To have first-hand case study to feedback in the gtcs design, and use the telescope for first prototype of gtcs usage. Specific objectives The system must: be capable to decide if the object is or not in the visible field of the sky. provide Presetting. provide Pointing.

11 CSAT Goals General objective To have first-hand case study to feedback in the gtcs design, and use the telescope for first prototype of gtcs usage. Specific objectives The system must: be capable to decide if the object is or not in the visible field of the sky. provide Presetting. provide Pointing. provide Tracking.

12 System Architecture

13 System Architecture There are four software layers: Hardware access layer (1/4) In this layer the DevIOs are placed.

14 System Architecture There are four software layers: Hardware access layer (1/4) In this layer the DevIOs are placed. New hardware only change this layer device component

15 System Architecture There are four software layers: (Logical + Devices control) layer (2/4) This layer has components that do control over the Dev* components. For example, Telescope over DevTelescope.

16 System Architecture There are four software layers: (Logical + Devices control) layer (2/4) This layer has components that do control over the Dev* components. For example, Telescope over DevTelescope. Also, are present logical components, as Pointing, Tracking and Calculations.

17 System Architecture There are four software layers: Interface layer (3/4) This layer is compound by CSATStatus and CSATControl.

18 System Architecture There are four software layers: Interface layer (3/4) This layer is compound by CSATStatus and CSATControl. These are the entry points for external applications.

19 System Architecture There are four software layers: Interface layer (3/4) This layer is compound by CSATStatus and CSATControl. These are the entry points for external applications. CSATStatus: read-only operations. CSATControl: send commands.

20 System Architecture There are four software layers: Clients layer (4/4) Hevelius: easy-to-use GUI designed for teaching purposes.

21 System Architecture There are four software layers: Clients layer (4/4) Hevelius: easy-to-use GUI designed for teaching purposes. External clients wrapper: a wrapper for external applications that connect to a telescope.

22 System Architecture There are four software layers: Clients layer (4/4) Hevelius: easy-to-use GUI designed for teaching purposes. External clients wrapper: a wrapper for external applications that connect to a telescope. ACS Object Explorer: GUI to access the interface of a component.

23 Generic Control Design (1/3) Control several amateur telescopes Uses the generic ACS DevIO abstraction Defines a generic telescope interface to be implemented: Set axis velocity Get axis velocity Get current axis position Different control for each axis type (called mount) In particular for equatorial and alt/azm telescopes

24 Generic Control Design (2/3)

25 Generic Control Design (3/3)

26 External Applications Wrapper (1/3) Scenario CSAT works with the Hevelius GUI, but... External application compatibility is a key-feature (Amateur) Astronomers want to use other existing front-ends These applications usually interacts with telescopes They use some standard protocol to connect to the telescope

27 External Applications Wrapper (2/3) Our response Solution: a CSAT client that binds a serial port service Result: enhance CSAT usability using star catalogs, graphical interfaces, etc. Available protocols: LX200 and Nexstar Opportunity: use several mounts with the same interface!

28 External Applications Wrapper (3/3)

29 Goals achieved Control for altitude/azimuth mounted telescopes, as well as Equatorial mounted ones. Manual and automatic pointing model. Tracking capabilities. Geographic information configuration. Current support for Nexstar 4 SE, Meade LX200 GPS and Meade LX200 EMC telescopes. Hevelius GUI client for CSAT. External applications wrapper

30 Deployment methodology To deploy CSAT on new telescopes you should follow these steps: 1. Study the communication protocol. 2. Develop simple test clients. 3. Encapsulate the communication code into DevIOs. 4. Write a DevTelescope interface, using the corresponding DevIOs

31 UTFSM Deployment (1/2) CSRG Laboratory (Valparaíso) CSAT development platform: Celestron Nexstar 4 SE telescope MEADE Lunar Planetary Imager GARMIN GPS Nexstar simulator (ACS based and stand-alone) CCD GUI for testing 10-month development

32 UTFSM Deployment (2/2)

33 Santa Martina/PUC Deployment (1/2) Observatorio UC at Cerro Santa Martina (Santiago) Meade LX200 GPS telescope DevIO implementation and protocol adaptation Amateur observation and tracking testing 2-month development during a summer job

34 Santa Martina/PUC Deployment (2/2)

35 OCA/UCN Deployment (1/2) Observatorio Cerro Armazones (Atacama desert) Equatorial Meade LX200 EMC Protocol adaptation from PUC experience Amateur observation and tracking testing more exhaustive 3-days development (Plus the previous experience with LX200 telescopes)

36 OCA/UCN Deployment (2/2)

37 Conclusions Developing generic interfaces for telescopes is possible! CSAT was a productive way of learning from the astronomical instrumentation domain The usage of ACS framework provides the tools for: Component distribution Generic interfaces Runtime configuration Multi-language support Concurrent access Software testing ACS is a good platform for a gtcs implementation Most of the patterns of CSAT are the basis of gtcs

38 Future Work Design a general architecture for the gtcs gtcs workshop will be held at the UTFSM An implementation of gtcs will be developed

39 Questions? This work has been supported by project ALMA-CONICYT Software Development for ALMA: Building Up Expertise to Meet ALMA Software Requirements withing a Chilean University. The development over the Meade LX200 GPS telescope on the Santa Martina Observatory could not have been done without the collaboration of the Pontificia Universidad Católica. The development over the Equatorial Meade LX200 and the testing over the 84 [cm] telescope on Cerro Armazones could not have been done without the collaboration of the Universidad Católica del Norte and Roland Lemke, who has also given us support with his participation on the gtcs discussions. Jorge Ibsen has been of great help during the whole process.