mala05

Attention à la densité 3,8 avec un 5D. Ne surtout pas mettre l’œil dans l’œilleton du reflex: danger pour la rétine. Réglage uniquement avec l'écran ou mieux un PC en déporté pour le confort. Si l'appareil n'est pas défiltré, il filtre déjà les UV et IR.

Pas très actif depuis un bout de temps mais je me remets à la bricole doucement. Dernière aventure en date via le boncoin.fr, je suis tombé par hasard il y a quelque temps sur un caillou un peu particulier: Objectif Zoom Canon XL 20x 5,4-108 mm L IS 1,6-3,5 estampillé "fluorite" pour 50€! Je me suis dit que je ne prenais pas trop de risques à faire joujou avec. Le hic, c'est que les XL sont utilisables exclusivement sur les caméscopes XL1 et XL2 commercialisés à la fin des années 90 / début des années 2000. Ces objectifs haut de gamme sont en effet entièrement numériques. Et pour couronner le tout, pour protéger les capteurs triCCD du caméscope, leur diaphragme est fermé au repos contrairement aux objectifs reflex de la marque. Pour contrôler le diaphragme, le zoom, la mise au point, etc, il faut donc reprendre la main sur le caméscope en termes de communication si l'on veut utiliser ces objectifs pour un autre usage. Bref, blablabla, hack de la communication SPI entre un objectif 16x et un XL1 de récup... Blablabla, reverse engineering du protocole, blablabla pas simple... Blablabla, conception d'une bague adaptée pour l'ASI 290 (backfocus de seulement 29mm et baïonnette non standard EF)... Blablabla, hack via un arduino nano et alimentation externe... Blablabla, ça commence à tomber en marche... Blablabla, conception d'une platine pour l'EM-10... Blablabla, premiers essais sur notre satellite... A ce stade, je contrôle: L'ouverture du diaphragme via le PC. La mise au point manuelle via la bague. Le zoom manuel via la bague et via le PC. La stabilisation qui est également pilotable via le PC. Ces optiques ont un champ image réduit étant conçues à la base pour un capteur 1/3". Le cercle image utile est seulement d'environ 6,64mm de diamètre après mesure. Par contre elles disposent d'une belle plage focale et d'une grande ouverture. A voir question coma et chromatisme en stellaire. Je n'ai pas pu pousser les tests avec la météo capricieuse. Concernant la stabilisation, ces optiques disposent d'un système qui me semble assez original puisqu'elles utilisent un concept de "prisme liquide"... De là à imaginer les dissocier sur des optiques de récup pour en faire un AO7 amélioré ou encore un correcteur de champ atmosphérique ça vaudrait le coup de tenter. Surtout si on est en mesure d'asservir la position via le PC... Je vous laisse apprécier la vélocité et la précision de positionnement de la stab. C'est assez bluffant. Merci de m'avoir lu et bon ciel.

Une bande led collée à une baguette en bois et plaquée au mur avec un angle d'environ 45°... De l'autre côté du couloir, à environ 10 mètres: monture, lunette (mon objo de 400mm), caméra et PC... Lorsque la lumière s'éteint, on a entre 5 et 6 magnifiques fausses étoiles dans le champs... On affine l'alignement de l'axe polaire afin de suivre parfaitement la bande led sur une hauteur de 256 pixels sur 20 min (2 tours de vis sans fin d'AD) et on lance la capture pendant 20 min à 25 img/s... J'ai baptisé cette méthode Starlink. Je vous laisse deviner pourquoi en regardant la vidéo... 30 Go de données plus tard... passage des images dans une moulinette de code perso: - Détermination des centroïdes des étoles dans le champs. - Pondération des étoiles en sortie/entrée de champs. - Calcul de la vitesse instantanée. Il n'y a plus qu'à visualiser sous Excel... Des données de vitesse instantanée, on peut intégrer pour en déduire la position "réelle" à un instant T. Et en faisant le delta avec la position théorique parfaite, on obtient une représentation de l'EP... On note à ce stade que: - Le principe fonctionne. - L'EP de ma petite EM-10 a pris du plomb dans l'aile avec les années à cause de la démultiplication 1/500 en plastique -> une sous sinusoïde rapide vient gangréner la sinusoïde de la vis sans fin. Je l'avais déjà constaté avant. Cela correspond à la rotation de l'engrenage 3 (*). Il faudra à terme que je remplace le moteur ou à minima que je le permute avec celui de déclinaison. - La précision de mesure est excellente. Avec le Canon 400mm et l'ASI, je suis à 1"/pixel. Si on ajoute à cela l’interpolation des centroïdes pondérées sur 5 étoiles on dépasse, à vu de nez, sans aucun souci le 10ème de second d'arc de précision de mesure. - L'EP s’aplatit légèrement et progressivement à mesure que le suivi de la baguette s'éloigne de la position tangente de départ. C'est tout à fait normal du fait de la proximité entre la baguette "starlink" et l'instrument. La baguette ne forme pas un arc de cercle comme le ciel. Donc à mesure que le temps passe, le mouvement des étoiles ralentit. Cela se corrigera sans problème algorithmiquement pour peu de mesurer la distance entre le matériel. *: Aperçu des engrenages de la démultiplication des moteurs équipant les EM-10 USD 2... Voili, voilou, je retourne regarder les étoiles à la cave...

