Analyse d'EP dans une cave: méthode Starlink par bibi ;)

[mala05 1067]

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...

Edited October 20 by mala05

[polorider 677]

il y a 8 minutes, mala05 a dit :

Voili, voilou, je retourne regarder les étoiles à la cave...

Bon alors celle-là je ne l'avais jamais entendue...      Génial ton montage 

[ALAING 56532]

Quelle ingéniosité superbe manip

Mais bon encore faut-il avoir une grande cave

Bonnes observations,

AG

[Marc S 599]

il y a 10 minutes, mala05 a dit :

Voili, voilou, je retourne regarder les étoiles à la cave...

 

Ingénieux.  Méthode à méditer car ils nous manquent le  "code perso"  d'analyse.

 

On ne parlera plus  désormais de voüte celeste étoilée mais bien de cave celeste étoilée. A moins que la cave soit voutée...

[mala05 1067]

Il y a 2 heures, polorider a dit :

Bon alors celle-là je ne l'avais jamais entendue...      Génial ton montage 

Merci Polorider! Avec la pluie qui tombe en ce moment dans les Alpes mon côté Breton remonte pour palier au temps!  On pas de pétrole mais on a des idées!

 

Il y a 2 heures, ALAING a dit :

Quelle ingéniosité superbe manip

Mais bon encore faut-il avoir une grande cave

Bonnes observations,

AG

Tu veux voir encore mieux Alain? 

 

J'ai également dégoté un couloir souterrain de 40m pour tripoter nos gros engins dans le noir avec les copaings... 

 

Température très stable et très peu de turbulence. Le top pour la collimation sur étoile artificielle...

 

Il y a 2 heures, Marc S a dit :

 

Ingénieux.  Méthode à méditer car ils nous manquent le  "code perso"  d'analyse.

 

On ne parlera plus  désormais de voüte celeste étoilée mais bien de cave celeste étoilée. A moins que la cave soit voutée...

Merci Marc. Et oui on innove avec la météo!

[teko38 1148]

Superbe trouvaille

il y a 41 minutes, mala05 a dit :

Température très stable et très peu de turbulence. Le top pour la collimation sur étoile artificielle

Pas de pb avec les bagues allonges

 

[exaxe17 5550]

C'est super ta manipulation ! Merci du partage ! En tout cas ta monture serait parfaite pour les poses courtes et le problème de walking noise!

[guy03 4144]

Et ben je dis chapeau!!! Bravo!

[mala05 1067]

Il y a 4 heures, teko38 a dit :

Superbe trouvaille

Pas de pb avec les bagues allonges

Merci teko38.

 

Heureusement qu'on en avait en rab car malgré les 40m il a fallut bien rallonger comme on l’aperçoit sur la photo avec le Mewlon CRS de mon ami. J'avais un peu peur que cela puisse fausser l'alignement mais non ça l'a fait parfaitement. Pour l'Epsilon 180 par cela a été plus simple.

 

Il y a 4 heures, exaxe17 a dit :

C'est super ta manipulation ! Merci du partage ! En tout cas ta monture serait parfaite pour les poses courtes et le problème de walking noise!

Merci exaxe17 Oui mais non pour walking noise. On va faire en sorte de corriger ça à terme.

 

Il y a 3 heures, guy03 a dit :

Et ben je dis chapeau!!! Bravo!

Merci Guy

[pierrot1674 73]

bonjour a tous

excelente manip je suis interessé

sa peut se faire en exterieur avec un laser pointé sur des billes en acier ?

mala 05 peut on esperer avoir ton logiciel de traitement Merci

[Pascal C03 3935]

Il y a 16 heures, mala05 a dit :

J'ai également dégoté un couloir souterrain de 40m pour tripoter nos gros engins dans le noir

 

Une fois de plus tu démontres ton génie manipulationnel...

