Ekos/Indi - control de captura, guiado y montura en Linux.

[minaya]

Vamos progresando ...

1. Montura (EQ6 via eqdir) -> Parece que hace los gotos bien (al menos dentro de casa apunta a donde debería apuntar aprox). Hay que probarlo de noche.
2. QHY5 -> Funcionando más o menos. Los drivers de la camarita para variar no son ninguna maravilla, pero imagino que servirá.
3. Canon -> La reconoce y consigo tomar imágenes en RAW. No obstante hay que mejorar alguna cosilla. Sigo empeñado en que poder acceder a la imagen del liveview para enfocar es lo suyo, hay que terminar de adaptar el módulo de autofoco para este tipo de cámaras, etc.

Por supuesto, todo en remoto claro. Todos los chismes están controlados por un Raspberry PI, mientras que EKOS/kstars (la parte 'cliente') se ejecuta en mi ordenador.

[hidra]

Hola Minaya, tengo curiosidad por saber como funciona.

Tienes la raspberry como servidor (o un PC) a pié de telescopio, y a la raspberry le conectas las camaras, el telescopio, el enfocador y lo que sea?, en caso afirmativo, que soft hay instalado en el PC ¿algo así como el EQmod (a modo de hub) para todos los dispositivos?

En caso afirmativo, en el PC remoto ¿tienes los programas de captura, planetario, autoguiado, etc, conectados por INDI como clientes, al servidor (EQmod / Ekos?) trabajando en INDI?.

Se agradecería una pequeña explicación / site con diagrama explicativo (a ser posible en castellano).

Una ultima pregunta ... supongo que los drivers de la camara y demás, se instalan en el servidor ¿no?.

INDI para mi es un misterio (todavia).

Saludos
Luis

[minaya]

En caso afirmativo, en el PC remoto ¿tienes los programas de captura, planetario, autoguiado, etc, conectados por INDI como clientes, al servidor (EQmod / Ekos?) trabajando en INDI?.

En el servidor:
- Tenemos por una parte los dispositivos, todos conectados (por usb, por serie, por lo que sea).
- Una serie de drivers para controlar esos dispositivos. Estos drivers están escritos de tal forma que le dicen al servidor INDI qué propiedades tiene disponibles (por ejemplo el tiempo de exposición en el caso de una cámara). El cliente por tanto no tiene porqué conocer nada de antemano. Esto tendrá por supuesto sus inconvenientes, pero tiene importantes ventajas:

1ª) El cliente no tiene porqué saber casi nada del dispositivo en cuestión. Al conectar, es el driver el que le cuenta al cliente qué puede modificar, y este genera todos los botoncitos, opciones en la interfaz, menus, etc. Todo de forma dinámica.
2ª) cliente, servidor y drivers quedan desacoplados. Podrías usar una versión vieja del cliente por ejemplo con una versión más nueva del servidor (o al revés).

En el cliente:
- Sólo necesitamos un software que sepa hablar en el protocolo indi. Que yo sepa, la comunicación se establece en puertos de red consecutivos (uno por dispositivo). Pero de esto último no me hagais mucho caso.

Kstars es un cliente, Xephem es otro cliente, Ekos (dentro de kstars) es un 'cliente embebido en Kstars', etc.

Decir que la comunicación cliente-servidor es transparente. Me explico. Si tu haces un goto en el cliente, obviamente la orden la aplica el servidor y devuelve el estado en tiempo real al cliente. Lo mismo si haces una imagen. La orden se envía, la imagen se toma y se descarga en el cliente de forma transparente.

En el caso del guiado, para evitar 'lags' en comunicaciones remotas, han desarrollado algo que llaman 'rapid guide'. Básicamente, si se activa los cálculos/correcciones los realizan directamente los drivers de la cámara, y no el software que corre en el cliente.

Algo positivo de tener un cliente que no tiene porqué conocer las propiedades de los aparatos que le conectes al servidor es que el desarrollo de los clientes parece simplificarse. Así, se pueden desarrollar con relativa facilidad clientes en diferentes lenguajes de programación y para diversas plataformas (hay un cliente ya en la apple store para los iphones/ipads por ejemplo).

Una ultima pregunta ... supongo que los drivers de la camara y demás, se instalan en el servidor ¿no?.

Sí, allí donde conectas todos los chismes.

