Contrôle setup astrophotographie nomade

Sebriviere · 7 juillet 2017

Rmor51,

Pas possible, les bonnes résolutions c'est janvier seulement.

Tu as vu cette partie de la doc?

https://lroge.scenari-community.org/nafa/co/SetRes.html

Es-tu connecté a ton Dell en HDMI?

patdut · 7 juillet 2017

J'ai gravé l'image sur une SDCard. Problème, l'écran étant un Dell 22", j'ai un message d'erreur comme quoi la résolution n'est pas prise en compte par celui-ci.
Où change-t-on la résolution dans ce système SVP ?

As-tu au moins un affichage quand tu est connectes à l'écran ?

C'est quoi la résolution de ton écran ?

Tu peux changer ta résolution dans le centre de contrôle d'ubuntu-mate.

Ensuite comme le précise Seb si tu veux adapter la résolution à ton terminal de contrôle tu passe par l'utilitaire alors que ton Tinkerboard ou RPi n'est pas relié à un écran (sur le RPi je n'ai pas encore vérifié que cela fonctionne bien).

rmor51 · 7 juillet 2017

Aucun affichage, juste le message d'inadéquation. Donc pas de système. J'ai cherché le config.txt dans /boot mais y a pas ! J'ai un peu farfouillé dans les fichiers de /boot sans résultat.

Non je n'ai pas lu la doc comme un utilisateur de base standard Donc il est branché en HDMI.

De toute façon dans la procédure d'install par l'archive rien n'est dit à ce sujet.

Le Dell 22" est en 1600x1200, je ne suis pas devant.

Modifié 7 juillet 2017 par rmor51

patdut · 7 juillet 2017

Aucun affichage, juste le message d'inadéquation. Donc pas de système. J'ai cherché le config.txt dans /boot mais y a pas ! J'ai un peu farfouillé dans les fichiers de /boot sans résultat.

Non je n'ai pas lu la doc comme un utilisateur de base standard Donc il est branché en HDMI.

De toute façon dans la procédure d'install par l'archive rien n'est dit à ce sujet.

Le Dell 22" est en 1600x1200, je ne suis pas devant.

C'est dès le départ quand tu installe l'image Armbian que ça ne fonctionne pas ?

rmor51 · 7 juillet 2017

Exact. C'est l'image NAFA.

Modifié 7 juillet 2017 par rmor51

patdut · 8 juillet 2017

Exact. C'est l'image NAFA.

Ça c'est plus ennuyeux. As-tu un autre moniteur pour tester?

Peut-être sur une télé.

Je n'ai hélas pas sous la main de moniteur 1600x1200 pour tester.

Je pense que c'est le serveur X qui merde.

As-tu essayé de faire un CTR+ALT+F1 pour voir déjà si le boot arrive au bout ?

pludov · 14 juillet 2017

Ce projet est super intéressant ! Voilà un bonne raison d'acheter la tinkerboard ...

Est-ce que les scripts d'install sur GitHub resteront à jour par rapport aux images pré-installées ?

J'ai eu pas mal de mauvaise expériences avec les hub USB... Vous utilisez quel modèle ?

Dans l'idéal, j'aimerais me passer autant que possible de tablette sur le terrain... Pensez-vous qu'il serait facile de scripter Ekos et compagnie pour qu'ils soit contrôlables avec une interface réduite à quelques boutons et un LCD dédié ?

Je pense par exemple à des rendre directement accessible : lancer l'autoguidage, démarrer une séquence, lancer une astrométrie, arreter le système ... en gardant l'accès VNC pour les besoins plus "avancés"...

En tout cas, si je serais ravis de contribuer d'une manière ou d'une autre ! (je suis développeur et je connais bien Linux)

kiwi74 · 14 juillet 2017

Oh que oui c'est un super projet !

J'ai reçu mon Tinkerboard il y a 2 jours. Dès que j'ai un peu de temps je fais les essais !

Sebriviere · 14 juillet 2017

Dans l'idéal, j'aimerais me passer autant que possible de tablette sur le terrain... Pensez-vous qu'il serait facile de scripter Ekos et compagnie pour qu'ils soit contrôlables avec une interface réduite à quelques boutons et un LCD dédié ?

Je pense par exemple à des rendre directement accessible : lancer l'autoguidage, démarrer une séquence, lancer une astrométrie, arrêter le système ... en gardant l'accès VNC pour les besoins plus "avancés"...

En tout cas, si je serais ravis de contribuer d'une manière ou d'une autre ! (je suis développeur et je connais bien Linux)

Pludov, tu serais pas entrain de vouloir faire un Starbook 10 (Vixen) de la Nafa?

https://www.vixenoptics.com/Vixen-STAR-BOOK-TEN-Controller-p/36919.htm

pludov · 14 juillet 2017

Je pensais plutôt à un lacerta mgen dopé aux hormones avec de l'astromerie et la gestion d'un focuser !

https://www.pierro-astro.com/materiel-astronomique/autoguidage/kit-autonome-lacerta-mgen-ii-superguider_detail

Argonothe · 14 juillet 2017

@pludov,

En tout premier merci pour ta proposition d'aide, tu es le bien venu, Padut à ouvert un Github, tu peux y contribuer directement, tu peux aussi prendre contact avec Patdut, c'est lui qui gère la partie dev.

En ce qui concerne l'utilisation d'un LCD, dédié, la principale limitation est liée au résolutions disponibles, en effet l'utilitaire d'Ekos pour la mise en station, qui est redoutablement efficasse nécessite un minimum de visibilité et l'interface d'Ekos une résolution conséquence...

L'option tablette est à mon sens la meilleure. Reste qu'il est aussi possible d'utiliser son smartphone, s'il dispose de la bonne résolution, de plus avec le pintch and zoom ça le fait bien ;-).