Excellent gehelem!

L'optique qui n'offrirait pas un champ plan cela ne pourrait pas introduire une accélération/décélération de la zone de suivi?

Le calcul du pouvoir séparateur ne tient pas compte du contraste. Ce n'est qu'un indicateur et en rien une limite absolue. L’œil peut percevoir un fil électrique sur un ciel bleu à plusieurs kilomètre alors que cela dépasse de très loin son pouvoir séparateur. Un bon objectif de 70mm permet de détecter des failles lunaire telles que Triesnecker sans aucune ambiguïté. La rainure dans la vallée des Alpes, pour peu d'avoir un éclairage légèrement rasant, cela passe sans problème. La photo de lyl détecte bien des parties de la faille sans ambiguïté à mon sens.

Very good choice!

J'ai aussi des réserves sur la précision de cette technique. Cela me fait penser à l'amélioration que j'avais apporté sur le bibliothèque arduinoFFT à l'époque... https://github.com/kosme/arduinoFFT/issues/41 Pour l'estimation des pics de fréquence, je reconstruisais une parabole sur la base de 3 points... Le gain était notable mais ce n'est pas parfait.

Oui en boucle fermée un PID c'est encore ce qu'il y a de plus simple à mettre en place et à tester. Sur mon premier proto, j'étais parti sur une régulation adaptative mais c'est plus complexe à mettre en œuvre. Pour le CD tu voudrais en faire ta mire ou c'est juste pour tester en visuel? j'ai peur que la régularité du pattern des pistes puissent poser plus de problèmes qu'autre chose par rapport à tes anciennes mires non?

Qui a écrit cela et dans quel contexte?

Belle! Un asservissement en boucle fermée et tu l'as ton TDM!

@gehelem 100% d'accord avec Cyrille. Tu y es presque! La régression linéaire derrière (attention que sa plage soit bien multiple de ta période de vis sans fin) va te permettre d’annuler la vitesse sidérale et tu l'auras ta courbe d'EP.

Cyrille me rependra si j'ai pas bien suivi mais au moment où tu bascules de mire tu appliques le delta de position entre les deux mires à tes nouvelles mesures pour ne pas décrocher et ainsi de suite.

En OpenCV, j'ai testé CvPlot. C'est basique mais ça fonctionne... il faut que je teste OpenCVGUI qui intègre également des graphiques et permet d'aller bien plus loin avec notamment des éléments d'interface (boutons, checkbox, etc). Cela a l'air pas mal.

Je reprends un peu ce soir. Merci Cyrille. Oui je connais. J'utilisais matchTemplate() sur un logiciel de HDR pour recaler la perspective sur des bracketing à main levée. Dans ce cas cela suffisait mais cela m'interpelle un peu en terme de précision pour une mesure d'EP. Il y a intérêt d'être sacrément suréchantillonné pour obtenir une précision correcte non? Très intéressant ça! Il faudra que je teste aussi à l'occasion. Vas-y pollue on s'en fou! Tu nous fais un retour de tes tests dans l'observatoire? Enfin le jour où on revoit un peu de ciel bleu. En ce moment c'est pas gagné. Moi de mon côté, j'ai mis un peu le code de mon analyseur d'EP au propre et je commence à intégrer les graphiques à la volée pour remplacer Excel. En l'état c'est très bon niveau précision des mesures. Pour estimer le bruit résiduel, je me suis amusé hier soir à analyser la variation de la distance moyenne entre les fausses étoiles. Mon échantillonnage étant quasi de 1pix/", on est largement en subpixel comme le montre ce graph sur un peu plus d'une vingtaine de secondes. Je pense que les quelques pics sont même liés à des légères turbulences lors des mesures dans la cave... Je vais voir pour intégrer le pilotage de l'ASI dans le soft comme ça je pourrai vraiment faire des tests en temps réel et plus traiter des png après coup.

