EROS (lite) : soft pour utiliser ses pilotes ASCOM en réseau

[obsbp 0]

Bonjour,

L'Observatoire des Baronnies Provençales vous présente son dernier né : E-SCOP Remote Observatory Service (E-SCOP, Service d'Observatoire Distant).

Suite à nos travaux informatiques et astronomiques liés au site LightBuckets.com, nous avons développé un outils permettant de faire transiter les commandes ASCOM via du réseau TCP/IP.
Ce petit outils nous permet de commander des télescopes complets (comprendre par là monture, caméras, focuseur...) situés sur différents sites physiques et de les partager au travers d'une application web.

Nous avons pour notre activité une version très spécifique mais nous nous sommes dit qu'il serait intéressant pour la communauté astro de faire une version plus générale et abordable d'utilisation. Ainsi nous vous proposons pour l'instant la version simplifiée et gratuite de cet outils : EROS Lite.

Dans les grandes lignes, il permet déporter et de partager les pilotes (drivers) ASCOM sur un réseau dit TCP/IP (celui qu'utilise Internet et, à priori, celui que vous utilisez chez vous) à l'aide de deux outils distincts.

Un premier outils s'installe sur un ordinateur à côté du télescope, dans l'observatoire. Il se connecte au matériel comme n'importe quel logiciel utilisant ASCOM. Puis, il met ce même matériel à disposition sur un réseau.
Un deuxième outils, qui se trouve être un ensemble de pilotes ASCOM gérant depuis la monture jusqu'au dôme, s'installe lui sur l'ordinateur où vous voulez utiliser votre matériel. Après un rapide tour dans la configuration, votre logiciel favori se connecte à ces pilotes ASCOM qui font suivre chaque demande générée par le logiciel au premier outils. Ce dernier exécute les demandes et renvoie les résultats au demandeur. Votre logiciel d'astronomie reçoit enfin les résultats sans même savoir que des communications réseaux ont lieu.

Une première "pré"version corrigée, la 0.9.1, est disponible à cet endroit :
http://research.lightbuckets.com/eros/ (puis "Downloads", à noter que le site hébergeant EROS est en construction)
Un article est disponible ici :
http://www.obs-bp.com/article-ascom-sous-tcp-ip-120887662.html

Ces outils sont pour l'instant disponibles pour MS-Windows avec la plateforme ASCOM d'installée. A terme une version Linux (ainsi que BSD, et donc Apple) est prévue afin d'étendre les possibilités d'ASCOM au delà des environnements Microsoft.

Aussi, des versions beaucoup plus évoluées (dites 'pro' et 'corp' pour professionnel et entreprise) sont en cours de développement. Elles permettront, entre autre, de piloter à distance la plupart des logiciels d'astronomie (comme MaxIM ou TheSky), de sécuriser les liaisons réseaux, de faire du multi-serveur,...

En espérant que cela vous plaise,

Clear Skies ! (cieux limpides !)
L'équipe de l'Observatoire des Baronnies Provençales (http://www.obs-bp.com/)

Remerciements au Webmaster d'Astrosurf pour l'autorisation de la publication de ce message.

[Ce message a été modifié par obsbp (Édité le 06-11-2013).]

[obsbp 0]

Une explication du protocole en image :

Du coté Ascom serveur, les instruments physiquement connectés
et du coté Ascom client la connexion aux instruments se faisant à travers
le réseau TCP/IP, Internet.

Deux PC peuvent donc être en relation distante et faire dialoguer les materiels d'un coté, avec les logiciels compatibles Ascom de l'autre coté.

Marc

[Ce message a été modifié par obsbp (Édité le 05-11-2013).]

[Alexandre Cucculelli 398]

Intéressant , merci pour nous ..!

@lex.

[Ce message a été modifié par Alexandre Cucculelli (Édité le 05-11-2013).]

[frédogoto 2 093]

+1 bravo car c'est vraiment pas simple a faire, mais mais vous allez rendre service a bcp de gens qui pourrons maintenant s’interroger sur la le choix entre le pilotage via ascom sur tcp/ip ou prise en main a distance ^^

[Leforgeron 22]

Bonsoir.

Très intéressant en effet merci. Il ne reste plus qu'a configurer le réseau. Et avec une LiveBox mini grrrr ! :-(
Déjà avec team viewer ça arrive a décrocher.

Si le serveur est en XP et le client en W7 cela fonctionne t-il ?
Bravo pour le boulot.

Régis.

[obsbp 0]

Bonsoir,

Oui cela fonctionne indépendamment du système d'exploitation coté serveur ou client, c'est le protocole Ascom qui transite donc on se libère des problématiques purement de versions windows par exemple.

Cela offre en effet une possibilité nouvelle de s'affranchir de la prise en main à distance pour tous les softs astro qui gèrent
ascom et ils sont très nombreux.

Marc

[Ce message a été modifié par obsbp (Édité le 05-11-2013).]

[astrovicking 902]

Et bien Merci!
J'avoue être agréablement surpris!

[Laurent51 2 850]

Beau travail!!
J'ai quand même une question:
je vois très bien pour du matériel du type motorisation du télescope, une roue à filtre, le dôme... mais pour une camera CCD, ca veux dire qu'obligatoirement il y a transfert des images vers le PC client en temps réel?..; si c'est le cas, par internet, ca va bloque avec le volume des images...
récupérer les images en tache de fond, pas de problème, mais en temps réel, ce n'est pas jouable à mon avis, sauf a être sur un réseau Gigabit entre le salon et l'observatoire. Je pense que vous avez pensez à ce type de problème avec une sauvegarde des images sur le PC serveur.

Cordialement,
Laurent Bernasconi

[obsbp 0]

Bonsoir Laurent,

oui en effet pour les images CCD, elles peuvent aussi transiter par le voie des airs et donc soumises alors au débit des différents fournisseurs d'accès. Mais la encore cela passe correctement si les images ne sont pas, disons trop lourdes.

Guillaume nous fera un petit débriefing la dessus demain, il a fait pas mal de tests la dessus il nous en dira plus ...

Marc,

[obsbp 0]

Bonjour,

1) interopérabilité
(@regis paret)

Il n'y a aucune contrainte de système. Le serveur et le client peuvent être indifféremment du windows xp, vista... 32 ou 64bits. Les deux morceaux de l'outils sont d'ailleurs en 32bits.
Une version Linux est même opérationnelle pour nos tests, en particulier pour la partie caméra, sur les drivers dits 'V4L' (video for linux). Linux offrant une meilleur gestion réseau et permettant de travailler sur des outils en temps réel (au sens informatique du terme), il est pour nous très important d'avoir un outils qui s'affranchit des systèmes... d'autant que le 820 de l'observatoire, fabriqué par Astelco, fonctionne sous Linux, tout comme le serveur web de LightBuckets. Sans compter la profusion d'outils automatisables qui existent dans cet environnement.
D'ailleurs, c'est un des intérêts d'EROS, un ordinateur sous Linux pourra accéder à du matériel disponible uniquement sous Windows et des drivers propriétaires, et vice versa.

2) réseau
(@régis paret)

