crub

Bonjour, c'est quand même bizarre ces coins à droite très sombre sur les 3 premières images et pas sur la 4... Si c'est pas ta boite à flats, il y a un truc qui vignette très brutalement (soit) mais surtout asymétriquement.

Bonjour, tardif aussi, Le rapport entre le coût des solutions que tu évoque et le gain en champ est clairement en faveur d'un APN d'occasion (canon 1100D, sony a5000, ...)

Bon début, 4mn de pose à 55mm sur les relativement gros pixel du 450D, cela me semble comparable avec quand je fait 45 secondes à 200 mm avec un alpha 5000 (APSC 20 Mega pixels).

Voui, comme MCJC, un APN en APSC (sur le Mak, c'est au moins très bien sur la lune), et même avec un APN à 100 euro d'occaz et un vieux 200mm (payé moint de 50) en parallèle, tu peut faire ca:

Bonjour Morgatte. Essayons de séparer les problèmes: - c'est une monture équatoriale, donc l'axe horaire de la monture doit être alignée sur le pôle (pas sur la polaire qui est quand même un peu à coté. Tu utilise ce que tu veut pour ce faire, c'est pareil, mais pour que le reste se passe bien, il faut que ce soit soigné. A partir de là, avec une monture infiniment plus basique que la tienne, tu pointe un astre, tu enclenche le suivi, et l'astre reste à la même position dans le champ. - Pour le goto, la monture doit savoir où elle en est par rapport à la rotation de la terre, pour cela il lui faut soit - soit l'heure plus la longitude plus la verticale ou l'horizontale, - soit la direction d'une étoile connue (qu'elle connaît), et cela suffit à part que si elle ne connaît que cela, la monture ne connaît pas où se trouve l'horizon (pour avoir une approximation raisonnable de cette valeur, il suffit que la monture dispose de l'une des 3 informations précédentes). Pour une précision raisonnable, cette étoile doit être loin du pôle et pas trop bas. - la calibration, sauf abus de langage pas exclus à travers les traductions, il s'agit de préciser la valeur exacte de ses déplacements sur les 2 axes. C'est à dire, de préciser pour des moteurs pas à pas à combien de secondes d'arc sur le ciel correspond un pas moteur. Pour cela, il faut pointer 3 étoiles qui ne soient pas alignées. Je ne connais pas ta monture, mais je trouve surprenant qu'il faille effectuer cette opération à chaque utilisation pour un usage de débutant.

Le dépôt a été mis à jour ce 22 février. La doc html est aussi accessible ici: http://www.crubille.lautre.net/c_polar_align/ Bonjour, j'ai réalisé un petit logiciel pour l'aide à la mise en station en projetant une mire de la zone polaire sur une image. Le code est actuellement pour linux et utilise gphoto2. Pour l'instant, comme avec ce temps de m..., il a été très peu testé, je préfère l'envoyer par mail à des béta testeurs que de le mettre en ligne. Voici quelques captures d'écran pour le présenter: La première étape consiste à acquérir une photo de la zone polaire avec une rotation entre 30 et 90 degrés, le logiciel affiche immédiatement cette première image: La seconde étape consiste à orienter la monture pour que la photo soit raisonablement horizontale, le logiciel calcule lle centre de rotation et affiche la mire: Si une translation ne peut suffire pour mettre les étoiles à leur place, c'est que l'horizontalité n'est pas respectée ou que le PC n'est pas à l'heure ou que la longitude n'est pas réglée. On peut faire tourner la mire pour ajuster: On aligne: et on peut affiner en zoomant (à 100%):

Il y a maintenant une version en FRANÇAIS! Ceux qui s'indignaient de son absence peuvent donc tester et sont remercié d'avance pour leur retour. Puisqu'il faut se justifier, la langue naturelle du logiciel est en anglais pour des raisons de diffusion et de contribution au code mais aussi parce que le code inclus des emprunts à des logiciels libres écrits par des non francophones et que je n'envisageais pas de diffuser ce programme sans les en informer ou sans leur permettre de s'informer réellement sur ce qu'il y avais dedans. Ce n'est pas une révélation: les références à ces emprunts sont explicites dans les README et dans les copyrights en en-tête des fichiers. Ensuite, le coût pour moi de faire une version française n'est pas de traduire le baratin, mais d'implémenter une solution multilingues adaptée. C'est ce qui est fait maintenant, c'est très simple pour les langues qui utilisent l'alphabet latin.

