Que barbaridad, jeje, me quitan internet unos días y cuando vuelvo veo todo esto revolucionadito.

Antes de nada, Antonio, creo que en un mensaje anterior me decías lo de borrar temas del repositorio, recuérdame, por favor, lo que necesitas borrar, lo hago y os comento los pasos a seguir.

En estos días me encuentro por temas de trabajo fuera de casa hasta el dia 21 (en valladolid), con internet limitado a un ratillo por la tarde desde el hotel, hoy he actualizado mi copia de trabajo y durante estos días me quiero centrar en terminar el ftw y de alguna manera conseguir un sistema de configuración de las cámaras más consistente como os comenté en anteriores correos; iré realizando cuando me dejen los commits poco a poco.

Sobre  todo lo que os he leído del  ASCOM5, me parece genial, pero ya que estamos pensando en limpiezas, vamos a hacerlo bien, EQAling funcionará en Linux y  para ello se usará INDI, que es el equivalente al ASCOM, por tanto y aunque nos cueste más trabajo, creo que hemos de crear un "wrapper" o capa intermedia que evite el acceso directo a cualquiera de estos  protocolos, con ello conseguimos que el programa realmente no dependa  DE NADA,  ya que pienso que una dependencia excesiva de ASCOM o cualquier otro puede darnos problemas en el futuro si, por ejemplo,  cambian la licencia o se les va la olla...

Más de la limpieza: la interfaz... bien, de nuevo tenéis que ponerme no muy complejo el port a Linux, y para ello lo que necesito es que el GUI siga dentro de lo posible el modelo vista-controlador, o dicho de otra manera, que sea completamente intercambiable,  eso lo podemos conseguir mediante la modularización completa del proyecto en librerías reutilizable, pero poco a poco, puede ser tedioso y pienso que no hemos de meternos en estos líos antes de la versión 2.0 final.

De momento, os sigo los pasos en las novedades, pero me centro en la estabilización de la versión 2.0: optimización de la base de datos, sistema íntegro de cámaras y estabilización y actualización del driver de la qhy5 (soporte de alta sensibilidad y binning 2x2), esto por mi parte dejaría listo el tema para la siguiente beta o incluso Release Candidate.

Un saludín!


----- Mensaje original ----
De: Antonio Fraga <antoniofga@yahoo.es>
Para: Lista de correo de desarrollo EQAlign <eqalign-devel@lists.sourceforge.net>
Enviado: sábado, 8 de diciembre, 2007 16:28:17
Asunto: Re: [Eqalign-devel] ASCOM, EQAlign modular

Bien,
Tenemos cámaras y una clase a través de la cual nos conectaremos a “cualquier” cámara.
Tenemos telescopios y una clase  a través de la cual nos conectaremos a “cualquier” telescopio.
Y tenemos relayboxes y (aún no en el nuevo esquema) una clase que nos permitirá conectarnos a “cualquier” relaybox.
 
Además las cámaras cumplen el interfaz GuiderInterfaz pues algunas cámaras permiten autoguiar y lo mismo con los telescopios. Así que tanto los relaybox como las cámaras como los telescopios son Guiders.
 
Estupendo, conceptualmente parece que todo está solucionado, pero ahora nos enfrentamos a un problema:
 
Imaginen que estamos conectados a un telescopio y que luego queremos conectar con una cámara. Hasta aquí bien. Ahora queremos conectarnos con un autoguiado. Puede ser que queramos conectarnos con un relaybox, entonces no hay problema, pero supongamos que queremos conectarnos al relaybox de la cámara a la que estamos conectados.
 
Aquí debe haber un pequeño negocio. Si la cámara que servirá de relaybox está ya conectada, “simplemente” hay que hacer que el guiador apunte a ella (haciendo la conversión de tipos necesaria):
guider = (GuiderInterface)cam;
 
Listo. Pero qué pasa cuando cerremos la sesión de autoguiado, o  qué pasa si cambiamos de cámara. En el primer caso al tratar de hacer un Disconnect() se debería detectar que el dispositivo aún es “útil” pues está sirviendo imágenes y en el segundo caso deberíamos dejar la instancia de cámara abierta e instanciar otra con la nueva cámara... si se hacen cargo, este “pequeño” negocio puede llegar a ser ¡un lío!
 
Se me ocurre una idea. En lugar de conectarnos a una cámara, a un telescopio o a un relaybox o cualqueir otro dispositivo de “hardware astronómico” de forma aislada, podríamos tener una clase de nivel superior, algo así como AstroHard (o yo qué sé) que centralice todos los accesos a cualquier tipo de hardware, por ahora sólo estos tres..
 
Si queremos conectarnos con cualquier dispositivo (cámara, telescopio o relay) podemos decirle a AstroHard que nos de acceso a ese dispositivo. Si detecta que ese dispositivo ya está abierto, pues le da acceso al mismo (con el interfaz que cumpla la petición). Si recibe una petición de desconexión, primero evalúa si no hay otra petición de uso todavía abierta... en fin sería el encargado de realizar todo ese “pequeño” negocio de dispositivos.
 
cameraID = “Atik 16IC”;
camera = AstroHard.ConnectCamera(cameraID);
 
ascomID = ASCOM.DriverAccess.Telescope.Choose("");
scope = AstroHard.ConnectScope(HardwareType.ASCOM, ascomID);
 
guider = AstroHard.ConnectGuider(HardwareType.Camera,  cameraID);
 
.....
AstroHard.Disconnect(guider.GUID)
AstroHard.Disconnect(scope.GUID)
AstroHard.Disconnect(camera.GUID)
 
Acabo de actualizar el proyecto EQAlign2.1, más o menos está funcional.
 
En cámaras (proyecto EQACam) falta implementar el acceso a ASCOM, creo que será bastante fácil (hay una plantilla para crear cámaras CamTemplate.cs) He esbozado lo que podría ser una conexión a las DSI y he “traducido” también el acceso a las Atik/Artemis
 
No encuentro información sobre los parámetros de guiado de las Atik/Artmeis, en la descripción del comando ArtemisPulseGuide(void *cam, int axis, int millisec); no se especifica los valores de axis. Buscaré, si no encuentro nada: prueba y error.
 

En telescopios (proyecto EQAScope) he implementado el acceso a ASCOM (versión 5), compatible con las dos versiones de ascom. He hecho trampas: primero se comprueba si es compatible ASCOM5, si es así perfecto, si no compruebo si la montura conectada es compatible con LX200, en ese caso también se puede enviar un pulso de movimiento (sin tiempo de acción) y si tampoco, pues el pulso dura 1 segundo. Eso dará un poco más de usabilidad a a botonera.
 
En el proyecto TestScope, se permite conectarse a un telescopio y a un guiador. En el guaidor se muestra un combo con las cámaras que permiten autoguiado y ascom. Pero no hay nada de ese “negocio”, si se desconecta un dispositivo que sirve a los dos, desconectado queda.
 
En el proyecto EQAControls sólo hay dos controles: la botonera (usable por autoguiadores y telescopios) y las coordenadas del telescopio.. Ahí puede ir un contenedor de imágenes, el control de tratamientos de imagen (histograma, gamma, contraste, desenfoque, apilado), el graficado de mediciones, etc.
 
Cuando esté todo, habrá que ir “cosiendo” EQAlign 2.1 con los “retales”.
 
Bien, mientras no hayan otras ideas continúo en este esquema.
 
Un saludo
 




¿Chef por primera vez? - Sé un mejor Cocinillas.
Entra en Yahoo! Respuestas.