[Besoin d'aide] Projet d'aide BTS

Meow · 10 mars 2014

Bonjour,

Je travaille actuellement sur un projet (Télescope électronique) avec mon collègue.

J'explique vaguement le projet:

On a

- un télescope (monture Dobson) avec 2 capteurs incrémentaux (RS58-0/1024EK)

- une carte Raspberry Pi

- Une tablette Android +4.0

On a pour but que le télescope suive une étoile sélectionnée.

Pour ça, on a créé une base de donnée SQL se basant sur le catalogue de Messier et le système solaire (la base de donnée est hébergée sur la Raspberry).

On a développé une application Android en java se connectant à la base de donnée et récoltant les informations.(L'appli communique avec la raspberry) L'application contient les formules pour calculer le jour julien, la hauteur du télescope, et l'azimuth. Les 2 capteurs sur le télescope permettent de connaitre la direction dans laquelle il pointe. Grace aux coordonnées dans la base de donnée, et la position du télescope on est capable de calculer grâce à des soustractions la différence entre la position d'une étoile et celle du télescope. Voilà en gros notre projet.

Globalement on est très avancé. Il nous reste la formule de l'azimuth, le branchement des capteurs du télescope sur les ports GPIO de la Raspberry. Et les calculs finaux pour conclure le projet.

Je viens poster ici car j'ai vu que c'était un forum actif.

J'aimerai votre aide pour m'éclaircir sur la formule d'azimuth. Nous avons fait beaucoup de recherches mais ça reste flou. Si jamais vous avez une formule de l'azimuth en java, ou simplement sa formule pour que nous l'intégrions à l'application.

Gontran · 10 mars 2014

Voici le site que j'avais utilisé pour calculer azimut et hauteur en connaissant les coordonées AD/Dec. Testé, ça marche. Faut juste faire gaffe aux unités.

http://emilie.bodin.free.fr/logiciel/logicielframe.html

Meow · 10 mars 2014

Merci on travaille dessus. Je tiens au courant !

starac · 10 mars 2014

quel crac, ce Gontran ...

Meow · 11 mars 2014

On a réussi à régler notre problème, il y avait quelques erreurs dans notre code.

Comparé à Stellarium, on a un petit décalage de 1 degré env. (peut-être dû à notre position GPS, latitude, longitude)

Avez-vous une idée de ce décalage?

Fred_76 · 11 mars 2014

Peut être des arrondis approximatifs ?

Tu peux récupérer le code de Stellarium pour le comparer avec le tien :

http://sourceforge.net/projects/stellarium/files/Stellarium-sources/

Gontran · 11 mars 2014

Certains logiciels de planétarium prennent en compte la diffraction causée par l'atmosphère terrestre. quand tu regardes une étoile proche de l'horizon, et bien elle n'est pas à cet endroit Par contre, au zénith, étant donné que la lumière incidente est perpendiculaire à l'atmoshpère, la position est équivalente.

Tu as testé à quelle hauteur ?

MoonDaka · 11 mars 2014

Bonjour

attention au point de référence des coordonnées équatoriales

le point vernal se déplace d'où les coordonnées au jour J ou plus simplement les coordonnées J2000 cad au premier janvier 2000

bonnes étoiles

Moondaka

Meow · 11 mars 2014

Merci de vos réponses.

Tu as testé à quelle hauteur ?

On a testé l'étoile M1 Nébuleuse du Crabe (Messier) grâce à notre base de donnée et les formules pour calculer l'azimuth et la hauteur.

Donnée de M1 dans notre base de donnée:

Déclinaison: 22° 1'

Ascension Droite! 5h 34m 30s

Par exemple actuellement:

Stellarium:

Azimuth: 55° 20' 30''

Hauteur: 0° 12'

Notre Appli:

Azimuth: 56° 06' 30'' (approximativement)

Hauteur: 1° 08'

Pour un position GPS de 48° 43' 54"/ 2° 15' 12" (L'attitude/Longitude)

On remarque donc un léger décalage..

Stellarium n'appliquerait pas une correction magnétique par hasard ?

C'est beaucoup au niveau astronomique ?

Parce que pour le projet je pense que ça suffira.

Gontran · 11 mars 2014

hauteur: 1°, c'est à dire pile poile au niveau de l'horizon, là où la couche athmosphérique est la plus importante. Peut être y a t il une correction.

Je suis pratiquement certain que le logiciel "carte du ciel" n'applique pas de correction. Tu as testé la différence entre carte du ciel et stellarium ?

As tu essayé le même objet mais à 20H (M1 est très haut dans le ciel).

Meow · 12 mars 2014

J'essaierai de test à 20h.

Dans le pire des cas je pense que l'on pourra ajouter une correction au code en mettant -1 pour la hauteur.

Que veux-"tu" dire par carte du ciel ?

Meow · 14 mars 2014

Je voulais savoir, dans notre projet, on doit initialiser la position du télescope en se basant sur le Nord polaire (étoile polaire). Est-ce une bonne idée de pointer (Dec: 89°18"4' / AD: 2h44') je me base sur http://www.astrosurf.com/quasar95/exposes/viseur_polaire_mise_en_station.pdf est-ce une bonne idée où pouvez-vous mieux me conseiller ?

Gontran · 14 mars 2014

Bonjour,

Non, ça n'est pas une forcément bonne idée. Mais ça n'est pas forcément mauvais...

- L'étoile polaire à juste la chance de se trouver à cet endroit, pas très loin du vrai pole céleste... Elle est lumineuse (magnitude 2), donc c'est un repère facile pour pointer. On l'utilise comme point de repère pour les monture équatoriales.

- Pour les montures azimutales (ou à base de Dobson), il n'y a pas d'intéret à aller la pointer plus qu'une autre étoile. Mais pourquoi pas...

- Pour que ça soit précis, il faut idéalement 3 étoiles.

Pour pouvoir calibrer la monture, je te suggère de trouver la documentation (dispo sur internet) de Dobson de type "inteliscope" ou même des instrument ETX (ETX70 par exemple) de chez meade.

Pour un ETX, voici comment ça se passe:

- tu t'assures que la base de ton Dobson est parfaitement de niveau, tu orientes manuellement l'instrument vers le nord et tu mets le tube à l'horizontal (avec un niveau). Grace à cela, l'instrument sait que tu pointes vers le nord avec une altitude de 0°. C'est une valeur approchée mais c'est son premier repère.

- Comme l'ETX sait plus ou moins précisément où il est, il se dirige ensuite automatiquement vers une étoile connue. Si l'étoile n'est pas tout à fait au centre de l'oculaire, tu bouges l'instrument avec la raquette. Tu valides, il a un premier repère.

- Il est possible de faire des alignements sur 1, 2 ou 3 étoiles. 1 suffit en théorie uniquement si la position initiale est parfaitement au nord, à 0° d'altitude et avec ka vase de niveau. Comme ça n'est pas précis, on préfère faire l'alignement sur 2 autres étoiles en plus de la première.

- avec 3 étoiles comme référence, la calibration est bonne.

L'ETX a en mémoire une liste d'étoiles de référence car toutes ne sont pas visibles en même temps: ça dépend de la saison mais aussi de la visibilité que l'observateur a, certaines étoiles pouvant être cachées par des arbres, bâtiments, etc...

De plus, il faut que ces étoiles soient suffisament espacées les unes par rapport aux autres et, si je me souviens bien, avoir au moins 2 étoiles de part et d'autre de l'équateur céleste.

Cette théorie est importante à expliquer. Mais relativement complexe à implémenter. Tu peux donc à mon avis te limiter dans le cadre de ton projet à la calibration sur une étoile (et ne pas oublier de partir de la position nord, altitude 0) en précisant les imprécisions que ça peut apporter (ça se calcule).

Si tu ne veux mettre que 1 étoile, prends une étoile dite "circumpolaire" (dans la grande ourse ou Cassiopée par exemple), et pourquoi pas la polaire dans la petite ourse.

Que veux-"tu" dire par carte du ciel ?

Carte du ciel est un logiciel de... cartes du ciel. Je suis sûr qu'il ne tient pas en compte la couche atmosphérique.

Modifié 14 mars 2014 par Gontran

Meow · 14 mars 2014

Hmmm voilà on se base sur un télescope à monture Dobson mais on utilise ce prototype pour notre projet, afin qu'on l'applique sur un vrai télescope si le projet habitude.

Donc est-ce que les réglages pour calibrer le télescope sont valables pour ça ?

Merci des conseils ~^.^~

Modifié 17 mars 2014 par Meow

Meow · 9 avril 2014

RE !!!!!!

J'ai besoin d'aide ou plutôt d'avis. On travaille actuellement sur la partie gestion codeurs incrémentaux (qui sont placés sur l'axe azimut et hauteur du télescope)

Je voudrais savoir si l'algorithme est bon:

Par exemple pour l'axe azimut quand on va augmenter:

if (sec=60)

{

min = min+1;

sec = 0;

}

if (min=60)

{

deg = deg+1;

min = 0;

}

if (deg=360)

{

sec=0;

min=0;

deg=0;

}

Les variables correspondent respectivement dans l'ordre à seconde,minute,degré.

Fred_76 · 9 avril 2014

Oulahhh... c'est du code plus que très basique et tu nous demandes notre avis ? Je n'ose pas imaginer pour le reste du codage.

Note que if (i=60) n'est pas forcément rempli même si i=60 ! i peut être égal (en interne) à 59.999999999 ou à 60.000000000001.

Il ne faut donc pas oublier de typer sec, min et deg comme étant des entiers :

int deg, min, sec; // degrés, minutes, secondes

Ensuite sur la partie :

if (deg=360)
{
sec=0;
min=0;
deg=0;
}

que se passe-t-il si deg=359, min=35 et sec=21 et que tu souhaites ajouter 1 degré ?

À la sortie de ton calcul, tu vas avoir deg=min=sec=0 alors qu'on attendait deg=0, min=35 et sec=21.

Je pense que le plus simple est de tout compter en secondes et, pour l'affichage uniquement, présenter en deg/min/sec. Comme ça tu n'as qu'à faire un modulo 1296000 (360x60x60) pour éviter de dépasser les 360° et tu ne gères plus que des secondes sans t'encombrer des passages des minutes et degrés. Ca simplifie tout aussi, si tu veux incrémenter ton compteur de 10s, 35s...

Avec un compteur en secondes, pour récupérer les degrés, minutes et secondes il suffit juste de faire :

int i, sec, min, deg // compteur en secondes, secondes, minutes, degrés

deg = (int)math.floor(i/3600);
min = (int)math.floor((i-3600*deg)/60);
sec = i % 60;

Modifié 9 avril 2014 par Fred_76

Meow · 9 avril 2014

bon en ayant implanté l'algorithme à l'appli, nous avons beaucoup de bug

Donc il faudrait partir sur une base de 1296000 sec au total?

Sachant que le codeur final est un codeur de 1024 pas, pour chaque pas, on augmente de (1296000/1024 =) 1265.625 sec. mais du coup on obtient un chiffre à virgule.

Peut-être faire un arrondi à l'entier supérieur ? Quoique ça pourrait perturber le résultat final pour l'observation :/

Leimury · 9 avril 2014

Bonjour,

Je travaille actuellement sur un projet (Télescope électronique) avec mon collègue.

J'explique vaguement le projet:

On a

- un télescope (monture Dobson) avec 2 capteurs incrémentaux (RS58-0/1024EK)

- une carte Raspberry Pi

- Une tablette Android +4.0

On a pour but que le télescope suive une étoile sélectionnée.

Pour ça, on a créé une base de donnée SQL se basant sur le catalogue de Messier et le système solaire (la base de donnée est hébergée sur la Raspberry).

On a développé une application Android en java se connectant à la base de donnée et récoltant les informations.(L'appli communique avec la raspberry) L'application contient les formules pour calculer le jour julien, la hauteur du télescope, et l'azimuth. Les 2 capteurs sur le télescope permettent de connaitre la direction dans laquelle il pointe. Grace aux coordonnées dans la base de donnée, et la position du télescope on est capable de calculer grâce à des soustractions la différence entre la position d'une étoile et celle du télescope. Voilà en gros notre projet.

Globalement on est très avancé. Il nous reste la formule de l'azimuth, le branchement des capteurs du télescope sur les ports GPIO de la Raspberry. Et les calculs finaux pour conclure le projet.

Je viens poster ici car j'ai vu que c'était un forum actif.

J'aimerai votre aide pour m'éclaircir sur la formule d'azimuth. Nous avons fait beaucoup de recherches mais ça reste flou. Si jamais vous avez une formule de l'azimuth en java, ou simplement sa formule pour que nous l'intégrions à l'application.

Bonjour,

Tu prévois de bosser chez Shadock incorporated ?

Mais pourquoi donc mettre la base de données sur la carte pour que la tablette aille se connecter dessus pour calculer l'altaz à appliquer et ensuite commander la carte ?

Le petit problème à mettre de l'astro dans le BTS c'est que vous n'aurez rien de concret à montrer, vous ne pouvez pas amener vos profs ou un jury dehors en pleine nuit pour montrer le bouzin qui tourne.

Dans ces conditions il faut un rapport béton qui montre que vous seriez prêts à rejoindre le joyeux monde réel.

Le BTS est orienté vers l'industrie, des solutions pragmatiques avec une petite vision du cout pendant l'étude.

Quand tu as des normes existantes et plein de logiciels il peut être bien vu de les intégrer au produit.

Bon ciel

Meow · 9 avril 2014

Évidement qu'on définit les variables sec/min/deg en tant qu'entier

que se passe-t-il si deg=359, min=35 et sec=21 et que tu souhaites ajouter 1 degré ?

Bonne question

Ca simplifie tout aussi, si tu veux incrémenter ton compteur de 10s, 35s...

C'est une idée, on verra en conséquence

Modifié 9 avril 2014 par Meow

Meow · 9 avril 2014

Bonjour,

Tu prévois de bosser chez Shadock incorporated ?

Mais pourquoi donc mettre la base de données sur la carte pour que la tablette aille se connecter dessus pour calculer l'altaz à appliquer et ensuite commander la carte ?

Le petit problème à mettre de l'astro dans le BTS c'est que vous n'aurez rien de concret à montrer, vous ne pouvez pas amener vos profs ou un jury dehors en pleine nuit pour montrer le bouzin qui tourne.

Dans ces conditions il faut un rapport béton qui montre que vous seriez prêts à rejoindre le joyeux monde réel.

Le BTS est orienté vers l'industrie, des solutions pragmatiques avec une petite vision du cout pendant l'étude.

Quand tu as des normes existantes et plein de logiciels il peut être bien vu de les intégrer au produit.

Bon ciel

Non je ne vais pas bosser pour une Entreprise... c'est juste un projet pour l'épreuve de BTS. Bien sûr on ne va pas faire une démonstration en pleine nuit lors du projet... Pour l'instant tout est question de théorie et d'appliquer ce qu'on a appris et d'en apprendre d'avantage.

Pour ce qui est cout du projet / normes etc... on explique tout ça lors de la présentation à l'oral.

Bref.

Leimury · 9 avril 2014

Après tout c'est juste un diplôme de technicien supérieur,

l'industrie n'a strictement rien à voir là dedans.

:dehors:

Fred_76 · 9 avril 2014

bon en ayant implanté l'algorithme à l'appli, nous avons beaucoup de bug

Donc il faudrait partir sur une base de 1296000 sec au total?

Sachant que le codeur final est un codeur de 1024 pas, pour chaque pas, on augmente de (1296000/1024 =) 1265.625 sec. mais du coup on obtient un chiffre à virgule.

Peut-être faire un arrondi à l'entier supérieur ? Quoique ça pourrait perturber le résultat final pour l'observation :/

Ton codeur a 1024 pas. Pour 360° ca te fait 1265.625 secondes, ou encore 0° 21' 5.625", c'est OK. Par contre ton moteur pas à pas, il a combien de pas par tour, as tu une démultiplication ? C'est le décompte des pas du moteur qui doit être suivi. Le retour du codeur est juste là pour vérifier qu'un pas n'a pas ripé au passage et corriger le suivi en conséquence.

Meow · 9 avril 2014

Après tout c'est juste un diplôme de technicien supérieur,
l'industrie n'a strictement rien à voir là dedans.

Je ne sais pas comment je dois le prendre... J'essaye juste d'obtenir de l'aide auprès de votre communauté et j'ai l'impression qu'on essaye de me rabaisser..

"Oulahhh... c'est du code plus que très basique et tu nous demandes notre avis ? Je n'ose pas imaginer pour le reste du codage."

"Tu prévois de bosser chez Shadock incorporated ?"

Enfin voilà, les remarques comme ça ne sont pas nécessaires et n'améliore aucunement la discussion. Je demande juste un peu d'aide, des avis.

Meow · 9 avril 2014

Ton codeur a 1024 pas. Pour 360° ca te fait 1265.625 secondes, ou encore 0° 21' 5.625", c'est OK. Par contre ton moteur pas à pas, il a combien de pas par tour, as tu une démultiplication ? C'est le décompte des pas du moteur qui doit être suivi. Le retour du codeur est juste là pour vérifier qu'un pas n'a pas ripé au passage et corriger le suivi en conséquence.

Effectivement, donc les décimales pour les secondes ne posent pas vraiment de problèmes, merci de m'avoir éclairci sur le sujet.

Malheureusement notre maquette ne possède pas de moteur. (je le croyais au début) du coup ça fait parti des améliorations futurs du projet.

Les valeurs des codeurs sont lues par la carte Raspberry sur ses ports GPIO. A l'aide d'un programme en python, il fait les calculs (incrémentations/décrémentation) des codeurs et renvoie les valeurs par wifi (via socket) à notre application sur la tablette.

Fred_76 · 9 avril 2014

Effectivement, donc les décimales pour les secondes ne posent pas vraiment de problèmes, merci de m'avoir éclairci sur le sujet.

Malheureusement notre maquette ne possède pas de moteur. (je le croyais au début) du coup ça fait parti des améliorations futurs du projet.

Les valeurs des codeurs sont lues par la carte Raspberry sur ses ports GPIO. A l'aide d'un programme en python, il fait les calculs (incrémentations/décrémentation) des codeurs et renvoie les valeurs par wifi (via socket) à notre application sur la tablette.

Le codeur 1024 pas aura donc une précision de 21 minutes environ. Ce n'est vraiment pas terrible. Pour mémoire, le diamètre de la Lune est de 30 minutes environ.

Une solution pour augmenter la précision sera de démultiplier le mouvement de la roue codeuse, par exemple en mettant un engrenage ou une courroie sur la base de la monture. Quand la base ferait 1 tour, le pignon en ferait N et le codeur se trouvant sur le pignon pourrait compter bien plus de pas : N x 1024. Pour une précision de 0.5 minute environ, il te faut N = 42.

Je ne sais pas comment je dois le prendre... J'essaye juste d'obtenir de l'aide auprès de votre communauté et j'ai l'impression qu'on essaye de me rabaisser..

"Oulahhh... c'est du code plus que très basique et tu nous demandes notre avis ? Je n'ose pas imaginer pour le reste du codage."

Enfin voilà, les remarques comme ça ne sont pas nécessaires et n'améliore aucunement la discussion. Je demande juste un peu d'aide, des avis.

Je ne cherche pas à te rabaisser. Sinon je n'aurais pas écrit le reste dans mes messages. Sauf que tu poses des questions pointues, alors imagine ma stupeur quand j'ai vu que tu nous demandais des conseils pour faire un compteur en degré/minutes/secondes en Java : c'est du b-a-ba de la programmation. Si tu bloques sur cette difficulté, permets moi d'avoir des doutes sur le reste du projet...

Modifié 9 avril 2014 par Fred_76

Meow · 9 avril 2014

Le codeur 1024 pas aura donc une précision de 21 minutes environ. Ce n'est vraiment pas terrible. Pour mémoire, le diamètre de la Lune est de 30 minutes environ.

Une solution pour augmenter la précision sera de démultiplier la sortie du pas codeur, par exemple en mettant un engrenage sur la base de la monture. Quand la base ferait 1 tour, le pignon en ferait N et le codeur se trouvant sur le pignon pourrait compter bien plus de pas : N x 1024. Pour une précision de 0.5 minutes environ, il te faut N = 42.

Je ne pense pas que cette solution soit possible. Les codeurs sont fixés au prototype :/

Merci quand même

Je tiendrai au courant de l'amélioration

Connexion

[Besoin d'aide] Projet d'aide BTS

Messages recommandés

Rejoignez la conversation !

En ligne récemment 0 membre est en ligne

Annonces

Aider Webastro

Information importante