Le 5000 est bien piloté avec gphoto2 sauf le liveview, d'après http://www.gphoto.org/proj/libgphoto2/support.php c'est pareil pour le 6000. Avec gphoto2, je peut faire des poses longues pilotées par le PC. Il peut aussi se piloter en wifi, soit avec les appli sony, mais celles ci n'ont pas bonne réputation, soit avec des logiciels androids comme c'est le cas sur les nex5R,5T, 6 et 7. Dans ce cas, les poses sont limitées à 30s au moins avec les applis sony. Si le 6000 est affublé du même problème de dark automatique en pose longue que le 5000, cela se règle en patchant l'APN. Je l'ai fait sur le mien.

J'ai fait une petite simu plus proche de mon projet: 255 mm à f5, le secondaire à 245mm du foyer, l'entrée du porte oculaire (50,8) à 110 mm du foyer ... il diaphragme le champ à 32mm! Et un secondaire à 70 mm va très bien, si il y en a un bientôt à vendre pas cher.

Ouh là ... 400 Ah!! Bon je me doit quand même de vous informer que pour intervenir - notamment, connecter/déconnecter des batteries de plus de 275Ah (voire peut être 180Ah si c'est considéré comme engin), il faut une habilitation électrique au moins B1T. Même en 12V, même un seul élément 3,2V! Dans un cadre strictement privé, vous faites ce que vous voulez, mais si il y a une utilisation associative, il faut être dans les clous. Même si le matos perso peut être seulement utilisé en présence de public, je ferais gaffe. Par ailleurs, si les réglementations électriques peuvent paraître bien tatillonne, elles ne sont pas totalement gratuite, et depuis Cloclo, répondent à des accidents qui ont vraiment eut lieu.

Bonjour jjc, oui, tu vas sur le git, tu récupère. Il te faut gphoto2 (pour t'en servir) et la jpeglib (pour compiler). Faut descendre un peu dans l'arborescence pour trouver les Makefile. Le Makefile est bon tel quel pour un ubuntu 20.

Bonjour Manup, j'enviseage un truc du même genre, mais sur une plateforme ARM - sympa comme projet, mais il y a du boulot... Pour la raquette, je pensait à celà: (version moderne en usb, mais l'arduino devrait pouvoir gérer la version originale). Pour les moteurs pas à pas, on est amené en fait à surdimensionner en effet, ces moteurs sont annoncés pour une tension à laquelle ils supportent d'être alimenté en continu et bloqué, la conséquence, dès que la vitesse de rotation augmente, l'intensité chute et le couple s'effondre. La solution c'est d'augmenter la tension - MAIS, il y a un MAIS (peut être 2): - à basse vitesse, il faut limiter la puissance typiquement en "hachant" le courant, normalement, c'est déjà fait pour limiter la consommation à ce qui est nécessaire, - consigne bloquée (avant que l'application ne contrôle le truc ou en cas de panne) le moteur crame (ou les transistors de commande). La solution est d'avoir un limiteur d'intensité. Comme c'est seulement une sécurité, on peut faire un limiteur linéaire.

Sans entretoise, si les pieds peuvent glisser, c'est l'articulation (ou la liaison rigide) haute qui encaisse la contrainte, si c'est une entretoise articulée (ou en câble), son intérêt est de reprendre cette contrainte, donc c'est utile et nécessaire si le truc en haut n'est pas très robuste. Si l'entretoise est rigide, et la liaison haute bloquée, on obtient une structure triangulée beaucoup plus rigide.

Il n'y a pas de raison qu'un capteur d'APN vieillisse plus vite en utilisation vidéos qu'un capteur de caméra de vidéo surveillance qui fonctionne 24h/24 et qui cumule en quelques semaines bien plus qu'un usage familial en quelques années. Par contre, les obturateurs mécaniques peuvent vieillir même quand ils servent peu (voir ne pas aimer du tout de ne pas déclencher pendant des mois). Toute l'électronique vieillie davantage en environnement chaud et humide et craint l'eau y comprit de condensation (par exemple en passant d'un extérieur glacial à un intérieur chaud et humide).

Pour la focale et le capteur, cela dépend aussi de l'utilisateur. Pour que cela soit confortable, c'est bien que polaris (pour le pole nord) ET le centre de rotation de la monture soient dans le champ pour les 2 premières images. J'ai fait les images ci dessus avec un 55mm et un capteur APSC cette condition est facile à vérifier (boussole et angle de latitude). La dernière image est zoomée à 100%, et la mire adaptée, cela correspond à ce que l'on aurais avec environ 300mm (et la mire comme l'image vont bien). Avec un 135, il faudrait faire un peu attention, avec un 200 bien plus (par exemple avoir des repères pour aligner l'axe optique et l'axe de la monture et avoir un viseur point rouge pour viser la polaire. Avec un capteur 24x36, et un 135mm, c'est sans problème. Après directement au foyer d'un instrument, si le tube est bien sur l'axe, que tu vise quand même assez près du pôle pour qu'il soit dans le champ ou très près du bord, la limite est le catalogue d'étoile. Actuellement, avec un APSC et 800 mm de focale (soit environ 1200 pour un 24x36), la mire comprend entre 3 et 6 étoiles autour de pôle. A mon avis, au delà de 500mm sur un APSC et de 800mm pour un 24x35, c'est chaud.

Oui Mehdi, c'est exactement cela. La détection de la rotation est purement géométrique. L'inconvénient, c'est qu'il n'y a pas d'autocalibration de la focale ... Cela pourrait s'arranger par une astrométrie très limitée. Le logiciel étant libre, chacun peut participer et m'envoyer un patch y compris pour avoir les messages en français. Après, si il y a plusieurs UTILISATEURS qui veulent une adaptation, je peux m'en occuper.

Voici le git pour accéder au code. git clone https://gitlab.utc.fr/crubille/polar_align.git Le dépôt a été mis à jour ce 22 février. Il y a maintenant un support multi langue et une version française et une doc plus complète dans le répertoire HTML qui précise notamment la connexion à l'APN. La doc html est aussi accessible ici: http://www.crubille.lautre.net/c_polar_align/

Bonjour, une solution est d'utiliser une bague d'adaptation pas de vis filtre photo de l'objectif vers le pas de vis filtre 2 pouces. Selon le diamètre de l'objectif, cela peut diaphragmer (par exemple sur un 200f4, la lentille frontale fait 50mm, tandis que le filtre fait 44mm, le 200 passe à f4,5). https://www.astronome.fr/produit-g30a193-bague-d-adaptation-geoptik-58mm-vers-48mm-Prix-20-euro-id-2086.html J'en ais aussi une en 49mm vers 48mm.

Le BMS surveille la tension de chacune des cellules (4 pour une 12V) et arrête la charge de chaque cellule individuellement. A la décharge, il lève une alarme voire coupe le débit quand la tension de la cellule devient critique. Je donne des valeurs de tension de tête, mais c'est assez proche. Lors de la charge, la tension monte très linéairement entre 12V et 14V, puis augmente très vite pour les derniers % de charge. En fin de charge à 100%, chacune des 4 cellules est à 3,7V soit en série 14,8V. Le chargeur doit donc ne pas dépasser cette tension. Mais sans BMS, si l'une des cellules était un peu moins déchargée, elle atteint les 3,7V avant les autres, ensuite, si la charge se poursuit, sa tension monte très vite, à 14,8V, il est ainsi possible que 3 cellules soit à 3,5V et la plus en avance à 4,3V. Hors il ne faut absolument pas dépasser 4,2V sous peine de destruction de la cellule (sans risque d'incendie contrairement à des LIPO, mais quand même HS).

Bonsoir à tous. Les batteries plomb c'est une capacité disponible de 50% de la capacité nominale pour ne pas avoir un vieillissement accéléré même pour les "décharge profonde". Sur un onduleur, c'est pas tous les jours que la coupure secteur dure si longtemps (ou que le groupe ne démarre pas). Les LIPO, il faut être bien scrupuleux sur les conditions de charge/décharge et d'environnement (c'est trucs là se vengent si on les maltraite). Lifepo4, capacité disponible de 80% du nominal (donc une 35Ah équivaut à une 55Ah en plomb), mais les contraintes de charges doivent être respectées pour chacune des cellules (4 pour une "12V"). Or les courbes de charge/décharge sont très plates dans l'intervalle [100-20] % de charge mais monte très vite en charge dès les 100% atteints et s'effondre juste en dessous de 20%. C'est pour cela qu'il est conseillé d'avoir un "BMS" qui contrôle individuellement les cellules et les équilibre. A défaut, il faut vérifier périodiquement qu'elles sont équilibrées.

Ce système ne nécessite pas de voir la polaire, mais par contre de voir le ciel autour du pôle. La polaire peut être masquée par le bord d'un toit ou un nuage. Higgins: non, il faut prendre plusieurs photos pour calibrer le système, notamment déterminer le point de l'image correspondant au centre de rotation de la monture, après on prend une image entre 2 corrections.

Concernant les barillets, est ce que quelqu'un a déjà essayer de faire un barillet à 4 ou à 12 points (avec un balancier évidemment)? En jouant avec plop (il faut jouer car il faut un peu lui expliquer ce que l'on veut), celui ci dit que cela marche plutôt bien: Un autre avantage est la simplicité de réalisation.

Lepithec, Si tu ne voit pas le pôle mais que tu vois le ciel assez près du ciel, mon algo doit marcher. Si on ne voit pas le pôle ni sa région, la solution classique est d'observer la dérive .... donc, c'est long. Avec un capteur, ce que l'on peut faire, c'est accélérer le truc: - on peut photographier 2 étoiles ayant la même déclinaison en passant de l'une à l'autre en ne touchant qu'à l'axe AD. On observe la différence entre la position de la seconde par rapport à où elle devrait pouvoir se trouver. On interprète cette différence comme une erreur de mise en station. - En fait, les 2 étoiles ont seulement une déclinaison voisine, et il faut aussi déterminer l'orientation du cliché. Soit il faut une autre étoile, soit astrométrie. Avec un grand champ (au moins 20 degrés), on peut aussi faire un filé en accéléré d'un bord à l'autre pour fournir une seconde donnée.

A mon avis, si tu as beaucoup de gradient sans le filtre, c'est un indice que la pollution lumineuse dégrade le rapport signal/bruit. C'est donc mieux avec.

Maintenant, si la question est le fonctionnement de l'algorithme, le seul point à discuter est le calcul du centre de rotation de l'image. Chaque étoile présente dans les 2 images apparaît dans ces images sur un cercle passant par ce centre de rotation. Les positions de cette étoile dans les 2 images forment un segment dont la bissectrice est un rayon de ce cercle. Si on prend toutes les étoiles présentent dans les 2 images, toutes les bissectrices ainsi calculées convergent en un point. Prenons un exemple: j'ai 100 étoiles commune dans mes 2 images, chacune définit une droite bissectrice de l'arc qu'elle a parcourue entre les 2. Chacune de ces droites va intersecter 99 autres bissectrices issues chacune de l'arc parcourue par l'une des autres étoiles et toutes au même endroit. Maintenant, pour chercher ce point particulier, je considère tous les segments définit en prenant la position d'une étoile dans la première image et la position d'une étoile de la deuxième image et pour chaque paire de ces segments, je calcule l'intersection de leur bissectrice. Le pb, c'est qu 'il y en a beaucoup dès que le nombre d'étoiles que l'on considère augmente un peu: le nombre de segment est le produit des nombres d'étoiles des 2 images, et le nombre d'intersections à calculer est la moitié du carré de ce nombre de segment (pour 100 étoiles, cela fait 50 millions, pour 1000 étoiles cela fait 500 milliards!), heureusement, on peut élaguer: - d'abord, on va ne garder que les étoiles les plus lumineuses (ce sont aussi celles pour lesquelles les algos de détection d'étoiles vont trouver la position le plus précisément). On peut choisir ce nombre, mais mieux vaut en garder le plus possible tant que l'algo tourne assez vite pour notre usage. - ensuite, si je trouve une intersection, si les proportions "longueur du segment/rayon" sont différente entre les 2 génératrice, cela ne peut être produit par la même rotation ("rayon" étant la distance entre les positions de l'étoile et le point intersection); ces intersections sont éliminées. - expérimentalement, on s’aperçoit que de nombreuses intersections parasites correspondent à des rapports rayon/longueurs du segment très petit (proche de 0,5). En excluant les très grandes rotations de la procédure, on peut aussi exclure ces valeurs. Pour donner un exemple réel des intersections calculées pour 1 étoiles de la première image et pour 2 de la deuxième par l'algo sur 2 images (les précédentes ou des analogues): first star is (3972.93, 2129.69) Premier segment versus tous les autres: 1.50454 = corde/rayon X=2776.86 Y=988.258 3.32683 = corde/rayon X=1963.35 Y=700.802 1.50262 = corde/rayon X=2768.7 Y=985.372 2.96778 = corde/rayon X=2069.5 Y=738.354 1.46451 = corde/rayon X=2791.43 Y=993.403 1.64102 = corde/rayon X=2701.7 Y=961.701 1.23809 = corde/rayon X=5463.22 Y=1937.45 2.9213 = corde/rayon X=6290.62 Y=2229.8 4.21426 = corde/rayon X=1632.47 Y=583.903 1.7564 = corde/rayon X=5774.91 Y=2047.58 0.902434 = corde/rayon X=3172.75 Y=1128.14 1.09811 = corde/rayon X=3009.77 Y=1070.55 1.78539 = corde/rayon X=2604 Y=927.179 1.79308 = corde/rayon X=5803.26 Y=2057.6 1.46129 = corde/rayon X=5598.27 Y=1985.16 4.24669 = corde/rayon X=1666.9 Y=596.068 1.48327 = corde/rayon X=2787.27 Y=991.934 Second segment versus tous les autres (Quelqu'un a un doute que l'on est sur le bon?) 3.9585 = corde/rayon X=3463.86 Y=1962.69 4.01096 = corde/rayon X=3458.65 Y=1962.37 3.98657 = corde/rayon X=3460.46 Y=1962.49 4.01166 = corde/rayon X=3461.38 Y=1962.54 4.01023 = corde/rayon X=3458.7 Y=1962.38 4.06459 = corde/rayon X=3456.46 Y=1962.24 4.01748 = corde/rayon X=3457.94 Y=1962.33 3.99501 = corde/rayon X=3460.99 Y=1962.52 4.05729 = corde/rayon X=3455.13 Y=1962.16 4.01107 = corde/rayon X=3459.83 Y=1962.45 4.01075 = corde/rayon X=3458.9 Y=1962.39 4.02689 = corde/rayon X=3460.72 Y=1962.5 4.03679 = corde/rayon X=3456.94 Y=1962.27 4.02931 = corde/rayon X=3460.09 Y=1962.46 4.01181 = corde/rayon X=3460.68 Y=1962.5 4.04621 = corde/rayon X=3454.28 Y=1962.11 4.03761 = corde/rayon X=3455.59 Y=1962.19 3.98799 = corde/rayon X=3462.02 Y=1962.58 4.06861 = corde/rayon X=3453.45 Y=1962.06 4.02089 = corde/rayon X=3457.43 Y=1962.3 4.16508 = corde/rayon X=3443.2 Y=1961.43 3.99947 = corde/rayon X=3462.7 Y=1962.62 1.88317 = corde/rayon X=4330.73 Y=2015.93 4.02306 = corde/rayon X=3460.98 Y=1962.52 3.97934 = corde/rayon X=3462.82 Y=1962.63 4.02172 = corde/rayon X=3460.9 Y=1962.51 4.01855 = corde/rayon X=3457.41 Y=1962.3