Reprise du message précédent :

 
Dites, j'ai certainement une question très con
Je regarde beaucoup de vidéo sur le télescope James Webb. Passionnant.  
Ma question est : comment manœuvre-t-on le télescope pour le pointer vers l'endroit voulu ? Je suppose qu'il a du carburant pour le déplacer quelque peu ? Ou est-ce uniquement électrique et donc limité vers un secteur unique ?  
Si vous comprenez ma question
 
Merci de vos retours

j'imagine que c'est des roues inertielles et/ou des propulseurs gaz froid, mais curieusement je trouve pas l'info précise sur wikipedia

roues de réaction + RCS

En détail
https://www.jwst.fr/2022/02/pointag [...] telescope/

Euclid fonctionne nickel
https://www.esa.int/Science_Explora [...] es_to_come

Le but est d'utiliser au maximum les roues à réaction pour orienter le téléscope sur 3 axes. Le principe est de varier à la demande la vitesse d'un volant d'inertie (avec un moteur électrique). Par conservation du moment angulaire, l'engin va tourner dans le sens opposé au sens de rotation du moteur. Ces roues peuvent fonctionner en couple (l’une pouvant décélérer le mouvement engagé par une autre).

Au bout d'un moment les roues sont saturées (elles tournent à leur vitesse maximale) et l'emploi des propulseurs est nécessaire pour remettre le JWST en place et laisser les roues ralentir.

https://www.jwst.fr/2022/02/pointag [...] telescope/

Premières lumières d'EUCLID  

 
 
NGC 6822
 

 

 
https://esawebb.org/images/potm2307a/
 
https://esawebb.org/images/potm2307d/

Le contact avec Voyager 2 a été perdu  

https://www.theguardian.com/science [...] ng-command

Ha c'est ballot
Mais bon je ne sais pas si on avait beaucoup de science encore à faire avec.

Ah si, carrément, les 2 Voyagers explorent les limites de l'héliosphère et on attend toujours qu'elles atteignent l'héliopause pour savoir où commence le milieu interstellaire. C'est carrément de la bonne science et y'a rien qui se substitue à une mesure in situ.

Des données uniques sur l'espace interstellaire, et un duplicat avec Voyager 1
Le RTG n'en a plus pour très longtemps de toutes façons (quelques années tout au plus)

Mais bon, je suis un peu sentimental avec Voyager 2. Pour moi, c'est LA sonde, mes premiers souvenirs d'exploration spatiale (Neptune en 1989), donc le jour où la mission sera finie, je serai bien triste  

Et à la NASA, ils doivent être pareil vu qu'ils essayent par tous les moyens de la récupérer :
In the coming week, the Canberra antenna – part of Nasa’s Deep Space Network – will also bombard Voyager 2’s vicinity with the correct command, in the hope that it hits its mark, according to Nasa’s Jet Propulsion Laboratory, which manages the Voyager missions.

Et si ça ne marche pas, ya un reset prévu en octobre :
Otherwise, Nasa will have to wait until October for an automatic spacecraft reset that should restore communication, according to officials.

Boh, ça va, deux mois à attendre avant le reset, c’est pas la mort.

 
bonsoir,
j'ai vu le sujet sur netflix :
https://www.netflix.com/fr/title/81473680
 
j'ai appris qques petites choses qu'un neophyte ne sait pas forcément :
ariane a déjà connu des ratés (:o) en crashant juste après le décollage
le hubble (prédécésseur de webb) a été envoyé avec une optique mal réglée (:D)
 
 
 