J'ai fait puis abandonné la collim de mon C11 dans un couloir de l'IUT de 70 m de long avec une étoile artificielle. Abandonné car la meilleure collim est celle que l'on fait sur site avant d'imager.

 

Je vois une monture AP, l'avez-vous testée pour voir son EP ?

Pour ta Taka, l'EP est de +/- 20 " d'arc si on interprète l'échelle en ordonnée ?

[mala05 1067]

Le 20/10/2023 à 23:11, pierrot1674 a dit :

bonjour a tous

excelente manip je suis interessé

sa peut se faire en exterieur avec un laser pointé sur des billes en acier ?

mala 05 peut on esperer avoir ton logiciel de traitement Merci

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.

 

Le 21/10/2023 à 06:46, Pascal C03 a dit :

 

Une fois de plus tu démontres ton génie manipulationnel...

J'ai fait puis abandonné la collim de mon C11 dans un couloir de l'IUT de 70 m de long avec une étoile artificielle. Abandonné car la meilleure collim est celle que l'on fait sur site avant d'imager.

 

Je vois une monture AP, l'avez-vous testée pour voir son EP ?

Pour ta Taka, l'EP est de +/- 20 " d'arc si on interprète l'échelle en ordonnée ?

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.

[Pascal C03 3935]

Il y a 4 heures, mala05 a dit :

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.

 

Les causes doivent se tenir dans les roulements ? Ces bestioles là sont assez mal dimensionnées je trouve pour l'essentiel des montures. Il te manque une décomposition de Fourier mais ça doit pas être le truc qui te fait peur !

Je doute que la VSF se soit mise en banane toute seule.

 

Ce qui est super dans ta manip est que tu élimines le bruit important crée par la turbulence. Tu as à 95% le comportement mécanique de la monture.

 

Est-ce qu'un stroboscope aurait pu remplacer tes leds ?

 

Si si, génie est bien le mot. Je l'ai employé à bon escient.

[mala05 1067]

Il y a 14 heures, Pascal C03 a dit :

Les causes doivent se tenir dans les roulements ? Ces bestioles là sont assez mal dimensionnées je trouve pour l'essentiel des montures.

Bonne remarque pour les roulements. Effectivement, cela doit jouer aussi. Je vais essayer d'isoler les éléments petit à petit.

 

Il y a 14 heures, Pascal C03 a dit :

Il te manque une décomposition de Fourier mais ça doit pas être le truc qui te fait peur !

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...

 

Il y a 15 heures, Pascal C03 a dit :

Ce qui est super dans ta manip est que tu élimines le bruit important crée par la turbulence. Tu as à 95% le comportement mécanique de la monture.

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...

 

 

 

Il y a 15 heures, Pascal C03 a dit :

Est-ce qu'un stroboscope aurait pu remplacer tes leds ?

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...

[Pascal C03 3935]

Il y a 2 heures, mala05 a dit :

Je ne sais pas. Intuitivement cela me semblerait ajouter de la complexité là où il n'y a pas lieu d'être.

Tu dois pouvoir avoir une EP sur la distance inter led !?

 

Tu n'es pas loin du tout de mettre en place un système de rétroaction de pilotage des moteurs ? Remplacer les encodeurs par des trucs moins onéreux te parait possible ?

 

Il y a 2 heures, mala05 a dit :

préparer un concours.

 

ça sent l'agreg en interne ! Tu es prof dans quelle matière ?

[mala05 1067]

Il y a 5 heures, Pascal C03 a dit :

Tu dois pouvoir avoir une EP sur la distance inter led !?

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.

 

Il y a 5 heures, Pascal C03 a dit :

Tu n'es pas loin du tout de mettre en place un système de rétroaction de pilotage des moteurs ? Remplacer les encodeurs par des trucs moins onéreux te parait possible ?

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.

 

Il y a 5 heures, Pascal C03 a dit :

ça sent l'agreg en interne ! Tu es prof dans quelle matière ?

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.

