Architecture d’application Kinect et modèle MVP

Plan de présentation O Introduction O Utilisation de la Kinect O Le modèle MVP

Introduction O L’objectif de ce cours de vous montrer le modèle MVP avec l’inteprétation de Windows Form. O Pour nous amuser un peu, nous allons utiliser le sdk 1,8 de la Kinect pour implémenter la théorie vue en classe.le sdk 1,8 de la Kinect Pour sauver du temps, est-ce que vous pouvez télécharger le SDK pendant le cours.

Évolution des interfaces Source:

Source:

Maintenant Amusons nous avec la Kinect! O Prenez le contrôle avec Kinect!

Kinect ? Qu’est ce que c’est ? O Kinect est La première caméra commerciale qui permet l’interaction entre l’humain et la machine. O Créée par Microsoft(09/2008) O Contrôler des logiciels et des jeux sans souris ni clavier avec le corps ou la voie O Le but est de créer une expérience immersive de jeu. O Windows Kinect VS Xbox Kinect

Éléments de la Kinect Émeteur (IR) Caméra RVB Capteur de profondeur(IR) Moteur Microphones

Source:

Éléments de la Kinect Le +/- 27 degrés vient du fait qu’il est possible de modifier l’angle de la Kinect de +/- 27 degrés.

Éléments de la Kinect 0.8m/2.6 ft

Éléments de la Kinect 1.3’2.6’9.8’13.1’26.2’ Default Mode Near Mode Pieds Mètres InconnuTrop prèsNormalTrop loin

Éléments de la Kinect O 43 degré vertical par 57 degré horizontal.

Possibilités de la Kinect O Caméra BGRA O Détection de la profondeur O Détection de personne(Squelette) O Reconnaissance vocale(si le temps le permet)

Avant de commencer O Si vous en manquer un bout de ma présentation, vous pouvez aller sur le site suivant : O us/kinectforwindows/develop/how-to-videos.aspx us/kinectforwindows/develop/how-to-videos.aspx O Vous devez installer les éléments suivants O Kinect for Windows SDK 1.8Kinect for Windows SDK 1.8 O Kinect for Windows Developer Toolkit 1.8 Kinect for Windows Developer Toolkit 1.8 O Connecter la Kinect (Tous les pilotes seront installés automatiquement)

La caméra O Résolutions : O 640 * 480, 1280 * 1024 O Format : O BGRA(Bleu, Vert, Rouge, Alpha)(byte) O Evénementiel( AllFramesReady) O Données fournies au travers d’un vecteur de bytes BGRA (Rouge, Vert, Bleu, Alpha) O Voici 3 pixels BGRABGRABGRA

Caméra de profondeur

O Résolutions O 640x480 O 320x240 O 80x60 O Lorsque les images sont prêtes, un événement est déclenché. O Stockage sur 16 bits O 13 bits pour la distance en millimètres depuis le capteur O 3 bits pour donner l’index de la personne reconnue

Caméra de profondeur O Retourne la distance et l’index du joueur pour chaque pixel O Ex: 320 x 240 = 76,800 pixels (x 16 bits) O Distance en mm de la Kinect ex: 2,000mm O 1-6 Joueur(s) simultanément O Ainsi pour chaque pixel, nous avons un 16-bit short

Caméra de profondeur O Voici la représentation de deux pixels DDDDDDDDDDDDDPPP DepthPlayer Index DDDDDDDDDDDDDPPP

Les couches de la Kinect

Pour connecter la Kinect O N’oubliez pas d’ajouter la référence Microsoft.Kinect O Nous allons créer une variable membre O Nous allons se connecter à l’événement AllFramesReady O Nous allons initialiser le bon angle pour la caméra(_sensor.ElevationAngle = 0;) O Nous allons convertir les images reçus en Image et nous allons les afficher dans des picturebox.

Démo

Détection des squelettes O 6 squelettes détectés O Chaque squelette donne sa position O 2 squelettes suivis (tracked) O Liste de joints (points de contrôles)

Squelettes détectés Identifiés Tracked

Points détectés sur un squelette FootLeft AnkleLeft KneeLeft HipLeft HipCenter HipRight FootRight AnkleRight KneeRight Spine HandLeft WristLeft ShoulderLeft Head ElbowLeft ShoulderRight HandRight WristRight ElbowRight ShoulderCenter Mode normal Mode assis

Coordonnées des jointures Z Axis X Axis Y Axis Negative Positive Negative

Coordonnées des jointures

Propriétés des squelettes O 3 possibilités de types de squelettes O NotTracked O PositionOnly O Tracked O 3 possibilités de types de joints O Inferred O NotTracked O Tracked

Démo!

