gehelem

d'une part personne n'a envie d'en arriver là, et d'autre part en effet ça a peu de chances d'aboutir... C'est aussi ce que j'ai compris, et comme ça a été gentiment indiqué auparavant "ça sert à rien ce fil, du coup" Bon après sur la centaine de contributeurs d'indi, il suffirait d'un 🙂 Coté gphoto c'est plus probable, il me semble que j'avais trouvé qq précédents (ou qu'on m'en avait parlé ? je ne sais plus) Bref, personne n'a rien à gagner de ce coté là non plus. De toute façon l'initiative devrait venir de ZWO d'une façon ou d'une autre, mais c'est mal barré aussi.

Hello J'avais décidé de laisser ce sujet de coté, je dois reconnaître que ça m'a fait du bien. C'est un peu à contrecœur que je suis presque obligé d'y revenir un an après, vous allez comprendre. Nous avions laissé nos précédents échanges sur ce constat : ZWO a fini par ajouter une sorte de liste des composants utilisés sur l'ASIair dans les menus de l'app sur smartphone. Les deux parties (pardon de schématiser ainsi, mais je vois mal comment le dire autrement) étaient restées sur cette extraordinaire avancée : -- Pour les uns - vous voyez, finalement ils sont pas méchants chez ZWO puisqu'ils ont reconnu le problème. -- Pour les autres - enfin on a réussi à les faire bouger. En tout cas c'est à peu près comme ça qu'ici ce fil s'est arrêté, et tout le monde est retourné prêcher pour ses paroisses. (moi le premier, j'aime pas me friter). Mais nous avions laissé un sujet important de coté : La publication du code modifié par ZWO. Petit rappel, au moins pour ce qui concerne certaines licences (GPL2/3), tout le monde peut utiliser du code qui utilise cette licence à condition : - de mentionner cette licence. - de publier le code modifié s'il y a lieu. C'est cette seconde obligation qui était restée sans avancée particulière. Sauf que le sujet continue à vivre ailleurs, et avec des types qui ont fouillé un peu plus qu'ici. C'est très probablement pour cette raison qu'il y a trois jours ... tadaaa .... : https://m.facebook.com/story.php?story_fbid=pfbid02J24WmHyFgeBe2ZMeXU8PPycMa7p76gXaLADXj3NpxPRo22675YE93qKF2Xds1Fzpl&id=100064365712721&mibextid=Nif5oz Et donc ? Lisez bien. Je me suis aussi senti un tout petit peu visé par le "few recent social media", d'où mon obligation/besoin de réagir. Ne me demandez pas d'aller le faire dans cette poubelle qu'est FB, j'ai pas envie de me coltiner les hordes d'utilisateurs promoteurs. Détaillons un peu le cours des événements. Sur le post que j'avais créé sur le forum indi, un intervenant est arrivé dernièrement avec des arguments et des preuves bien plus solides que celles qu'on a vues ici jusqu'à présent. je passe sur la technique, vous trouverez ça ici : https://indilib.org/forum/development/10380-asiair-and-opensource-software-licences.html?start=24 Il a aussi ouvert un sujet sur Reddit J'insiste : le monsieur n'a pas cherché à fumer les mots de passe ou les mécanismes de protection De ce que j'ai compris, il s'est contenté d'analyser l'image de OS fournie par ZWO, avec un œil bien affûté. Il a été assez insistant auprès de ZWO, je pense que c'est ce qui a déclenché ce communiqué. Et désormais je vous mets au défi d'aller argumenter quoique ce soit qui dirait que ZWO est dans les clous à propos de ces licences : Oui, l'asiair est littéralement truffé de briques opensource Oui, le code a été modifié Non ce code modifié n'est pas disponible Les repos publiés par ZWO sur github sont un écran de fumée, ils ne correspondent pas du tout à ce qui est présent réellement dans l'ASIair La conversation sur reddit est assez intéressante à suivre, je vous la conseille si le sujet vous chatouille. Personnellement je trouve que transformer ça en "Allegations" ou "rumors" est assez gonflé de la part de ZWO https://www.larousse.fr/dictionnaires/francais/allégation/2327 "We strictly follow open-source protocols for the open-source software and libraries used by ASIAIR" Euh, non. absolument pas (je ne développe pas encore une 25000ième fois, tout est ici et ailleurs) "Our teams regularly publish open-source development of the relevant software and libraries involved" Euh, non. absolument pas. Voir point 4 ci-dessus, et éléments apportés Même la conclusion ne manque pas d'air : "ZWO retains all rights over ASIAIR's software (...)" Euh, non. absolument pas : Je rappelle donc entre autres que ce qui permet à l'ASIair sa très grande compatibilité avec toutes les montures, c'est bel et bien le serveur Indi, accompagné de tous les drivers associés à chaque type de monture. Ce qui permet à l'ASIair sa très grand compatibilté avec de nombreux DSLR, c'est bel et bien Gphoto. Rien ne l'interdit, au contraire. Mais mais mais ... l'un et l'autre (et d'autres) ont été bridés pour donner une exclusivité au matériel ZWO (caméras/RAF/focuseurs => exit) donc-il-faut-pu-bli-er-les-sources. Bref, je n'argumente pas plus, je vais encore me faire appeler Hortense. Le pompon ça a été ceci, à prendre avec des pincettes parce que c'est pas neutre non plus : https://www.cloudynights.com/topic/850846-player-one-first-cooled-camera-series-poseidon-m-pro-and-poseidon-c-pro-released/#entry12611354 En gros ZWO fait pression sur les revendeurs US pour avoir l'exclusivité => exit les petits nouveaux comme player one. Ce n'est pas interdit, mais qu'on ne me fasse plus le coup du cuicui les ptis oiseaux, ils sont gentils chez ZWO. Ce sont des commerçants, avec des techniques agressives. Et pendant ce temps là, ça te fait le buzz sur Facebook en te réinventant la caméra dual CCD pour guider. Les fanboys sont chauds chauds chauds. Ceci dit heureusement que les anciens viennent vite les calmer en leur expliquant, c'est ça qui est bien. Moi franchement ça me fatigue d'avance de repartir là-dedans, mais il me semble que ce fil le méritait. Allez, à vous Cognacq-Jay. Gilles.

un petit rappel, c'est ce soir et ça commence à 21h N'hésitez pas à nous rejoindre G.

Bonjour Ce jeudi à 21h sur le discord Astro-fr nous vous proposons une présentation d'utilisation d'un interferomètre de Bath, pour sonder les entrailles d'un miroir en cours de taille. N'hésitez pas à nous rejoindre ! G. https://discord.gg/Um2kd8gB?event=1088027506440933376

C'est époustouflant le soin que tu apportes à cette réalisation ! Nous sommes nombreux à baver devant le niveau, j'te l'dit, moi

Le même commanditaire qui m'dit : "et ton truc, y ferait pas des graphes de la météo" ? Maintenant, oui : Je me suis un peu amusé : l'utilisateur peut sélectionner n'importe quelle valeur numérique exposée par ses drivers indi (truc météo ou n'importe quoi d'autre, genre température du CCD) et ça fait un graphe avec tout con. il faudrait que je fasse un seul graphe, mais c'est la misère avec les échelles variables

Une petite commande spéciale de cet après-midi "il fait les khéogrammes ton machin ?" Je me disais que ça ne devait pas être bien compliqué du coup j'ai tenté. Il faut dire que Qt me sauve la mise une fois de plus, ça s'écrit presque comme "copie/colle la barre du milieu sur la droite du khéogramme précédent" (et je suis très content de ne pas avoir eu à utiliser OpenCV, j'ai eu peur ce machin c'est la misère) Zou. J'ai d'ailleurs réalisé que je pourrais faire pareil avec le timelapse : pour le moment je ne le génère qu'à la demande avec ffmpeg, une fois que tous les clichés sont prêts. Du coup c'est long pour le petit Rpi3 A priori je devrais pouvoir me contenter d'ajouter le cliché courant à la fin du film... on va voir ça. En attendant :

ça commence à faire une chouette petite collection 🙂

... et un machin pour faire le goto, avec un catalogue qui va bien (pompé chez @vinvin et @lock042 , merci beaucoup !)

ça y est, j'ai codé les trucs pour charger/sauvegarder des configurations ( = ensemble de modules+profiles) ... ça m'a l'air de fonctionner ...

J'ai plus d'idée de trucs à faire. Jm'ennuie.

bon, je pense que la situation est rétablie attention donc : ostserver-daily était le seul qui contenait des trucs jsuqu'à présent , et avec la branche stable d'indi maintenant c'est changé : il pointe sur la branche nightly d'indi Donc à vous ô valeureux beta testeurs qui seraient déjà passés par ici et qui voudraient recommencer : je vous conseille amicalement et fermement de basculer sur mon ppa ostserver (tout court, pas le daily) Et désormais les builds se font bien pour armhf sur mon daily, youpi ! Je vais regarder si la pulpe se secoue bien dedans.

Amis bidouilleurs attention : Je suis en train de faire quelques manœuvres sur mon launchpad pour avoir des builds armhf sans bouger le petit doigt, mais en les compilant directement avec les nightlies d'indi J'ai pris les options suivantes : - L'archive ostserver (tout court) est construite avec indi-stable - L'archive ostserver-daily est construite avec indi-nightly Je n'ai pas encore différencié ma source à moi, ce sera le même code ostserver/ostmodules qui sera compilé dans les deux. A terme, il faudra sans doute que je dirige vers un truc "release" de mon coté, ou je sais pas quoi mais qqch du genre. Je pense que je vais galérer un peu à faire ça (c'est déjà en train de péter), mais ça m'intéresse bien d'avoir des builds pour mon RPI3 sans lever le petit doigt Les manœuvres sont en cours, donc faites gaffe prenez un café avant si vous êtes d'humeur beta testeuse. N'allez pas me gâcher votre dimanche à installer des merdes sans réfléchir un peu avant : Danger. G.