mais j'ai aussi qques questions :
a/ ils confient dans le reportache que les photos spatiales obtenues de webb, sont colorisées parce que l'optique/capteur est en noir et blanc : ya un wtf n/b vs couleurs, j'ai pas compris le truc : choix spécifique/délibéré, ya un truc avec les couleurs dans l'espace? j'imagine que toutes les photos des planètes sont pas recolorées à la mano (c'est un truc à en déclencher de la conspiration )
b/ pourquoi avoir choisi ariane (nasa) au lieu de spacex (ou autres), notamment si ariane "perd du marché en raison de la baisse des prix"?
c/ l'opératrice "exécute des commandes" pour déployer le téléscope : ca marche comment l'info là bas? (1...)
d/ james webb, pour james bond et le web spatial 30.0?
e/ n'y a t-il pas de "bras robot" embarqué pour effectuer des maintenances à distance?
 
1. ce genre de satellite utilise quoi de manière générale comme système informatique? simple carte unix embarquée?
2. pour communiquer, a t-il différents systèmes redondés? est ce qu'en raison de la distance, il communique en une sorte de bas débit via communication différée?
3. peut il y avoir plusieurs ordis embarqués sur ce genre de satellite?
4. est ce que pour recevoir les images du webb, plusieurs satellites font relais entre celui ci et la terre?
5. est ce que le thinkpad est toujours la norme là haut?
6. est ce que des systèmes informatiques unix mais non linux (bsd ou autres) peuvent etre utilisés?
7. to be continued, les questions viennent avec les réponses
 
merci!

 
(je considère tout "unix", système n'étant ni windows évidemment, pas Linux Is Not UniX" non plus )
 
et ils sont pléthore, notamment dans le monde pro, embarqué, industriel :
les dérivés d'unix,
les bsd,
d'antan, il y avait os2, beos...
et yen a toute une page!
https://en.wikipedia.org/wiki/List_of_operating_systems
le plus connu du GP étant sans doute macos, cependant ici l'interrogation est dans le spatial, l'ISS ayant des thinkpad dotés de nux (mais pas tous)
je trouvais donc la question intéressante, notamment sur la diversité des os..
peut etre des os en temps réel?

b/ C'était la participation de l'ESA au projet, de plus elle a été choisie par rapport a son taux d'echec super bas
c/ C'est fini les commandes envoyées a la mano depuis longtemps La plupart du temps ce sont des TC timetagguée, ie qui s’exécutent a une date précise chargée a bord + automatismes bord

1/ cela se repose sur des systèmes d'exploitation propriétaires, le tout sur des proc dédiées et bindés, d'assez faible (voir ultra en compraraison avec ton téléphone) performances, regarde les spec d'un LEON3 par exemple.
2/ oui c'est redondé, avec généralement deux bande de fréquence utilisés, la bande S par défaut pour la donnée housekeeping (ie propre a la plateforme), puis X/Ka et cie pour les données science.
3/ oui, tout est redondé, plus plein de proc dédiés un peu de partout
4/ Non c'est en direct, en L2 tu as des passages avec la même station de plusieurs heures (voir jusqu'a 8h), pas besoin de relais
6/ Au sol oui

a) y'a pas de wtf, le capteur est n/b (plus sensible, et une matrice de bayer par exemple n'est pas un bon choix, puisqu'il va supprimer de l'information), et les filtres utilisés sont à bande courte (y'a qu'une partie du spectre qui passe, tu peux faire un test avec une frontale rouge, tu ne verra qu'une variante de rouge vers noir). Après on associe une couleur par filtre, et on empile
Une image colorée spatiale, y'a et y'aura toujours un peu d'"art" dedans
je suis sur le pc du boulot, je dois avoir un exemple de traitement de brutes/image sur l'autre, je filerai au besoin
pour les filtres ça ressemble à ça en version IR puisqu'on parle du James Webb : https://www.telescopes-et-accessoir [...] 2x39870620

Analogie "simplifiée", les images colorées sont comme une image photoshop chaque image N/B sert de luminanace pour un canal de couleur. La difference c'est que ce n'est pas une decomposition RGB prise en photo mais les longueurs d'ondes (d'une autre couleur voire carrement hors du spectre) qui sont ensuite utilisées comme R,G et B pour reconstituer l'image que tu vois sur ton écran.

 
Toute les images astronomiques, au sol comme dans l'espace, sont obtenus au travers de filtres précisément calibré. La lumière filtrée tombe sur des capteur CCD qui renvoient un résultat en niveau de gris.  Pour reconstituer la couleur, on fait une superposition de calque sur photoshop ou équivallent.
 
