Coach Dance - Historique des versions

Rex le 25 mai 2011 à 19:15

2011-05-25T19:15:25Z

Cdesravi : /* Séances Bonus */

2011-05-12T16:34:31Z

‎Séances Bonus

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

2011-05-11T22:55:27Z

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

Cdesravi : /* Seizième Séance (12/04/2011) -- 4h */

2011-05-04T22:30:44Z

‎Seizième Séance (12/04/2011) -- 4h

Cdesravi : /* Séances Bonus */

2011-05-04T22:27:21Z

‎Séances Bonus

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

2011-05-04T22:12:48Z

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

Mheciak : /* Séances Bonus */

2011-05-04T19:55:56Z

‎Séances Bonus

Mheciak : /* Séances Bonus */

2011-05-04T19:55:27Z

‎Séances Bonus

Mheciak : /* Séances Bonus */

2011-05-04T19:34:06Z

‎Séances Bonus

Mheciak : /* Séances Bonus */

2011-05-04T19:33:04Z

‎Séances Bonus

@@ Ligne 1 : / Ligne 1 : @@
-[[Image:salsa.jpg|right|thumb]]
+<include nopre noesc src="/home/pedago/pimasc/include/video-DanseCoach-iframe.html" />
 = 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.

← Version précédente		Version du 12 mai 2011 à 16:34
Ligne 262 :		Ligne 262 :

	Fin des coutures, légère modification du programme pour l'adapter à certains éléments notamment la led RVB Lilypad et l'interrupteur 2 positions. Lors des tests le programme de fonctionnait pas correctement: une fois implanté dans le Lilypad parce qu'avec les coutures effectuées le module Xbee était sous alimenté (il recevait environ 2,2V alors que la tension d'alimentation minimale est de 2,8V) il faut donc alimenter le module sans passer par des protoboards intermédiaires pour éviter les chutes de tension.		Fin des coutures, légère modification du programme pour l'adapter à certains éléments notamment la led RVB Lilypad et l'interrupteur 2 positions. Lors des tests le programme de fonctionnait pas correctement: une fois implanté dans le Lilypad parce qu'avec les coutures effectuées le module Xbee était sous alimenté (il recevait environ 2,2V alors que la tension d'alimentation minimale est de 2,8V) il faut donc alimenter le module sans passer par des protoboards intermédiaires pour éviter les chutes de tension.
		+
		+	[[Fichier:tshirt_final.jpg\|400px\|thumb\|center\|t-shirt final]]

	<strong>Plateforme Altium :</strong>		<strong>Plateforme Altium :</strong>

@@ Ligne 212 : / Ligne 212 : @@
 Il y avait une problème au niveau du changement de mode sur la platine Arduino: lorsque qu'on changeait de mode en plein milieu d'un cycle de vibration le cycle suivant ne faisait que trois vibrations puis s'arrêtait et recommençait quelques minutes après. Après divers tests, j'ai remarqué que ce problème apparaissait à cause d'une instruction delay() pour les pas 3-et-4 puis 5-et-6. Pour bien respecter les temps entre deux beats il fallait inclure la vibration pour le temps "et" qui n'est pas sur un beat marqué, de façon à ne pas râter les beats suivants (les beats 4 et 6). Or le délai que je calculais entre la fin d'activation des vibreurs pour les beats 3 et 5 et l'activation des vibreurs pour les temps "et" était parfois négatif. Le calcul que j'effectuais était le suivant:
-attente entre 3 et "et"=((delta/2) - pause).
+attente entre 3 et "et"=((delta/2) - temps d'activation vibreur).
 [[Fichier:cycle_de_vibration.jpg|300px|thumb|right|cycle de vibration des vibreurs]]
-Pour une raison qui m'est encore inconnue, lors d'un changement de mode, quelque soit le sens du changement (mode femme --> mode homme, mode homme --> mode femme), le temps delta/2 était inférieur à mon temps de pause (delta est calculé à partir d'une mesure de t1 et t2 les temps relevés grâce à la fonction millis() lors des beats 1 et 2). La fonction delay() que j'utilisais prenait donc un argument entier signé négatif transformé en entier non signé (la fonction delay() prend un unsigned long en paramètre) ce qui donnait des chiffres incohérents (par exemple au lieu d'avoir un délai de 200ms j'avais un délai de 10000ms voire beaucoup plus) j'ai donc changé ma gestion des activations et désactivations des vibreurs en partant du principe qu'une pause est toujours égale à delta/4. Le temps "et" se trouvant à delta/2 il suffisait d'attendre à nouveau delta/4 pour activer les vibreurs pour les temps "et". Grâce à cette technique le système s'adapte à n'importe quel tempo (initialement j'avais créé des temps de pauses particuliers pour des rythmes de 60bpm et 120bpm) .
+Pour une raison qui m'est encore inconnue, lors d'un changement de mode, quelque soit le sens du changement (mode femme --> mode homme, mode homme --> mode femme), le temps delta/2 était inférieur à mon temps d'activation des vibreurs(delta est calculé à partir d'une mesure de t1 et t2 les temps relevés grâce à la fonction millis() lors des beats 1 et 2). La fonction delay() que j'utilisais prenait donc un argument entier signé négatif transformé en entier non signé (la fonction delay() prend un unsigned long en paramètre) ce qui donnait des chiffres incohérents (par exemple au lieu d'avoir un délai de 200ms j'avais un délai de 10000ms voire beaucoup plus) j'ai donc changé ma gestion des activations et désactivations des vibreurs en partant du principe qu'une pause est toujours égale à delta/4. Le temps "et" se trouvant à delta/2 il suffisait d'attendre à nouveau delta/4 pour activer les vibreurs pour les temps "et". Grâce à cette technique le système s'adapte à n'importe quel tempo (initialement j'avais créé des temps de pauses particuliers pour des rythmes de 60bpm et 120bpm) .

← Version précédente		Version du 4 mai 2011 à 22:30
Ligne 246 :		Ligne 246 :

	===<u>Seizième Séance (12/04/2011) -- 4h</u>===		===<u>Seizième Séance (12/04/2011) -- 4h</u>===
		+	<strong>Arduino :</strong>
		+
		+	voici le t-shirt après quelques coutures:
		+	[[Fichier:Couture_debut.jpg\|400px\|center]]

	<strong>Plateforme Altium :</strong>		<strong>Plateforme Altium :</strong>

← Version précédente		Version du 4 mai 2011 à 22:27
Ligne 255 :		Ligne 255 :

	===<u>Séances Bonus </u>===		===<u>Séances Bonus </u>===
		+	<strong>Arduino :</strong>
		+
		+	Fin des coutures, légère modification du programme pour l'adapter à certains éléments notamment la led RVB Lilypad et l'interrupteur 2 positions. Lors des tests le programme de fonctionnait pas correctement: une fois implanté dans le Lilypad parce qu'avec les coutures effectuées le module Xbee était sous alimenté (il recevait environ 2,2V alors que la tension d'alimentation minimale est de 2,8V) il faut donc alimenter le module sans passer par des protoboards intermédiaires pour éviter les chutes de tension.

	<strong>Plateforme Altium :</strong>		<strong>Plateforme Altium :</strong>

@@ Ligne 227 : / Ligne 227 : @@
 ===<u>Quatorzième Séance (7/04/2011) -- 2h</u>===
 <strong>Arduino</strong>
 début de couture des éléments Lilypad sur le t-shirt

@@ Ligne 267 : / Ligne 267 : @@
 <br/>
-[[Fichier:Signal.png|200px|thumb|right|signal filtré]]
+[[Fichier:Signal.png|400px|thumb|right|signal filtré]]
 Au final j'arrive à détecter des beats, mais il reste deux points noirs :
 <ul>

@@ Ligne 262 : / Ligne 262 : @@
 <li/>Une autre solution est de monter la fréquence d'horloge. Mais cette méthode ne fonctionne pas non plus, la nanoboard n'est pas en mesure d'établir de route assez courte dans le fpga pour permettre une fréquence plus rapide. D'après le rapport d'Altium Designer établi après le 'place and route' et la génération du bit file dans le fpga, il est sûr de fonctionner correctement à une fréquence maximale de 40MHz. Je test en descendant la fréquence d'horloge à 40Mhz des fois que mes données soient corrompues à 50Mhz mais je n'obtiens pas de changements. Je reste donc à 50Mhz.
 <li/>Un problème qui peut intervenir aussi, mais qui n'est pas majeur, est un mauvais échantillonnage qui entrainerait des fausses données à basses fréquences, après l'échantillonnage : j'échantillonne à 2000Hz, ce qui est suffisant pour les basses fréquences. Mais pour les plus hautes fréquences, l'échantillonnage ne veut plus rien dire (pour une fréquence à 10kHz, on échantillonnerait une période sur 5). Cela peut en plus créer des faibles basses fréquences, qui n'en sont pas à la base (aliasing).
