kope2008

Bonjour à tous,

Désolé par avance de la longueur de mon message
Je m'appelle Frédéric, j'habite sur la région parisienne, pas vraiment nouveau sur le forum mais je ne trouve pas souvent le temps de poster.

J'ai commencé à prendre en main Kstars il y a 2 ans, inspiré notamment pas Patdut bien connu sur le forum à qui je passe le bonjour 😉. Je remercie également tous les généreux créateurs et contributeurs (je pense notamment à Gehelem) de ce super logiciel

Avec quelques partenaires et amis nous avons décidé de monter un projet de télescope en remote au Chili. Pour le moment nous sommes en phase de test, les conditions actuelles que tout le monde connait font que le projet a pris du retard, mais les tests avancent, aussi je voulais partager mon expérience, qui intéressera peut-être d'autres utilisateurs qui recherchent des solutions viables pour leur station fixe (ou non) ou qui ont comme nous le projet d'installer leur matériel sous des cieux plus propices

Voici la liste du matériel que nous utilisons:
- FSQ-106
- Caméra Moravian G3-16200 + roue à filtre 
- DO Skymeca avec bague à tilt
- Caméra de guidage Lodestar
- Focuser Pegasus Cube V2
- Monture EQ8-R (à venir), pour le moment les tests s'effectuent sur une Avalon (avec le protocole EQmod)
- Flip Flat Optec
- mini PC NUC sous Ubuntu Mate
- disque-dur réseau (NAS)
- Armoire électrique à base d'IPS-800 V4

Ce qu'aujourd'hui nous avons réussi à tester et réaliser (je suis à jour de la dernière version Kstars) :
- reconnaissance complète du matériel par Indi
- alignement polaire automatique de kstars
- flats automatisés avec prise en charge de l'ouverture du flip-flat
- mise au point avec sélection d'étoile automatique et refocus toutes les x heures. Tests en cours avec la sonde de température
- astrométrie avec le nouveau processus Stellar Solver (très performant !)
- reprise de capture à partir de la résolution astrométrique d'une image précédente (fonction "Load eand Slew")
- renversement au méridien (avec refocus, astrometrie, recalibration et reguidage !)

La  connexion à distance au mini PC se fait en utilisant Nomachine (en réseau local ou distant) ou Anydesk (en réseau distant)

Et après avoir réussi à mettre tout ça au point de manière indépendante, j'ai décidé de tester l'utilisation du Scheduler, donc automatisation complète d'une séance de l'allumage du PC jusqu'à la mise hors tension, le but étant de programmer sa séance à l'avance et ... d'aller se coucher !

Les seules tâches à effectuer en amont :
- Programmer la séquence complète sur le différents filtres + les flats
- Inclure cette séquence dans l'outil de planification (Scheduler)
- Préciser l'objet à imager
- Entrer l'heure de début

- une petite tisane et au lit !

A l'heure indiquée, le processus suivant se déroule :
- la monture est déparkée
- ouverture du flip-flat
- pointage vers l'objet à imager
- sélection du filtre et mise au point
- astrométrie
- lancement de la séquence
- basculement au méridien
- refocus automatique selon scénario choisi

A la fin de la séquence :
- fermeture et allumage du flip-flat et réalisation des flats
- park de la monture
- refroidissement de la caméra
- mise hors tension du matériel

D'autre part à la fin du process il y a possibilité de lancer un script. J'en ai réalisé un qui se charge de récupérer toutes les images, les zipper dans un dossier, copier ce dossier en local + sur le disque-dur NAS. Les images peuvent ainsi être récupérées en local chez soi 

J'ai créé un autre script de surveillance (donc qui tourne en permanence) chargé de surveiller les arrivées régulières des photos sur le disque, si je constate qu'il n'y a plus de mouvement durant x minutes le script envoie un mail d'alerte, il suffit d'activer les notifications sur son téléphone afin d'être prévenu (et réveillé !) de l'anomalie. Il y a une fonction "watchdog" sous Kstars mais pas encore compris son fonctionnement

Aujourd'hui quasiment tout ce process est fonctionnel et a été testé (y compris sur un nuit complète). L'armoire électrique est terminée (merci à mon ami Laurent 😉 ) mais nous n'avons pas encore pu la valider, compte tenu de sa réalisation soignée je ne me fais pas de souci sur son fonctionnement. Il me restera à inclure dans le script les commandes de mise hors tension du matériel (ça doit être jouable avec l'IPX-800)

Voilà, beaucoup d'heures de mise au point comme vous l'imaginez. Si vous avez des questions, si vous souhaitez avoir d'avantage de précision sur tout ça, si vous avez le même genre de projet ou si vous avez juste envie d'échanger sur le sujet n'hésitez pas et de mon côté je suis bien-sûr preneur de toutes vos suggestions et conseils

Bon week-end

Frédéric

Je parle bien d'avoir installé la librairie libqhy (et non pas qhyccd comme j'avais mis dans mon précédent message):

sudo apt-get install libqhy

