Art embarqué

Cahier des charges

Présentation générale du projet

Contexte

La création artistique peut être enrichie par l'apport des nouvelles technologies.

Objectif du projet

L'objectif de ce projet est de créer un système permettant de générer des œuvres d'art qui viennent compléter la performance d'un danseur.
Cette œuvre sera visuelle et potentiellement agrémentée de sons suivant l'avancement du projet.
Le but est de projeter cette œuvre en direct sur le fond de la scène où évoluera le danseur.

Description du projet

Un arduino intégré sur le costume de l'artiste transférera les données d'un accéléromètre vers un PC par le biais un transmission sans fil.
Une Kinect placée au plafond récupérera les positions du danseur sur la piste (2D plan au sol).
Nous traiterons les données récupérées par l'arduino et la Kinect sur le PC afin de créer l'œuvre visuelle.
L'oeuvre à réaliser sera dans un premier temps un cercle qui se déplacera dans une zone en X,Y en fonction de la position détecté par le kinect.
La couleur et la taille évoluera en fonction des données renvoyés par accéléromètre.

Choix techniques : matériel et logiciel

• Un Arduino lilypad [fourni le 28/1/2015], utilisé sur le danseur, avec :
  • alimentation autonome (batterie + régulateur? pour une bonne autonomie) [fourni le 28/1/2015]
  • un module Xbee pour la communication vers le PC [Platine de support Xbee] [fourni le 28/1/2015]
  • un accéléromètre [de ce type] [fourni le 28/1/2015]

• PC avec :
  • Kinect branché en USB ( peut être une rallonge à prévoir) [fournie le 28/1/2015]
  • récepteur Xbee [platine USB de ce type] [fourni le 28/1/2015]

• Traitement des données et création du visuel via le logiciel Processing

Étapes du projet

Étape 1

• Capture et récupération des données de la Kinect et de l'arduino

Étape 2

• Envoi et réception des données par Xbee

Étape 3

• Traitement des données via "Processing"

Étape 4

• Finalisation de l'œuvre et projection sur scène en live

Avancement du Projet

Semaine 1 (26/01/2015)

• Mise en place du cahier des charges, discussions avec les enseignants
• Recherche du matériel envisageable
• Prêt du matériel par les enseignants après validation du cahier des charges(kinect, arduino et modules Xbee)
• Documentation sur le fonctionnement de la Kinect
• Essais de fonctionnement avec processing sous windows :
  • Recherche des librairies
  • Recherche de codes sous processing

--> Pas encore de fonctionnement

Semaine 2 (02/02/2015)

• Prise en main de la Kinect :

Installation du SDK Kinect et fonctionnement de la Kinect sous windows via processing

• Premiers test sous windows, on se rend compte qu'on pourrait plutot le faire sur Linux : demande avis des enseignants
• Essais de communication entre les modules Xbee

• CONFIGURATION des Xbee sur minicom: réseau 1111, ID 1 et 2 (voir photos)

commandes pour la configuration du Xbee1

configuration du Xbee1

• utilisation de la librairie OpenNI sous processing, compatible avec linux et Windows.
• Recuperation des données "depthMap" réalisation d'un simple code de tracking d'objets présents dans une plage de distance donnée.

Semaine 3 (09/02/2015)

• Branchement de l'accelero sur le lilypad, transmission des données d'un des axes par Xbee.
• Récupération des données sur processing, code simple sur processing pour faire varier la couleur du cercle de tracking
  • Demo : proof of concept avec le capteur dans la main

On constate donc sur la vidéo que la détection d'une personne fonctionne (ici la main remplace la tête du danseur).
Le code sous processing est simpliste, on modifie la couleur en rouge et bleu de façon opposé, avec le canal x de l'accéléromètre.
La transmission se fait via Xbee à 9600 bauds.

Semaine 4 (16/02/2015)

Reflexion sur l'evolution du projet:

• Ajout d'un 2nd accéléromètre afin de récupérer les données provenant de chaque bras du danseur.
• Verrouiller la position du point s'il y a pas/peu de mouvement.
• Agrandir la taille du cercle en fonction du nombre de points détectés (par la kinect) dans la plage de distance
• Fluidifier la transition de couleurs, et attribuer une couleur par voie (X,Y,Z) ou par main ?

