MASTER 2 INFORMATIQUE - UNIVERSITE DE FRANCHE-COMTE Projet Kinect Détection de mouvements intempestifs dans un bloc opératoire Benoît Bernardin et Paul Meyer sous l encadrement de Jean-Christophe Lapayre 2012-2013 Ce document est un rapport du projet tuteuré : «Détection de mouvements intempestifs dans un bloc opératoire» effectué dans le cadre du Master 2 Informatique à l Université de Franche-Comté.
Remerciements Nous tenons à remercier Jean-Christophe Lapayre pour l aide qu il nous a fourni tout au long de ce projet ainsi que les deux médecins, Daniel Talon et Daniel Pazart, pour leurs conseils avisés. Page 2
Sommaire Introduction... 6 I. Présentation de la Kinect... 7 a. API, kit de développement et langages de programmation... 7 b. Caractéristiques... 8 c. Reconnaissance physique... 9 d. Flux de données... 10 II. Le projet... 11 a. Etude du sujet... 11 b. Notre gestion du temps... 12 c. Développement de la version 1... 12 d. Améliorations et adaptation de l application (version 2)... 19 III. Axe futur de développement de l application et ses améliorations... 23 Conclusion... 26 Annexes Annexe 1 : Diagramme GANTT du projet.. 27 Annexe 2 : Solution de développement «OpenKinect»... 28 Page 3
Table des illustrations Figure 1 : Logo Kinect... 7 Figure 2 : La Kinect et ses capteurs... 8 Figure 3 : Champ de vision de la Kinect... 8 Figure 4 : Portée du capteur Kinect... 8 Figure 5 : Squelettes «trackés» et «non-trackés»... 9 Figure 6 : Espace 3D géré par la Kinect... 9 Figure 7 : Représentation d'un squelette tracké... 9 Figure 8 : Flux de données envoyés par la Kinect... 10 Figure 9 : Représentation graphique du sujet initial... 11 Figure 10 : Extrait du diagramme GANTT... 12 Figure 11 : Logo... 13 Figure 12 : Fonctionnement de la version 1... 13 Figure 13 : Tests de performances du calcul de l'écart-type... 14 Figure 14 : Comparaison des résultats du calcul de l'écart-type... 15 Figure 15 : Aperçu d'écran de la version 1... 16 Figure 16 : Inclinaisons verticale du capteur Kinect... 17 Figure 17 : Couplage «Kinect - ScreenAir»... 18 Figure 18 : Collaboration de Kinect... 19 Figure 19 : Schéma de l'interface graphique finale... 20 Figure 20 : Logo de la bibliothèque Dynamic Data Display... 21 Figure 21 : Fonctionnement de la version 2... 21 Figure 22 : Aperçu d'écran de la version 2... 22 Figure 23 : Extrait du fichier de sauvegarde des données... 23 Page 4
Bibliographie - Netographie A noter que la classification n est pas stricte. Chaque site ayant servi pour plusieurs catégories. Kinect et ses caractéristiques http://www.xbox.com/fr-fr/kinect http://msdn.microsoft.com/fr-fr/ http://www.microsoft.com/france/etudiants/formations/kinect-sdk.aspx http://www.microsoft.com/france/etudiants/telecharger/boutique/sdk-kinect.aspx http://fr.wikipedia.org/wiki/kinect Kinect et le développement http://msdn.microsoft.com/fr-fr/library/ http://sebastien.warin.fr/2011/01/05/1067-kinect-introduction-openkinect-openni-nite/ http://hawkcreation.com/kinect-commencer-developpement-applications/ http://devonkinect.wordpress.com/ Algorithme de B.P. Welford http://fr.wikipedia.org/wiki/the_art_of_computer_programming Livre «The Art of Computer Programming» de Donald Knuth Dynamic Data Display http://dynamicdatadisplay.codeplex.com/ http://research.microsoft.com/en-us/um/cambridge/projects/ddd/d3isdk/ http://msdn.microsoft.com/fr-fr/magazine/ff714591.aspx Ainsi que des tutoriaux et des forums d aide au langage C# et aux applications WPF.NET Page 5
Introduction Dans le cadre du Master 2 Informatique à l Université de Franche-Comté, un projet doit être réalisé en binôme sous l encadrement d un enseignant. De nombreux sujets sont mis à disposition selon l option et la spécialité de chacun. Désireux d apprendre et d évoluer, nous avons décidé de choisir l un des projets Kinect proposé : «Détection de mouvements intempestifs dans un bloc opératoire». En effet, la médecine est en constante évolution et appliquer l informatique au service de ce domaine est une idée qui nous a paru très intéressante. Il existe aujourd hui trois principales sources de contamination reconnues dans un bloc opératoire : la première est le malade lui-même rejetant des particules, on appelle cela la contamination particulaire à l opposé des contaminations bactériennes comme les deux autres sources à savoir les «va-et-vient» du personnel ainsi que leurs mouvements et déplacements. C est sur ces deux derniers points qu intervient notre projet. En effet, plusieurs études ont démontré qu il existait un lien très fort entre le niveau de mouvements dans un bloc et la quantité de bactéries détectées, et donc le risque de contamination du patient : on parle alors de maladies nosocomiales. Peu d outils permettent à l heure actuelle d avoir une vision immédiate ou temporisée du niveau de mouvements des personnes au sein d un bloc opératoire. Il existe juste un système de comptabilisation d ouverture/fermeture des portes mais cela ne reflète pas le niveau général de mouvements à l intérieur. C est ici qu intervient la Kinect : l idée, de départ, est de développer une application permettant la visualisation du niveau de mouvements et de déplacements des personnes au sein d un bloc opératoire grâce à cette caméra de reconnaissance et permettre l interprétation des résultats. Le projet s inscrivant dans le cadre d une collaboration entre l Université de Franche-Comté et l hôpital Jean-Minjoz, tous deux à Besançon (25), l idée de départ sera ajustée en fonction des besoins réels du personnel médical. Afin de comprendre le travail effectué et les enjeux possibles, nous allons, tout d abord, aborder la Kinect et ses fonctionnalités en faisant, bien entendu, le parallèle avec le monde médical. Nous détaillerons ensuite les différentes phases qui ont composées ce projet pour aboutir au résultat obtenu. Puis, nous terminerons par décrire les améliorations futures à apporter à l application développée et enfin, nous conclurons en expliquant l apport de connaissances et les différents problèmes/difficultés rencontrés. Page 6
I. Présentation de la Kinect Afin de reconnaitre les personnes à l intérieur d un bloc et pouvoir, ensuite, interpréter leurs mouvements, l utilisation d une caméra de reconnaissance était nécessaire. L une des plus connues et des plus utilisées est, sans aucun doute, la Kinect. La Kinect est, à l origine, un périphérique destiné aux consoles de jeux-vidéo Xbox360 de Microsoft permettant de contrôler un jeu sans manette. Cette caméra, utilisant des techniques d interactions, est basée sur un périphérique d entrée branché sur la console de jeux qui permet d interagir par commande vocale et par reconnaissance de mouvements ou d images. Ainsi, on peut jouer sur des jeux spécialement conçus pour cet outil sans aucune manette ni périphérique autre que son propre corps. En Février 2012, la Kinect a aussi été porté sur les ordinateurs : on parle alors de Kinect pour Windows en opposition à la Kinect pour Xbox360. Livrée avec un kit de développement, elle permet aux développeurs de créer des applications utilisant ce périphérique. Les fonctionnalités et les caractéristiques des deux Kinect diffèrent selon la destination, pour Windows ou pour Xbox360, mais cela ne perturbe pas Figure 1 : Logo Kinect notre développement. A noter que toutes les informations indiquées ci-après correspondent à la Kinect pour Xbox360. a. API, kit de développement et langages de programmation Après une version «beta» de quelques mois, l API 1.0 de Kinect est sortie en Février 2012 avec la correction de bugs et avec la possibilité de gérer jusqu à 4 capteurs Kinect sur une même machine. Peu de temps après, en Mai 2012, la version 1.5 de l API sort avec un lot important de nouvelles fonctionnalités : enregistrement des données du capteur, guide permettant d optimiser l interaction homme-machine et proposant de nombreux exemples, intégration d un module de suivi du visage en temps réel et en 3D (3 dimensions), possibilité de ne reconnaitre que le haut du corps (position «assis») et surtout la reconnaissance vocale en français disponible exclusivement en anglais auparavant. Depuis peu, Octobre 2012, la version 1.6 est disponible et ajoute quelques fonctionnalités. Néanmoins, celles-ci sont beaucoup moins intéressantes pour notre projet que la version 1.5 (exemple : prise en charge de la langue allemande). Citons, tout de même, la prise en charge de Windows 8 et de l outil de développement Microsoft Visual Studio 2012. A ce propos, nous avons commencé au départ avec la version 1.5 et l environnement de développement Microsoft Visual Studio 2010. C est au cours du projet, mais assez rapidement, que nous nous sommes portés sur l API 1.6 avec l utilisation de la version 2012 de Visual Studio. Page 7
Au sujet du langage de programmation, trois langages peuvent être choisis pour développer des applications avec la Kinect : C#, C++ ou VB. Notre choix s est porté vers C# car la communauté Kinect y est très riche. De plus, ne le connaissant pas du tout, c était pour nous l occasion de découvrir un nouveau langage en plein essor. b. Caractéristiques La Kinect dispose de trois capteurs : des lentilles détectant la couleur et la profondeur grâce à la technologie infrarouge (IR), un micro à reconnaissance vocale et un capteur motorisé permettant l orientation verticale de la tête de la Kinect pour suivre les déplacements. Figure 2 : La Kinect et ses capteurs Utilisable même dans le noir, la Kinect a un champ de vision horizontal de 57 degrés et un champ de vision vertical de 43 degrés avec une marge de déplacement de +/- 27 degrés grâce à la motorisation. Au sujet de sa portée, deux modes peuvent être privilégiés. Le premier, par défaut, détecte des personnes entre 0.8 et 4 mètres avec en pratique des distances approchant davantage les 1.2 à 3.5 mètres. Le second mode est dit rapproché. Il permet une détection entre 0.4 et 3 mètres (0.8 à 2.5 mètres en pratique). Toute personne se trouvant hors du champ de vision ou même à sa limite n est pas du tout reconnue par la Kinect. De plus, à l approche de ces limites et après quelques tests, nous pouvons affirmer que la reconnaissance n est plus fiable d où la différence entre les distances théoriques et pratiques. A noter aussi que le mode utilisé fait varier le degré du champ de vision. Figure 3 : Champ de vision de la Kinect Figure 4 : Portée du capteur Kinect Page 8
Toutes ces caractéristiques permettent à la Kinect de gérer un espace en 3D (3 dimensions) en X, Y et Z pour respectivement l abscisse (gauche ou droite), l ordonnée (assis ou debout) et la profondeur (près ou loin). Figure 6 : Espace 3D géré par la Kinect Figure 5 : Squelettes «trackés» et «non-trackés» c. Reconnaissance physique Vocabulaire : Pour la suite, nous parlerons de squelettes détectés par la Kinect et non de personnes. La Kinect peut détecter jusqu à six squelettes, assis ou debouts, au maximum : c est cette caractéristique qui devient l une des principales limites actuelles du périphérique. Parmis ces six squelettes, deux peuvent être reconnus totalement : on parle alors de squelettes «trackés» (suivi en anglais) tandis que les quatre autres sont appelés squelettes «non-trackés». L image ci-dessus montre cette fonctionnalité. Comme vous pouvez le constater sur la figure précédente, les squelettes «non-trackés» sont gérés différemment par rapport à ceux «trackés». Dans le premier cas, la Kinect reconnait un seul point correspondant à la position courante du squelette dans le repère X, Y, Z (voir figure 5) alors que dans le second cas, elle détecte 20 points représentant le squelette de la personne détectée : c est pourquoi nous parlons de squelettes et non de personnes. Ces points sont appelés des joints. Ils correspondent pour la plupart aux articulations de l Homme et constituent le squelette de la personne. La figure ci-contre détaille les 20 joints d un squelette tracké. Dans le cas d un squelette nontracké, un seul joint est pris en compte : HIP_CENTER. Chaque joint est associé à un squelette et est identifiable par sa position en X, Y et Z dans le repère 3D. Figure 7 : Représentation d'un squelette tracké Page 9
d. Flux de données Lors de la connexion de la Kinect à l ordinateur, un flux de données est créé afin de récupérer toutes les informations détectées. Ce flux de données correspond à une image de la scène : 30 images sont envoyées par seconde entre la Kinect (émettrice) et l ordinateur (récepteur). Une image est composée de trois flux : - Un flux «couleur» permettant de différencier les couleurs de la scène et d afficher le flux vidéo en couleur. Figure 8 : Flux de données envoyés par la Kinect - Un flux «profondeur» principalement lié au capteur infrarouge permettant de gérer l axe Z de la scène 3D et ainsi connaitre la distance à laquelle se trouve un squelette. - Et un flux «squelettes» associé à un tableau composé des 6 squelettes avec pour chacun : un identifiant leur étant attribué automatiquement, leur position globale (joint HIP_CENTER) et la position des 20 joints pour chacun des deux squelettes trackés. Cela représente donc une quantité considérable de données envoyées et pas encore traitées pour l instant A titre d exemple, 20 secondes de scène enregistrées correspondent à 500Mo de données : une opération de trois heures dans un bloc opératoire générerait alors plus de 260Go de données. L idée est de pouvoir traiter toutes ces données afin d atteindre notre objectif mais avec des traitements peu coûteux puisque les performances sont déjà réduites dû à ces flux. C est pourquoi, tout au long du projet, nous nous sommes souciés de l optimisation de notre code. Maintenant que nous connaissons davantage la Kinect : ses caractéristiques et ses limites, nous allons pouvoir nous intéresser au projet lui-même. Page 10
II. Le projet Nous allons, dans un premier temps, étudier le sujet et l objectif fixé au départ. Nous poursuivrons par la gestion de notre temps tout au long de ce projet en détaillant les différentes phases par lesquelles nous sommes passés. Ensuite, nous aborderons le développement de la première version de l application finalisée par une démonstration auprès de médecins. Nous regarderons les adaptations faites pour produire la deuxième version et enfin, nous terminerons cette partie en précisant l axe de développement futur de l application et ses différentes améliorations possibles. a. Etude du sujet L idée est d utiliser la Kinect pour détecter des personnes au sein d un bloc opératoire et notamment leurs mouvements et leurs déplacements. Ainsi, après interprétations et dans un cadre préventif, il sera possible d afficher un niveau d alerte leur indiquant de faire attention à leurs gestes. Figure 9 : Représentation graphique du sujet initial Dans un premier temps, cet objectif est fixé par notre responsable M.Lapayre sans aucune intervention de médecins. Le but est donc de créer une application répondant à ses critères afin d ensuite, la proposer aux médecins et de l adapter à leurs besoins réels. C est pourquoi, deux versions de l application ont été produites durant ce projet. La première correspondant à l objectif de départ et la seconde, correspondant à la première, adaptée aux besoins des médecins. En effet, une démonstration de la première version auprès de médecins de l Hôpital Minjoz de Besançon (25), nous a permis de l adapter afin de produire la seconde version. Page 11
b. Notre gestion du temps Afin de respecter les délais, l une des toutes premières tâches a été de déterminer les différentes phases du projet ainsi que d estimer approximativement le temps nécessaire à leur réalisation. Le tableau suivant, extrait du diagramme GANTT généré et visible en annexe 1, présente ces étapes avec le temps réel consacré. Figure 10 : Extrait du diagramme GANTT Etude des outils Version 1 Présentation Version 2 Préparation soutenance Point bilan quotidien avec notre responsable M.Lapayre Nous pouvons distinguer rapidement les principales phases du projet. Tout d abord, une première phase d étude des outils permettant d appréhender la Kinect et de choisir une solution de développement. Suit le développement de la version 1 de l application, finalisé par sa démonstration : évènement majeur et tremplin de notre projet. Enfin, il y a eu toute une phase d améliorations en conséquence de cet échange avec les médecins (version 2) jusqu à la préparation de la soutenance. Chaque semaine, un point «bilan» était réalisé avec notre responsable afin de lui montrer notre avancement et échanger avec lui sur d éventuelles difficultés. Cela nous a permis aussi d avoir une version toujours fonctionnelle de l application. c. Développement de la version 1 Avant tout commencement, il nous fallait choisir une solution de développement parmi deux existantes : la première, officielle, s appuie sur l API et le kit de développement Kinect ainsi que sur Microsoft Visual Studio. La seconde, présentée en annexe 2, est une solution open-source basée sur l impressionnant projet «OpenNI» et appuyée par une communauté très riche. Page 12
Après quelques recherches, les performances de la solution opensource ne sont apparemment pas aussi satisfaisantes que la solution officielle, c est pourquoi notre choix s est porté sur cette dernière. Le fonctionnement Figure 11 : Logo Microsoft Visual Studio Une fois la solution choisie, nous avons pu nous concentrer sur l application. L idée est donc de stocker les positions de chaque squelette au fur-et-à-mesure du temps et de les comparer ensuite pour savoir s ils bougent ou non. Ainsi, il est possible d interpréter le résultat de cette opération pour afficher un niveau global des déplacements dans une pièce. Comme évoqué précédemment, la Kinect envoie toutes les informations d une scène trente fois par seconde. Parmi elles, le flux de squelettes, associé à un tableau de six squelettes avec tous les renseignements nécessaires sur eux (identifiant, position, positions des joints pour les squelettes trackés etc.). Ici, nous nous sommes d abord concentrés sur la position globale des squelettes à savoir le joint «HIP_CENTER» (centre du bassin) pour savoir s ils se déplaçaient ou non. L idée est de conserver toutes ces informations, à la seconde, est de les comparer pour interprétation. Ainsi, pour un squelette donné, nous stockons ses positions dans une table de sauvegarde. Chaque seconde, nous prenons l ensemble des données stockées et calculons l écart-type pour avoir une valeur correcte du mouvement du squelette. Nous étions partis, au départ, sur un calcul de moyenne mais nous nous sommes très rapidement rendu compte que les valeurs obtenues n étaient pas du tout représentatives des mouvements. Nous nous sommes alors dirigés sur le calcul de l écart-type donné par la formule suivante : Le schéma suivant montre ce principe. Figure 12 : Fonctionnement de la version 1 Page 13
Dans un souci d optimisation, nous avons volontairement omis le calcul sur «Y» correspondant à des mouvements de bas en haut et ne reflétant pas un déplacement réel. De plus, les médecins s agenouillent ou s assoient très rarement à l intérieur d un bloc durant une opération. Grâce à ce calcul d écart-type sur «X» et «Z», il est facile ensuite d interpréter les résultats afin de déduire le déplacement d un squelette. Ainsi, après de nombreux tests, une valeur limite a été fixée temporairement pour savoir si un squelette est immobile ou se déplace. En bref, si l écarttype de l ensemble des valeurs prises est supérieur à cette limite fixée, nous savons que le squelette associé est en déplacement. Pour rappel, nous distinguons ici les «déplacements» et les «mouvements» d un squelette. Dans le premier cas, nous nous concentrons sur la position générale du squelette dans la scène tandis que dans le second cas, nous regarderions la position des joints. Néanmoins et toujours dans une idée d optimisation, ce calcul classique de l écart-type est très couteux. En effet, il utilise des multiplications, des divisions et surtout une racine carrée. Par conséquent, nous avons essayé de rechercher une autre solution moins coûteuse. C est comme cela que nous avons trouvé l algorithme de B.P. Welford décrit par Donald Knuth dans son livre «The art of Computer Programming». Après implémentation de cet algorithme, nous voulions comparer ces deux méthodes de calcul de l écart-type afin de voir si nous trouvions les mêmes résultats et si l algorithme de B.P. Welford était réellement moins coûteux en termes de performances que le calcul classique. Nous avons donc effectué une série de tests dont les résultats sont détaillés ci-dessous. 100 90 80 70 60 50 40 30 20 10 0 1 2 4 5 6 Calcul classique 3 Calcul avec B.P. Welford Figure 13 : Tests de performances du calcul de l'écart-type Ces deux courbes représentent l utilisation du processeur lors du lancement de l application. Plusieurs phases sont à distinguer : processeur au repos (1), lancement de l application (2), un squelette est détecté (3), le squelette reste immobile (4), le squelette se déplace (5) et enfin l application se termine (6). Ces différentes étapes successives sont différenciées par les traits verticaux. Page 14
On observe bien la différence de performances exigée par le calcul classique lors des étapes «4» et «5» : étapes où la demande d écarts-types est importante pour savoir si le squelette se déplace ou non. L aperçu d écran suivant présente les valeurs obtenues par les algorithmes développés. Nous pourrons observer ces valeurs préfixées par le nom de la méthode de calcul utilisée : «welford» pour l algorithme correspondant, «manuel_ss» pour le calcul classique sans sauvegarde c est-à-dire le calcul de l écart-type à chaque réception de positions et enfin «manuel_as» pour le calcul classique avec sauvegarde c est-à dire le calcul de l écart-type chaque seconde (toutes les trente réceptions de positions). Bien entendu, la comparaison est à faire entre «welford» et «manuel_as» puisque le calcul à chaque réception («manuel_ss») a été testé et ne donne pas de bons résultats. Effectivement, cette méthode est tellement précise qu elle ne détecte pas du tout les déplacements. Calcul de base avec sauvegarde Calcul avec l algorithme de Welford Figure 14 : Comparaison des résultats du calcul de l'écart-type Les valeurs obtenues sont quasiment identiques entre les deux méthodes (voir les encadrés ci-dessus). Par conséquent, nous constatons que l algorithme B.P. Welford est fiable, dans le sens où il donne approximativement le même résultat que la formule classique en plus d être beaucoup moins coûteux que cette dernière. Pour des raisons de compréhension, nous ne détaillerons pas ici l implémentation de l algorithme de B.P. Welford. Toutes les informations importantes ont déjà été citées. L interface graphique Après le fond, la forme : l interface graphique de notre application. Celle-ci s appuie sur trois parties : la vidéo permettant d afficher la scène en couleur, le réglage de la motorisation permettant d incliner le capteur de la Kinect grâce à des boutons et enfin une dernière partie d informations sur les squelettes détectés. Page 15
La figure suivante est une visualisation de la version 1 finale de l application. Partie «Réglages» Partie «Informations» Partie «Réglages» Figure 15 : Aperçu d'écran de la version 1 Sur cette capture d écran, nous remarquons que l option «Afficher les squelettes» est activée. Celle-ci s appuie sur la détection des vingt joints (des deux squelettes «trackés») et notamment de leur position dans la scène afin de les dessiner et de les lier par un trait : ceci afin de constituer un squelette comme nous pouvons le constater. Le troisième squelette est, quant à lui, «non-tracké» (puisque deux seulement peuvent y être sur six au total détectés). Donc, nous récupérons seulement sa position générale, représentée ici par un point bleu au centre du bassin. La partie d informations sur les squelettes est dynamique. Elle affiche des renseignements sur les squelettes détectés avec pour chacun : son identifiant lui étant attribué automatiquement par le système, sa position générale en X, Y et Z, le résultat du dernier calcul d écart-type sur «X» et «Z» et enfin une barre d interprétation de ces résultats affichant «vert» si le squelette est immobile ou «orange» s il se déplace dans la scène. A noter, la présence d un bouton «tracked» permettant d indiquer au système s il faut «tracker» un squelette en particulier et abandonner, si nécessaire, un autre squelette «tracké» jusqu alors. Ainsi, si l on souhaite suivre un squelette «non-tracké», le clic de la souris sur ce bouton déclenche son «trackage». Page 16
Les trois boutons positionnés en bas de la fenêtre permettent d incliner verticalement le capteur de la Kinect afin de pouvoir s adapter à la scène rapidement. L inclinaison est tout de même limitée à plus ou moins vingt-sept degrés. Les figures ci-dessous présentent cette fonctionnalité. -21 0 +20 Figure 16 : Inclinaisons verticale du capteur Kinect Au bout de quelques semaines de développement, nous avions donc une application optimisée par la forme et le fond, permettant de savoir pour chaque squelette, détecté par la kinect, s il se déplace ou non. La suite du développement était d intégrer un niveau de mouvement général reflétant le déplacement de tous les squelettes détectés afin de pouvoir ensuite afficher une alerte en cas de dépassement. Les règles ci-dessous présentent l implémentation que nous voulions suivre pour effectuer cette étape. - Pour un squelette, nous savons s il se déplace ou non - Pour plusieurs squelettes : - NIVEAU 1 : aucun squelette détecté ou les squelettes détectés sont immobiles - NIVEAU 2 : moins de la moitié des squelettes se déplace, les autres sont immobiles - NIVEAU 3 : tout le monde ou la majorité se déplace Néanmoins, ces règles n ont pas été implémentées car la démonstration auprès des médecins approchait et nous avions besoin de faire davantage de tests pour déterminer au mieux ces critères, et savoir s ils correspondaient réellement aux besoins des médecins. Nous ne voulions pas perdre du temps (estimé tout de même à quatre jours) à tester ces règles d interprétation au risque qu elles ne correspondent pas aux besoins du milieu médical. Présentation de l application : démonstration aux médecins La présentation s est déroulée le Mardi 27 Novembre 2012 en compagnie de notre responsable de projet Jean-Christophe Lapayre ainsi que des docteurs Daniel Talon et Lionel Pazart, médecins au CHU de Besançon. Page 17
Le but de cette réunion était de montrer les possibilités de la Kinect et de faire une démonstration de notre application développée jusqu à maintenant afin de voir si elle pouvait correspondre à un réel besoin dans les blocs opératoires. Très intéressés par le projet, les médecins ont même soulevés la possibilité de prendre un stagiaire pour continuer le développement. L idée initiale correspond réellement à leur besoin et pas seulement dans un souci de prévention. En effet, l application s inscrirait dans une démarche de traçabilité des conditions d intervention opératoire. Ainsi, si l hôpital est confronté à un problème en justice, ce dernier peut fournir une preuve des conditions d intervention. De plus, ils envisagent de coupler l application au dispositif «ScreenAir». Ce dernier est un appareil capable d analyser l air d un bloc constamment et d interagir avec le système de ventilation afin de renouveler l air. Couplé à l application Kinect, il pourrait comparer ses résultats aux mouvements détectés de cette dernière et déterminer précisément si un risque d aérobiocontamination. Il pourrait alors indiquer au système de ventilation de renouveler beaucoup plus d air dans la pièce. L intérêt du couplage «Kinect - ScreenAir» est double car il permettrait à terme en comparant les résultats des deux appareils de déterminer avec précision les mouvements à proscrire durant une opération : l idée serait de faire des statistiques pour associer les mouvements effectués et les pics d aérobiocontamination. A noter que cette dernière est une contamination aéroportée par la présence dans l air ambiant de micro-organismes vivants pouvant présenter un risque pathogène, véhiculés par des particules. Le schéma suivant détaille ce fonctionnement envisagé. Figure 17 : Couplage «Kinect - ScreenAir» Lors de pic d activité, le ScreenAir indique au système de ventilation du bloc de renouveler davantage d air. Système d aspiration Renouvellement d air BLOC OPERATOIRE Détection de mouvements Comparaison de ses résultats avec les infos de la Kinect ScreenAir Envoi d informations Kinect Ce couplage, nécessitant de nombreuses phases de tests et de réglages, ne pouvait pas être réalisé dans le cadre de ce projet mais pourra faire l objet d un stage comme cité ci-avant. Tout comme la possibilité d équiper un bloc avec plusieurs «Kinects» travaillant en collaboration. Effectivement, ceci est l une des possibilités que nous avons proposées durant l échange avec les médecins. Ceux-ci préfèrent, dans un premier temps, mettre en place l application avec une Kinect et envisager la collaboration de Kinect pour l avenir. Un bloc opératoire est composé de diverses zones réservées à chaque médecin (une pour l anesthésiste, une pour le chirurgien ). Cette fonctionnalité permettrait d affecter une Kinect à une zone et ainsi, savoir précisément d où provient le risque de contamination. Les Kinect pourraient travailler en collaboration et, du coup, s échanger des informations. Page 18
Le schéma ci-après explique cette fonctionnalité. BLOC OPERATOIRE PORTE PATIENT Zone 1 réservée à l anesthésiste Kinect n 2 Pos2 Zone 2 réservée au Pos1 chirurgien Kinect n 1 n Le chirurgien est initialement dans la zone 2 : position référencée par «pos1». Son déplacement vers la zone 1, réservée à l anesthésiste, est indiqué par «pos2». Figure 18 : Collaboration de Kinect Ici, la Kinect n 1 serait informée par la Kinect n 2 que le chirurgien passe de la zone n 2 à la zone n 1. La seconde Kinect enverrait alors les informations relatives au chirurgien (positions etc.) dont elle dispose, à la première. Nous constatons ici la collaboration étroite entre les Kinect sachant qu au final, une limite de quatre Kinect, reliées mutuellement, est imposée par le fabricant. Cela constituerait tout de même un outil très perfectionné et complet pour la détection de mouvements intempestifs au sein d un bloc opératoire. A ces deux grandes évolutions possibles s ajoutent de nombreuses remarques des médecins réalisables de suite de la part des médecins afin que l application «colle» parfaitement avec leurs besoins. Ces différentes remarques ont été prises en compte pour parvenir à une seconde version de l application étudiée ci-après. d. Améliorations et adaptation de l application (version 2) A noter, tout d abord, que toutes les remarques n ont pas été prises en compte pour le moment. En effet, étant dans une phase de développement, de tests et de réglages, certains modules présents dans l interface graphique nous sont nécessaires. On peut citer notamment l exemple de la vidéo affichant la scène visualisée par la Kinect. Les médecins ont suggéré la suppression de ce module car inutile à l intérieur d un bloc. Effectivement, l application se doit d être un outil de détection et d alerte de mouvements intempestifs mais elle ne doit en aucun cas perturber le travail du personnel médical. Page 19
Dans cette optique, nul besoin de regarder la vidéo lors d une opération. Néanmoins, ce module nous est nécessaire pour le moment afin de vérifier que les résultats obtenus sont en parfaite adéquation avec la scène visualisée. Par conséquent, le flux vidéo reste présent, pour le moment, sur l interface graphique de l application mais sera supprimé lors du déploiement de l application, tout comme la partie d informations sur les squelettes qui sert à tester et vérifier les résultats obtenus. Mais que reste t-il alors? De la version 1, doit rester le réglage de l inclinaison du capteur Kinect qui donnera lieu à un module complet de réglages. En effet, des paramètres supplémentaires doivent pouvoir être modifiés dynamiquement par l utilisateur lors du lancement de l application : ainsi, les médecins pourront ajuster ces paramètres en début d intervention afin de s adapter au bloc opératoire dans lequel il se trouve. A ce module de réglages s ajoute une représentation graphique des déplacements dans la pièce. C est cette partie qui a été le principal axe de développement de cette seconde version de l application. En effet, nous avions suggéré aux médecins lors de la présentation, une vue graphique et dynamique représentant le niveau général de déplacements des individus à l intérieur d un bloc. On arrive alors sur un schéma d interface comme présenté ci-après. REPRESENTATION GRAPHIQUE Niveau de mouvements REGLAGES DYNAMIQUE DES PARAMETRES Temps Figure 19 : Schéma de l'interface graphique finale Néanmoins, et comme évoqué précédemment, le flux vidéo et les informations sur les squelettes détectés seront présents pour l instant. Cette vue, ci-dessus, représente par conséquent l interface graphique de l application finale. Pour réaliser ce graphique dynamique prenant le temps en abscisse et le niveau général de déplacements des individus en ordonnée, aucune information supplémentaire n était nécessaire. En effet, le temps est une variable pouvant être récupérée très facilement et à n importe quel moment, et le niveau général était déjà calculé. On remarquera ici que nous avons bien fait de ne pas débuter la phase de tests pour interpréter les résultats globaux (voir fin du chapitre précédent). Effectivement, le niveau général est juste la somme des écarts-types calculés. Page 20
Deux possibilités s offraient à nous pour la réalisation de ce graphique : le développer nousmêmes ou rechercher d éventuelles solutions existantes. Nous avons privilégiés, dans un premier temps, la seconde solution : à défaut de résultats, nous aurions opté pour la première. C est après quelques recherches que nous avons trouvé une bibliothèque permettant la visualisation interactive de données dynamiques grâce à un ensemble de contrôles : «Dynamic Data Display». Cette bibliothèque open-source, reprise par le programme Microsoft Research, permet de créer des graphiques Figure 20 : Logo de la bibliothèque Dynamic Data Display linéaires et à bulles, des cartes de chaleur ou tout autre tracé 2D (deux dimensions) complexe. Basée sur la technologie Silverlight de Microsoft, elle est compatible avec les outils de développement tels que Visual Studio et elle s intègre parfaitement dans une application WPF comme la notre («Windows Presentation Foundation», spécification graphique de Microsoft.NET 3.0). Son fonctionnement est relativement aisé car il s appuie sur l utilisation de deux tableaux : un contenant les données relatives à l axe des abscisses et un second pour l axe des ordonnées. Il suffit ensuite d appeler la méthode de traçage en spécifiant les paramètres de tracé que l on désire. On arrive alors sur un fonctionnement comme décrit ci-dessous. LA SCENE Figure 21 : Fonctionnement de la version 2 P1 P3 Kinect Flux de données P2 P4 ORDINATEUR Récupération des positions des squelettes détectés : P1, P2, P3 Toutes les 30 positions (à la seconde) INTERFACE GRAPHIQUE On recommence Calcul d écart-type (pour chaque squelette) Somme des écarts-types et insertion de cette valeur dans un tableau dynamique en y ajoutant une notion de temps Découpage en deux tableaux : un pour l abscisse avec les résultats d écart-type et un second pour l ordonnée avec les valeurs de temps associées. Il suffit ensuite de réafficher le graphique à l aide de ces deux tableaux en y ajoutant quelques paramètres de tracé. Page 21
Ci-dessous, un aperçu du rendu de cette seconde version. Figure 22 : Aperçu d'écran de la version 2 Nous pouvons remarquer, en bleu, la courbe représentant le niveau général de déplacements et, en rouge, la limite à ne pas franchir. Cette dernière, définie déjà lors de la version n 1, s adapte au nombre de squelettes. Effectivement, on se doute bien que la limite est différente s il n y a qu un seul squelette ou s il y en a cinq. Nous obtenons donc cette valeur en multipliant la limite d un squelette avec le nombre de squelettes détectés dans la scène. Afin de respecter la notion de traçabilité des conditions d intervention opératoire, une étape de sauvegarde a été mise en place lors de l ajout de la somme des valeurs d écart-type dans le tableau dynamique. Ainsi, avant même de mettre à jour le graphique, une écriture dans un fichier texte est réalisée. Page 22
Un extrait de ce fichier est visualisable ci-dessous. Format de la sauvegarde : - DATE - HEURE - SOMME DES ECARTS-TYPES - LIMITE CORRESPONDANTE Un squelette détecté Deux squelettes détectés Figure 23 : Extrait du fichier de sauvegarde des données Au cours de ce développement, nous avons eu l idée de plusieurs améliorations envisageables pour le futur. Nous allons étudier brièvement ce point. III. Axe futur de développement de l application et ses améliorations L axe de développement a déjà été cité dans les pages précédentes. En effet, à la suite de ce projet, un stagiaire a été pris pour développer la suite de l application durant environ six mois. Les deux grands objectifs sont la combinaison de la Kinect avec l appareil de renouvellement d air «ScreenAir» ainsi que la collaboration de plusieurs «Kinects». Pour cela, des blocs opératoires vides ont déjà été réservés par les médecins afin de tester ces points. A cet axe s ajoute des améliorations que nous avons trouvées durant toute la phase de développement et notamment sur la deuxième version de l application. Quatre améliorations ressortent : la représentation graphique, le «multithreading», la détection de «mouvements» et enfin la reconnaissance précise de squelettes. Page 23
La représentation graphique Le graphique dessiné au fur-et-à-mesure doit subir deux modifications importantes : le rafraichissement et la détection d aucun squelette. Dans le premier cas, il faudrait que le graphique affiche les courbes dans un intervalle de temps toujours régulier comme par exemple les trois dernières minutes. Actuellement, si l application tourne deux heures, le graphique met juste à jour ses axes (abscisses et ordonnées) c est-à-dire qu au final, le graphique affichera les courbes représentant les deux heures de lancement. Ainsi, au début, nous avons une bonne visibilité des courbes mais celle-ci se dégrade avec le temps. Le second point concerne le déplacement des squelettes hors du champ de vision de la Kinect. Ainsi, si un squelette est détecté, les courbes s afficheront au fur-et-à-mesure du temps. Maintenant, si ce dernier sort du champ de vision de la Kinect : la courbe s arrête. Si le squelette revient, la courbe se redessine depuis le dernier point où elle s était arrêtée. Or, lors du départ du squelette du champ de vision, la courbe devrait continuer à se dessiner avec des valeurs à «zéro». Le multithreading Nous nous sommes rendu compte qu une optimisation importante pouvait être faite en «multithreadant» l application et notamment pour le calcul d écart-type. A noter tout de même qu il faut prendre connaissance du matériel sur lequel sera déployée l application. Effectivement, si l application tourne sur un ordinateur possédant deux «cœurs», cela sera différent par rapport à un ordinateur tournant avec huit processeurs. Ce détail est à prendre en compte lors du développement afin de «multithreader légèrement» l application ou non. Les points suivants sont les opérations pouvant être multithreadées afin d optimiser le fonctionnement de l application : - Lors du calcul d écart-type : nous savons que six squelettes maximum peuvent être détectés. Pourquoi ne pas envisager d associer un squelette à un processus. Ainsi, lors du calcul d écart-type, chaque processus gérerait son propre squelette et un processus «maitre» n aurait qu à récupérer les résultats. - Lors de la sauvegarde en fichier : il est envisageable d associer l écriture des valeurs à un processus unique afin de décharger le processeur gérant le programme principal. - Lors du traçage des courbes : le découpage du tableau dynamique, où sont stockées les valeurs d écart-type, en deux tableaux suivis du traçage de courbes sont deux opérations prenant un certain temps non négligeable. Nous pourrions très bien associer un processus à ces opérations. Page 24
La détection de mouvements Comme cité à plusieurs reprises, nous avons géré ici dans ce projet les déplacements des squelettes dans la scène. Afin d être plus précis, nous pourrions faire de même avec les mouvements des squelettes. Ainsi, un squelette qui ne se déplace pas mais qui bouge les bras fortement, par exemple, est aussi susceptible d agrandir le risque de contamination du patient. Cette partie se baserait alors sur la position en X, Y et Z des joints des squelettes. La seule limite, fixée par le fabricant, est la possibilité de gérer cela que pour deux squelettes (squelettes «trackés»). D où la dernière amélioration possible La reconnaissance précise de squelettes Comme seulement deux squelettes peuvent être trackés dans la scène, il est envisageable de détecter les mouvements des deux squelettes bougeant le plus et non de ceux définis automatiquement par le système. A noter que le système «tracke» les deux squelettes les plus proches. Ainsi, on se retrouverait avec une application détectant les déplacements des six squelettes possibles et détectant les mouvements des deux squelettes bougeant le plus dans la scène. On aurait alors un outil complet. Page 25
Conclusion Pour conclure, nous pouvons affirmer que ce projet a été réellement bénéfique : nous avons appris un nouveau langage de programmation et de nouveaux concepts, mais pas seulement. Ayant une grande liberté sur nos choix, nous avons pu faire preuve d autonomie et de prise d initiatives. La notion de travail en équipe a aussi joué un grand rôle : nous avons, en effet, privilégié la communication entre nous et réduit les échanges par e-mails. Ce projet a été vraiment stimulant de par son objectif. Le fait de savoir que l application développée sera reprise par un stagiaire et qu elle est destinée aux besoins des médecins, est quelque chose de très motivant. C est la première fois, pour nous, que nous mettons l Informatique (et donc nos compétences) au service d un domaine inconnu mais riche en connaissances. Page 26
Annexe 1 : Diagramme GANTT du projet Page 27