Coach Dance

Présentation

L'apprentissage de la danse peut poser certains problèmes aux débutants. Un des problèmes majeurs rencontré concerne la synchronisation des mouvements sur le rythme de la musique. De nombreux débutants n'entendent pas le rythme soit parce qu'ils ne connaissent pas bien le type de musique (e.g. salsa) soit parce que la coordination des mouvements (bras et jambes) leur demandent de gros efforts cognitifs.

L'objectif du projet consiste à aider les danseurs débutants en donnant les indications de rythme et de mouvement. Pour cela, vous devez développer un système portable (type wearable computer) qui devra :

• détecter de manière automatique le rythme de la musique. Dans un premier temps, nous ciblerons deux danses, la salsa et le rock 6 temps. Le type de danse sera indiqué au système afin de "simplifier" la reconnaissance
• en fonction du rythme et de la danse, activer un des vibreurs qui seront disposé sur le danseur. Dans un premier temps, un vibreur sera installé sur chacun des mollets afin d'indiquer quel est le pied à bouger. Si le temps le permet, il sera possible d'étendre le système au mouvement des bras ou à d'autres danses.

Préparation du projet

Matériel

• 1 arduino lilypad (disponible) ;
• 4 vibreurs (à commander) ;
• 1 micro portable (à commander) [1];
• -> un cable jack par micro pour la connection à une plateforme Altium (disponibilité ?)
• pour la connection Altium/Zigbee : puce Zigbee/cable(adaptateur usb)
• Des morceaux de musique Salsa et Rock (à commander...XD);

Danses

