Todo list » History » Revision 11
Revision 10 (Rafael Bailon-Ruiz, 2020-10-26 15:02) → Revision 11/25 (Rafael Bailon-Ruiz, 2020-10-27 10:43)
h1. Todo list h2. Mapping h3. Ameliorer le traitement des donnees brutes la partie concerne plus particulierement le filtre "CloudSensorProcessing":https://redmine.laas.fr/projects/nephelae-devel/repository/nephelae_base/revisions/master/entry/nephelae/dataviews/types/CloudSensorProcessing.py. Par sentiment personnel, je trouve que son utilisation pourrait etre plus claire pour un utilisateur n'ayant aucune ou peu de connaissance sur le processus de debruitage du capteur. NOTE : le capteur est egalement susceptible de changer, evitant ainsi la dependance directe avec la batterie. h3. Apprentissage des hyperparametres Le kernel utilise la classe "WindKernel":https://redmine.laas.fr/projects/nephelae-devel/repository/nephelae_base/revisions/master/entry/nephelae/mapping/GprKernel.py qui utilise directement la "librairie scikit-learn":https://scikit-learn.org/stable/modules/gaussian_process.html pour effectuer les calculs de processus gaussiens. Le probleme est qu'aucun des parametres n'est appris au cours du temps. Integrer leurs calculs dans la boucle serait judicieux. NOTE : Se pencher sur les travaux des anciens stagiaires (si existants...) h3. Carte de vent Integrer une carte vent 3D qui puisse renvoyer a la fois des informations globales et locales par rapport a la position des UAVs, sur demande de l'utlisateur. Les cartes de bases couplees avec les filtres de vent offrent deja une premiere approche qui pourrait fonctionner. Il faudrait egalement prendre en compte les entrees utilisateurs, comme de nouveaux samples dans la database (cette partie deja faite sur les cartes de vent de bases). L'image suivante serait un bon debut pour obtenir ce que l'on souhaite. !windserver.jpg! h2. Interface graphique : h3. Cookies Facultatifs mais peuvent etre tres utile pour des developpeurs ne possedant qu'un seul ecran ou des ressources limitees. Le role des cookies ici serait de garder les parametres de visualisation de page (coordonnees dans la carte + zoom, length scale des vues...). Cela permettrait a un utilisateur de basculer d'une page a une autre sans s'embeter a retoucher les parametres a nouveau. *rbailonr* Django permet stocker des "configurations 'session'":https://docs.djangoproject.com/en/3.1/topics/http/sessions/ C'est mieux d'utiliser un framework existant que de gérer le stockage de la configuration à la main. De plus lorsque c'est preconisé d'etablir seulement une cookie session et sauvegarder les informations coté serveur. h3. Planner Integrer les appels du planner dans l'interface. Deux choix sont possibles : soit on modifie les pages existantes pour ajouter les plans, soit on cree des nouvelles pages + fonctionnalites dans de nouvelles pages. Pour tout les appels, reprendre les methodes utilises pour le module Mission : requetes pour get et requetes pour set. Voir "ici":https://redmine.laas.fr/projects/nephelae-devel/repository/nephelae_gui/revisions/master/show/web/nephelae_gui/config/missions. h3. Timelines de l'execution des plans L'idee est la suivante, voir s'afficher pour un UAV son plan initial et son plan effectif est leur evolution au cours du temps. Chaque mission est bornee temporellement de 0 a t, t etant la somme des temps des missions, et seraient disposees sur un diagramme de Gantt evoluant au cours du temps. On pourrait voir d'une part si le plan se deroule correctement, et son comportement par rapport au plan initial (si il est meilleur ou pire temporellement). Bonus point si un graphe est ajoute sur la meme page decrivant la consommation estimee est reelle au cours du temps. Utiliser un GraphLine comme sur les pages des sensors2d me semble judicieux. *rbailonr* On pourrait utiliser un diagramme de gantt pour afficher les taches de la mission. Il existent quelques bibliothèques pour créer des gantt interactifs en javascript; par exemple: https://frappe.io/gantt (tuto: https://www.cssscript.com/interactive-gantt-chart/) h3. Affichage des erreurs dans le GUI *rbailonr* Des nombreux erreurs de configuration ne sont affichés que dans les logs. Par exemple établir un rayon de cubature trop grand ou trop petit ne permet pas d'instancier un pattern dans CAMS, mais rien est indiqué à l'utilisateur. Il pense que tout est bon, mais rien ne va s'afficher dans l'onglet de validation des missions. h3. Nettoyage de l'API web *rbailonr* Actuellement l'API http utilisée par l'interface graphique ne suit aucun modèle et elle n'est pas documentée. En particulier: * C'est difficile de trouver le code correspondant à chaque appel * Le modèle de réponse JSON ne suis pas des bonnes pratiques: Les information renvoyées ne sont pas très riches et il n'y a pas de réponse lors d'une erreur. Nous devrions nous inspirer des API existantes (github, twitter,...) et des standards proposés ("JSON API":https://jsonapi.org/) pour créer une interface propre qui serait utilisée par le GUI. Des nouveaux outils pour interagir avec le serveur CAMS pourraient être rajoutés dans le futur h2. Planification h3. Acceptation et mise a jour des missions Paparazzi a un comportement particulier en ce qui concerne l'ajout des missions du a son utilisation de buffer circulaire pour gérer gerer le tout. Il faut prendre garde au fait qu'un ajout de mission dans une liste ne soit pas dépendant dependant de Paparazzi (ce problème probleme concerne plus les MissionsTypes en eux même meme que le Planner) h2. Documentation Documenter fréquemment frequemment chaque nouvel ajout, et terminer la documentation générale. generale. C'est une tache qui n'a pas vraiment de fin... Penser a chaque nouvel ajout son utilisation dans un script ou en ligne de commande. h2. Extras h3. Pour aller plus loin ajouter un superviseur ou moteur d’exécution. d'execution. Il sera utile pour faire des taches synchronises avec 2+ UAVs. L’idée L'idee serait qu'il puisse changer l’état l'etat du plan en UAV en réponse reponse a certains evenements ou signaux. h3. Pour aller TRES loin Installer un middleware pour la définition definition des messages. Le traitement sera propre aux modules (paparazzi ou autre autopilote). (Se pencher sur les middleware qu'utilise ROS2 et l'utilisation d'idl ?)