pludov
-
Compteur de contenus
57 -
Inscription
-
Dernière visite
Type de contenu
Profils
Forums
Téléchargements
Blogs
Boutique
Calendrier
Noctua
Messages posté(e)s par pludov
-
-
Hello, c'est au moins 45° en azimuth.
Pas besoin d'être très precis, le but est de viser des astres qui passeraient un peu au sud du zenith lors de leur culmination ( ça fait un grand cercle, donc plus précis )
-
Le 26/01/2020 à 10:38, Daube-sonne a dit :
C'est celui-là que j'ai https://s.click.aliexpress.com/e/2ePqC1rw
Ce circuit semble avoir quelques défauts (en tout cas la version dispo sur amazon): https://www.amazon.fr/Hilitand-convertisseur-dalimentation-Ajustable-Converter/dp/B07DNHXWV5/ref=sr_1_fkmr1_1?__mk_fr_FR=ÅMÅŽÕÑ&keywords=DC-DC+10A+Step+Down+Regulator+Module+60V+36V+24V+12V+to+24V+12V&qid=1581874973&sr=8-1-fkmr1#customerReviews
-
Hello,
L'astrometrie sert effectivement a améliorer la précision du pointage (sync de la monture), et elle peut aussi servir pour affiner le cadrage : dans l'onglet camera (tout à gauche), une fois une photo résolue par astrometrie, tu peux faire "centrer ici" par un clic droit / appuis long, et ça va centrer le télescope à cet endroit.
Pour le framing, tu peux afficher la fwhm moyenne d'une image (encore clic droit/ appuis long dans l'onglet camera. Il n'y a pas (encore) de mode continu.
L'onglet focuser est utile si tu as un focuseur motorisé : il fait simplement le scan d'une plage et trouve la meilleure fwhm.
-
Mobindi est un logiciel permettant de piloter une séance d'astrophoto (ciel profond) depuis un mobile ou une tablette.
Je travaille sur Mobindi en hobby depuis 2 ans, au début pour ma stricte utilisation personnelle, puis plus récemment en Open Source.
Le but est d'avoir une interface simple, concentrée sur des fonctionnalités bien supportées. L'accès à Mobindi depuis le mobile se fait via un navigateur Chrome ou Firefox.
Les principales fonctions sont :
* le controles des cameras (paramétrage, prise de vue)
* la visualisation des prise de vue (fits) avec une ergonomie particulièrement adaptée au mobile, niveaux, fwhm, ...
* le support des roues à filtres (automatiques et manuelles)
* le support des focuser avec une mise au point automatique
* un sequenceur de prises de vues (images, dark, flat, ...)
* l'autoguidage avec Phd (choix de l'étoile guide, dithering, ...)
* l'astrometrie pour affiner le pointage de la monture
* l'utilisation du GPS du mobile pour la localisation de l'observatoire
* un outil d'aide à l'alignement polaire
* un control Panel INDI complet permettant d'accéder à toutes les propriétés des drivers
* des notifications "push" pour vous informer du succès d'une séquence ou des problèmes éventuels.
* peut etre utilisé depuis plusieurs terminaux en même tempsContrairement aux solutions qui sont basées sur l'utilisation de VNC ou de Remote Controle, Mobindi fourni une ergonomie directement pensée pour l'écran d'un mobile, avec une interface simplifiée et réactive.
Néanmoins, le pilotage en lui même n'est pas effectué par votre mobile, ce qui permet d'économiser la batterie de votre mobile en l'éteignant pendant les séquence de photo.
C'est également très utile pour éviter qu'un problème de wifi ou de réseau n'interrompe votre session photo !Pour fonctionner, Mobindi communique en Wifi avec un Raspberry PI installé sur le téléscope (ou tout autre nano ordinateur, comme une tinkerboard).
Le Raspberry héberge un logiciel de pilotage qui va communiquer avec à la monture, les caméra et autres équipements, via le protocole INDI. Utiliser INDI permet d'avoir la richesse des drivers et la réactivité de la communauté.Mobindi est compatible avec la plupart des distributions dédiées à l'astro sur miniordinateur (stellarmate, nafabox, ...), il est même installé par défaut sur les dernières versions de la Nafabox!
Il est prévu pour être utilisé comme outil principal, mais est aussi utile en complément de kstar/ekos/phd2 (par exemple, pour pouvoir depuis son mobile inspecter les FITS résultants des captures, ou suivre les performances de l'autoguidage)
Il y a quelques fonctions qui sont encore manquantes de mon point de vue, avant d'avoir une expérience complète:
* le pointage du téléscope. Il y a pas mal de client INDI qui peuvent le faire. SkySafari peut-etre utilisé depuis le tel mobile via un driver INDI, ça marche bien !
* la configuration initiale: il faut installer et configurer INDI et PHD avant de pouvoir utiliser Mobindi. Mais normalement, on ne fait ça qu'une fois 🙂Enfin, c'est 100% OpenSource, vous pouvez donc aussi contribuer, pas uniquement avec du code, mais aussi avec des idées !
Tous les détails par ici: https://github.com/pludov/mobindi
L'interface de prise de vue:
L'interface pour l'autoguidage:
-
3
-
6
-
-
Vous avez tester les écrans pour ces systems genre celui la sur amazon.
Quimat Raspberry Pi 3 Écran,LCD TFT 3,5 pouces Compatible Raspberry Pi3 2 Modèle B B+ A A+,Touch Screen for Raspberry Pi.
Est-ce fonctionnel?
J'ai essayé egalement de brancher un ecran un peu plus grand : 6 pouces, 800x480 hdmi. Au final ca marchait mais la tinker board est capricieuse en hdmi : il fallait parfois plusieurs boot pour que lecran fonctionne!
-
Pour ma part, ça pendouille encore, mais une pointure de mon club d'astro a fabriqué une queue d'aronde super bien foutue :
astro.kizix.org/gestion-du-cablage-suite-un-boitier-informatise/
Avec du temps, je ferais bien ce genre de truc.
En effet, c'est un chouette montage, et le résultat est vraiment propre !
-
Hello !
Je me pose une question mécanique/pratique que tout le monde à du se poser sur ce fil: où installer la carte tinker board ?
J'avais pensé à :
* Sous ma lunette, dans le prolongement de la queue d'arronde. l'orientation par rapport au téléscope ne bouge pas, du coup on connait à l'avance la taille de la pluspart des cables. Et c'est facile à monter. Mais ça alourdi le tout ~ 400g
* Sur l'axe du contrepoid. Je pense que c'est aussi fixe par rapport au téléscope, et cette fois on gagne le poids... Pourquoi pas mettre les batteries aussi ?
* Sur la tete de la monture (sur l'axe horaire). Sur l'heq5 ce serait sur le coté donc pas super symétrique
* Au niveau du trepied en mode raquette (trés facile à mettre en place mais ça allonge les fils...)
Et vous, qu'avez vous choisi ?
Ludovic
-
Biensur, avec plaisir !
Merci c'est top ;-)Tu m'autorises à reprendre ton tuto et à l'intégrer dans la doc ?
-
Il faudra peut-être juste modifier le device tree blob (dtb). Mais je ne sais pas si on peut forcer le noyau a ne pas utiliser le rtc builtin...
Super voilà encore un truc important de réglé !J'ai exploré le fichier de conf du kernel 4.14 qui permet de produire l'image nightly actuel de armbian pour tinkerboard. La ligne qui active le RTC ds1307 est bien active mais la ligne pour le RK808 aussi. Je vais en brancher un pour voir ce que ça donne et si je le voie dans le dmesg.
-
Pour ceux qui seraient intéressés par l'ajout d'une horloge RTC sur la tinker board (par exemple, si votre lieux d'observation n'a pas de réseau...), il existe des petits modules DS3231 prêts à brancher et vraiment pas chers (par exemple http://www.ebay.fr/itm/Precision-New-DS3231-RTC-Module-Memory-Module-for-Arduino-Raspberry-Pi-/400786764495 )
J'ai écrit un mini tuto sur la configuration de ces petites bềtes sur la tinker board:
https://pludov.blogspot.fr/2017/10/asus-tinker-board-mettons-les-pendules.html
Ludovic
-
Oui gehelem, j'étais tombé sur ce soft (en cherchant une lib indi pour nodejs...) mais je n'avais pas réussi à le faire tourner (à cause de dépendances avec des versions de librairies python ou swig, ...).
-
Hello,
J'ai un peu avancé sur le projet d'interface simplifiée : J'ai pas mal travaillé sur les briques techniques de bases (de la tuyauterie pas très visible...), mais le fonctionnel commence maintenant à s'étoffer:
J'ai créé un équivalent du INDI control panel, et du coté du guidage PHD2, on peut démarrer/arrêter, et il y a maintenant un graph de suivi en temps réél.
La prochaine étape sera certainement d'afficher une capture (ccd ou guider) puis une séquence.
J'ai partagé tout ça ici: https://github.com/pludov/iphd
-
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.
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 !
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
-
Ç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.
- action en cours - calibration, guidage, dithering,
-
Je pensais plutôt à un lacerta mgen dopé aux hormones avec de l'astromerie et la gestion d'un focuser !
-
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)
-
Après plusieurs mois de dev et d'ajustement divers, je pense avoir fini la partie logiciel : J'ai écrit une petite interface pour garder les fonctions sous la main, ainsi qu'un driver ASCOM qui s'y connecte.
En effet, le "moule" du driver ASCOM ne permet pas facilement d'avoir des fonctions en plus comme l'affichage du chauffage, de l'état de la batterie, ...
Sa ressemble à ça:
Je réfléchi maintenant à motoriser sur le même principe une roue à filtre...
Les détails sont ici: http://pludov.blogspot.fr/2016/01/focuser-arduino-interface-et-driver.html
-
Hello,
Je me suis réalisé une motorisation de mise au point basée sur un Arduino et un moteur BYJ48 (celui à 2€ sur ebay...) Au passage, j'ai ajouté un circuit de contrôle de chauffage anti-buée - pour économiser de la batterie -, et un voltmètre pour avoir l'état de la dite batterie :-)
La partie mécanique est plutot spécifique à mon téléscope INTES (mise au point un peu comme les SC, mais sans shifting...), mais le reste pourra certainement resservir à d'autres !
Tous les détails (circuits, code source, ...) sont ici : http://pludov.blogspot.fr/
Ludovic
-
C'est une reprise : ma précédente photo remonte exactement à un an !
Le temps pour moi de bricoler un focuser motorisé à base de Arduino...
Il n'est pas encore complètement mis à profit sur cette image, car la MAP a bougé en cours de route plus que ce que je m'attendais... mais le gain de temps est déjà appréciable, et je vais pouvoir automatiser tout ça maintenant !
Il y a également un problème dans les coins gauches, peut-être du à l'alignement entre le diviseur et l'axe.
Les détails : 3h de pose en LRVB (1h40 de L + 30min par couche)
Imageur: Atik 428ex sur Intes M503 (125/1250) réduit à FD/8 (focale résultante ~1000)
Monture: HEQ5
Traitement: DSS et PixInsight
-
En effet, l'interface est encore trop "brouillon" pour être prise en main intuitivement; il y a même quelques menus qui ne servent à rien.
La vidéo est une bonne idée, il faut juste que je trouve le temps!
Ludovic
-
Hello,
Sous OSX (et Linux), l'interface va bien se lancer, mais ce qui dépend d'autres librairies va certainement echouer:
- pour la monture, il faut ASCOM
- pour la synthèse vocale, c'est le moteur de Windows
- pour l'astrométrie, j'ai inclu l'exe astrometry.net pour windows (mais celui-là, il ne doit pas être trop compliqué à recompiler...)
Ludovic
Bonjour Ludovic,J'ai fait toute la procédure d'installation sans problème, hier soir, sur un iMac de 2006, sous OS X Lion sans aucun problème, je teste sur la monture quand il arrêtera de pleuvoir !!
-
Hello
Je développe depuis quelques années un logiciel d'aide à la mise en route d'une session d'astrophoto, notamment en itinérant, et j'ai décidé de partager :-)
Son but est de gagner en efficacité sur les principales étapes d'une séance d'astrophoto (CCD ou APN) :
- Mise au point (calcul de FWHM, graph d'évolution)
- Sync par astrométrie (via ASCOM et l'excellent moteur Astrometry.net, embarqué)
- Mise en station fine
- Aide au (re)cadrage manuel
- Recherche d'étoiles guide
- Suivi de paramètres pendant les pauses
L'ergonomie permet d'utiliser le logiciel avec le téléscope à quelques metres du PC, sans avoir à faire des aller-retour incessants (lecture vocale des indication, pilotage partiel au joystick, ...)
Il ne s'agit pas d'un logiciel de prise de vue; il va plutot collaborer avec (notamment APT)
Le logiciel est développé en Java et devrait donc pouvoir tourner sur tous les OS. Mais pour l'instant, il fonctionne à 100% uniquement sous Windows.
Il est dans un état "alpha"; c'est à dire qu'il marche chez moi avec mon setup, ... :-)
Enfin, j'ai également publié le code source; toutes les bonnes volontés seront bienvenues !
La suite est ici: http://pludov.free.fr/20141012-ScopeExpress.html
Ludovic
- Mise au point (calcul de FWHM, graph d'évolution)
-
Bonjour,
J'image avec un Mak INTES (M500 à F10, un Rumak), et depuis peu une CCD avec un petit capteur (Atik 428ex).
Avec cette CCD, le champ est vraiment petit (échantillonnage à 0.75''); du coup je cherche un réducteur de focale.
Comme mon champ est censé être plat, j'ai d'abord essayé avec un réducteur Antares x0.5 (à 35€...), mais j'ai des déformations assez importantes en dehors du centre.
Il y en a d'autres qui semblent plus sérieux (à en juger par leurs prix...) :
- CCDT67 x0.67 http://www.teleskop-express.de/shop/product_info.php/info/p4955_Astro-Physics-CCDT67-0-67x-Reducer-2----e-g--for-GSO-RC.html
Mais je n'ai pas d’élément pour les comparer. Notamment, pour le INTES, le backfocus à l'air d'être beaucoup moins contraint; ça doit indiquer une formule optique différente...
Est-ce que quelqu'un a un retour d’expérience sur un de ces réducteurs avec une optique similaire (champ plat) ?
Ludovic
-
Bonjour, j'ai peut être ça en stock... Elle ressemble à quoi ta monture ?
Logiciel d'aide à l'astrophoto : ScopeExpress
dans Logiciels
Posté
Hello,
Il faut avoir assez d'étoile détectées pour que l'astrometrie resolve le champ. Ca marche bien a partir de 10-15. Souvent je suis au dela de 100. (Ca depend essentiellement de la duree d'expo , du f/d et de la taille du capteur )
Si tu prends juste une photo, avec un appui long dans l'image , tu a un menu "fwhm", qui permet d'avoir le nombre d'étoiles détectées. Tu peux ajuster tes parametres ici pour obtenir assez d'étoiles...