-<li/>Pour résoudre le problème d'aliasing, il faudrait échantillonner à au moins 44kHz, mais avec cela on augmenterai ne nombre de coefficients, donc le temps de calcul, et en plus on échantillonnerait moins de temps de musique à la fois. Je e peux pas me le permettre vu que le calcul est déjà long avec les paramètres actuels
+<li/>Pour résoudre le problème d'aliasing, il faudrait échantillonner à au moins 44kHz, mais avec cela on augmenterai ne nombre de coefficients, donc le temps de calcul, et en plus on échantillonnerait moins de temps de musique à la fois. Je ne peux pas me le permettre vu que le calcul est déjà long avec les paramètres actuels
 <li/>L'idéal serait de mettre au point une accélération matérielle pour les multiplications, ce qui augmenterait considérablement le temps de calcul pour le filtrage (bien que cela baisse probablement la fréquence d'horloge du processeur). L'accélération matérielle consiste à sous traiter certaines opération du processeur par le fpga même, qui peut lui les effectuer en parallèle. Malheureusement j'ai eu connaissance de cette option assez tard et je n'ai pas réussi à la mettre correctement au point sur la nanoboard. Cela m'aurait permis en plus d'augmenter ma fréquence d'échantillonnage pour limiter au maximum le phénomène d'aliasing.
 </ul>

@@ Ligne 260 : / Ligne 260 : @@
 <li/>Redéfinition du filtre : J'agrandi un peu la bande passante de 40 à 75Hz. J'ai à présent 100 coefficients.
 <li/>J'envisage le multi thread  en espérant accélérer le processus de filtrage (les multiplications). Mais j'abandonne vite l'idée : dans tous les cas de figure j'aurai des ressources partagées entre les deux threads, et comme les deux threads ne peuvent accéder à la ressource en même temps, l'un attendra toujours pendant que l'autre s'exécute.
-<li/>Une autre solution est de monter la fréquence d'horloge. Mais cette méthode ne fonctionne pas non plus, la nanoboard n'est pas en mesure d'établir de route assez courte dans le fpga pour permettre une fréquence plus rapide. D'après le rapport d'Altium Designer établi après le 'place and route' et la génération du bit file dans le fpga, il est sur de fonctionner correctement à une fréquence maximale de 40MHz. Je test en descendant la fréquence d'horloge à 40Mhz des fois que mes données soient corrompues à 50Mhz mais je n'obtiens pas de changements. Je reste donc à 50Mhz.
+<li/>Une autre solution est de monter la fréquence d'horloge. Mais cette méthode ne fonctionne pas non plus, la nanoboard n'est pas en mesure d'établir de route assez courte dans le fpga pour permettre une fréquence plus rapide. D'après le rapport d'Altium Designer établi après le 'place and route' et la génération du bit file dans le fpga, il est sûr de fonctionner correctement à une fréquence maximale de 40MHz. Je test en descendant la fréquence d'horloge à 40Mhz des fois que mes données soient corrompues à 50Mhz mais je n'obtiens pas de changements. Je reste donc à 50Mhz.
 <li/>Un problème qui peut intervenir aussi, mais qui n'est pas majeur, est un mauvais échantillonnage qui entrainerait des fausses données à basses fréquences, après l'échantillonnage : j'échantillonne à 2000Hz, ce qui est suffisant pour les basses fréquences. Mais pour les plus hautes fréquences, l'échantillonnage ne veut plus rien dire (pour une fréquence à 10kHz, on échantillonnerait une période sur 5). Cela peut en plus créer des faibles basses fréquences, qui n'en sont pas à la base (aliasing).
 <li/>Pour résoudre le problème d'aliasing, il faudrait échantillonner à au moins 44kHz, mais avec cela on augmenterai ne nombre de coefficients, donc le temps de calcul, et en plus on échantillonnerait moins de temps de musique à la fois. Je e peux pas me le permettre vu que le calcul est déjà long avec les paramètres actuels