Quand le filtre est dans la bande optique (entre 0,3 et 0,6 µm en gros) on peut reconstituer la couleur réelle. Mais le JWST fonctionne quasi complètement dans l'infrarouge donc toutes les couleurs sont fictives.
 
Pour l'instrument MIRI (infrarouge moyen) du JWST la roue à filtre ressemble à ça:
 

 
 

 
Parce que l'Europe est partie prenante du projet JWST, et que le lancement est une forme de contribution, avec les instruments (dont MIRI fabriqué en France).
 
 

 

 
James Webb fut le deuxième administrateur de la Nasa, de 1961 à 1968, époque mythique pour la conquête spatiale. Son nom est en effet associé à la réussite du programme Apollo, qui permettra en 1969 à Neil Armstrong et Buzz Aldrin de fouler la Lune.
 

 
Non
 

 
https://www.jwst.nasa.gov/resources/ISIMmanuscript.pdf
3.6 Système logiciel de vol  
 
Le logiciel de vol ISIM (IFSW) est composé d'un ensemble de tâches indépendantes qui interagissent pour traiter les commandes provenant du sol, ou générées à bord à partir d'un plan d'observation stocké dans la mémoire du processeur. Les tâches résident dans un environnement de système d'exploitation adapté aux composants matériels spécifiques à la mission avec un ensemble de pilotes de périphériques personnalisés illustrés à la figure 21 en tant que services de système d'exploitation.  
 

Figure 21
 
 
Les tâches peuvent être classées en trois catégories :  
(1) Services de commande et de télémétrie,  
(2) Applications qui exploitent les instruments scientifiques (IS) et prennent en charge les opérations scientifiques, et  
(3) Services de support système qui gèrent l'environnement des tâches et les interfaces système externes.  
 
Ces tâches ont toutes été développées à l'aide d'IBM® Rational® Rose Real-Time® (RRT), un environnement de développement orienté objet qui propose une conception visuelle des tâches en tant que état machine (state machine) et définition de messagerie inter-tâches en tant que « ports » avec des « protocoles » , et qui utilise les conventions établies dans le langage de modélisation unifié ™ (UML ™).  
 
Les transitions entre les états sont définies graphiquement [Note de Moi: ] et le code de comportement peut être associé à des transitions ou à l'entrée ou à la sortie d'un état. Les transitions sont déclenchées par des événements spécifiés tels que l'expiration d'un timer ou la réception d'un signal sur un port.  
 
Le code du framework est automatiquement généré et combiné avec le code de comportement par RRT, ce qui réduit considérablement la quantité de code qui doit être écrit manuellement. Le même environnement de développement a été fourni aux équipes de développement de logiciels de Science Instrument pour faciliter l'intégration lorsque leurs applications sont livrées au laboratoire de logiciels de vol ISIM à Goddard. Goddard a défini et implémenté, à l'aide de RRT, un ensemble de ports d'interface de tâche standard auxquels chaque tâche se conforme et qui lui permet d'envoyer des paquets de commande, de recevoir des paquets de télémétrie, de recevoir des valeurs de table internes pour la configuration des tâches, de recevoir des informations sur l'heure système, d'effectuer des opérations sur les fichiers, utilisez des timers gérés de manière centralisée et répondre aux demandes d'enregistrement pour vérifier que chaque tâche est toujours en cours d'exécution.  
 
Au démarrage, chaque tâche lie ces ports et enregistre les informations clés dont le système a besoin pour fournir ces services. À ce jour, six des huit versions entièrement fonctionnelles de l'application SI ont été intégrées avec seulement quelques problèmes mineurs qui étaient pour la plupart simples à identifier et à résoudre, le système prend en charge le développement de l'I&T et des opérations, et toutes les exigences de performance importantes ont été respectées.  
 
Pour illustrer comment les tâches interagissent pour fournir les fonctions d'opération d'instrument souhaitées, nous décrirons quelques transactions retraçant le chemin emprunté par les messages successifs que la transaction comprend. Les transactions commencent généralement par la réception d'une commande, l'expiration d'un timer ou l'arrivée d'un paquet de télémétrie.  
 