2023-03-18 18-46-09.mkv

Me voilà avec un petit séquenceur tout simple, qui m'a l'air de marcher

Hop, 6 coches en plus qui devraient me permettre de tester en vrai Accessoirement, en choisissant les bonnes j'arrive à guider partout - ça va bien m'aider

Ahhhh, en effet c'est vicieux Possible d'ailleurs que ce soit aussi à l'origine de mon problème ... Il va falloir que je teste en vrai pour vérifier, et probablement que j'ajoute les mêmes coches d'inversion (au moins pour faciliter l'analyse) Merci !!

Merci pour tes encouragements ! Tu peux être plus précis sur ce qu'il fait de mal ? Là moi c'est même pas le retournement qui pose problème, c'est "juste" le coté où ça regarde Calibration+guidage Est => OK Calibration+guidage Ouest => KO Il faudrait que j'essaie ceci Calibration Est + guidage Ouest et inversement J'y cours Je me dis qu'en utilisant la propriété "pier side" de la monture je devrais arriver à piger puis corriger ... Calibration à l'Est + guidage à l'Ouest = la correction en RA se fait à l'envers, du coup : Calibration à l'ouest + guidage à l'ouest : Calibration à l'ouest ++ guidage à l'est : ==> je pense qu'en ajoutant un "-" qq part dans la phase de guidage en fonction du "pier-side" je devrais arriver à corriger dans le bon sens mais je ne comprends pas le fond du problème 🙂