après un update et un upgrade, et je n'ai pas eu de message m'indiquant que la lib était déjà installée. Comme je disais je n'ai pas eu besoin de faire cette manip sur mon PC Ubuntu où la qhy5LII  a marché tout de suite. C'est peut-être lié à la façon dont j'ai installé la Nafabox sur la RPI.

Hier j'ai finalement pu essayer le Canon 60D çà marche bien. Par contre pas le 350D mais j'ai lu après coup qu'il fallait passer par gphoto pour le déclenchement, je referai d'autres essais.

N'hésite pas si tu as besoin que je fasse d'autres tests, nous avons pas mal de matériel à mon club.  Vendredi prochain j'essaye une monture CG5 et donc une qhy5II (je suis confiant !)

Fred

Merci Dragonlost pour ta réponse

Tu parles du paramètre Accuracy, c'est çà ? J'ai laissé la valeur par défaut (30) qui fonctionne très bien pour une résolution "normale", aussi je ne comprends pas pourquoi çà ne marche aussi bien après un renversement au méridien ou une résolution sur une image  précédente (ce qui finalement correspond au même process j'imagine puisqu'après un renversement au méridien Kstars doit récupérer l'image précédente pour faire une résolution dessus, du moins c'est comme çà que je l'imagine)

Je vais essayer de jouer sur ce paramètre accuracy

Bonne soirée

Oui en fait je ne suis pas sûr de la manip qui l'a fait vraiment marcher sur la RPI puisque:

- j'ai fais un upgrade qui a permis de récupérer notamment les derniers drivers qhy de la nouvelle version Indi

- j'ai installé la librairie qhyccd (ce que visiblement je n'avais pas fait). Il semble que sur l'installe de mon PC Ubunut64 l'installation de Indi inclus la librairie qhy, ce qui n'est pas le cas sur l'image nafabox à installer  sur la Raspberry

En tout cas maintenant la QHY5LII fonctionne. Je confirmerai que c'est également le cas avec la QHY5II, je sais que ces deux caméras sont quand même largement utilisées

Pour info, j'ai testé le matériel suivant avec succès sur Raspberry (je passe systématiquement par un Hub alimenté):