Toutes les commandes entrant dans le système sont des messages, envoyés par une tâche à partir de son port de commande, qui sont mis en file d'attente pour le service par la tâche du gestionnaire de commandes qui envoie la commande à la tâche indiquée par l'ID d'application dans le paquet de commande. Une commande du sol sera reçue par le système de communication de l'engin spatial et transférée à l'ISIM par le processeur de commande et de télémétrie (CTP) de l'engin spatial. La tâche d'interface IFSW CTP, qui gère l'échange de toutes les commandes et la télémétrie entre l'ISIM et le vaisseau spatial, place la commande dans un message envoyé par son port de commande à la tâche du gestionnaire de commandes.  
 
 La principale source de commande dans les opérations normales est la tâche de processeur de script (SP), qui exécute des scripts écrits en JavaScript    lors de la réception d'une commande pour le faire.  
 
L'exécution du script est effectuée par un moteur JavaScript exécuté en tant que tâche distincte qui prend en charge dix JavaScripts simultanés exécutés indépendamment les uns des autres. Un ensemble d'extensions du langage JavaScript a été implémenté pour fournir l'interface au SP, qui à son tour peut accéder aux services ISIM FSW via les ports d'interface de tâche standard. De plus, pour fournir une communication entre des JavaScripts exécutés indépendamment, il existe des extensions qui peuvent définir et récupérer les valeurs des paramètres partagés. Une collection de JavaScripts, stockés sous forme de fichiers ASCII, constitue le système de scripts d'opérations, décrit à la section 3.7, qui offre la possibilité d'effectuer des opérations automatiques (voir Figure 22).  
 

 
 
Un JavaScript peut envoyer une commande en communiquant avec SP, qui envoie le paquet de commande au gestionnaire de commandes. Si la commande provenant d'un JavaScript est une fonction SI, telle que déplacer une roue de réseau vers une certaine position, la commande serait acheminée vers la tâche d'application pour ce SI. Cette tâche d'application SI peut générer de nombreuses commandes vers le matériel SI pour terminer l'opération demandée. Ces commandes matérielles sont envoyées via le gestionnaire de commandes à la tâche d'interface de bus, 1553 ou SpaceWire, qui se connecte au composant SI commandé. La même tâche d'application SI peut envoyer une commande au matériel SI, via la tâche d'interface de bus, demandant des informations d'état pour vérifier que la commande précédente a été correctement exécutée. Ces informations sur l'état du matériel seront reçues par la tâche d'interface de bus et formatées dans un paquet de télémétrie qui est envoyé par son port de télémétrie au gestionnaire de télémétrie, qui achemine le paquet vers toute tâche qui s'est abonnée pour recevoir des paquets identifiés avec cet ID d'application. Lorsque la tâche d'application SI reçoit ce paquet, elle peut décider si la commande a réussi, si l'opération est terminée ou si une erreur s'est produite. Chaque tâche émet à intervalles réguliers un paquet de télémétrie « de ménage » fournissant des informations générales sur l'état qui peuvent être visualisées en temps réel lors d'un contact au sol, ou enregistrées sur le SolidState Recorder et analysées ultérieurement sur le terrain. En outre, chaque tâche peut émettre des messages d'événement pour signaler des erreurs ou des opérations réussies.

Et encore ça c'est que pour la charge utile, pour la partie plate-forme ça doit être encore nettement plus compliqué (et oui voir du javascript c'est toujours un peu déroutant )

 
pourtant dans le reportage netflix précité, c'est exactement ce qui est montré :
j'ai pas la vidéo netflix sous la main, mais celle ci, avec le bras qui s'étend, est également présente dans le reportage, avec pour chacun des "mouvements" de la mécanique sur le télscope, entrecoupés des séquences du service correspondant au sol, qui "envoie les commandes" littéralement selon les communications vocales de la nasa au sol, à l'appareil pour qu'il suive le process. ca donne en tout cas l'impression que c'est effectué sur commande du sol jusqu'à l'espace, manuellement par chaque équipe dédiée, images de l'écran de l'opérateur à l'appui
https://youtu.be/IBPNi7uGgWM?t=8193
 

 
 
