Interfaces para Clientes CSAT

[Rodrigo Tobar]

Jorge Ibsen wrote:
> Hola,

Hola Jorge!

> Estuve mirando la pagina y tengo algunas preguntas:
> 
> 00)Como una regla general, seria bueno agrupar toda la terminologia 
> usada en las paginas en un glosario en el Twiki y agregar referencias al 
> glosario cuando sea pertinente.

Mmmm... sera discutido en la proxima reunion ;)

> 0)https://csrg.inf.utfsm.cl/twiki4/bin/view/ACS/ControlAmateurTelescope 
> muesta un diagrama de componentes. Son esto ACS components, o se 
> refieren a otra definicion de componentes? Seria bueno que definieran 
> cuales son todos los elementos considerados en este software de 
> observacion y expresar claramente cuales son las responsabilidades 
> asociadas a cada uno de ellos. En particular ese diagrama debiera 
> mostrar claramente cual es el rol del CSAT y que intereacciones tiene 
> con los otros elementos.

Los habiamos pensado como ACS components. Las responsabilidades no las 
tenemos explicitadas en ninguna parte, sino que solamente una idea 
general de cada componente, tomando como ejemplo el trabajo en UOS y 
viendo otros modelos de TCS.

> 1)Porque estan acoplando el telescopio con la adquisicion de imagenes de 
> la camara? Esto asocia responsabilidades que no debieran estar en el 
> control del telescopio. El control de la camara debiera ser un 
> componente independiente y esta fuera del scope del CSAT. La 
> coordinacion entre el telescopio y la camara sedebe hacer desde un 
> componente de mas alto nivel, parte del observing software, pero fuera 
> del CSAT (ver punto 0)

Habiamos pensado en el asunto del autoguiding. En ese ambito tampoco 
deberia estar asociada la CCD con el telescopio?

> 2)Cual es la interaccion entre los dos componentes propuestos: 
> CSATControl y CSATStatus? Es posible clarificar esto a traves de un 
> diagrama?

La idea era separar responsabilidades. Los nombres tal vez no sean los 
mas emblematicos (pues las ideas originales para cada uno eran 
distintas), pero el rol de cada uno es el descrito en 
https://csrg.inf.utfsm.cl/twiki4/bin/view/ACS/PublicInterfacesDiscussion20070725, 
que en resumen dice que:
  * CSATControl provee todos los metodos para acceder a las capas mas 
inferiores del TCS, para mover el telescopio a mano, por ejemplo.
  * CSATStatus provee los metodos para mover el TCS de un estado a otro 
y controlar su ciclo de vida, ademas de entregar informacion acerca de 
su estado.

La interaccion directa entre estos dos componentes seria, mas que nada, 
que CSATControl pida cierta informacion de status a CSATStatus, y que 
este ultimo, a su vez, pida a CSATControl el control de los dispositivos 
de bajo nivel para continuar el ciclo de vida del TCS.

> 3)Una pequena introduccion y ejemplos acerca de las transformaciones de 
> coordenadas que se usan en un TCS se puede encontrar aca: 
> http://www.ing.iac.es/~docs/external/starlink/sun67/node195.html. En 
> particular seria bueno que se consiguieran algunos de las referencias 
> que se mencionan en la pagina. La siguiente pagina 
> http://www.ing.iac.es/~docs/external/starlink/sun67/node200.html#SECTION00053000000000000000 
> da una idea acerca de los sistemas de coordenadas celestiales (en 
> particular miren el diagrama). En particular noten que la posicion de 
> los objetos estelares se especifican de maneras diferentes dependiendo 
> del catalogo usado, y que esto tiene impacto en los tipos de data a 
> definir.

Gracias por el dato :D... le estuve echando una ojeada rapida, y parece 
bastante util ;)

> 4)Calibrating sounds more like a transition than a state. Por regla 
> general me gustan mas los nombre SHUTDOWN, STANDBY, ONLINE. A modo de 
> ilustracion en el VLT se usaba: OFF, INIT, STANDBY, ONLINE. La 
> transicion entre OFF e INIT era inicializacion de HW, y entre INIT y 
> STANDBY una inicializacion de SW (threads, resources, etc), pero el 
> sistema no es operable. STANDBY to ONLINE deja el sistema listo para 
> hacer operaciones sobre el HW. A lo mejor era esto lo que se tenia en 
> mente con "calibrating" y la eleccion de nombres no fue muy buena. No 
> entiendo el sentido de AUTOMATIC.