Je me suis rendu compte que les builds armhf sont dispos sur les nightlies !! Du coup hop, sur le pi3 Et compil ost dessus, vu que j'ai bazardé mon ppa armhf... Et donc, depuis le téléphone...

bon, héhé, finalement 🙂

Bon alors celle là elle déchire : J'avais laissé le truc en l'état sans me rappeler que ça marchait déjà un peu. En gros c'est le drift plot (mais en pixels) lors d'un guidage Et le résultat ressemble vraiment beaucoup à ce que me sors Ekos, dans à peu près les mêmes conditions de simulation : > on s'approche d'un test grandeur nature, il serait temps Je vais essayer de mettre en place le graphe temporel et les stats (le fameux RMS), ça va moins rigoler mais juste besoin de temps. Mais le seul vrai problème ... ça ne fait du guidage qu'à l'Est Si je pointe à l'Ouest ça part en sucette 🙂 Bref, on avance G.

Tests concluants sur ma VM, j'en ai profité pour ajouter qq bricoles : - ajout des fichiers nécessairess pour créer un deamon (service) - un script d'install pour ostserver / indiwebmanager / indi / service ost / qq index astronmetrie (à améliorer pour rendre le user dynamique, là j'ai mis "ost" en dur) Ma allsky et mon CCD inspector sont en train de cuire sur le Launchpad on testera tout ça demain En attendant, premières vraies images en indi 2 :

bon, le pour et le contre ont été pesés et la décision a été prise : On passe à Indi 2 Je vais galérer à suivre les lascars de Kstars, mais il aurait de toutes façon fallu y passer. Et accessoirement autant couper tout de suite des usages voués à l'abandon (les mentions "deprecated" ça fait pas sérieux quand on compile, je trouve) Donc j'ai essayé, je ne peux pas dire que ça a été facile mais j'y suis arrivé. La façon dont c'est codé me semble plus moderne, mais je manque vraiment d'expérience pour juger. Bref : Le build d'ostserver est en cours sur mon launchpad, j'ai besoin de savoir si ça fonctionne jusque là-bas. Je testerai demain avec ma juge de paix préférée : une VM tout fraiche. Le temps de l'écrire, le jeu de builds est ok, il faut juste attendre qu'il soit publié (et du coup dodo) (autre Inconvénient transitoire : j'ai coupé mon truc en armhf perso pour le moment) Je migrerai les modules ensuite, c'est sans doute là que je vais avoir le plus d'adaptations à faire. M'enfin ça ne devrait pas pisser trop loin, juste les méthodes de signaux des propriétés indi à modifier il n'y en a plus qu'une pour tous les types de propriétés, au lieu d'une sur chaque type : "updateProperty" En lieu et place de newNumber / newText / newSwitch / ... C'est pas mal en fait. G.