Edited October 23 by mala05

[gehelem 174]

Passionnant !! je vais suivre ça de près

Petite suggestion : utiliser Stellarsolver pour détecter tes centroïdes, c'est ce qui est utilisé sur Ekos pour le guidage (entre autres), c'est très simple à utiliser

 

ça me rappelle aussi que j'ai au fond d'un tiroir une belle mire imprimée aussi finement que possible et un capteur de souris optique 1200ppp (de mémoire) que je comptais essayer de tambouiller pour faire aussi ce genre de mesure, ça me redonne envie d'essayer mais c'est encore un machin à y passer des nuits

 

 

[Pascal C03 3935]

Il faudrait pouvoir récupérer le signal au niveau d'un roulement...

ça doit couter un bras

https://www.ntn-snr.com/sites/default/files/2018-10/doc.i_bbs_incremental_gba-web.pdf

 

Je ne crois pas que les erreurs en dehors de la VSF soient si importantes. Le pignon monté sur l'axe de la VSF voit son erreur divisée par le nombre de dents de la roue. Plus il y a de dents sur la roue, plus le filtrage des EP dues aux pignons est important.

 

Maintenant, je n'ai pas tout intégré dans le calcul théorique d'EP dû à la seule VSF. Me manque des facteurs à prendre en compte pour expliquer l'EP mesurée sur ma propre monture.

[mala05 1067]

Il y a 13 heures, gehelem a dit :

Passionnant !! je vais suivre ça de près

Petite suggestion : utiliser Stellarsolver pour détecter tes centroïdes, c'est ce qui est utilisé sur Ekos pour le guidage (entre autres), c'est très simple à utiliser

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/

[gehelem 174]

Il y a 16 heures, mala05 a dit :

mais cela n'apporterait rien si ce n'est de plomber les performances.

je n'en suis pas certain, tu peux utiliser Stellarsolver sans trianguler quoique ce soit, perso je le trouve très rapide, il faudrait que je teste pour voir s'il est capable d'avaler du 25im/s

Mais c'était juste pour ramener ma fraise après la bataille, pour faire genre que j'ai pigé la manip...

 

Et comme ça m'intéresse par ailleurs, est-ce que OpenCV permet de faire du "subpixel" ??

[Pascal C03 3935]

Le 23/10/2023 à 18:44, mala05 a dit :

Mais c'était sans compter sur le défaut de précision du montage de l'encodeur sur la vis sans fin

 

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...

 

Il y a un pb possible de centrage de ton codeur mais ta forme en banane de la vis peut tourner de manière hyper précise, la banane va te créer une EP sur la roue... Et ça, ce n'est pas (encore) résolu.

Il faut trouver une solution avec un ruban collé sur l'axe AD. En 1981, comme élève ingé, j'ai travaillé avec 2 collègues en // avec l'OHP* pour imaginer un système de pointage précis (projet précipoint ou un truc du genre) La solution OHP avait été de coller un ruban de grande longueur sur une partie cylindrique de grand diamètre de l'axe AD et d'avoir une tête de lecture (matériel Heidenhain)... S'il y a une petite erreur de centrage du ruban, ce n'est pas majeur puisque la période de cette EP est de ...24h.

 

*Ils avaient déjà opté pour une solution.

[mala05 1067]

Le 25/10/2023 à 08:57, Pascal C03 a dit :

Le 23/10/2023 à 18:44, mala05 a dit :

Mais c'était sans compter sur le défaut de précision du montage de l'encodeur sur la vis sans fin

 

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.

 

Le 25/10/2023 à 01:07, gehelem a dit :

je n'en suis pas certain, tu peux utiliser Stellarsolver sans trianguler quoique ce soit, perso je le trouve très rapide, il faudrait que je teste pour voir s'il est capable d'avaler du 25im/s

Mais c'était juste pour ramener ma fraise après la bataille, pour faire genre que j'ai pigé la manip...