- Caméra Atik One (avec roue à filtre intégrée et caméra d'autoguidage Atik GP): fonctionne sans problème sur le Raspberry, en revanche sur mon PC Ubuntu Mate lorsque je démarre Ekos la roue à filtre se met à tourner sans fin. Le seul remède que j'ai trouvé: démarrer une seul fois la caméra sous Windows et ensuite relancer linux (oui c'est un peu reloud mais à terme je serai sur RPI !). J'ai essayé de la connecter avant le démarrage de Linux, après, avant le démarrage de Ksatrs, etc..mais sans succès

- Focuser Hitecastro DC Focus

- Caméra Atik 314L

- Caméra Atik  8300

- Nikon D750 

- monture EQ6 et HEQ5 avec module bluetooth de fabrication personnelle

- monture EQ8

- qhy5LII donc

Prochainement: Canon 60D, Canon 350D, USB FOCUSER V2

C'est tout pour le moment !

Fred

Bonjour Gelehem

Je suis confronté à un petit souçi sous Kstars. Je l'utilise sous Ubuntu Mate 64bits avec succès, notamment l’astrométrie est très précise mais lorsque j'ai testé le renversement au méridien (qui réexécute bien toutes les phases de l’astrométrie à la reprise de guidage) OU la reprise d'une photo ("Load and slew") j'ai un décalage de plusieurs dizaines de pixels entre mon image initial (avant renversement) et l'image résultante après l'astrométrie (qui pourtant indique "successful" assez rapidement) . J'ai bien noté que Slew to Target effectuait une synchro sur la nouvelles positions (j'ai bien coché toutes les cases Auto Update dans les Solver Options) donc aucune raison que çà ne marche pas puisque l'astrométrie directe fonctionne parfaitement. Sans doute une mauvaise manip de ma part mais j'ai pas trouvé dans les tutos et les vidéos

Une idée ?

Merci d'avance

Fred

Salut Dragonlost et Gehelem

Je viens d'essayer sous Ubuntu Mate 64bits par dépôt de fit manuel dans le répertoire de scan, çà marche nickel !

Encore un super boulot, bravo à tous les deux  ! Dés que la normalisation de l'image stackée sera implémentée, j'y vois déjà un intérêt énorme.

Par exemple nous recevons régulièrement du public à notre club, notamment des jeunes, ce sera la possibilité de leur monter "facilement" un objet du ciel profond  (un peu comme du visuel assisté) difficile à voir en visuel, sans parler de pouvoir suivre ses acquisitions en live sur le terrain. J'attends la suite avec impatience 🙂. Et peut-être une intégration dans Kstars ?

 Fred

Bonjour dragonlost,

Merci pour ta réponse. Effectivement c'était un problème de librairie, que j'ai finalement résolu

Bonne journée

Frédéric

Bonjour à tous,

Sujet mainte fois remonté mais je m'y perds un peu dans toutes les solutions (ou non-solutions) proposées.

Je possède une qhy5LII que j'ai testé avec succès sous kstars - indi en stand alone sur mon PC linux Ubunutu Mate. En revanche quand je tente de la faire fonctionner sur mon RPI 3b+ sur lequel j'ai installé la Nafabox également sous Ubuntu Mate j'ai un crash de la qhy au démarrage (il retente 10 fois la connexion avant d’échouer):

C'est surtout le "error while loading shared libraries: ..." qui m'interpelle

Je précise que je suis à jour (upadte & upgrade en date du 26/06/19)

Y a t'il une solution simple ou est-ce lié directement à un problème de driver qhy (qui semble t'il est en train d'évoluer en ce moment) ?

Merci pour votre aide

[2019-06-26T20:02:31.948 CEST DEBG ][           org.kde.kstars.indi] - INDI Server:  "2019-06-26T18:02:31: Driver indi_qhy_ccd: stderr EOF"
[2019-06-26T20:02:31.948 CEST DEBG ][           org.kde.kstars.indi] - INDI Server:  "Child process 2949 died"
[2019-06-26T20:02:31.949 CEST DEBG ][           org.kde.kstars.indi] - INDI Server:  "2019-06-26T18:02:31: Driver indi_qhy_ccd: restart #10"
[2019-06-26T20:02:31.949 CEST DEBG ][           org.kde.kstars.indi] - INDI Server:  "2019-06-26T18:02:31: Driver indi_qhy_ccd: pid=2950 rfd=5 wfd=11 efd=12"
[2019-06-26T20:02:31.949 CEST DEBG ][           org.kde.kstars.indi] - INDI Server:  "2019-06-26T18:02:31: Driver indi_qhy_ccd: indi_qhy_ccd: error while loading shared libraries: libqhyccd.so.5: cannot open shared object file: No such file or directory"

...
[2019-06-26T20:02:31.949 CEST DEBG ][           org.kde.kstars.indi] - INDI Server:  "2019-06-26T18:02:31: Driver indi_qhy_ccd: stderr EOF"
[2019-06-26T20:02:31.949 CEST DEBG ][           org.kde.kstars.indi] - INDI Server:  "Child process 2950 died"
[2019-06-26T20:02:31.949 CEST DEBG ][           org.kde.kstars.indi] - INDI Server:  "2019-06-26T18:02:31: Driver indi_qhy_ccd: Terminated after #10 restarts."
[2019-06-26T20:02:31.949 CEST DEBG ][           org.kde.kstars.indi] - INDI Server:  ""
[2019-06-26T20:02:31.950 CEST CRIT ][           org.kde.kstars.indi] - INDI driver  "indi_qhy_ccd"  crashed!

Frédéric

Oui la solution avec systemd est très certainement plus propre puisque le système se charge de démarrer et d'arrêter les services. Je m'y pencherai

Merci !

Problème résolu.

Sur les dernières versions d'Ubuntu il n'y a plus de fichier script /etc/rc.local chargé de lancer les process au démarrage. Je l'ai donc recréé et ajouté au lancement en utilisant l'outil "Application au démarrage" (impossible de le faire en ligne de commande)

Maintenant ma liaison bluetooth démarre bien dés la fin du boot de la Raspberry et j'ai directement la main sur ma monture.

Cette méthode doit fonctionner pour n'importe quel script à lancer au démarrage, si çà peut intéresser du monde...

Fred 

Bonjour Pat,

Merci pour ta réponse

Oui c'est exactement çà et j'ai bien modifié le main.conf comme indiqué avec:

AutoEnable = true

DiscoverableTimeout = 0

mais je n'arrive pas à obtenir la connexion automatiquement.

Je pense que l'appairage est effectif dés le début puisqu'il suffit que je lie l'adresse mac  avec le rfcomm0 avec la commande:

rfcomm bind rfcomm0 mac_adress 

pour que j'arrive à prendre la main avec Indi et ensuite piloter la monture correctement

Dans la page https://wiki.archlinux.org/index.php/bluetooth ils précisent bien que pour lancer automatiquement la connexion au boot il suffit de mettre 

AutoEnable = true dans le main.conf du coup je ne comprends pas trop...

Fred

Bonjour à tous,

Je me présente, Frédéric, nouvellement inscrit sur le forum. J'ai décidé de ma lancer dans l'aventure Nafabox. J'ai donc installé Ubuntu Mate sur une RPI3 et je suis parvenu à tout faire fonctionner en remote avec un PC distant également sous Ubuntu Mate grâce notamment au tutoriel et support de Patdut.

Aujourd'hui je suis plutôt confronté à un problème Linux. Jusqu'à présent ma RPI était connecté à ma monture avec un câble Pierro-astro et çà fonctionne parfaitement. Afin de gagner encore un câble je tente maintenant de connecter Indi à un module Eqtooth de fabrication personnel. Le module fonctionne, pour l'essayer j'ai suivi l'explication très simple dans les trucs et astuces de http://nafabox.linux-astro.fr

Problème, je souhaiterai bien-sûr automatiser la connexion BT au démarrage de la Raspberry sans être obligé de m'y connecter à chaque fois avec nomachine pour entrer la commande. J'ai tenté plusieurs choses:

1 - créer un script :