Les livebox... tout un monde... J'intégrerai dans la documentation une marche à suivre pour configurer un outils formidable (gratuit et performant) : OpenVPN, qui permet de pallier à pas mal de problèmes de déconnexion mais aussi de crypter et compresser ses données réseau à la volée. Aussi, il n'est pas impossible de changer la livebox par un boitier adsl comme netgear ou linksys.

3) images et caméras
(@laurent51)

C'est une très bonne remarque. EROS est totalement dépendant du réseau, c'est au coeur de son fonctionnement.

Il est optimisé au niveau de la communication réseau (délais au plus court, tampons mémoires importants, contournement de certaines options windows). Il échange très vite les messages, d'autant plus qu'ils sont très courts en ce qui concerne l'ensemble des éléments du télescope (entre 64 et 128octets, entêtes réseaux comprises).
Cependant, pour les images, il est évident que le débit influe sur la rapidité d'échange. De plus, EROS Lite utilise un protocole sous jacent en mode texte, ce qui implique une conversion dite 'base64' (comme dans les emails, les annuaires LDAP...) qui augmente la taille de 33%, ce qui n'est pas rien, et nécessite un temps de calcul sur le serveur et le client. En plus ASCOM impose des images avec des 'entiers' où chaque pixel fait 32bits (4octets), même si vous avez une caméra 8, 12 ou 16bits...

