doc/Charges/cahier.mdown

159 lines
8.9 KiB
Markdown

# Cahier des charges
## Description du besoin
Dans le cadre du projet long de 3ème année et en étroite collaboration avec
Bastien Durix dont la thèse porte sur le sujet de l'extraction de squelettes,
notre rôle est de fournir un pipeline complet allant partant d'un ensemble
d'images en entrée dont on segmente les contours. On extrait ensuite le
squelette. En parallèle, on apparie les points. Une fois ces deux premières
étapes faites, on cherche à habiller et enfin à animer le squelette ainsi
habillé en définissant des points de rotation.
Nous définissons ici un cahier des charges aussi précis que possible : dans un
premier temps, nous spécifions le besoin, puis nous dressons une liste
d'exigences.
## Livrables attendus et dates de livraison souhaitées
On s'appliquera à livrer une archive contenant :
- une documentation détaillée
- les codes sources : une partie calibrage et mise en correspondance dont la
date de livraison espérée est prévue pour le 6 février, puis une partie
habillage et animation dont la date de livraison est fixée au 13 mars
- une formation au C++ 11
## Fournitures du client
Le client s'engage à fournir les éléments suivants :
- les programmes réalisant l'extraction de squelette
- les formules mathématiques permettant l'habillage du squelette
- les références aux articles sur lesquels s'appuyer pour l'animation
## Contraintes techniques imposées
Les contraintes techniques sont les suivantes :
- le langage de programmation sera le C++
- il est suggéré de s'appuyer sur la librairie OpenCV
- l'utilitaire de compilation suggéré est CMake
- les librairies utilisées doivent toutes être portables entre Windows et
Linux
## Contraintes de gestion de projet et de suivi qualité
Les contraintes de gestion de projet sont les suivantes :
- la programmation sera effectuée par pair programming
- au moins une réunion par semaine sera effectuée avec le client
- une réunion par semaine est programmée chaque jeudi après-midi de 15h30 à
16h30 avec l'industrielle
## Organisation client
Les clients sont une équipe de chercheurs composée de :
- Bastien Durix, en thèse à l'IRIT
- Sylvie Chambon, maître de conférence à l'IRIT
- Géraldine Morin, maître de conférence à l'IRIT
Au moins une réunion par semaine sera effectuée avec le client, deux en début
de projet pour la rédaction du cahier des charges.
# Gestion des risques
## Tableau des risques
| Id | Description | Cause du risque | Proba(1-5) | Conséquence | Gravité(1-5) | Actions préventives | Actions correctives | Etat du risque |
| --- | --- | --- | :---: | --- | :---: | --- | --- | --- |
| 1 | Mauvaise estimation du temps | Sous-estimation de la difficulté du problème | 3 | Livraison en retard | 4 | Prendre de la marge sur le planning, nommer un responsable de l'avancement des différentes tâches | Augmenter la charge de travail, revoir le planning | Ouvert |
| 2 | L'autre groupe ne livre pas à temps | Sous-estimation de la difficulté de leur problème, augmentation de la charge de travail au dernier moment | 2 | Retard pour les tests de la partie mise en 3D du squelette | 3 | Envisager une autre méthode pour pouvoir tester sur des cas simples | Implémenter soi-même une méthode de segmentation plus simple se basant sur un simple seuil | Ouvert |
| 3 | L'autre groupe ne livre pas les bonnes sorties | Mauvaise compréhension des termes du sujet | 3 | Les tests ne fonctionneront pas correctement | 1 | Se mettre d'accord sur le format | Développement d'une fonction de transition | Ouvert |
| 4 | Les binaires fournis par le client ne sont pas compatibles | Complexité des systèmes | 2 | On ne peut pas continuer le pipeline | 3 | Discuter avec le client à propos du binaire fourni | Emuler le système permettant d'utiliser les binaires | Ouvert |
| 5 | L'entente au sein du groupe est fragile | Différentes habitudes de gestion de projet, de programmation | 1 | Tensions, ambiance accablante, stress intense | 5 | Nommer un responsable de la cohésion | Organiser une médiation entre les deux partis | Ouvert |
| 6 | L'entente avec l'autre groupe est périlleuse | Le découpage un peu bancal du projet pourrait amener des tensions | 2 | Difficultés à gérer les parties communes | 3 | Apporter une offrande en gage de bonne entente | Faire des compromis | Ouvert |
| 7 | L'un des membres est absent pendant une période donnée | Maladie, évènement | 5 | Absence d'une personne | 1 | Mettre en place des solutions de télétravail | Adaptation du planning | Ouvert |
| 8 | Production de code non fiable, non maintenable et non lisible | Manque de maîtrise des technologies utilisées | 4 | Pertes de temps, mauvaise qualité, devoir refaire des programmes | 3 | Formation au C++ par un expert technique | Appel de l'expert | Ouvert |
| 9 | Besoin d'accéder à une ressource supprimée de manière urgente | Utilisation d'une commande de suppression, crash du matériel | 2 | Pertes de temps, devoir refaire des programmes | 5 | Utiliser git | Utilisation de techniques de récupération de fichiers, longues et compliquées | Ouvert |
## Spécifications
### Partie appariement
- En entrée : $n$ images d'un même objet photographiées selon $n$ points de vue
différents sur un fond unis de même couleur (vert, rouge ou bleu) dont une
sera l'image de référence. Pour un même objet, les conditions de prises de
vue (éclairage, appareil photo, position de l'objet) doivent être les mêmes :
entre deux photos, l'objet ne doit pas bouger, c'est l'utilisateur qui se
déplace. Si le temps le permet, on pourra envisager de suspendre l'objet pour
les prises de vue. On définira une résolution minimale. Un marqueur (croix)
servant à calibrer par la suite la caméra sera visible sur le papier. On
définira précisément la façon dont ces marqueurs seront présents : un damier
risque de géner la segmentation. Des croix espacées régulièrement seraient
plus discrètes mais pourraient aussi géner. On se demande s'il serait
possible de n'afficher que 4 croix pour définir 4 coins.
- Traitement :
1. Appliquer SIFT sur chaque photo pour récupérer un ensemble de points
d'intérêt par photo. Les paramètres de l'algorithme SIFT seront à définir.
1. Définir les paramètres intrinsèques de la caméra sous la forme d'un fichier
au format xml (matK).
1. Définir les paramètres extrinsèques de la caméra à l'aide des marqueurs :
les détecter puis calculer l'homographie.
1. Appariement des points d'intérêt.
- En sortie : Des paires de correspondances de points d'intérêt entre l'image
de référence et une autre image.
### Partie habillage
- En entrée : un squelette 3D (B-Splines) et une fonction de rayon.
- Traitement : Utilise les surfaces canales.
- En sortie : Un maillage 3D (points et faces).
### Partie animation
- En entrée : le maillage 3D, les points d'articulations sur le squelette
et leur degré de liberté associé.
- Traitement: à élucider ?
- En sortie : l'affichage d'une animation.
### Définition des tâches
| | Détection des points d'intérêts | Appariement | Calibrage interne de la caméra | Calibrage externe de la caméra | Reconstruction 3D du squelette | Habillage | Animation |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Conception | | | | | | | |
| Rédaction de la documentation | | | | | | | |
| Préparation des tests | | | | | | | |
| Implémentation | | | | | | | |
### Matrice de Rasci
| | Groupe 8 | Chef de projet | Service qualité | Equipe 1 | Equipe 2 | Client | Régine Nigris|
| --- | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
| Prise des photos | R | I | I | A-R | R | C | |
| Détection des points d'intérêts | | C | I | A-R | | C | |
| Appariement | | C | I | A-R | | C | |
| Calibrage interne de la caméra | | C | I | | A-R | C | |
| Calibrage externe de la caméra | | C | I | | A-R | C | |
| Reconstruction 3D du squelette | | C | I | R | A-R | C | |
| Habillage | | C | I | | | C | |
| Animation | | C | I | | | C | |
| Gestion de projet | | A | R | R | R | | C |
### Exigences
1. L'algorithme doit pouvoir évaluer les paramètres extrinsèques à partir des
marqueurs.
1. L'algorithme doit pouvoir évaluer les paramètres intrinsèques de la caméra.
### Rôles
Afin de réaliser le projet dans de bonnes conditions, nous avons choisis de développer notre prototype en travaillant par *pair-programming*, c'est à dire travailler en parallèle par groupe de deux. La cinquième personne serait quand à elle mobile et servirait de support aux deux groupes en cas de blocage sur un aspect technique. Le poste de *support technique* pourra éventuellement être tournant.
La répartition initiale des rôles est la suivante :
- Le chef de projet : Thomas Forgione
- Responsable qualité : Amandine Pailloux
- Expert algorithmique : Thierry Malon
- Gestion des ressources humaines : Marion Lenfant