Les deux danses visées dans un premier temps sont la salsa (style cubain, http://fr.wikipedia.org/wiki/Salsa) et le rock 6 temps (http://fr.wikipedia.org/wiki/Rock_%C3%A0_six_temps). Le système devra permettre de sélectionner la danse et le sexe de la personne (les pas de la fille sont inversés par rapport à ceux du garçon)

Avancement du projet

Première Séance (28/02/2011) -- 2h

Nous avons trouvé un lien pour un montage de détection des beats par minute (d'une basse) dans une chanson. Ce montage devra sûrement être adapté pour la salsa car le rythme est repéré par le claquement des claves de fréquence plus hautes que les basses.

lien pour du montage de détection bpm

http://www.sonelec-musique.com/electronique_realisations_compteur_tempo_001.html

idée à développer: filtre numérique passe bande à tester sur 2 sons wav différents... (fft sur un fichier wav avec matlab puis calcul du filtre)

lien pour le câblage d'un micro 

http://www.sonelec-musique.com/electronique_bases_alim_micro_electret.html

Etapes prévues:

Test de la méthode de détection des beats par minute 

Nous voulons trouver une façon de faire le traitement numérique avec le microcontrôleur du LilyPad (ATmega328V) pour éviter d'avoir à concevoir un circuit imprimé en parallèle avec un montage à amplificateur opérationnel.

Phase de développement 

Après avoir trouvé la méthode finale de détection des beats par minute nous devrons concevoir un programme permettant de traiter ces informations et surtout adaptable à plusieurs sortes de musique

Partie pratique

Conception du vêtement intelligent

Deuxième Séance (3/03/2011) -- 2h

Test de traitement FFT avec Matlab d'un fichier wav a résulté à un échec. Test avec un programme développé par un étudiant de Supelec a échoué également. Nous nous sommes donc décidé à effectuer un traitement avec une plateforme Altium et utilisation de arduino / lilypad pour la communication zigbee et la gestion des vibreurs.

les micros dont nous avons besoin sont disponibles il nous manquera juste des composants type résistance condensateur etc...

Prochaine séance: Essai avec la plateforme Altium (Maxime) recherche d'info sur Zigbee (Catherine)

Troisieme Séance (3/03/2011)-- 2h

Test sur la plateforme Altium :

• Mise en place du programme Altium : conception du schematic (indique quels composants de la nanoboard utiliser) et d'un code C simple.
• Un micro est connecté sur la plateforme Altium. On a essayé de récupérer le signal numérisé, pour pouvoir ensuite le traiter. Les résultats obtenus ne sont pas satisfaisants.

Quatrième Séance (7/03/2011)-- 2h

Pour communiquer via Zigbee il suffit de

-pluger une plateforme zigbee sur arduino : cette manoeuvre permet d'utiliser zigbee comme un port série en la branchant en usb sur un pc

-brancher une autre puce zigbee avec un câble miniusb-usb sur un autre port usb du pc

On peut ensuite faire communiquer les puces entre elles en faisant des read() et write() sur les descripteurs de fichiers associés (test non encore effectué à faire à la prochaine séance)

Plateforme Altium

• Je comprends comment faire pour enregistrer, notamment l'utilitée et le fonctionnement de la fonction get_audio() d'Altium. Celle-ci enregistre dans un buffer d'entiers les valeurs en sortie du CAN d'Altium.
• Je m'aide d'un programme exemple fourni avec le soft Altium Designer
• Probleme : les valeurs retournées par l'enregistrement ne sont pas satisfaisantes.

Cinquième Séance (10/03/2011) -- 2h

Programme arduino et zigbee.c développés et fonctionnnent. A la prochaine séance il faudra voir comment on peut envoyer le numéro du vibreur à actionner et le traitement qui sera fait par lilypad en fonction du numéro reçu par la puce zigbee sur le t-shirt.

Plateforme Altium

• Identification du problème sur les valeurs retournées par l'enregistrement : l'enregistrement est réalisé sur 8 bit, mais le stockage est fait dans un int (integer) donc sur 4 octets (32 bits). Quand on cast les entiers enregistrés, les valeurs retournées sont plus probables. Il y a cependant des valeurs de 'bruit' ou en tout cas abérentes supérieures à 200. (les valeurs sont codées de 0 à 255)
• Je décide d'utiliser directement l'exemple d'Altium et de le modifier pour mon projet

Sixième Séance (14/03/2011) -- 2h

Méthode retenue pour l'envoi du numéro de vibreur: branchement de 4 pins de l'arduino sur la platine et la platine altium envoi un signal état haut pour l'activation d'un des 4 vibreurs (pin 1 à l'état haut : activation du vibreur 1, idem pour les 3 autres vibreurs), une fois le numéro de pin reçu on l'envoi via la puce Xbee présente sur arduino.

Plateforme Altium :
Je travaille toujours sur la récupération des données que je recois sur le micro.

Septième Séance (17/03/2011) -- 2h

Il va falloir brancher la puce Xbee réceptrice sur le Lilypad (câble mini-USB vers connectique Lilypad commandé). il faut d'abord faire les tests sur plateforme Arduino (câblage de Lilypad avec du fil à coudre fastidieux et long à modifier).

Début de la programmation de commande des vibreurs: Les rythmes du rock 6 temps sont les suivants: 1,2, 3 et 4,5 et 6. pour le garçon cela revient à faire gauche(1), droite (2),gauche(3)-droite(et)-gauche(4), droite(5)-gauche(et)-droite(6). Idem pour la fille mais en miroir. On remarque qu'entre les temps 3 et 4, puis 5 et 6, il y a un demi-temps à marquer qui n'est pas indiqué par un beat. Il faut donc déterminer le temps qui sépare 2 beats et prévoir une vibration supplémentaire pour le demi-temps "et". La fonction millis() sous Arduino permet d'obtenir le temps qui s'est écoulé depuis le lancement du programme en millisecondes. Pour obtenir le demi-temps il suffit de stocker le temps lors du pas 1 et lors du pas 2 puis de diviser la différence par 2 pour obtenir la durée d'un demi-temps. Sachant que l'on actionne le vibreur pendant un certain temps il faudra déduire ce temps du demi-temps pour actionner le vibreur suivant.

NB: trouver une solution pour sélectionner le mode femme ou le mode homme (platine Lilypad interrupteur? http://www.lextronic.eu/doc/produit/img1_18685.jpg)

plateforme Altium :

• J'arrive à recevoir les données audio du micro et à les faire jouer par la nanoboard. Le résultat est plutôt satisfaisant, on discerne assez bien ce que l'on envoie sur le micro, bien que la qualité de retour soit médiocre.
• Dorénavant je travaillerais en insérant directement par câble Jack les données audio sur l'entrée casque de la nanoboard, pour limiter le bruit au maximum.

Huitième Séance (21/03/2011) -- 2h

Fin de la programmation du code à implanter dans le Lilypad idée trouvée pour sélectionner mode homme ou femme: un bouton poussoir et une LED RVB qui change de couleur en fonction du mode sélectionné (orange: aucun mode, bleu: homme, rose: femme)

Plateforme Altium :

Affichage de 300 coefficients. Une 50aine est utile

• Implémentation d'un filtre à réponse impulsionnelle finie (RIF).
• Pour l'instant je filtre les fréquences entre 250 et 350Hz (fréquences de la caisse claire environ).
• Pour cela, je regarde chez moi sur le logiciel de calcul scilab les coefficients d'un tel filtre :
  • Filtre passe bande,
  • Fréquence de coupure haute : 350Hz,
  • Fréquence de coupure basse : 250Hz,
  • Échantillonnage à 2000Hz (ça devrait suffire), sur 8 bits.
• Quand je trace la caractéristique d'un tel filtre pour un grand nombre de coefficients, je vois qu'il me faut une cinquantaine de coefficients pour avoir un filtre correct.
• Je peux donc en séance projet implémenter mon code avec 50 coefficients.

Choix de l'algorithme :

• Le problème du filtrage temps réel se pose : je ne peux pas stocker en mémoire tout le morceau puis envoyer un signal à chaque fois que je détecte un beat par re-lecture. Il faut les détecter en temps réel.
• Je vais donc faire la conversion d'un temps très court de musique pour pouvoir le stocker en mémoire vive (je stocke 50 échantillons).
• Puis je filtre ces 50 échantillons. (Note : pour cela j'ai besoin des 50 échantillons précédents; les 50 premières valeurs en sortie de filtre ne seront donc pas bonnes).
• Je recommence avec 50 nouveaux échantillons, ad infinitum.
• Étant donné que la fréquence de l'horloge est de 50MHz et que les beats arrivent au maximum toutes les demies secondes, l'algorithme devrait être assez rapide.

Neuvième Séance (24/03/2011) -- 2h

Câblages et test de code Lilypad. Problème rencontré: les puces zigbee semblent ne pas communiquer ensemble à cause d'un changement de canal de transmission: à vérifier à la prochaine séance.

Prochaine séance: câblage Lilypad.

Plateforme Altium
Je continue les tests sur le filtrage. J'essaie de localiser des endroits précis de musique où il y a des basses, qui devraient apparaître en sortie de filtre.

Dixième Séance (28/03/2011) -- 2h

Problème des puces zigbee résolu: cela venait bien d'un changement de canal de transmission. On a donc changé les paramètres grâce au logiciel X-CTU. Amélioration du code

Plateforme Altium :

• Les données reçues en sortie de filtre ressemblent bien à des signaux mais ceux-ci restent tous du même ordre de grandeur.
  Soit ils sont tous trop grand et mon filtre ne filtre rien, soit il sont tous faible et je ne détecte aucune basse.
• Je met en place une fonction qui joue la sortie du filtre (on sait jamais, des fois qu'on puisse discerner une basse parmi le bruit), mais le résultat n'est pas satisfaisant.
• Je remet en question la bande passante de mon filtre, elle est peut être trop large et trop haute en fréquence.

Onzième Séance (31/03/2011) -- 2h

Problème de pause entre chaque cycle de vibrations

Plateforme Altium :

• Je décide de changer mes coefficients pour qu'ils correspondent à un nouveau type de filtre :
  • Filtre passe bande toujours
  • fréquence de coupure haute 80Hz
  • fréquence de coupure basse 50Hz
  • Même échantillonnage à 2000Hz sur 8 bits
• Pour déterminer ces nouveaux coefficients ne me suis aidé du logiciel audacity qui me permet de faire entre autre une alanyse spectrale de mon signal : sur un morceau de musique donné (celui que je test, avec des battements de grosse caisse évidents et réguliers), je remarque un pic (en puissance (dB)) à 75Hz.

Résultat :

• Les données reçues en sortie de filtre me laissent toujours perplexe :
• Visiblement le filtrage fonctionne puisque d'une part plus mon signal est fort (donc plus de puissance), plus je reçois de puissance en moyenne en sortie de filtre, et d'autre part, les données en sortie de filtre sont plus faibles sur des morceaux sans basses (testé avec un caprice de Paganini au violon - fréquences variant autour de la corde de la à 440Hz) que sur des morceaux saturés de basses (double pédale sur du métal).
• Mais sur mon morceau test avec ses basses claires et régulières, je ne vois pas de changement particulier lors de l'arrivée d'une basse.

Douzième Séance (4/04/2011) -- 2h

Problème de pause entre chaque cycle de vibrations : ce problème était du au fait qu'après incrémentation de la variable nbStep jusqu'à 6, on la réinitialisait à 0 au lieu de 1. le switch de notre code ne proposant aucune action pour un nbStep=1 on passait la boucle sans rien faire.

Plateforme Altium :

• Je décide de ré-examiner mes valeurs reçues dès l'enregistrement audio.
• En faisant plus attention aux valeurs de bruit que j'obtenais (valeurs supérieures à 190), je remarque qu'en fait ce sont des nombres négatifs complémentés à 2, envoyés par le CAN. En effet, plus le signal est puissant en entrée, plus la sortie du CAN varie autour de zéro et plus les valeurs hautes s'éloignent de 255. Ces valeurs hautes sont donc bien des valeurs négatives.
• Je met en place une fonction qui me renvoie ces données sur des entiers non signés.

Treizième Séance (5/04/2011) -- 4h

Plateforme Altium :

• Suite à la modification des entiers reçus en sortie du CAN, je n'ai plus ces valeurs excessivement hautes. Le signal en sortie devient du CAN devient beaucoup plus propre.
• Problème : maintenant lorsque je n'envoie rien, la valeur de mon signal en sortie du CAN est de 128 (le milieu entre 0 et 255). Pour ne pas que cela perturbe mes mesures ulétrieures (bien que en théorie cela ne devrait pas perturber le filtrage), je change ma fonction qui me renvoie un entier non signé pour qu'elle me renvoie cette fois-ci des entiers signés (mais cohérents : de -128 à 127, et pas de 0 à 127 puis 128 à 255 pour les entiers négatifs).
• Poursuite des tests.

Quatorzième Séance (7/04/2011) -- 2h

Plateforme Altium :

• J'imprime sur le tableur d'open office les valeurs de mon signal filtré. Je fais quelques graphes avec plusieurs musiques différentes (avec basse, sans basses, plus fort, moins fort, ...). Les résultats semblent cohérents et j'ai même un graphe prometteur qui me renvoie une puissance de sortie 100 fois supérieure à la moyenne pour un temps assez court, ce qui me laisse penser que ça pourrait être une basse.
• Problème principal : Pour pouvoir faire ces graphes, je suis obligé de stocker des quantités beaucoup plus importantes de données que ce que mon programme devra faire. En effet, pour filtrer en temps réel je stocke 150 coefficients, mais pour pouvoir les imprimer je dois en stocker beaucoup plus car je dois afficher une durée supérieure à celle qui correspond à 150 coefficients (75ms pour un échantillonnage à 2kHz). Or je peux afficher au maximum 3000 échantillons (1.5s).