L'affichage est utile, pour la mise en station, mettre en route l'autoguidage,déclencher la prise de vue (qui a été préalablement préparée à la maison) et ensuite de temps en temps vérifier le déroulement, c'est donc possible avec un téléphone...

patdut · 14 juillet 2017

Ce projet est super intéressant ! Voilà un bonne raison d'acheter la tinkerboard ...

Est-ce que les scripts d'install sur GitHub resteront à jour par rapport aux images pré-installées ?

J'ai eu pas mal de mauvaise expériences avec les hub USB... Vous utilisez quel modèle ?

Dans l'idéal, j'aimerais me passer autant que possible de tablette sur le terrain... Pensez-vous qu'il serait facile de scripter Ekos et compagnie pour qu'ils soit contrôlables avec une interface réduite à quelques boutons et un LCD dédié ?

Je pense par exemple à des rendre directement accessible : lancer l'autoguidage, démarrer une séquence, lancer une astrométrie, arreter le système ... en gardant l'accès VNC pour les besoins plus "avancés"...

En tout cas, si je serais ravis de contribuer d'une manière ou d'une autre ! (je suis développeur et je connais bien Linux)

Ça c'est un projet super intéressant. Il pourrait trouver sa place dans le cadre de l'initiative INDI. Je vais demander à Jasem Mutlaq s'ils ont envisagé de scripter Ekos. Kstars est déjà scripté alors why not....

L'autre solution serait de créer un client INDI. Mais je ne suis pas sûr que ce soit la bonne solution.

Toutefois, le premier boulot c'est de définir ce que l'on met dans une interface minimale. Je suis prêt à en discuter avec toi.

David6813 · 16 juillet 2017

Bonjour,

Quel boulot fantastique ! Bravo !

Je cherchais justement des infos sur la possibilité d'adapter un mini PC / stick PC (mais sur Win 10) sur mon set up en itinérant lorsque je suis tombé sur ce topic. Je suis très impressionné par les capacités de ce "petit machin" mais mes connaissances de tout autre OS hors Windows sont = 0. Cependant le coup de l'investissement semble raisonnable et le travaille réalisé pour démocratiser l'utilisation est sensationnel !!

Mon set up actuel utilise un PC portable utilisant la platforme ASCOM (comme beaucoup !). J'utilise BYE, PHD, ainsi que les drivers ASCOM pour mon focuser. Est ce que la NAFAbox utilise ASCOM ou est ce que la plateforme integrée sur la Tinker prends tout en charge ? De plus pour mon alignement polaire j'utilise PoleMaster (QHY) via un soft dédié dont je suis tres satisfait. Est ce possible de continuer a utiliser PoleMaster avec la Tinker ? Enfin concernant la sauvegarde des data, vous recommandez une mini SD rapide.. est ce plus rapide qu'un HD de plus grosse capacité branché sur le Hub USB ?