Donc en effet, pour ce qui est du transfert des images il ne faut pas compter sur du temps réel pur, comme si on se situait à côté du télescope. Les tests menés ici sur un réseau 100mbps (soit 10Mo/s) et de vieux Pentium IV ont donné (pour une image d'une FLI 8300M) :
* 33Mo pour l'image, 44Mo une fois encodée en base64
* 6 sec de chargement et d'encodage sur le serveur
* 9 sec de transfert (environ 4 à 5Mo/s de débit effectif)
* 4 à 5 sec de décodage sur le client
Pour un total de 17sec (Prism indique des débits allant de 300 à 500ko/s) Les temps d'encodage varient en fonction de la puissance de l'ordinateur et de la taille de l'image.

Sur des liaisons internet 'pas très haut' débit, comme ma connexion personnelle (adsl 512/128), de telles images mettent beaucoup de temps à arriver (EROS a des paramètres de temps d'attente configurables). Mais sur une telle liaison, je ne peux pas utiliser Prism à distance (via remote desktop) de manière convenable, et encore moins dans des résolutions de 1600x1200 en 32bits, ce que me permet mon pc sous windows.
Il est sûr qu'il n'est pas possible sur de grosses images de demander, par exemple, des poses de 1sec toutes les secondes. Les contraintes dépendent bien du réseau : le débit et la latence. Quelques calculs sont donc à faire avant de se lancer tête baissée dans les captures.

A noter que la version pro devra intégrer le protocole d'échange en binaire (donc plus de conversion) et une option de compression (sans perte, type zip).
L'idée de pouvoir sauvegarder sur le serveur est intéressante et sera étudiée... il y aura une astuce à trouver pour tromper ASCOM du côté client (le fait de prendre une image et ne pas la recevoir n'est pas prévu dans ASCOM et EROS n'est prévu, à la base, que pour déporter les commandes ASCOM sur TCP/IP).

Bien cordialement,

Guillaume

(toute proposition et remarque constructive sont les bienvenues)

[Ce message a été modifié par obsbp (Édité le 06-11-2013).]

[jpg&mtl 57]

Je teste ça.

Cieux limpides

[bbdb 1]

bonjour

très intéressant. est-ce que par exemple on peut du coup avoir deux logiciels de planetarium connectés à la même monture, un en local et l'autre distant ?

disons que pour le guidage et l'acquisition j'aurais tendance à privilegier le remote desktop (teamviewer ou autre) pour ne pas prendre de risque cote latence, mais ca doit être bien plus confortable de faire le pointage à distance via cartes du ciel par exemple.

Bruno

[obsbp 0]

@bbdb

Oui.

Précisions : c'est possible mais le 'montage' choisi dépendra des pilotes ASCOM du matériel. En effet certains pilotes ne permettent pas d'avoir plusieurs logiciels simultanément connectés (en particulier tout ce qui concerne les ports séries (COM)). Dans ce cas, l'unique client possible sera EROS serveur et chaque logiciel devant se connecter au matériel passera par EROS Client. A savoir que EROS client et serveur peuvent cohabiter sur une même machine.

Bien entendu, il faudra veiller à ce que les commandes de contrôle ne se catapultent pas : si un client demande au scope d'aller sur la polaire pendant que l'autre demande orion... il y aura un problème. De même, si un client demande une pose de 600sec sur une caméra il est assez évident qu'un autre client ne pourra demander une pose ou un changement de binning, mais pourra quand même changer la température de refroidissement (bizarre mais c'est dû aux contraintes du standard ASCOM). Des possibilités de 'lock' (exclusivité d'utilisation) de matériel sont envisagées mais sortent du standard.

Dans la mesure où un seul logiciel pilote (c'est à dire 'écrit') et d'autres ne font que lire les données (position, température,...), cela n'entraine pas de contrainte particulière.

Guillaume

[Ce message a été modifié par obsbp (Édité le 06-11-2013).]

[Leforgeron 22]

Bonsoir.

Merci Guillaume pour ces infos. Je test pour voir si la live box tient le coup.

Cordialement.

Régis.

[jpg&mtl 57]

Guillaume,

Un mail pour te faire un CR de test?
JPG

[obsbp 0]

Bonsoir

alors pour ceux qui souhaitent nous faire un compte rendu de test
voici l'adresse info at obs-bp.com

Bon tests

Marc

[obsbp 0]

Merci pour les retours,

Vous pouvez m'écrire à gfe.escop AT gmail.com

Je suis plus réactif aux horaires de travail (c'est mon email professionnel) mais consulte cette boite mail de temps en temps à la maison.

Cordialement,

Guillaume

edit: ah... catapultage de commandes ! Carbon Copy si jamais

[Ce message a été modifié par obsbp (Édité le 06-11-2013).]

[dédé 34]

bonjour
Initiative sympa cette interface client serveur pour ascom.
Comment se comporte l'autooguidage , sans doute une des opérations les plus critiques en termes de ressources réseau puisqu'on doit rapatrier l'image du guideur, analyser celle ci et rénvoyer les corrections.
Ce lapse de temps sur l'aller retour ne doit pas être facile à maîtriser.

A titre d'information starlight mentionne sur son site le projet Jindi http://www.cloudmakers.eu/jindi

d'aprés ce que j'ai compris une interface style ascom muti platform, je crois aussi en client serveur.
ils ont aussi des drivers qui sont multi os, notamment linux, debian, mac OS. Pour l'instant ils sont compatible atik, starlight xpress, et shoestring .

Faut tester !

dédé

[obsbp 0]

@dédé

Pour Indi, des informations sont dispo ici (jINDI étant la partie en langage JAVA) : http://www.indilib.org/
On s'y intéresse fortement, il y a beaucoup d'idées derrière indi mais ce n'est pas encore mature (à mon avis). Nous avons des tests à mener de ce côté là et c'est, entre autre, à intégrer dans la version Linux d'Eros.

En fait, Eros se borne plus à être un protocol réseau qu'un ensemble de spécifications matérielle et logicielle (un peu comme l'est le HTTP pour le web). Les outils Eros Lite sont une mise en application de ce protocol. A ce titre les buts d'Indi ne sont pas les mêmes qu'Eros (le protocol).

Pour le guidage.

C'est en effet sensible et dépend des contraintes 'imposées'. Ca va être difficile de m'étendre à ce sujet car je n'ai pas pu encore faire tous les tests que je voulais (météo exécrable et de nombreux tests très différents à mener).

En gros, sur un LAN (réseau local) et avec de petites ccd (souvent le cas pour le guidage, voir même systématique) je ne pense pas qu'il y ait de problème. Eros (toujours dans la configuration avec les Pentium IV) est vraiment rapide. Les images d'une ccd de 640x480 occupent entre 1 et 2Mo : c'est encodé et décodé très rapidement, le transfert (en 100Mpbs) est aussi très rapide, les commandes de corrections partent très vite et sont petites. Eros doit prendre entre 1 et 2 secondes pour faire tout ça, et moins d'une seconde s'il s'agit d'images binnées. A moins d'une monture vraiment défectueuse ou d'une nécessité impérative de suivi parfait, les corrections devraient bien se passer...

Au conditionnel, il faut que nous vérifions cela. Au conditionnel aussi en ce qui concerne les connexions adsl qui rament ou encore les connexions satellites. Sans trop m'avancer, je ne pense pas qu'il y aura de problème pour guider la monture toutes les 5 à 10secondes (en LAN, c'est quasi sûr).

Guillaume

[obsbp 0]

Bonjour,

Une mise à jour est disponible (0.9.2) avec quelques corrections sur les commandes des 'rotateurs'.

Certains passages du code pour le réseau ont évolué. Il y a désormais moins d'attente dans les déconnexions et les arrêts brutaux, le débit a été amélioré aussi. Les derniers tests sur les transferts d'images ont donné une bande passante à 8Mo/s dans les meilleurs cas (testé avec MaximDL principalement) sur un réseau local relativement étendu (ethernet 100Mbps sur une trentaine de mètres, avec une passerelle intermédiaire).

Toujours disponible sur http://research.lightbuckets.com/eros/?lang=FR

Merci pour les retours qui nous ont été faits.

Bien cordialement,

Guillaume pour l'équipe de l'Observatoire des Baronnies Provençales.

[Ce message a été modifié par obsbp (Édité le 13-11-2013).]