In that case, I think a C11 or a Mewlon 250 would be a better option. I doubt that the Mewlon 210 could make a big enough improvement.

Voilà qui valide joliment notre contrôle de collimation sur étoile artificielle dans le tunnel. C'est du tout bon pour la suite!

Splendide et traitement tout en douceur.

Si j'ai bien tout compris, il y a une erreur de principe dans cette solution. Tu vérifies la vitesse de rotation de la VSF... Celle-ci est fonction de la chaine cinématique en amont de la VSF. Mais tu ne prends pas en compte le défaut de faux rond de la vis qui induit au 1er ordre l'EP sur la roue... Cela ne correspond au graphique publié ici. En fait je ne pouvais pas prendre en compte le défaut de montage de l'encodeur sur l'axe de la vis sans fin. La fameuse banane que tu évoque ensuite. Pour les premiers essais j'avais été contraint de faire une rallonge en impression 3D pour pouvoir positionner la roue codeuse car son axe était trop court. Et avec les coutures d'impression ce n'était pas assez précis. Il va falloir que je vois pour faire fabriquer une petite rallonge en usinage. J'avais laissé ça en plan à l'époque. Je vais en profiter pour mettre un nouveau encodeur ABZ pour avoir un zéro sur la position de la vis. Il est dans un carton. Je rebondis sur le graphique que tu as crayonné. J'ai trouvé d'où vient le décrochage que tu as marqué en violet. Mon PC c'est mis en veille pendant la mesure. Je pensais avoir touché le clavier assez vite mais cela a généré un trou dans les mesures. J'ai constaté de visu en passant en revue les images dans cette zone. Mais tu as bien raison. C'est un outil au demeurant intéressant. Oui aucun problème pour les calculs. C'est pour l'affichage qu'il ne gère qu'au pixel près par défaut à ma connaissance. Mais en faisant quelques recherches, cela semble avoir évolué: many drawing functions can handle pixel coordinates specified with sub-pixel accuracy. This means that the coordinates can be passed as fixed-point numbers encoded as integers. The number of fractional bits is specified by the shift parameter and the real point coordinates are calculated as 𝙿𝚘𝚒𝚗𝚝(x,y)→𝙿𝚘𝚒𝚗𝚝𝟸𝚏(x∗2−shift,y∗2−shift) . This feature is especially effective when rendering antialiased shapes. Source: https://docs.opencv.org/3.4/d6/d6e/group__imgproc__draw.html Si tu es curieux, voici mon code C++ qui s'occupe de trouver tous les centroïdes d'une image. /** * @brief Structure pour stocker les informations sur un centroïde. * * @struct Centroid */ struct Centroid { double x; ///< Coordonnée X du centroïde. double y; ///< Coordonnée Y du centroïde. double mass; int minX; ///< Bordure gauche de la boîte englobante. int maxX; ///< Bordure droite de la boîte englobante. int minY; ///< Bordure supérieure de la boîte englobante. int maxY; ///< Bordure inférieure de la boîte englobante. }; /** * @brief Trouve les centroïdes des taches lumineuses dans une image. * * Cette fonction traite une image pour y détecter des taches lumineuses * et détermine la centroïde ainsi que la boîte englobante de chacune. * * @param image L'image en niveaux de gris à traiter. * @param thresholdLevel Le seuil pour la binarisation de l'image. * @param margin La marge à ajouter aux boîtes englobantes. * @param smoothingPasses Nombre de passes de lissage. * * @return Une liste des centroïdes détectés. */ vector<Centroid> findLightSpotsCentroids(const Mat &image, int thresholdLevel, int margin, int smoothingPasses) { // Duplique l'image pour travailler dessus Mat blurredImage = image.clone(); Mat mask; // Applique un filtre de flou // Note: 1 passe: suppression de la matrice Bayer for (int i = 0; i < smoothingPasses; i++) { boxFilter(blurredImage, blurredImage, -1, Size(2, 2)); } // Binarise l'image selon le seuil donné threshold(blurredImage, mask, thresholdLevel, 255, THRESH_BINARY); // Trouve les contours dans l'image binarisée vector<vector<Point>> contours; findContours(mask, contours, RETR_EXTERNAL, CHAIN_APPROX_SIMPLE); // Parcourt des contours détectés pour extraire les centroïdes vector<Centroid> centroids; for (const auto &contour : contours) { int minX = INT_MAX; int maxX = -INT_MAX; int minY = INT_MAX; int maxY = -INT_MAX; // Extraction de la boite englobante du contour cv::Rect boundingBox = cv::boundingRect(contour); Centroid c; c.minX = boundingBox.x - margin; c.maxX = boundingBox.x + boundingBox.width + margin; c.minY = boundingBox.y - margin; c.maxY = boundingBox.y + boundingBox.height + margin; // Vérifie si la boîte englobante ne touche pas les bords de l'image if (c.minX >= 0 && c.minY >= 0 && c.maxX <= image.cols - 1 && c.maxY <= image.rows - 1) { // Calcul barycentrique double totalX = 0.0; double totalY = 0.0; double totalWeight = 0.0; for (int y = c.minY; y < c.maxY; y++) { for (int x = c.minX; x < c.maxX; x++) { double weight = static_cast<double>(blurredImage.at<uchar>(y, x)); totalX += x * weight; totalY += y * weight; totalWeight += weight; } } // On obtient le centroïde c.x = totalX / totalWeight; c.y = totalY / totalWeight; // Ajout du centroïde à la liste centroids.push_back(c); } } // Trie des centroides par ordre croissant des coordonnées X std::sort(centroids.begin(), centroids.end(), [](const Centroid &a, const Centroid &b) { return a.x < b.x; }); return centroids; } La base pour n'importe quel système de suivi stellaire.