Merci d'avance pour les réponses a mes questions qui peuvent sembler basique !

Argonothe · 16 juillet 2017

@David6813

En ce qui concerne la connaissance de l'OS, nous avons choisi un gestionnaire de fenêtres (Maté) simple, facile à comprendre et utiliser. Donc tu devrais très facilement franchir le pas.

Tu vas retrouver PHD2 qui est très stable sous Linux ;-)

Pour le reste et bien c'est l'ensemble Kstars/Indi/Ekos qui fais le job, on peut même se passer de PHD2.

Le logiciel pour le PoleMaster n'est pas utilisable sous Linux,en revanche, tu vas retrouver

qui est une tuerie. Il utilise soit ton APN, soit ta caméra, est redoutable d'efficassité, de simplicité et de rapidité.

En ce qui concerne la sauvegarde des données, tu peux brancher un HDD en USB, la rapidité est suffisante pour la sauvegarde des données.

Nous faisons un effort important pour la partie documentation afin que vous puissiez d'une part faire facilement la transition vers un environnement Linux, d'autre part utiliser les logiciels qui existent dans celui-ci.

David6813 · 16 juillet 2017

Merci pour le retour rapide !

Ca a l'air canon, je vais me lancer et essayer !!

L’investissement est plus que raisonnable...

Quel type de boitier tu utilises pour protéger la carte ? Quelque chose d’étanche, en alu ?

Si ca ne convient pas, je pourrais toujours revenir sur mon ancien set up via mon PC...

Encore un fois félicitation pour ce travail et le partage !

:wave2:

David6813 · 16 juillet 2017

Commentaire supplémentaire : je viens de regarder le lien video sur l'alignement polaire par Ekos : c'est le meme principe que PoleMaster : determination de l'axe de rotation mécanique de la monture par rotation successives pour la détermination de l'alignement polaire.

Je soupçonne la methode Ekos encore plus précise que celle de Polemaster car basée sur le Plate solving et pas simplement de la superposition du profil des etoiles peri-polaire sur le champ de la cam !

Argonothe · 16 juillet 2017

Commentaire supplémentaire : je viens de regarder le lien video sur l'alignement polaire par Ekos : c'est le meme principe que PoleMaster : determination de l'axe de rotation mécanique de la monture par rotation successives pour la détermination de l'alignement polaire.
Je soupçonne la methode Ekos encore plus précise que celle de Polemaster car basée sur le Plate solving et pas simplement de la superposition du profil des etoiles peri-polaire sur le champ de la cam !

Oui c'est vraiment très précis :-)

Pour le boîtier, j'ai repris celui en plastique de mon PI2, pas de boîtier en métal, car cela limite fortement la portée du Wifi (cage de faraday).

Donc un boîtier en plastique pour PI assez aéré est parfait, pas de risque de condensation, la carte chauffe bien ;-)

Modifié 16 juillet 2017 par Argonothe

pludov · 16 juillet 2017

Ça c'est un projet super intéressant. Il pourrait trouver sa place dans le cadre de l'initiative INDI. Je vais demander à Jasem Mutlaq s'ils ont envisagé de scripter Ekos. Kstars est déjà scripté alors why not....
L'autre solution serait de créer un client INDI. Mais je ne suis pas sûr que ce soit la bonne solution.

Toutefois, le premier boulot c'est de définir ce que l'on met dans une interface minimale. Je suis prêt à en discuter avec toi.

Pour moi (mon besoin perso...) le minimum c'est l'autoguidage et le contrôle de l'APN/CCD avec dithering.

Concernant l'autoguidage, l'interface doit présenter :

action en cours - calibration, guidage, dithering,
qualité du suivi,
SNR de l'étoile guide
Tout messages d'erreur éventuel

Et les prises de vues:

avancement des pauses,
progression de la pause en cours,
au moins la FWHM sur la derniere photo prise
De nouveau tout messages d'erreur éventuel

Physiquement, ça pourrait passer par un afficheur 20x2 caractères, mais je préfererais un mini écran HDMI (Il y a des 5'' en 800x480 à 30€ sur ebay...). Ce dernier permettrait une interface nettement plus sympa visuellement.