Con respecto a este tema, nosotros habiamos pensado algo parecido al 
ejemplo del VLT que tu mencionas:

  * El sistema comienza apagado en Stop
  * La transicion entre Stop y Stand-By es la inicializacion de HW
  * La transicion entre Stand-By y Calibrating supone el HW 
inicializado, pero se hace explicito el hecho de que no esta calibrado. 
Entonces, se hace un calibrado (sin usar necesariamente CSAT), y luego 
se vuelve al estado Stand-By.
   * La transicion entre Stand-By y Ready es la inicializacion de los 
componentes del sistema (SW).
   * Finalmente, Ready y Automatic suponen casi el mismo estado, excepto 
que en Ready las observaciones y el control del telescopio se hace de 
forma manual, mientras que en automatic se hace uso del scheduler.

> 5) Seria bueno considerar en el disenno la posibilidad de tener un nivel 
> de simulacion para los devices de HW. Frecuentemente es necesario que 
> algunas funciones de HW se puedan simular en run time para hacer un 
> bypass en caso de algunos tipos de falla. No tengo muy claro como se 
> puede hacer esto, pero conviene tenerlo en mente.

Claro. Por mientras tenemos el simulador del nexstar (muy roñoso aun la 
verdad). Algo es algo :P

> 6)Seria bueno agregar una explicacion a los metodos propuestos para los 
> IDLs (y mejor escribir los IDLs!). En particular, cual es que proposito 
> de set/getTrackingStatus, initialize, getSafety, setMode? Emergency 
> stops se implementan normalmente en HW, no en SW.

Eso ya va en camino, vamos con calma :). Esperemos que esten pronto 
escritas las IDL con su respectiva documentacion.

> 7)Acuerdense que el objetivo de este ejercicio es tambien iterar un 
> diseno de interfaces suficientemente genericas para el gTCS, asi que por 
> favor no olviden que la interfaz del LEGO model tiene que ajustarse para 
> caer como especializacion de la interfaz generica. Tengan siempre al 
> LEGO como el segundo telescope type.

Si, esto es algo que tenemos bien claro. De hecho, en el diagrama de la 
pagina (que Mauricio realizo amablemente) aparece en unos cuadros 
semi-transparentes otros modelos para la CCD y el telescopio, dando la 
idea de reemplazar ese componente, de la misma forma que lo hicimos en 
el workshop. Por eso tambien existe esa cada Dev en la arquitectura.

Con respecto al disenno de las interfaces, es claro que no es 
definitivo. Con Mauricio propusimos iteraciones de mas/menos 1 mes, pero 
necesitabamos alguna version por donde empezar (para que Hevelius 
tambien pudiera comenzar su trabajo, ellos terminan en octubre).

> 8)Porque tantas tipos de GUI para el CSAT? Seria interesante considerar 
> tambien el uso de un web browser para comandar el sistema. :)

Hevelius es un proyecto semi-aparte. Estan trabajando en colaboracion 
con nosotros, pero tienen sus metas propias (tienen que presentar su 
proyecto en una feria de software, donde todo tiene que ser bonito y no 
  perfectamente funcional, necesariamente). AmConsole es una consola que 
se le ocurrio a Mauricio para la administracion por parte de los 
operadores cabrones que les gusta la linea de comando y la consola (no 
es una necesidad, y yo de verdad prefiero la GUI). el WebSched, 
obviamente, es la interfaz de entrada para la insercion de proposals en 
el scheduler.

> Eso es todo por el momento.

OK... estamos tomando nota de todos los puntos ;)

> Saludos,
> 
> Jorge
> 

Saludos!!!
-- 
Rodrigo Tobar Carrizo                   Linux User #399271
CSAT Project Leader                     +5690541932
http://www.alumnos.inf.utfsm.cl/~rtobar