Exercice O Brancher le module du perceptron pour permettre de reconnaitre les mouvements de la célèbre chanson YMCA.

Note O Il est plus performant de normaliser le corps avant d’exécuter le perceptron.

Le modèle MVP

O Le modèle consiste à diviser la couche d'interface graphique en deux. La partie la plus basse, le "Presenter", sera la seule à communiquer avec la couche métier et éventuellement avec celle d'accès aux données dans les limites où c'est acceptable dans votre architecture globale. O Ce modèle est bien adapté pour les applications où l’on s’attends à avoir plusieurs interface différente(Web, Form, WPF, etc.) O C’est un dérivé de MVC et MVVM. O En résumé, ce sera comme 3-tiers, mais nous aurons une couche entre le GUI et le BLL.

Le modèle MVP

O Pour plus de flexibilité, je vous conseille de faire une interface entre la vue et le Presenter.*** It's remarkable to say that Martin Fowler has extended the original MVP design pattern with Passive View and Supervising Controller/Presenter. In the case of the Passive View pattern, the main idea is to have no dependencies between the View and the Model concerns and the view is dumb. The Supervising Controller is a flexible interpretation of the original MVP design pattern and the view is not completely dumb and has some responsibilities.

Le modèle O Le modèle représente le comportement de l'application : traitements des données, interactions avec la base de données, etc. C’est la Business Logic ET la DAL O Il décrit ou contient les données manipulées par l'application. O Il assure la gestion de ces données et garantit leur intégrité. Dans le cas typique d'une base de données, c'est le modèle qui la gère. O Le modèle offre des méthodes pour mettre à jour ces données (insertion, suppression, changement de valeur). O Il offre aussi des méthodes pour récupérer ces données.

Le modèle

La vue O La vue correspond à l'interface avec laquelle l'utilisateur interagit. O Sa première tâche est de présenter les résultats. O Sa seconde tâche est de recevoir toutes les actions de l'utilisateur (clic de souris, sélection d'une entrée, boutons, etc.). Ces différents événements sont envoyés au contrôleur. O La vue n'effectue aucun traitement, elle se contente d'afficher les résultats des traitements effectués.

La vue O Certaines opérations peuvent nécessiter une interaction avec l'utilisateur (affichage d’erreur, confirmation, …), ces interactions doivent être assurées par la VUE. O La VUE connaît la présentation. O La VUE peut utiliser le binding pour récupérer les données à afficher depuis la couche PRESENTATION, ou lui envoyer les informations saisies ou modifiées par l’utilisateur. O La VUE dispose d’un traitement particulier pour effectuer les mises à jour nécessaires (traitement "Demande de mise à jour de l’IHM"). Ce traitement est appelé automatiquement lors de l’initialisation, puis sur demande de la couche PRESENTATION ou de la couche MODELE (fonction DemandeMiseAJourIHM).DemandeMiseAJourIHM

Le modèle

La présentation O Le présentation prend en charge la gestion des événements de synchronisation pour mettre à jour la vue ou le modèle et les synchroniser. O Il reçoit tous les événements de l'utilisateur et enclenche les actions à effectuer. Si une action nécessite un changement des données, le contrôleur demande la modification des données au modèle, ce dernier avertit la vue que les données ont changée pour qu'elle se mette à jour. Certains événements de l'utilisateur ne concernent pas les données, mais la vue. Dans ce cas, le contrôleur demande à la vue de se modifier. Le contrôleur n'effectue aucun traitement, ne modifie aucune donnée. Il analyse la requête du client et se contente d'appeler le modèle adéquat et de renvoyer la vue correspondant à la demande.

En résumé O En résumé, lorsqu'un client envoie une requête à l'application : 1. la requête envoyée depuis la vue est analysée par la couche de présentation(par exemple un clic de souris pour lancer un traitement de données), 2. La couche de présentation demande au modèle approprié d'effectuer les traitements et retourne l’information à la couche de présentation,

Différence avec l'Architecture trois tiers O L'architecture trois tiers est un modèle en couches, c'est-à- dire, que chaque couche communique seulement avec ses couches adjacentes (supérieures et inférieures) et le flux de contrôle traverse le système de haut en bas; les couches supérieures contrôlent les couches inférieures, c'est-à-dire, que les couches supérieures sont toujours sources d'interaction (clients) alors que les couches inférieures ne font que répondre à des requêtes (serveurs). O Dans le modèle MVP, la différence se trouve au niveau des rôles de chaque couche. Les couches de BL et DAL sont incluses dans le modèle. La couche de présentation des données est séparé en deux : une qui représente le design de l’interface(Vue) personne machine et l’autre représente son fonctionnement(Présentation).

Exemple O Modèle O Vue O Présentation

Période de questions O Vous avez des questions?