En terme d'architecture, j'ai pensé à une interface HTML basée sur React. D'un coté, un process exposerait en HTTP un état en JSON, plus quelques points d'entrées pour les commandes, et de l'autre coté l'interface REACT lit l'état et se met à jour en conséquence.

Les forces de cette archi:

* on dispose de la puissance d'un navigateur pour l'affichage (responsive design !). ça évite d'avoir à écrire du code pour le rendu, l'adaptation aux résolutions des écrans, ...

* l'ihm est aussi simple à développer (il y a pléthore d'outils pour faire du HTML/CSS...)

* exactement le même code permet d'afficher la même interface en http déporté (sur un tel mobile ou une tablette)

* En cas d'utilisation remote, ça peut être très fluide (car il n'y a pas de volume important, juste l'état de l'application)

* Techniquement c'est évolutif, on peut pousser plus loin (pré-visualisation des captures par exemples)

Les faiblesses:

* l'affichage sur un écran local nécessitera de faire tourner un navigateur (en mode "kiosk"). Il faut regarder le coût minimum en RAM... (mais d'expérience, chrome passe déjà bien avec un RPI3 qui n'a que 1Go)

* il faut que les applis scriptées se prettent bien à l'exposition de leur état (en fait qu'elles aient une notion d'état suffisamment claire)

J'ai commencé un petit prototype avec OpenPHD. Pour l'instant, j'ai une petite application qui utilise l'interface de notification de PHD pour tenir à jour l'"action en cours". Il me reste à écrire le client qui va afficher ça avec un bouton pour démarrer le guidage.

patdut · 16 juillet 2017

Pour moi (mon besoin perso...) le minimum c'est l'autoguidage et le contrôle de l'APN/CCD avec dithering.

Concernant l'autoguidage, l'interface doit présenter :

action en cours - calibration, guidage, dithering,

qualité du suivi,

SNR de l'étoile guide

Tout messages d'erreur éventuel

Et les prises de vues:

avancement des pauses,

progression de la pause en cours,

au moins la FWHM sur la derniere photo prise

De nouveau tout messages d'erreur éventuel

Physiquement, ça pourrait passer par un afficheur 20x2 caractères, mais je préfererais un mini écran HDMI (Il y a des 5'' en 800x480 à 30€ sur ebay...). Ce dernier permettrait une interface nettement plus sympa visuellement.

En terme d'architecture, j'ai pensé à une interface HTML basée sur React. D'un coté, un process exposerait en HTTP un état en JSON, plus quelques points d'entrées pour les commandes, et de l'autre coté l'interface REACT lit l'état et se met à jour en conséquence.

Les forces de cette archi:

* on dispose de la puissance d'un navigateur pour l'affichage (responsive design !). ça évite d'avoir à écrire du code pour le rendu, l'adaptation aux résolutions des écrans, ...

* l'ihm est aussi simple à développer (il y a pléthore d'outils pour faire du HTML/CSS...)

* exactement le même code permet d'afficher la même interface en http déporté (sur un tel mobile ou une tablette)

* En cas d'utilisation remote, ça peut être très fluide (car il n'y a pas de volume important, juste l'état de l'application)

* Techniquement c'est évolutif, on peut pousser plus loin (pré-visualisation des captures par exemples)

Les faiblesses:

* l'affichage sur un écran local nécessitera de faire tourner un navigateur (en mode "kiosk"). Il faut regarder le coût minimum en RAM... (mais d'expérience, chrome passe déjà bien avec un RPI3 qui n'a que 1Go)

* il faut que les applis scriptées se prettent bien à l'exposition de leur état (en fait qu'elles aient une notion d'état suffisamment claire)

J'ai commencé un petit prototype avec OpenPHD. Pour l'instant, j'ai une petite application qui utilise l'interface de notification de PHD pour tenir à jour l'"action en cours". Il me reste à écrire le client qui va afficher ça avec un bouton pour démarrer le guidage.

C'est très très intéressant ça. J'ai posé à Jasem Mutlaq la question de savoir si Ekos pouvait être scripté. Sa réponse est que tout est envisageable étant donné que les process utilisent un protocole de communication DSUB. Maintenant reste à voir si ça peut s'insérer dans ta démarche.