Trop facile d'accuser les autres. La nature humaine est ainsi faite. Bien entendu le problème était derrière le clavier. Quelle andouille. Mais remonter jusqu'à la "dernière version qui marche" avec git c'est super pratique, du coup une fois que j'ai trouvé la modif qui pète la correction a été vite trouvée. C'est publié sur mon ppa, donc amis testeurs...

6 heures après, toujours le brouillard. Je suis à la limite de la panique. ( = je me suis enfilé une bière) Donc je résume l'état des lieux des dégâts : Symptôme : les dialogues en websocket ne fonctionnent pas lorsque j'utilise les paquets buildés sur le Launchpad. Le front reste muet, il ne voit pas le back. (testé sur deux machines différentes NUC en 20.04 et une VM toute fraîche en 22.04) Pistes : Le front n'est pas en cause, en attaquant direct sur les websockets, la connexion échoue (Au passage découverte de ce petit outil "FireCamp" qui est bien pratique pour mes diagnostics, "mon expérience est la somme de mes échecs") J'ai donc creusé coté Qt : Le constat c'est que lorsque je compile mon code avec une version de Qt issue des distributions d'Ubuntu ça fouarre Accessoirement ça colle bien avec le build du launchpad Version de Qt annoncée =5.15.3 à l'inverse, si j'utilise le Qt "officiel" --installé avec leur installeur à la con--, ça fonctionne (test effectué sur le NUC, pas sur la VM) Version annoncée Qt =5.15.2 Vraiment curieux. Donc si un barbu qui passait par là avait une petite idée ça m'éviterait de picoler ... Merci d'avance G.