Mais tu as bien raison. C'est un outil au demeurant intéressant. 

 

Le 25/10/2023 à 01:07, gehelem a dit :

Et comme ça m'intéresse par ailleurs, est-ce que OpenCV permet de faire du "subpixel" ??

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.

 

Edited October 27 by mala05

[Pascal C03 3935]

Il y a 16 heures, mala05 a dit :

La fameuse banane que tu évoque ensuite

Pour moi, la banane est la forme de la VSF. Et c'est ce faux rond qui engendre ton EP au 1er ordre de +/- 10" avant d'évoquer le décalage entre axe codeur et axe "banane".

 

Regarde mon fil dédié à la mesure de faux rond.

Ta VSF-banane peut tourner avec une régularité d'horloge atomique ; à chaque fois que le bombé se rapproche de la roue, celle ci accélère et à chaque fois qu'il s'en éloigne, la roue ralentit.

Bien sûr qu'il y a défaut d'alignement entre l'axe de la VSF et l'axe du codeur et ça crée un défaut supplémentaire mais j'insiste, il faut trouver le moyen de récupérer la vitesse de la roue. au temps des K7, on aurait "collé" de la bande magnétique sur une surface circulaire avec un signal à 15 kHz enregistré + 1 tête de lecture + interpolation !?

 

Toujours difficile de communiquer comme ça. En live, on règlerait ce petit débat en 3 minutes.

 

bonnes vacances !

[gehelem 174]

Allez, j'ai remis une pièce aussi

J'ai tenté avec une souris, ça n'est pas très concluant.

J'ai donc mis une webcam, et je filme la rotation directement sur la monture comme avec un encodeur

(+ impression toute bête d'un motif en échelle)

 

Et ensuite j'essaie de me dépatouiller avec opencv, j'ai pas tout pigé mais le premier résultat est très encourageant !

Je pense que j'ai des effets de quantification parce que j'utilise le matchTemplate d'opencv

Je vais creuser cette histoire de subpixels...

 

 

A mon avis la bonne piste serait le "optical flow"

https://docs.opencv.org/4.x/d4/dee/tutorial_optical_flow.html

 

Et aussi avec les petits microscopes à 10€ je devrais obtenir une résolution bien meilleure du fait du grossissement plus important

Clic, order, livraison en 15j ;-)

 

Si ça marche, je n'aurai plus qu'un petit driver Indi à coder et ça ferait un TDM à 10€ au lieu de 1000

Mais je divague.

 

En tout cas merci @mala05 ça m'a boosté ton truc !

Gilles 

Edited November 6 by gehelem

[Cyrille Thieullet 100]

Bonjour,

 

Personnellement, dans le soft de mesure de l'EP pour Hobym auquel j'ai participé à la conception et à la réalisation, nous avions utilisé la fonction matchTemplate d'opencv.

 

//int match_method = TM_SQDIFF_NORMED;

int match_method = TM_CCORR_NORMED;

cv::matchTemplate(m_matCapture, m_matReference, m_result, match_method);

//Normalize, in cas of

cv::normalize( m_result, m_result, 0, 1, NORM_MINMAX, -1, Mat() );

// Get Min & Max

minMaxLoc(m_result, &m_minVal, &m_maxVal, &m_minLoc, &m_maxLoc, Mat());

// Upon matching method, must take min r max

if( match_method == TM_SQDIFF || match_method == TM_SQDIFF_NORMED ) {

   m_maxVal = m_minVal;

  m_maxLoc = m_minLoc;

}

 

Il y a une image de référence (m_matReference) et celle en cours (m_matCapture)

Quand le delta de position entre les deux est > à 2/3 en X, la capture courante devient la capture de référence.

 

Ca permet de faire la mesure n'importe où car il est possible de calculer le delta entre de portions d'images.

Une clôture à 20m c'est parfait, le mur d'en face depuis un balcon aussi.

 

Cyrille