Je pensais que ce pouvait être une bonne solution pour éviter de sortir l'artillerie lourde. Mais j'avoue que sur ce protocole j'ai tout à apprendre et donc pour l'instant je n'ai qu'une vague idée de ce qu'il conviendrait de faire pour créer cette interface minimale.

http://indilib.org/support/tutorials/148-dbus-scripting-with-kstars-python.html

https://api.kde.org/4.x-api/kdeedu-apidocs/kstars/html/#Scripting

gehelem · 19 juillet 2017

Salut a tous

Je me suis permis un petit signalement sur le forum indilib sur un fil ou il est justement question de la Tinker

Le forumeur a utilisé les scripts, mais il a des questions avec ... le desktop français!

http://indilib.org/forum/general/2393-indi-and-kstars-running-on-asus-tinker-board.html#17961

Modifié 19 juillet 2017 par gehelem

patdut · 19 juillet 2017

@gehelem

J'ai fait une réponse au gars Petarm. J'espère que ça va fonctionner pour lui.

Comme ça on aura la communauté anglophone avec nous .

Sebriviere · 19 juillet 2017

Nos réponses avec Patdut s'y sont croisées....

on va voir ce qu'il nous raconte...

gehelem · 19 juillet 2017

C'est chouette, merci à tous les deux

pludov · 19 juillet 2017

C'est très très intéressant ça. J'ai posé à Jasem Mutlaq la question de savoir si Ekos pouvait être scripté. Sa réponse est que tout est envisageable étant donné que les process utilisent un protocole de communication DSUB. Maintenant reste à voir si ça peut s'insérer dans ta démarche.
Je pensais que ce pouvait être une bonne solution pour éviter de sortir l'artillerie lourde. Mais j'avoue que sur ce protocole j'ai tout à apprendre et donc pour l'instant je n'ai qu'une vague idée de ce qu'il conviendrait de faire pour créer cette interface minimale.

http://indilib.org/support/tutorials/148-dbus-scripting-with-kstars-python.html

https://api.kde.org/4.x-api/kdeedu-apidocs/kstars/html/#Scripting

Merci pour ces docs! C'est déjà pas mal, mais il manque pleins de choses pour espérer faire une interface sympa ( beaucoup d'infos pas accessibles, pas de notifications, ...)

J'ai contacté Jasem Mutlaq... il est emballé, mais sa réponse (en gros) c'est que j'ai qu'à tout coder ! :cry:

Entrer dans le code d'Ekos, c'est vraiment pas la route la plus simple pour un petit projet comme ça...

J'ai donc continué mon proto autours de PHD2. ça commence à prendre forme: j'ai un process qui fourni l'interface HTML et celle ci est mise à jour en live. Il me reste à lancer phd automatiquement et j'aurai un autoguider autonome :cool:

patdut · 19 juillet 2017

Merci pour ces docs! C'est déjà pas mal, mais il manque pleins de choses pour espérer faire une interface sympa ( beaucoup d'infos pas accessibles, pas de notifications, ...)
J'ai contacté Jasem Mutlaq... il est emballé, mais sa réponse (en gros) c'est que j'ai qu'à tout coder !

C'est souvent la réponse que fait Jasem. Sauf quand il s'agit d'améliorations qui concernent Ekos.

Je le comprends car il a déjà un énorme boulot à consolider l'ensemble de l'édifice. Ekos est vraiment un monument.

Ceci dit, ton interface est beau et clean.

De mon côté j'ai survolé DSUB. Ça semble tout à fait abordable. Cela nécessite de lancer kstars en background et permet de prendre la main sur presque tout. Mais là, je n'ai pas pu juger du périmètre de fonctions couvert.

Je ne suis pas aussi catégorique que toi. Je pense qu'on peut faire l'essentiel avec l'interface et si tu présente bien à Jasem l'idée d'ouvrir un peu plus l'interface avec Ekos de sorte qu'il considère que c'est une amélioration je pense qu'il le fera.

Je pense aussi qu'il faut préciser ton besoin pour qu'il puisse agir.

Modifié 19 juillet 2017 par patdut

Argonothe · 19 juillet 2017

@pludov

Je rejoins complètement PatDut, en plus cela peu avoir un intérêt pour Jasem si cela peu compléter son StellarMate ;-)

gehelem · 19 juillet 2017