Merci gehelem mais cela n'apporterait rien si ce n'est de plomber les performances. Ici on a pas besoin de triangulation et le calcul d'une centroïde est simple à faire avec OpenCV: recherche de contours, on en déduit les boites englobantes et on termine par un simple calcul de barycentre sur les pseudos étoiles. Et pour ce qui est de "suivre une étoile" d'une image à une autre, il suffit de vérifier les boites englobantes qui se chevauchent comme le mouvement est très lent. Une illustration de ce qu'on peut faire en quelques lignes de code avec OpenCV: https://learnopencv.com/find-center-of-blob-centroid-using-opencv-cpp-python/

Je ne vois pas bien l'idée. En l'état, je n'exploite pas la distance entre les leds si ce n'est pour déterminer le coefficient d'atténuation en bord d'image lorsqu'elles sortent ou entrent dans le champ. Pour le reste, je me base uniquement sur la vitesse moyenne de déplacement des leds présentes. La distance inter led n'intervient donc quasiment pas. Si tu te rappelles, j'avais réalisé en 2019 des tests avec un encodeur basse résolution de 1000 lignes (soit 4000 positions) à quelques dizaine d'euros en sortie de vis sans fin... L'idée est là aussi de partir sur une analyse de la vitesse en temps réel et non de la position absolue comme ils sont utilisés habituellement. Les premiers résultats étaient très intéressants... Mais c'était sans compter sur le défaut de précision du montage de l'encodeur sur la vis sans fin. J'avais fini par laisser le truc en plan en 2019. Le nouveau système de mesure d'EP à la cave devrait me faciliter le travail pour reprendre où j'en étais. Le gros avantage que j'y vois, si cela tombe en marche , c'est qu'on obtiendrait alors un système PEC capable de s'auto corriger tout seul en amont de la vis sans fin. Et c'est gros plus car les engrenages de démultiplication en amont ne sont pas forcément des sous multiples de la période de la vis sans fin d'AD. Cela les rends quasi impossible à corriger avec un PEC standard. Bref, il y a de quoi s'amuser. Non, au final après avoir préparé le CAPET en Sciences de l'ingénieur (que j'ai raté ), j'ai finalement passé le concours interne d'éco gestion cette année. Mais je te rassure en spécialité informatique... Aujourd'hui, je suis enseignant de spécialité SLAM (Solutions Logicielles et Applications Métiers) en BTS SIO et je me régale.

Bonne remarque pour les roulements. Effectivement, cela doit jouer aussi. Je vais essayer d'isoler les éléments petit à petit. J'avais déjà commencé à travailler sur le sujet il y a un peu plus de 3 ans avant de mettre en pause l'astro. A l'époque j'avais passé un peu de temps sur l'étude de la bibliothèque arduinoFFT et une grosse amélioration de sa précision dans l'idée de l'intégrer à mon projet. C'est tout à fait exploitable sur le PC également vu que c'est du C++. Je l'avais d'ailleurs déjà adaptée avec une IHM pour valider mes devs avec le concepteur de la bibliothèque... Oui et là on est vraiment en bout de chaine. Et c'est d'autant plus intéressant que les données peuvent être recoupées avec mon analyseur d'EP de moteur pas à pas que j'avais mis au point déjà en 2017 en montant une mire directement sur l'axe moteur... Je ne sais pas. Intuitivement cela me semblerait ajouter de la complexité là où il n'y a pas lieu d'être. Sans parler du coût. Là on en a pour moins de 5€ avec un bandeau leds sur pile de chez Action. Sur ce, je retourne un peu à Flutter et Dart pour préparer les TPs de mes élèves! C'est bien beau d'avoir mis l'astro en pause à l'époque pour préparer un concours. Mais maintenant il faut assurer aussi...

Belle soirée au CosmoDrôme vendredi soir dernier. Le début de soirée a été un peu limité par des passages brumeux limitant la résolution mais c'était tout de même sympa... Mewlon 250 Original + Powermate 2x + ADC ZWO + IR Cut + ASI 678 MC - Réduction d'échelle à 50% La vision bino m'a rappelé ce passage de L'odyssée deux... "À cet endroit, sur un autre monde et avec d’autres acteurs, quelque chose comme l’histoire de l’Égypte s’était joué bien avant l’apparition de l’homme. De même que le Nil avait apporté la vie sur un étroit ruban désertique, cette rivière de chaleur avait vivifié les profondeurs d’Europe. Le long de ses rives, sur une bande qui n’avait jamais plus de deux kilomètres de largeur, des espèces innombrables avaient évolué, s’étaient épanouies et avaient disparu. Et l’une d’elles, au moins, avait laissé derrière elle un monument." 2010 - Odyssée Deux. Arthur Charles Clarke En deuxième partie de nuit, cela s'est encore amélioré à mesure que Jupiter montait. Dommage que la GTR s'était éclipsée. Mewlon 250 Original + Powermate 2x + ADC ZWO + IR Cut + ASI 678 MC - Réduction d'échelle à 75%

Je profite du mauvais temps pour reprendre un peu le traitement notamment de la deuxième image prise en seconde partie de nuit. Plus douce encore et avec 75% d'images retenues sur 10x1min contre 25% pour la première version. On ne gagne pas en détails mais je trouve que visuellement on gagne encore en sensation de "réalisme". Avec un suréchantillonnage à 0,1"/pix je trouve que ça passe encore bien pour 250mm. Par contre il faut vraiment le ciel qui suive.

Merci Pierrot. Pour l'instant je n'en suis qu'à l'étape du "proof of concept" bricolé avec des bouts de code en C++ et OpenCV. Le principe reste à affiner. On est loin d'un logiciel sur étagère. Je ne conceptualise pas très bien ton idée de l'usage d'un laser pointé sur des billes d'acier. A 10m, le télescope se déplace sur la mire d'environ 45cm/10min. C'est pour cela qu'on a besoin d'une bande led avec une multitude de fausses étoiles. Qui plus est Ici l'idée est d'être en intérieur pour limiter au maximum les effets de la turbulence. Merci Pascal! Génie manipulationnel! Rien que ça! Je ne sais pas sur les C11 mais sur les Mewlons 250 la collimation tient bien et l'horizontalité de la manip ne pose pas de problème. Par contre, il faut faire bien attention aux flexions côté bagues allonges. Là on avait des bagues allonges vissantes qui sont vraiment parfaites une fois serrées. On a fait différents essais et pas de soucis de flexion Sinon on pas encore testé l'AP. Il faut qu'on voit pour l'adaptation de mon 400mm dessus. Je pense que la prochaine étape va être déjà de tester mon moteur de Dec (comme je programme moi même la carte d'asservissement de mes moteurs c'est tout con de switcher les deux moteurs logiciellement). Et l'étape suivante sera je pense de tester ma vieille EM200 comme j'ai la même embase. Sinon oui tu es dans le bon ordre de grandeur à vue d’œil pour l'EP à +/- 20 " si l'on ne tient pas compte de l'engrange fatigué. Mais je pense qu'il n'est pas le seul. En données constructeur elle est à +/- 10 " et je pense qu'elle les tenait bien à l'époque il y a 25 ans.