Dicho todo esto, en mi caso aun no podría utilizar de forma efectiva INDI (o al menos no si quiero ser productivo) por el driver de la cámara de fotos básicamente. Si bien actualmente es posible controlar el enfoque de forma rudimentaria y disparar/descargar las imágenes, programar las tomas que vas a sacar, etc, no funciona bien la previsualización (tendrías que abrir con otro programa el fichero descargado) y creo que no funcionaría bien la parte del astrometry solver ni el enfoque.

Lo bueno es que están trabajando en ello, así que será cuestión de tiempo .

Para quienes tiran de CCDs parece que la cosa está bastante mejor. Al menos hay demos 'de campo' que han colgado en youtube que parecen prometedoras.

PD. Lo tenía conectado desde esta mañana y no se ha caído la conexión en todas estas horas. Sigue haciendo los gotos, parks/unparks, sigue tomando imágenes, etc. Mola.

[hidra]

Gracias Minaya, has respondido a las preguntas que te he hecho y a las que te pensaba hacer en un futuro.

Al principio pensé en IP's aunque lo de los puertos parece mucho mas lógico, pero si no es el user el que los asigna debe ser el propio servidor INDI, y si es así supongo que el servidor y el cliente tendran que establecer un dialogo para eso... o bien tiene que ser el user el que tenga que consultarlo en el servidor para entrar el puerto que toca a cada programa del cliente.

Ummmm ¿tu eres del Atletic no?, lo digo por que has respondido al poco de terminar el partido.

Saludos

[minaya]

Ummmm ¿tu eres del Atletic no?, lo digo por que has respondido al poco de terminar el partido.

No, no soy muy futbolero

[J30]

Pues mira, para empezar a cacharrear me he liado la manta a la cabeza y he pedido una Raspberry para funcionar en Raspbian, y empezar a instalar y hacer correr las aplicaciones. Me habéis picado...

[cometas]

Miguel , te lo pasaras pipa, no es que sea muy complicado pero si tienes experiencia en LINUX , todo es mas facil.

Yo uso una raspberry , pero de momento solo como servidor web y FTP (mi web esta alojada en mi raspberry)

[J30]

Miguel , te lo pasaras pipa, no es que sea muy complicado pero si tienes experiencia en LINUX , todo es mas facil.

Yo uso una raspberry , pero de momento solo como servidor web y FTP (mi web esta alojada en mi raspberry)

Si, ya me manejo más o menos en linux, aunque lo haya dejado un poco de lado (al final es un poco lata estar con 2 SO dentro de la misma máquina). Ahora con un dispositivo exclusivamente dedicado a linux será más sencillo. Y me motiva mucho el probar un cacharro nuevo. Eso si, con la miniaturización, a este paso, nos vamos a ir olvidando los ordenadores en los bolsillos de la chaqueta y las tarjetas microSD se van a perder por el desagüe

[J30]

Preguntas para Minaya:
Al empezar la sesión, hay que iniciar el servidor INDI con la orden correspondiente. ¿Tendré que conectarme en remoto con el servidor, y allí arrancar INDI, ya para después trabajar desde el cliente? parece que knro, en el foro, cuenta que se conecta por SSH.

¿Y cómo encontraré el servidor INDI desde el cliente? ¿por el puerto? Planteo la cuestión suponiendo que me conecto con el servidor dentro de una wifi.

Gracias

[minaya]

Preguntas para Minaya:
Al empezar la sesión, hay que iniciar el servidor INDI con la orden correspondiente. ¿Tendré que conectarme en remoto con el servidor, y allí arrancar INDI, ya para después trabajar desde el cliente? parece que knro, en el foro, cuenta que se conecta por SSH.

Exacto, tienes que conectarte por ssh (por ejemplo) y arrancar el indiserver. Eso al principio, cuando lo tengas ya más o menos montado simplemente puedes poner que se ejecute indiserver como tarea al arranque (en sistemas tipo debian que usan el arranque clásico, bastaría con colocar la orden de indiserver en el rc.local).

¿Y cómo encontraré el servidor INDI desde el cliente? ¿por el puerto?

El puerto por defecto creo que es el 7624, la ip será la ip del servidor (lo puedes ver con un ifconfig). En un servidor lo suyo es configurar la IP como fija, aun en el caso de que te conectes por wifi.

Miguel