petit partage autour d'un première simulation décevante

J'ai été obligé de trouver un peu de temps pour au moins brancher mon asi178mm toute neuve

J'ai donc sorti l'artillerie dans le salon

odroid tout seul, avec la cam dessus pour voir si ça marchait.

Et comme les enfants ne sont pas là, j'ai enfin pu avoir la tablette (vieille) pour moi tout seul.

J'ai essayé pour la première fois une session distante avec la tablette.

Je suis assez déçu de cette expérience :

mes gros doigts, la réactivité, la prise en main sans doute aussi, nom d'un chien que c'est difficile de cliquer avec les doigts... et alors saisir des valeurs au clavier virtuel, pfff...

IL faut que je persévère un peu, mais je pense que je vais rester un moment avec mon vieux laptop pour faire ça.

c'est peut-être lié à ma façon de faire aussi :

ma vieille tablette ne permet pas d'installer l'appli vnc, et de plus je préfère utiliser RDP.

Du coup je pense vraiment pour pouvoir utiliser sereinement une tablette, il faudrait une appli dédiée...

A peine conscient de l'énormité que je viens d'écrire (voir vos échanges ci-dessus), je vais pas trop la ramener.

Bonnes soirées,

Gilles.

Projectsoft · 20 juillet 2017

Félicitations aux initiateurs de ce superbe projet, j'en ai l'eau à la bouche et presque envie de me jeter ... à l'eau!

Question matériel: le Tinkerboard peut se mettre dans n'importe quel boitier Raspberry pour le protéger? Les ports ont-ils les même emplacement?

Avez-vous un lien d'achat à me proposer?

A titre d'exemple, qu'utilisez-vous comme batterie externe? (marque / modèle)

Totalement nomade, j'utilise pour le moment une batterie 12V 17A.

Config actuelle: Nikon D5600 + Lacerta motorfocus + Lacerta Mgen pour l'autoguidage

Sous peu, je souhaiterai passer avec une ASI 1600 + roue à filtre + guidage au diviseur optique

Oui, il me faudra une batterie plus performante et faire une création à ma sauce pour pouvoir ajouter prise allume-cigare et hub alimenté.

M'étant renseigné sur le net, j'ai très bien vu les caméras ZWO et roue à filtre fonctionner.

Mais maintenant pour mon focuser robotisé ...

Si je comprends bien les pilotes ASCOM (Windows) = pilotes INDI (Linux)

Donc si des pilotes ne sont pas créés pour Linux, le focuseur ne sera pas fonctionnel (corrigez-moi si je me trompe)

Dans ce cas, vers qui me tourner pour la compatibilité du Lacerta Motorfocus avec Ekos?

> Demander le développeur de fournir les infos à Jasem pour qu'il le créé?

Quelqu'un utilise un focuseur automatisé? Si oui lequel? Cela fonctionne bien sous Ekos?

gehelem · 20 juillet 2017

Oui, tu as aussi tout un tas de drivers pour les focuser

Perso j'utilise le driver moonlite, avec un focuser diy

Argonothe · 20 juillet 2017

Question matériel: le Tinkerboard peut se mettre dans n'importe quel boitier Raspberry pour le protéger? Les ports ont-ils les même emplacement?

Avez-vous un lien d'achat à me proposer?

A titre d'exemple, qu'utilisez-vous comme batterie externe? (marque / modèle)

Bonjour,

Tu trouveras ici les liens pour la tinkerboard,le premier lien est toujours à 60 €, le second sur amazon à un prix variable... En ce qui concerne le boîtier, c'est un boîtier pour PI, le form factor est stritement identique à celui du PI, prends en un en plastique pas en métal qui limite la portée du wifi (cage de faraday).

Pour la batterie, j'utilise une batterie pour téléphone portable de 10800 mA/h avec une sortie de 2.1 A, fait attention toutes n'ont pas cette puissance de sortie, et pour la monture j'ai un booster.

Bonne journée,

Connexion

Contrôle setup astrophotographie nomade

Messages recommandés

Les pipelettes du sujet

Les pipelettes du sujet

Messages populaires (du sujet)

dragonlost

kiwi74

Traou Mad

Images postées dans ce sujet

En ligne récemment 0 membre est en ligne

Annonces

Aider Webastro

Information importante