Passage en code C pour la programmation du lilypad, avec synchronisation de l'envoi :

1) L'arduino fait l'aquisition des valeurs de l'accéléro et attend un message de l'appli pc.
2) L'aplication processing envoie 'd' à l'arduino.
3) L'arduino répond en envoyant les 3 octets de chaque canal de l'accelero. Il refait ensuite les 3 acquisitions pour être prêt à les envoyer.

Semaine 5 (23/02/2015)

Nous avons rencontré quelques soucis lors du passage en C de notre code pour l'arduino.
Il n'y avait pas d'erreur lors du make upload, nous ne savions donc pas si le problème venait des modules Xbee, de notre code, du Makefile.
Ces petits soucis nous ont malheureusement ralenti et nous n'avons donc pas beaucoup avancé durent cette 5e semaine.

Semaine 6 (09/03/2015)

• Fonctionnement du code arduino en C.
• Essais pour augmenter le baud rate afin d'avoir de meilleures performances:

Initialement à 9600 bauds, nous avons essayé de passer à 115200 directement, mais sans succès.
Nous sommes ensuite passés à 57600, cette fois ci avec succès.
Nous avons donc du reconfigurer les Xbee à 57600 bauds, et changer nos codes C pour le lilypad (émission) et processing pour la réception.

• Nous avons ensuite testé la distance communication des Xbee en branchant le montage arduino/Xbee/accéléromètre à une batterie.
  

La réception reste très bonne et stable à 10-15 mètres, nous n'avons pas essayé à une plus grande distance.

Semaine 7 (16/03/2015)

A la remise en route de l'arduino : problème de communication avec les Xbee, configuration à refaire ainsi que le programme du lilypad à réUP pour un fonctionnement correct. Source du problème inconnue.

Mise en place d'une méthode de "moyenage" pour la modification des couleurs, les transitions sont plus douces. Améliorer la fluidité du "point", en retirant le traçage des bords et quelques autre réglages sous processing.

Mise en place d'une fonction de transformation du cercle en octogone, a lancer par exemple lors d'un mouvement de la deuxième main.

Semaine 8 (23/03/2015)

On applique des méthodes de fluidification et on intègre le deuxième accéléromètre. Le premier accéléromètre sera utilisé pour colorer le point traceur,
le deuxième accéléromètre, quand à lui, sera utilisé pour jouer sur la forme ou la taille du point : à méditer. Egalement quelques réflexions sur la mise en place du circuit arduino/Xbee/accéléromètre sur le danseur : gants, fil conducteur pour coudre l'accéléromètre et nappe pour longer le bras.

Semaine 9 (30/03/2015)

Manque de fluidité sous Windows, peut être un Baudrate trop élevé ?
Après être repassé de 57600 à 9600, on ne retrouve pas de fluidité dû à une mauvaise réception série. Les valeurs reçues n'étaient pas correctes et donnaient une vision saccadée. Nous avons pu trouver la cause de ce problème : Les valeurs reçues sont censées être comprises entre 0 et 255, notre programme processing (pour la réception) renvoi la valeur -1 lorsqu'il rencontre un erreur. Lorsque la valeur -1 est reçue, le point devient noir. Nous recevions beaucoup trop de -1, d'où ce manque de fluidité.

On a donc décidé d'installer la kinect sur linux, ainsi que processing. Malgré quelques problèmes rencontrés, notamment le fait de devoir tout lancer en super utilisateur, nous avons finalement réussi à faire tourner la kinect sous linux, ainsi que processing.

L'entièreté du projet tourne désormais sous linux.

Semaine 10 (06/04/2015)

Objectif de la semaine : faire une démo du projet
Fichier:Demo 1.mp4 On peut observer les différentes actions en fonction des mouvements fait sur l'accélero
Début de la couture : fixer les accéléros sur les gants

Semaine 11 (13/04/2015)

Le premier accéléro est fixé mais nous avons cassé l'aiguille dans la nappe et donc nous n'avons pas pu continuer.
Mise en place d'une interface graphique pour faciliter l'usage et permettre à l'utilisateur de configurer/paramétrer directement la kinect:

_choix de la distance à laquelle la kinect détecte la personne.
_listage des ports disponible et choix du port USB correspondant au module Xbee récepteur
_