wow.... merci l'ingé esa, ca va me faire de la lecture
(meme si jvais pas tout comprendre, jpense que sans avoir fait supaero ou autre école d'ingé yen a pour un moment de tout décomposer )
 

En plus simple, on a un PC qui tourne avec un OS VxWorks, spécifique de système embarqué et écrit en C++
https://fr.wikipedia.org/wiki/VxWorks

La couche logicielle a été développée avec l'IDE graphique d'IBM Rational Rose Real-Time
https://www.ibm.com/docs/en/rtr/8.0 [...] rking.html

et le système est capable de faire tourner des scripts JavaScript au niveau de chaque instrument.

Du JavaScript  

https://www.bbc.com/news/world-66371569

Heartbeat reçu en scannant le ciel avec l'antenne australienne !

Hello,

Au début de jwst j'ai lu un excellent article qui expliquait le travail de colorisation des images.
- C'est en noir et blanc mais dans différentes longueurs d'ondes, donc comme dit au dessus, on applique une colorisation a chaque longueur d'onde. Chaque photo a une dizaine de calques en différentes longueurs d'ondes. La colorisation est bien entendu artificielle et faite "a la mano" (choisie par l'artiste/colorisateur), elle n'est pas forcément faite pour se rapprocher de l'image "en vrai" mais surtout pour faire ressortir les détails ou mettre en valeur un aspect spécifique de la photo prise.

Une fois le travail de colorisation fait, tu empiles chaque calque de longueur d'onde pour obtenir une photo colorisée unique. C'est fait en général à la mano mais ça va relativement vite.

Edit : ouais ok j'aurais du lire tout le reste, c'est mieux esspliqué que moi

C'est tout a fait commun pour les interfaces.
 
Comme dans la capsule Dragon
 

 
 
Dans plein de bagnoles aussi  

Je ne savais pas que ça avait si bien évolué

         
Allez, iono, NFS, gaz du sang et on la récupère !!    
 
L'occasion de voir ou revoir cette scène complètement badass d'un documentaire de James Burke (à 2'15) ayant pour fond le lancement de Voyager 2     :
 
https://youtu.be/cCJh5D0FCZk?t=90

 
Le meilleur de le meilleur  

Ouyi bien sur, on a divers procédures (parfois autour du millier) a appliquer selon le besoin, et on programme leur excécution sur le passage (ou alors on envoi des TC file faites par le centre dédié a la programmation de la mission).

Tu es à l'ESA Gilga ?

La pour le cas c'est utilisé pour faire des programmes annexes a ce qui tourne en PM RAM, que l'on ai pas a patcher une EEPROM pour chaque implémentation d'une nouvelle fonction bord (pour les OBCP : https://ecss.nl/item/?glossary_id=4149).

c'est un langage de haut niveau qui en vaut un autre, toute la fiabilité est dans le moteur d'interpretation du script comme d'hab et c'est pas récent comme techno

Le JavaScript au départ c'est un langage fini à la pisse, laborieusement réentoilé par des surcouches successives de frameworks.

Mais la base reste bien merdique  

Mais quelle violence monsieur Uruk

 
une fois de plus vous répandez la sagesse factuelle, cher monsieur

+1 sur le JavaScript, on continue à l'utiliser par paresse d'une remise en question.

pour ceux qui le boycottent pas ^^

https://esawebb.org/images/elgordo3/

https://www.youtube.com/watch?v=KSNRXoHxg7Q

Y a pas grand monde qui boycotte le javascript de nos jours, les fronts à la mode sont en angularJs

[HS]c'est des FW js, mais c'est plus forcément du js pur quand tu le codes (d'ou le fait que ca c'est répandu, ca et le fait que google a bcp investi dans les moteurs d'execution vraiment performant côté navigateur).
Bref.
Je dois dire que je m'attendais plus a voir du C, ou des langages plus exotiques mais reportés comme plus robuste aux erreurs et aux tests.