Wiki de Projets IMA - Contributions de l’utilisateur [fr]

Google ADK et wearable computing

2012-02-22T17:14:38Z

Cdesravi : /* Code Arduino */

=Présentation=

'''Contexte:''' Développement d'extension pour Android

Android dispose d'un protocole facilitant la connexion de périphériques sur les téléphones et les tablets
http://developer.android.com/guide/topics/usb/adk.html
A l'heure actuelle, il existe quelques kit de développement, mais peu d'extension existent. L'objectif du projet consiste à réaliser plusieurs cartes d'extensions. Ci-après la liste des premières cartes à réaliser,
Les étudiants pourront ensuite proposer leurs propres extensions:

- Support XBee (comme pour les Arduino)

- Support RFID

- Support vêtement intelligent pour la danse (suite du projet IMA4SC)

-...

=Résultats=
En cas de question n'hésitez pas à contacter Catherine Desravine ( Catherine.Desravines [ at ] polytech-lille [dot] net ) ou Nicolas Lefebvre ( lef.nicolas [ at ] gmail [ dot ] com).

Les codes sources sont aussi disponible en E306 sur tutur02 (partie Android + detection de mouvement) dans le dossier /home/pifou/IMA5sc/PFEADKAndroid/ ou sur tutur01 ( reste de la partie Arduino) dans le dossier /home/pifou/Documents/Coachoid/

== Application Android ==
L'application Coachoid v1.0 permet de lire les musiques sur le téléphone, détectes si les musiques sont taggées au format Coachoid ("Coachoid=[12.5,42.1,78.6]" par exemple), auquel cas elle envoie les informations recueillies à l'accessoire Arduino connecté.

* Telecharger Coachoid v1.0 : http://www.mirorii.com/fichier/44/507446/Coachoid_1-0-apk.html
* Code source : http://www.mirorii.com/fichier/26/507454/Coachoid_1-0-zip.html

== Code Arduino ==
=== Detection de mouvement ===
Ce petit programme utilise la norme des vecteurs d'acceleration renvoyés par les acceleromètres Lilypad pour en déduire si un mouvement a été effectué ou non.
Il permet de créer des tag pour l'application Coachoid ( informations renvoyées sur le port série ) contenant les temps auxquels des pas sont effectués.
Code source : http://pastebin.com/e2bhiFV9
=== Accessoire pour Android et programme pour le Tshirt===
====Accessoire Android====
Ce programme détecte la connexion d'un téléphone Android et interagit avec l'application Coachoid. Il envoie les informations sur le sexe de l'utilisateur , le style de musique (salsa ou rock 6 temps) ainsi que les beats d'une chanson en fonction des informations qu'il reçoit du téléphone.
====Programme pour le T-shirt====
Ce programme gère l'activation des vibreurs en fonction du genre de l'utilisateur ainsi que de la musique selon les informations de beat reçue par la liaison sans fil Zigbee.

Le code source de l'accessoire Android à compiler et uploader sur la MegaADK board se trouve dans le dossier ADKFinal de l'archive. Le code source pour le Lilypad sur le T-shirt se trouve dans le dossier TShirtFinal.
* Code source : http://www.mirorii.com/fichier/74/507486/Sources-tar-gz.html

[[Fichier:Tshirt.png|300px|thumb|center|Prototype Final]]

=Réalisation=

==Séance 1 (5/10/2011)==

Prise en main des téléphones et du sujet, mis à jour des téléphones vers 2.3.4.

==Séance 2 (10/10/2011)==

Fin de mise à jour des téléphones vers 2.3.4 et 2.3.5.

==Séance 3 (11/10/2011)==
Installation de Android SDK
: -http://developer.android.com/sdk/installing.html
:: -http://developer.android.com/sdk/requirements.html
::: -installation de Eclipse Galileo
::: -installation du plugin ADT http://developer.android.com/sdk/eclipse-adt.html

Problèmes rencontrés et solutions apportées:

lien https de dl-ssl.google.com ne fonctionne pas: remplacement du https en http
NB: pour le STEP 4 de http://developer.android.com/sdk/installing.html => http forcé dans les paramètres du SDK Manager

== Séance 4(18/10/2011)==
Test de l'installation DemoKit de l'ADK.

== Séance 5(2/11/2011)==
Définition des tâches principales et répartition:

*lecture de la musique par le téléphone (application Android), détection des BPM (Matlab) => Nicolas
*envoi des infos BPM à l'arduino (extraction des metadatas et envoi) => Nicolas
*transmission des BPM via Zigbee au T-shirt => Catherine

*Test liaison telephone <-> Arduino : affichage message sur terminal serie (arduino) lors de l'appui sur un interrupteur sur le telephone.
* Exploration des datasheet du Arduino pour trouver la correspondance des Port en C avec les broches.

===Problèmes rencontrés===
*Manque de certains fichiers qui permettent la communication USB sur les téléphones.
*Incompatibilité du programme Arduino de démonstration => programmation en C

== Séance 6 (04/11/2011) ==
Début des tâches séparées.

* début création application android simple avec un seul bouton qui permet l'envoi d'un seul bit sur le port usb lorsqu'il est appuyé.
* prise en main du makefile pour la compilation directe en C pour arduino

== Séance 7 ( 07/11 ) ==
* App: Mise en place bouton d'envoi de bit et Slider de selection de BPM pour simulation : interface ok, mais pas connecté.

* [[Fichier:C360 2011-11-0816-01-14.jpg|200px|thumb|right|led qui clignote]] Arduino : Finalisation clignotage de LED en C, et mise en place d'AVR pour eclipse.

== Séance 8 ( 8/11 ) ==
[[Fichier:App01_test_bpm.png|200px|thumb|right|application de test avec un envoi à 124 BPM]]
* Finalisation interface de l'application de test et début d'intégration de l'ADK pour communiquer avec la board.
* headers et codes source C pour le connecteur usb de la carte trouvés il ne reste qu'à tranposer le header AndroidAccessory.cpp en .c et adapter le header.

== Séance 9 (14/11) ==

* Mise en place de la connectivité avec les accessoires sur l'application de test. Reste à tester sur l'arduino.

== Séance 10 (15/11) ==

* L'application communique bien avec le circuit arduino. Début de mise en place d'un tâche périodique pour envoyer un bit régulièrement suivant le BPM.

* Traduction en C des librairies.

== Séance 11 (18/11) ==
* Tâche périodique d'envoi de Beat mise en place. Mais soucis de prise en compte des modifications lors du slide ( trop de changements d'états en peu de temps...). ( aide : http://www.developpez.net/forums/d669466/c-cpp/outils-c-cpp/visual-cpp/mfc/interception-levt-mousedown-slider/ et http://stackoverflow.com/questions/937313/android-basic-gesture-detection )
* Traduction en C de la librairie AndroidAccessory.c

== Séance 12 (21/11) ==

* Finalisation de l'application de test avec l'envoi periodique de Beat ( 1 binaire) en choisissant la fréquence grâce au slider. Création de l'[http://www.mirorii.com/fichier/91/456089/DemoKit_0-3-1-apk.html apk associé DemoKit 0.3.1] ([http://www.mirorii.com/fichier/46/456090/DemoKit_0-3-1-zip.html sources]).
* Poursuite de la traduction en C.

== Séance 13 (22/11) ==

* Test de l'application avec les XBee (configuration de ceux-ci), et test avec le T-shirt du projet de l'année dernière avec succès.
* Début de l'application Coachoid v4.0 = application finale de lecture de musique & co. ( http://developer.android.com/guide/topics/media/mediaplayer.html )
* Les sources trouvées sur Internet se sont révélées être incomplètes et trop complexes à utiliser. Adaptation en C des sources C++ fournies avec l'ADK
** codes source inchangés: ch9.h, Max3421e_constants.h
** codes source en cours d'adaptation: Usb.h,Max3421e.h, Max3421e.c, Usb.c
** codes source restant à adapter: AndroidAccessory.cpp, AndroidAccessory.h

Il y aura la fonction digitalWrite à réécrire également.

== Séance 14 (28/11) ==

* Suite de l'adaptation des sources C++ en C:
** codes sources adaptés: Max3421e.h, Max3421e.c
** codes source en cours d'adaptation: Usb.h, Usb.c
** codes source restant à adapter: AndroidAccessory.cpp, AndroidAccessory.h, fonction digitalWrite de la librairie Wiring
* Mise en place de la recherche des musiques du telephone, affichage en list et début d'implementation des intéractions avec les musiques.

== Séance 15 (29/11) ==

* Lecture basique de musique fonctionnel avec barre progression et selection de musique
* Suite et fin de l'adaptation des sources C++ en C:
* Déboggage des sources C

== Séance 16 (30/11) ==

* Suite du déboggage des sources C
* Finitions de la liste (avec enchainement, bouton play-pause)

== Séance 17 (1/12) ==

* Mise en avant de la musique joué
* Lecture des tag des mp3 grâce à http://www.jthink.net/jaudiotagger/
* Fin du déboggage des sources
* Début du développement d'un programme test

== Séance 18 (5/12) ==
* Test inclusion de l'information de BPM dans les tags de la musique. Tests Réussi
* Recherche de solution pour prendre le bpm de chaque musique ( http://stackoverflow.com/questions/79445/beats-per-minute-from-real-time-audio-input http://www.streamhead.com/easy-bpm-calculation-in-java/ http://bpmdj.yellowcouch.org/ & http://jorgenmodin.net/index_html/archive/2010/07/23/counting-bpm-beats-per-minute-on-linux/weblogentry_view#1315989621 )
* deboggage des sources terminé, développement d'un programme test

== Séance 19 (04/01) ==
* Exploration du calcul du BPM instantanéement. Exploration de la solution http://www.streamhead.com/easy-bpm-calculation-in-java/ qui donne des résultats cohérents.
* Recherche d'autres outils de calcul pour avoir des référance de BPM.

== Séance 20 (05/01) ==
* Débuggage des sources C pour Arduino

== Séance 21 (11/01) ==
* Premier programme de test de connexion d'un téléphone à la plateforme Arduino
Deux fonctions posent problème : celle d'initialisation du port usb (powerOn) de la plateforme ainsi que celle qui permet de détecter la connexion d'un téléphone (isConnected).

== Séance 22 (12/01) ==
Arduino
Le problème des fonction powerOn et isConnected a été résolu en réalité les soucis venaient du fait que le port usb n'était pas initialisé dans le programme test et il y avait également un délai trop long (200s) à la fin de la fonction powerOn.

== Séance 23 (16/01) ==
*Début d'intégration de la bibliothèque de calcul de BPM dans l'application

Arduino:
La lecture de l'information sur le port usb pose problème il semblerait qu'un code retour soit égal à 0x65 au lieu de 0x00 (usb.c ligne 320)

== Séance 24 (31/01) ==
* Ecriture des BPMs dans le champs "encoder" des fichiers. Sous la forme : "CDD|Nombre_de_BPMs|[Liste des BPMs]" exemple : "CDD|6|[95, 119, 119, 131, 107, 143]"
Arduino:
bugs du programme de base=>
* il arrive que le programme s'arrête puis redémarre après qu'on ai connecté la borne MISO et la borne +5V du composant ICSP.
* La fonction isConnected renvoie toujours 1 même quand le téléphone n'est pas connecté

== 07/02 ==

* création du circuit permettant de detecter le mouvement d'un accelerometre pour tagger automatiquement les musiques.
http://web.media.mit.edu/~leah/LilyPad/build/accelero_shirt.html et http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1245357699

* Après correction des sources C par Mr. Vantroys, le code arduino de test a été amélioré. On peut maintenant brancher un téléphone sur la MegaADk, récupérer l'octet '1' envoyé par l'application demokit v0.3.1 et le renvoyer par commmunication zigbee.

== 10/02 ==
* L’accéléromètre permet uniquement de détecter les angles : http://bildr.org/2011/04/sensing-orientation-with-the-adxl335-arduino/

=Préparation téléphones=
== Commun ==
* Suivre ce tuto pour pouvoir tester els applciations directement sur le telephone : http://developer.android.com/guide/developing/device.html j'ai utilisé celui ci : http://bzed.de/posts/2009/05/howto_set_android_developer_device_permissions_with_udev/

=== Soucis de com.android.future.usb.accessory.jar ===
xml : [[Google_ADK_et_wearable_computing/android.hardware.usb.accessory.xml|android.hardware.usb.accessory.xml]]

jar : [http://www.mirorii.com/fichier/8/444186/com-android-future-usb-accessory-jar.html com.android.future.usb.accessory.jar]

su
mount -o remount,rw -t yaffs2 /dev/block/mtdblock4 /system
cp /sdcard/com.android.future.usb.accessory.jar /system/framework
chmod 655 /system/framework/com.android.future.usb.accessory.jar
vi /etc/permissions/android.hardware.usb.accessory.xml
chmod 655 /etc/permissions/android.hardware.usb.accessory.xml
mount -o ro,remount -t yaffs2 /dev/block/mtdblock4 /system

manipulation légèrement différente pour le motorola defy:

mount -o remount,rw -t ext3 /dev/block/mmsblk1p21 /system
cp com.android.future.usb.accessory.jar /system/framework
chmod 644 /system/framework/com.android.future.usb.accessory.jar
cp android.hardware.usb.accessory.xml /etc/permissions
chmod 644 /etc/permissions/android.hardware.usb.accessory.xml
mount -o ro,remount -t ext3 /dev/block/mmsblk1p21 /system
---------> reboot pour que la librairie soit prise en compte.

==Milestone 2 (droid2)==
Passage en 2.3.4 : http://forum.xda-developers.com/showthread.php?t=1169038
Compte google : imapolytech@gmail.com (mot de passe = mot de passe habituel "root")

==Motorola Defy==
Passage en 2.3.4 : http://forum.frandroid.com/topic/51780-rom-cyanogen-7-rc15/ (gingerbreak incompatible avec android 2.1 : utilisation de z4root => failed, nécessite un passage à froyo via Windows avec le logiciel Motorola Software Update)
Compte google : defypolytechima@gmail.com

= Arduino =
==Hardware==
*liste des pins pour le microprocesseur ATmega2560 
http://arduino.cc/en/Hacking/PinMapping2560
*exemple de programmation avec AVR 
http://hlt.media.mit.edu/wiki/pmwiki.php?n=Main.AVRProgrammingAdvanced
*exemple de code arduino en C pour communiquer via le port série 
http://todbot.com/blog/2006/12/06/arduino-serial-c-code-to-talk-to-arduino/
*présentation arduinoboardADK 
http://www.arduino.cc/en/Main/ArduinoBoardADK
*code source led qui clignote pour Atmega328p (commande pour compiler avec avr-gcc et uploader avecavrdude) 
http://balau82.wordpress.com/2011/03/29/programming-arduino-uno-in-pure-c/
*code source led qui clignote atmega168 
http://www.javiervalcarce.eu/wiki/Program_Arduino_with_AVR-GCC
*code source pour USB Host: MAX3421E 
http://code.google.com/p/microbridge/source/browse/trunk/src/mcu/?r=20#mcu

== Xbee ==

Utilisation du channel 15 ( sous minicom -s "+++" -> "ATCH15" -> "ATCH" pour verifier -> "ATWR" pour sauvegarder -> ATCN pour quitter la modif
=== Configuration===

*http://arduino.cc/en/Guide/ArduinoXbeeShield

== C ==
===Compilation ===
*[[:Fichier:Makefile.jpg|Makefile de Mr Vantroys]] points à veririer : MCU, CFLAG et DUDE
*[http://www.robgray.com/temp/makefile Makefile plus imposant]

==Divers==
=== Connexion root pour lancer l'IDE arduino===
ssh -X -lroot localhost

=Arduino=
*[http://www.mirorii.com/fichier/84/492503/code_arduinoV1-tar-gz.html code arduino v1.0]: Version de code qui fonctionne
**envoie d'un octet '1' par appli android, récupération par arduino sur le port usb, envoi d'un 1 par liaison Zigbee

= Android =
== Création apk ==
Le certificat contenant les clef de cryptage des apk se situe dans le repertoire /home/pifou/.android/keystore_signature_apk de tutur02. Les mots de passe sont ceux les mots de passe root habituels.

== Version App Coachoid ==

* [http://www.mirorii.com/fichier/91/456089/DemoKit_0-3-1-apk.html DemoKit 0.3.1] : Appli de test d'envoi d'1 bit avec un BPM voulu. ([http://www.mirorii.com/fichier/46/456090/DemoKit_0-3-1-zip.html sources])
* [http://www.mirorii.com/fichier/45/460974/Coachoid_0-4-apk.html Coachoid 0.4] : Application présentation pre-soutenance.
**Lecture musiques
**Lecture d'un BPM dans les tags de la musique
**Envoi des BPMs à l'accessoire.

Google ADK et wearable computing

2012-02-22T17:13:26Z

Cdesravi : /* Code Arduino */

=Présentation=

'''Contexte:''' Développement d'extension pour Android

Android dispose d'un protocole facilitant la connexion de périphériques sur les téléphones et les tablets
http://developer.android.com/guide/topics/usb/adk.html
A l'heure actuelle, il existe quelques kit de développement, mais peu d'extension existent. L'objectif du projet consiste à réaliser plusieurs cartes d'extensions. Ci-après la liste des premières cartes à réaliser,
Les étudiants pourront ensuite proposer leurs propres extensions:

- Support XBee (comme pour les Arduino)

- Support RFID

- Support vêtement intelligent pour la danse (suite du projet IMA4SC)

-...

=Résultats=
En cas de question n'hésitez pas à contacter Catherine Desravine ( Catherine.Desravines [ at ] polytech-lille [dot] net ) ou Nicolas Lefebvre ( lef.nicolas [ at ] gmail [ dot ] com).

Les codes sources sont aussi disponible en E306 sur tutur02 (partie Android + detection de mouvement) dans le dossier /home/pifou/IMA5sc/PFEADKAndroid/ ou sur tutur01 ( reste de la partie Arduino) dans le dossier /home/pifou/Documents/Coachoid/

== Application Android ==
L'application Coachoid v1.0 permet de lire les musiques sur le téléphone, détectes si les musiques sont taggées au format Coachoid ("Coachoid=[12.5,42.1,78.6]" par exemple), auquel cas elle envoie les informations recueillies à l'accessoire Arduino connecté.

* Telecharger Coachoid v1.0 : http://www.mirorii.com/fichier/44/507446/Coachoid_1-0-apk.html
* Code source : http://www.mirorii.com/fichier/26/507454/Coachoid_1-0-zip.html

== Code Arduino ==
=== Detection de mouvement ===
Ce petit programme utilise la norme des vecteurs d'acceleration renvoyés par les acceleromètres Lilypad pour en déduire si un mouvement a été effectué ou non.
Il permet de créer des tag pour l'application Coachoid ( informations renvoyées sur le port série ) contenant les temps auxquels des pas sont effectués.
Code source : http://pastebin.com/e2bhiFV9
=== Accessoire pour Android et programme pour le Tshirt===
====Accessoire Android====
Ce programme détecte la connexion d'un téléphone Android et interagit avec l'application Coachoid. Il envoie les informations sur le sexe de l'utilisateur , le style de musique (salsa ou rock 6 temps) ainsi que les beats d'une chanson en fonction des informations qu'il reçoit du téléphone.
====Programme pour le T-shirt====
Ce programme gère l'activation des vibreurs en fonction du genre de l'utilisateur ainsi que de la musique selon les informations de beat reçue par la liaison sans fil Zigbee.

Le code source de l'accessoire Android à compiler et uploader sur la MegaADK board se trouve dans le dossier ADKFinal de l'archive. Le code source pour le Lilypad sur le T-shirt se trouve dans le dossier TShirtFinal.
* Code source : http://www.mirorii.com/fichier/74/507486/Sources-tar-gz.html

Fichier:Tshirt.png

=Réalisation=

==Séance 1 (5/10/2011)==

Prise en main des téléphones et du sujet, mis à jour des téléphones vers 2.3.4.

==Séance 2 (10/10/2011)==

Fin de mise à jour des téléphones vers 2.3.4 et 2.3.5.

==Séance 3 (11/10/2011)==
Installation de Android SDK
: -http://developer.android.com/sdk/installing.html
:: -http://developer.android.com/sdk/requirements.html
::: -installation de Eclipse Galileo
::: -installation du plugin ADT http://developer.android.com/sdk/eclipse-adt.html

Problèmes rencontrés et solutions apportées:

lien https de dl-ssl.google.com ne fonctionne pas: remplacement du https en http
NB: pour le STEP 4 de http://developer.android.com/sdk/installing.html => http forcé dans les paramètres du SDK Manager

== Séance 4(18/10/2011)==
Test de l'installation DemoKit de l'ADK.

== Séance 5(2/11/2011)==
Définition des tâches principales et répartition:

*lecture de la musique par le téléphone (application Android), détection des BPM (Matlab) => Nicolas
*envoi des infos BPM à l'arduino (extraction des metadatas et envoi) => Nicolas
*transmission des BPM via Zigbee au T-shirt => Catherine

*Test liaison telephone <-> Arduino : affichage message sur terminal serie (arduino) lors de l'appui sur un interrupteur sur le telephone.
* Exploration des datasheet du Arduino pour trouver la correspondance des Port en C avec les broches.

===Problèmes rencontrés===
*Manque de certains fichiers qui permettent la communication USB sur les téléphones.
*Incompatibilité du programme Arduino de démonstration => programmation en C

== Séance 6 (04/11/2011) ==
Début des tâches séparées.

* début création application android simple avec un seul bouton qui permet l'envoi d'un seul bit sur le port usb lorsqu'il est appuyé.
* prise en main du makefile pour la compilation directe en C pour arduino

== Séance 7 ( 07/11 ) ==
* App: Mise en place bouton d'envoi de bit et Slider de selection de BPM pour simulation : interface ok, mais pas connecté.

* [[Fichier:C360 2011-11-0816-01-14.jpg|200px|thumb|right|led qui clignote]] Arduino : Finalisation clignotage de LED en C, et mise en place d'AVR pour eclipse.

== Séance 8 ( 8/11 ) ==
[[Fichier:App01_test_bpm.png|200px|thumb|right|application de test avec un envoi à 124 BPM]]
* Finalisation interface de l'application de test et début d'intégration de l'ADK pour communiquer avec la board.
* headers et codes source C pour le connecteur usb de la carte trouvés il ne reste qu'à tranposer le header AndroidAccessory.cpp en .c et adapter le header.

== Séance 9 (14/11) ==

* Mise en place de la connectivité avec les accessoires sur l'application de test. Reste à tester sur l'arduino.

== Séance 10 (15/11) ==

* L'application communique bien avec le circuit arduino. Début de mise en place d'un tâche périodique pour envoyer un bit régulièrement suivant le BPM.

* Traduction en C des librairies.

== Séance 11 (18/11) ==
* Tâche périodique d'envoi de Beat mise en place. Mais soucis de prise en compte des modifications lors du slide ( trop de changements d'états en peu de temps...). ( aide : http://www.developpez.net/forums/d669466/c-cpp/outils-c-cpp/visual-cpp/mfc/interception-levt-mousedown-slider/ et http://stackoverflow.com/questions/937313/android-basic-gesture-detection )
* Traduction en C de la librairie AndroidAccessory.c

== Séance 12 (21/11) ==

* Finalisation de l'application de test avec l'envoi periodique de Beat ( 1 binaire) en choisissant la fréquence grâce au slider. Création de l'[http://www.mirorii.com/fichier/91/456089/DemoKit_0-3-1-apk.html apk associé DemoKit 0.3.1] ([http://www.mirorii.com/fichier/46/456090/DemoKit_0-3-1-zip.html sources]).
* Poursuite de la traduction en C.

== Séance 13 (22/11) ==

* Test de l'application avec les XBee (configuration de ceux-ci), et test avec le T-shirt du projet de l'année dernière avec succès.
* Début de l'application Coachoid v4.0 = application finale de lecture de musique & co. ( http://developer.android.com/guide/topics/media/mediaplayer.html )
* Les sources trouvées sur Internet se sont révélées être incomplètes et trop complexes à utiliser. Adaptation en C des sources C++ fournies avec l'ADK
** codes source inchangés: ch9.h, Max3421e_constants.h
** codes source en cours d'adaptation: Usb.h,Max3421e.h, Max3421e.c, Usb.c
** codes source restant à adapter: AndroidAccessory.cpp, AndroidAccessory.h

Il y aura la fonction digitalWrite à réécrire également.

== Séance 14 (28/11) ==

* Suite de l'adaptation des sources C++ en C:
** codes sources adaptés: Max3421e.h, Max3421e.c
** codes source en cours d'adaptation: Usb.h, Usb.c
** codes source restant à adapter: AndroidAccessory.cpp, AndroidAccessory.h, fonction digitalWrite de la librairie Wiring
* Mise en place de la recherche des musiques du telephone, affichage en list et début d'implementation des intéractions avec les musiques.

== Séance 15 (29/11) ==

* Lecture basique de musique fonctionnel avec barre progression et selection de musique
* Suite et fin de l'adaptation des sources C++ en C:
* Déboggage des sources C

== Séance 16 (30/11) ==

* Suite du déboggage des sources C
* Finitions de la liste (avec enchainement, bouton play-pause)

== Séance 17 (1/12) ==

* Mise en avant de la musique joué
* Lecture des tag des mp3 grâce à http://www.jthink.net/jaudiotagger/
* Fin du déboggage des sources
* Début du développement d'un programme test

== Séance 18 (5/12) ==
* Test inclusion de l'information de BPM dans les tags de la musique. Tests Réussi
* Recherche de solution pour prendre le bpm de chaque musique ( http://stackoverflow.com/questions/79445/beats-per-minute-from-real-time-audio-input http://www.streamhead.com/easy-bpm-calculation-in-java/ http://bpmdj.yellowcouch.org/ & http://jorgenmodin.net/index_html/archive/2010/07/23/counting-bpm-beats-per-minute-on-linux/weblogentry_view#1315989621 )
* deboggage des sources terminé, développement d'un programme test

== Séance 19 (04/01) ==
* Exploration du calcul du BPM instantanéement. Exploration de la solution http://www.streamhead.com/easy-bpm-calculation-in-java/ qui donne des résultats cohérents.
* Recherche d'autres outils de calcul pour avoir des référance de BPM.

== Séance 20 (05/01) ==
* Débuggage des sources C pour Arduino

== Séance 21 (11/01) ==
* Premier programme de test de connexion d'un téléphone à la plateforme Arduino
Deux fonctions posent problème : celle d'initialisation du port usb (powerOn) de la plateforme ainsi que celle qui permet de détecter la connexion d'un téléphone (isConnected).

== Séance 22 (12/01) ==
Arduino
Le problème des fonction powerOn et isConnected a été résolu en réalité les soucis venaient du fait que le port usb n'était pas initialisé dans le programme test et il y avait également un délai trop long (200s) à la fin de la fonction powerOn.

== Séance 23 (16/01) ==
*Début d'intégration de la bibliothèque de calcul de BPM dans l'application

Arduino:
La lecture de l'information sur le port usb pose problème il semblerait qu'un code retour soit égal à 0x65 au lieu de 0x00 (usb.c ligne 320)

== Séance 24 (31/01) ==
* Ecriture des BPMs dans le champs "encoder" des fichiers. Sous la forme : "CDD|Nombre_de_BPMs|[Liste des BPMs]" exemple : "CDD|6|[95, 119, 119, 131, 107, 143]"
Arduino:
bugs du programme de base=>
* il arrive que le programme s'arrête puis redémarre après qu'on ai connecté la borne MISO et la borne +5V du composant ICSP.
* La fonction isConnected renvoie toujours 1 même quand le téléphone n'est pas connecté

== 07/02 ==

* création du circuit permettant de detecter le mouvement d'un accelerometre pour tagger automatiquement les musiques.
http://web.media.mit.edu/~leah/LilyPad/build/accelero_shirt.html et http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1245357699

* Après correction des sources C par Mr. Vantroys, le code arduino de test a été amélioré. On peut maintenant brancher un téléphone sur la MegaADk, récupérer l'octet '1' envoyé par l'application demokit v0.3.1 et le renvoyer par commmunication zigbee.

== 10/02 ==
* L’accéléromètre permet uniquement de détecter les angles : http://bildr.org/2011/04/sensing-orientation-with-the-adxl335-arduino/

=Préparation téléphones=
== Commun ==
* Suivre ce tuto pour pouvoir tester els applciations directement sur le telephone : http://developer.android.com/guide/developing/device.html j'ai utilisé celui ci : http://bzed.de/posts/2009/05/howto_set_android_developer_device_permissions_with_udev/

=== Soucis de com.android.future.usb.accessory.jar ===
xml : [[Google_ADK_et_wearable_computing/android.hardware.usb.accessory.xml|android.hardware.usb.accessory.xml]]

jar : [http://www.mirorii.com/fichier/8/444186/com-android-future-usb-accessory-jar.html com.android.future.usb.accessory.jar]

su
mount -o remount,rw -t yaffs2 /dev/block/mtdblock4 /system
cp /sdcard/com.android.future.usb.accessory.jar /system/framework
chmod 655 /system/framework/com.android.future.usb.accessory.jar
vi /etc/permissions/android.hardware.usb.accessory.xml
chmod 655 /etc/permissions/android.hardware.usb.accessory.xml
mount -o ro,remount -t yaffs2 /dev/block/mtdblock4 /system

manipulation légèrement différente pour le motorola defy:

mount -o remount,rw -t ext3 /dev/block/mmsblk1p21 /system
cp com.android.future.usb.accessory.jar /system/framework
chmod 644 /system/framework/com.android.future.usb.accessory.jar
cp android.hardware.usb.accessory.xml /etc/permissions
chmod 644 /etc/permissions/android.hardware.usb.accessory.xml
mount -o ro,remount -t ext3 /dev/block/mmsblk1p21 /system
---------> reboot pour que la librairie soit prise en compte.

==Milestone 2 (droid2)==
Passage en 2.3.4 : http://forum.xda-developers.com/showthread.php?t=1169038
Compte google : imapolytech@gmail.com (mot de passe = mot de passe habituel "root")

==Motorola Defy==
Passage en 2.3.4 : http://forum.frandroid.com/topic/51780-rom-cyanogen-7-rc15/ (gingerbreak incompatible avec android 2.1 : utilisation de z4root => failed, nécessite un passage à froyo via Windows avec le logiciel Motorola Software Update)
Compte google : defypolytechima@gmail.com

= Arduino =
==Hardware==
*liste des pins pour le microprocesseur ATmega2560 
http://arduino.cc/en/Hacking/PinMapping2560
*exemple de programmation avec AVR 
http://hlt.media.mit.edu/wiki/pmwiki.php?n=Main.AVRProgrammingAdvanced
*exemple de code arduino en C pour communiquer via le port série 
http://todbot.com/blog/2006/12/06/arduino-serial-c-code-to-talk-to-arduino/
*présentation arduinoboardADK 
http://www.arduino.cc/en/Main/ArduinoBoardADK
*code source led qui clignote pour Atmega328p (commande pour compiler avec avr-gcc et uploader avecavrdude) 
http://balau82.wordpress.com/2011/03/29/programming-arduino-uno-in-pure-c/
*code source led qui clignote atmega168 
http://www.javiervalcarce.eu/wiki/Program_Arduino_with_AVR-GCC
*code source pour USB Host: MAX3421E 
http://code.google.com/p/microbridge/source/browse/trunk/src/mcu/?r=20#mcu

== Xbee ==

Utilisation du channel 15 ( sous minicom -s "+++" -> "ATCH15" -> "ATCH" pour verifier -> "ATWR" pour sauvegarder -> ATCN pour quitter la modif
=== Configuration===

*http://arduino.cc/en/Guide/ArduinoXbeeShield

== C ==
===Compilation ===
*[[:Fichier:Makefile.jpg|Makefile de Mr Vantroys]] points à veririer : MCU, CFLAG et DUDE
*[http://www.robgray.com/temp/makefile Makefile plus imposant]

==Divers==
=== Connexion root pour lancer l'IDE arduino===
ssh -X -lroot localhost

=Arduino=
*[http://www.mirorii.com/fichier/84/492503/code_arduinoV1-tar-gz.html code arduino v1.0]: Version de code qui fonctionne
**envoie d'un octet '1' par appli android, récupération par arduino sur le port usb, envoi d'un 1 par liaison Zigbee

= Android =
== Création apk ==
Le certificat contenant les clef de cryptage des apk se situe dans le repertoire /home/pifou/.android/keystore_signature_apk de tutur02. Les mots de passe sont ceux les mots de passe root habituels.

== Version App Coachoid ==

* [http://www.mirorii.com/fichier/91/456089/DemoKit_0-3-1-apk.html DemoKit 0.3.1] : Appli de test d'envoi d'1 bit avec un BPM voulu. ([http://www.mirorii.com/fichier/46/456090/DemoKit_0-3-1-zip.html sources])
* [http://www.mirorii.com/fichier/45/460974/Coachoid_0-4-apk.html Coachoid 0.4] : Application présentation pre-soutenance.
**Lecture musiques
**Lecture d'un BPM dans les tags de la musique
**Envoi des BPMs à l'accessoire.

Fichier:Tshirt.png

2012-02-22T17:12:28Z

Cdesravi : Projet final

Projet final

Google ADK et wearable computing

2012-02-22T17:02:25Z

Cdesravi : /* Résultats */

=Présentation=

'''Contexte:''' Développement d'extension pour Android

Android dispose d'un protocole facilitant la connexion de périphériques sur les téléphones et les tablets
http://developer.android.com/guide/topics/usb/adk.html
A l'heure actuelle, il existe quelques kit de développement, mais peu d'extension existent. L'objectif du projet consiste à réaliser plusieurs cartes d'extensions. Ci-après la liste des premières cartes à réaliser,
Les étudiants pourront ensuite proposer leurs propres extensions:

- Support XBee (comme pour les Arduino)

- Support RFID

- Support vêtement intelligent pour la danse (suite du projet IMA4SC)

-...

=Résultats=
En cas de question n'hésitez pas à contacter Catherine Desravine ( Catherine.Desravines [ at ] polytech-lille [dot] net ) ou Nicolas Lefebvre ( lef.nicolas [ at ] gmail [ dot ] com).

Les codes sources sont aussi disponible en E306 sur tutur02 (partie Android + detection de mouvement) dans le dossier /home/pifou/IMA5sc/PFEADKAndroid/ ou sur tutur01 ( reste de la partie Arduino) dans le dossier /home/pifou/Documents/Coachoid/

== Application Android ==
L'application Coachoid v1.0 permet de lire les musiques sur le téléphone, détectes si les musiques sont taggées au format Coachoid ("Coachoid=[12.5,42.1,78.6]" par exemple), auquel cas elle envoie les informations recueillies à l'accessoire Arduino connecté.

* Telecharger Coachoid v1.0 : http://www.mirorii.com/fichier/44/507446/Coachoid_1-0-apk.html
* Code source : http://www.mirorii.com/fichier/26/507454/Coachoid_1-0-zip.html

== Code Arduino ==
=== Detection de mouvement ===
Ce petit programme utilise la norme des vecteurs d'acceleration renvoyés par les acceleromètres Lilypad pour en déduire si un mouvement a été effectué ou non.
Il permet de créer des tag pour l'application Coachoid ( informations renvoyées sur le port série ) contenant les temps auxquels des pas sont effectués.
Code source : http://pastebin.com/e2bhiFV9
=== Accessoire pour Android et programme pour le Tshirt===
====Accessoire Android====
Ce programme détecte la connexion d'un téléphone Android et interagit avec l'application Coachoid. Il envoie les informations sur le sexe de l'utilisateur , le style de musique (salsa ou rock 6 temps) ainsi que les beats d'une chanson en fonction des informations qu'il reçoit du téléphone.
====Programme pour le T-shirt====
Ce programme gère l'activation des vibreurs en fonction du genre de l'utilisateur ainsi que de la musique selon les informations de beat reçue par la liaison sans fil Zigbee.

Le code source de l'accessoire Android à compiler et uploader sur la MegaADK board se trouve dans le dossier ADKFinal de l'archive. Le code source pour le Lilypad sur le T-shirt se trouve dans le dossier TShirtFinal.
* Code source : http://www.mirorii.com/fichier/74/507486/Sources-tar-gz.html

=Réalisation=

==Séance 1 (5/10/2011)==

Prise en main des téléphones et du sujet, mis à jour des téléphones vers 2.3.4.

==Séance 2 (10/10/2011)==

Fin de mise à jour des téléphones vers 2.3.4 et 2.3.5.

==Séance 3 (11/10/2011)==
Installation de Android SDK
: -http://developer.android.com/sdk/installing.html
:: -http://developer.android.com/sdk/requirements.html
::: -installation de Eclipse Galileo
::: -installation du plugin ADT http://developer.android.com/sdk/eclipse-adt.html

Problèmes rencontrés et solutions apportées:

lien https de dl-ssl.google.com ne fonctionne pas: remplacement du https en http
NB: pour le STEP 4 de http://developer.android.com/sdk/installing.html => http forcé dans les paramètres du SDK Manager

== Séance 4(18/10/2011)==
Test de l'installation DemoKit de l'ADK.

== Séance 5(2/11/2011)==
Définition des tâches principales et répartition:

*lecture de la musique par le téléphone (application Android), détection des BPM (Matlab) => Nicolas
*envoi des infos BPM à l'arduino (extraction des metadatas et envoi) => Nicolas
*transmission des BPM via Zigbee au T-shirt => Catherine

*Test liaison telephone <-> Arduino : affichage message sur terminal serie (arduino) lors de l'appui sur un interrupteur sur le telephone.
* Exploration des datasheet du Arduino pour trouver la correspondance des Port en C avec les broches.

===Problèmes rencontrés===
*Manque de certains fichiers qui permettent la communication USB sur les téléphones.
*Incompatibilité du programme Arduino de démonstration => programmation en C

== Séance 6 (04/11/2011) ==
Début des tâches séparées.

* début création application android simple avec un seul bouton qui permet l'envoi d'un seul bit sur le port usb lorsqu'il est appuyé.
* prise en main du makefile pour la compilation directe en C pour arduino

== Séance 7 ( 07/11 ) ==
* App: Mise en place bouton d'envoi de bit et Slider de selection de BPM pour simulation : interface ok, mais pas connecté.

* [[Fichier:C360 2011-11-0816-01-14.jpg|200px|thumb|right|led qui clignote]] Arduino : Finalisation clignotage de LED en C, et mise en place d'AVR pour eclipse.

== Séance 8 ( 8/11 ) ==
[[Fichier:App01_test_bpm.png|200px|thumb|right|application de test avec un envoi à 124 BPM]]
* Finalisation interface de l'application de test et début d'intégration de l'ADK pour communiquer avec la board.
* headers et codes source C pour le connecteur usb de la carte trouvés il ne reste qu'à tranposer le header AndroidAccessory.cpp en .c et adapter le header.

== Séance 9 (14/11) ==

* Mise en place de la connectivité avec les accessoires sur l'application de test. Reste à tester sur l'arduino.

== Séance 10 (15/11) ==

* L'application communique bien avec le circuit arduino. Début de mise en place d'un tâche périodique pour envoyer un bit régulièrement suivant le BPM.

* Traduction en C des librairies.

== Séance 11 (18/11) ==
* Tâche périodique d'envoi de Beat mise en place. Mais soucis de prise en compte des modifications lors du slide ( trop de changements d'états en peu de temps...). ( aide : http://www.developpez.net/forums/d669466/c-cpp/outils-c-cpp/visual-cpp/mfc/interception-levt-mousedown-slider/ et http://stackoverflow.com/questions/937313/android-basic-gesture-detection )
* Traduction en C de la librairie AndroidAccessory.c

== Séance 12 (21/11) ==

* Finalisation de l'application de test avec l'envoi periodique de Beat ( 1 binaire) en choisissant la fréquence grâce au slider. Création de l'[http://www.mirorii.com/fichier/91/456089/DemoKit_0-3-1-apk.html apk associé DemoKit 0.3.1] ([http://www.mirorii.com/fichier/46/456090/DemoKit_0-3-1-zip.html sources]).
* Poursuite de la traduction en C.

== Séance 13 (22/11) ==

* Test de l'application avec les XBee (configuration de ceux-ci), et test avec le T-shirt du projet de l'année dernière avec succès.
* Début de l'application Coachoid v4.0 = application finale de lecture de musique & co. ( http://developer.android.com/guide/topics/media/mediaplayer.html )
* Les sources trouvées sur Internet se sont révélées être incomplètes et trop complexes à utiliser. Adaptation en C des sources C++ fournies avec l'ADK
** codes source inchangés: ch9.h, Max3421e_constants.h
** codes source en cours d'adaptation: Usb.h,Max3421e.h, Max3421e.c, Usb.c
** codes source restant à adapter: AndroidAccessory.cpp, AndroidAccessory.h

Il y aura la fonction digitalWrite à réécrire également.

== Séance 14 (28/11) ==

* Suite de l'adaptation des sources C++ en C:
** codes sources adaptés: Max3421e.h, Max3421e.c
** codes source en cours d'adaptation: Usb.h, Usb.c
** codes source restant à adapter: AndroidAccessory.cpp, AndroidAccessory.h, fonction digitalWrite de la librairie Wiring
* Mise en place de la recherche des musiques du telephone, affichage en list et début d'implementation des intéractions avec les musiques.

== Séance 15 (29/11) ==

* Lecture basique de musique fonctionnel avec barre progression et selection de musique
* Suite et fin de l'adaptation des sources C++ en C:
* Déboggage des sources C

== Séance 16 (30/11) ==

* Suite du déboggage des sources C
* Finitions de la liste (avec enchainement, bouton play-pause)

== Séance 17 (1/12) ==

* Mise en avant de la musique joué
* Lecture des tag des mp3 grâce à http://www.jthink.net/jaudiotagger/
* Fin du déboggage des sources
* Début du développement d'un programme test

== Séance 18 (5/12) ==
* Test inclusion de l'information de BPM dans les tags de la musique. Tests Réussi
* Recherche de solution pour prendre le bpm de chaque musique ( http://stackoverflow.com/questions/79445/beats-per-minute-from-real-time-audio-input http://www.streamhead.com/easy-bpm-calculation-in-java/ http://bpmdj.yellowcouch.org/ & http://jorgenmodin.net/index_html/archive/2010/07/23/counting-bpm-beats-per-minute-on-linux/weblogentry_view#1315989621 )
* deboggage des sources terminé, développement d'un programme test

== Séance 19 (04/01) ==
* Exploration du calcul du BPM instantanéement. Exploration de la solution http://www.streamhead.com/easy-bpm-calculation-in-java/ qui donne des résultats cohérents.
* Recherche d'autres outils de calcul pour avoir des référance de BPM.

== Séance 20 (05/01) ==
* Débuggage des sources C pour Arduino

== Séance 21 (11/01) ==
* Premier programme de test de connexion d'un téléphone à la plateforme Arduino
Deux fonctions posent problème : celle d'initialisation du port usb (powerOn) de la plateforme ainsi que celle qui permet de détecter la connexion d'un téléphone (isConnected).

== Séance 22 (12/01) ==
Arduino
Le problème des fonction powerOn et isConnected a été résolu en réalité les soucis venaient du fait que le port usb n'était pas initialisé dans le programme test et il y avait également un délai trop long (200s) à la fin de la fonction powerOn.

== Séance 23 (16/01) ==
*Début d'intégration de la bibliothèque de calcul de BPM dans l'application

Arduino:
La lecture de l'information sur le port usb pose problème il semblerait qu'un code retour soit égal à 0x65 au lieu de 0x00 (usb.c ligne 320)

== Séance 24 (31/01) ==
* Ecriture des BPMs dans le champs "encoder" des fichiers. Sous la forme : "CDD|Nombre_de_BPMs|[Liste des BPMs]" exemple : "CDD|6|[95, 119, 119, 131, 107, 143]"
Arduino:
bugs du programme de base=>
* il arrive que le programme s'arrête puis redémarre après qu'on ai connecté la borne MISO et la borne +5V du composant ICSP.
* La fonction isConnected renvoie toujours 1 même quand le téléphone n'est pas connecté

== 07/02 ==

* création du circuit permettant de detecter le mouvement d'un accelerometre pour tagger automatiquement les musiques.
http://web.media.mit.edu/~leah/LilyPad/build/accelero_shirt.html et http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1245357699

* Après correction des sources C par Mr. Vantroys, le code arduino de test a été amélioré. On peut maintenant brancher un téléphone sur la MegaADk, récupérer l'octet '1' envoyé par l'application demokit v0.3.1 et le renvoyer par commmunication zigbee.

== 10/02 ==
* L’accéléromètre permet uniquement de détecter les angles : http://bildr.org/2011/04/sensing-orientation-with-the-adxl335-arduino/

=Préparation téléphones=
== Commun ==
* Suivre ce tuto pour pouvoir tester els applciations directement sur le telephone : http://developer.android.com/guide/developing/device.html j'ai utilisé celui ci : http://bzed.de/posts/2009/05/howto_set_android_developer_device_permissions_with_udev/

=== Soucis de com.android.future.usb.accessory.jar ===
xml : [[Google_ADK_et_wearable_computing/android.hardware.usb.accessory.xml|android.hardware.usb.accessory.xml]]

jar : [http://www.mirorii.com/fichier/8/444186/com-android-future-usb-accessory-jar.html com.android.future.usb.accessory.jar]

su
mount -o remount,rw -t yaffs2 /dev/block/mtdblock4 /system
cp /sdcard/com.android.future.usb.accessory.jar /system/framework
chmod 655 /system/framework/com.android.future.usb.accessory.jar
vi /etc/permissions/android.hardware.usb.accessory.xml
chmod 655 /etc/permissions/android.hardware.usb.accessory.xml
mount -o ro,remount -t yaffs2 /dev/block/mtdblock4 /system

manipulation légèrement différente pour le motorola defy:

mount -o remount,rw -t ext3 /dev/block/mmsblk1p21 /system
cp com.android.future.usb.accessory.jar /system/framework
chmod 644 /system/framework/com.android.future.usb.accessory.jar
cp android.hardware.usb.accessory.xml /etc/permissions
chmod 644 /etc/permissions/android.hardware.usb.accessory.xml
mount -o ro,remount -t ext3 /dev/block/mmsblk1p21 /system
---------> reboot pour que la librairie soit prise en compte.

==Milestone 2 (droid2)==
Passage en 2.3.4 : http://forum.xda-developers.com/showthread.php?t=1169038
Compte google : imapolytech@gmail.com (mot de passe = mot de passe habituel "root")

==Motorola Defy==
Passage en 2.3.4 : http://forum.frandroid.com/topic/51780-rom-cyanogen-7-rc15/ (gingerbreak incompatible avec android 2.1 : utilisation de z4root => failed, nécessite un passage à froyo via Windows avec le logiciel Motorola Software Update)
Compte google : defypolytechima@gmail.com

= Arduino =
==Hardware==
*liste des pins pour le microprocesseur ATmega2560 
http://arduino.cc/en/Hacking/PinMapping2560
*exemple de programmation avec AVR 
http://hlt.media.mit.edu/wiki/pmwiki.php?n=Main.AVRProgrammingAdvanced
*exemple de code arduino en C pour communiquer via le port série 
http://todbot.com/blog/2006/12/06/arduino-serial-c-code-to-talk-to-arduino/
*présentation arduinoboardADK 
http://www.arduino.cc/en/Main/ArduinoBoardADK
*code source led qui clignote pour Atmega328p (commande pour compiler avec avr-gcc et uploader avecavrdude) 
http://balau82.wordpress.com/2011/03/29/programming-arduino-uno-in-pure-c/
*code source led qui clignote atmega168 
http://www.javiervalcarce.eu/wiki/Program_Arduino_with_AVR-GCC
*code source pour USB Host: MAX3421E 
http://code.google.com/p/microbridge/source/browse/trunk/src/mcu/?r=20#mcu

== Xbee ==

Utilisation du channel 15 ( sous minicom -s "+++" -> "ATCH15" -> "ATCH" pour verifier -> "ATWR" pour sauvegarder -> ATCN pour quitter la modif
=== Configuration===

*http://arduino.cc/en/Guide/ArduinoXbeeShield

== C ==
===Compilation ===
*[[:Fichier:Makefile.jpg|Makefile de Mr Vantroys]] points à veririer : MCU, CFLAG et DUDE
*[http://www.robgray.com/temp/makefile Makefile plus imposant]

==Divers==
=== Connexion root pour lancer l'IDE arduino===
ssh -X -lroot localhost

=Arduino=
*[http://www.mirorii.com/fichier/84/492503/code_arduinoV1-tar-gz.html code arduino v1.0]: Version de code qui fonctionne
**envoie d'un octet '1' par appli android, récupération par arduino sur le port usb, envoi d'un 1 par liaison Zigbee

= Android =
== Création apk ==
Le certificat contenant les clef de cryptage des apk se situe dans le repertoire /home/pifou/.android/keystore_signature_apk de tutur02. Les mots de passe sont ceux les mots de passe root habituels.

== Version App Coachoid ==

* [http://www.mirorii.com/fichier/91/456089/DemoKit_0-3-1-apk.html DemoKit 0.3.1] : Appli de test d'envoi d'1 bit avec un BPM voulu. ([http://www.mirorii.com/fichier/46/456090/DemoKit_0-3-1-zip.html sources])
* [http://www.mirorii.com/fichier/45/460974/Coachoid_0-4-apk.html Coachoid 0.4] : Application présentation pre-soutenance.
**Lecture musiques
**Lecture d'un BPM dans les tags de la musique
**Envoi des BPMs à l'accessoire.

Google ADK et wearable computing

2012-02-09T14:38:26Z

Cdesravi : /* Android */

=Présentation=

'''Contexte:''' Développement d'extension pour Android

Android dispose d'un protocole facilitant la connexion de périphériques sur les téléphones et les tablets
http://developer.android.com/guide/topics/usb/adk.html
A l'heure actuelle, il existe quelques kit de développement, mais peu d'extension existent. L'objectif du projet consiste à réaliser plusieurs cartes d'extensions. Ci-après la liste des premières cartes à réaliser,
Les étudiants pourront ensuite proposer leurs propres extensions:

- Support XBee (comme pour les Arduino)

- Support RFID

- Support vêtement intelligent pour la danse (suite du projet IMA4SC)

-...

=Réalisation=

==Séance 1 (5/10/2011)==

Prise en main des téléphones et du sujet, mis à jour des téléphones vers 2.3.4.

==Séance 2 (10/10/2011)==

Fin de mise à jour des téléphones vers 2.3.4 et 2.3.5.

==Séance 3 (11/10/2011)==
Installation de Android SDK
: -http://developer.android.com/sdk/installing.html
:: -http://developer.android.com/sdk/requirements.html
::: -installation de Eclipse Galileo
::: -installation du plugin ADT http://developer.android.com/sdk/eclipse-adt.html

Problèmes rencontrés et solutions apportées:

lien https de dl-ssl.google.com ne fonctionne pas: remplacement du https en http
NB: pour le STEP 4 de http://developer.android.com/sdk/installing.html => http forcé dans les paramètres du SDK Manager

== Séance 4(18/10/2011)==
Test de l'installation DemoKit de l'ADK.

== Séance 5(2/11/2011)==
Définition des tâches principales et répartition:

*lecture de la musique par le téléphone (application Android), détection des BPM (Matlab) => Nicolas
*envoi des infos BPM à l'arduino (extraction des metadatas et envoi) => Nicolas
*transmission des BPM via Zigbee au T-shirt => Catherine

*Test liaison telephone <-> Arduino : affichage message sur terminal serie (arduino) lors de l'appui sur un interrupteur sur le telephone.
* Exploration des datasheet du Arduino pour trouver la correspondance des Port en C avec les broches.

===Problèmes rencontrés===
*Manque de certains fichiers qui permettent la communication USB sur les téléphones.
*Incompatibilité du programme Arduino de démonstration => programmation en C

== Séance 6 (04/11/2011) ==
Début des tâches séparées.

* début création application android simple avec un seul bouton qui permet l'envoi d'un seul bit sur le port usb lorsqu'il est appuyé.
* prise en main du makefile pour la compilation directe en C pour arduino

== Séance 7 ( 07/11 ) ==
* App: Mise en place bouton d'envoi de bit et Slider de selection de BPM pour simulation : interface ok, mais pas connecté.

* [[Fichier:C360 2011-11-0816-01-14.jpg|200px|thumb|right|led qui clignote]] Arduino : Finalisation clignotage de LED en C, et mise en place d'AVR pour eclipse.

== Séance 8 ( 8/11 ) ==
[[Fichier:App01_test_bpm.png|200px|thumb|right|application de test avec un envoi à 124 BPM]]
* Finalisation interface de l'application de test et début d'intégration de l'ADK pour communiquer avec la board.
* headers et codes source C pour le connecteur usb de la carte trouvés il ne reste qu'à tranposer le header AndroidAccessory.cpp en .c et adapter le header.

== Séance 9 (14/11) ==

* Mise en place de la connectivité avec les accessoires sur l'application de test. Reste à tester sur l'arduino.

== Séance 10 (15/11) ==

* L'application communique bien avec le circuit arduino. Début de mise en place d'un tâche périodique pour envoyer un bit régulièrement suivant le BPM.

* Traduction en C des librairies.

== Séance 11 (18/11) ==
* Tâche périodique d'envoi de Beat mise en place. Mais soucis de prise en compte des modifications lors du slide ( trop de changements d'états en peu de temps...). ( aide : http://www.developpez.net/forums/d669466/c-cpp/outils-c-cpp/visual-cpp/mfc/interception-levt-mousedown-slider/ et http://stackoverflow.com/questions/937313/android-basic-gesture-detection )
* Traduction en C de la librairie AndroidAccessory.c

== Séance 12 (21/11) ==

* Finalisation de l'application de test avec l'envoi periodique de Beat ( 1 binaire) en choisissant la fréquence grâce au slider. Création de l'[http://www.mirorii.com/fichier/91/456089/DemoKit_0-3-1-apk.html apk associé DemoKit 0.3.1] ([http://www.mirorii.com/fichier/46/456090/DemoKit_0-3-1-zip.html sources]).
* Poursuite de la traduction en C.

== Séance 13 (22/11) ==

* Test de l'application avec les XBee (configuration de ceux-ci), et test avec le T-shirt du projet de l'année dernière avec succès.
* Début de l'application Coachoid v4.0 = application finale de lecture de musique & co. ( http://developer.android.com/guide/topics/media/mediaplayer.html )
* Les sources trouvées sur Internet se sont révélées être incomplètes et trop complexes à utiliser. Adaptation en C des sources C++ fournies avec l'ADK
** codes source inchangés: ch9.h, Max3421e_constants.h
** codes source en cours d'adaptation: Usb.h,Max3421e.h, Max3421e.c, Usb.c
** codes source restant à adapter: AndroidAccessory.cpp, AndroidAccessory.h

Il y aura la fonction digitalWrite à réécrire également.

== Séance 14 (28/11) ==

* Suite de l'adaptation des sources C++ en C:
** codes sources adaptés: Max3421e.h, Max3421e.c
** codes source en cours d'adaptation: Usb.h, Usb.c
** codes source restant à adapter: AndroidAccessory.cpp, AndroidAccessory.h, fonction digitalWrite de la librairie Wiring
* Mise en place de la recherche des musiques du telephone, affichage en list et début d'implementation des intéractions avec les musiques.

== Séance 15 (29/11) ==

* Lecture basique de musique fonctionnel avec barre progression et selection de musique
* Suite et fin de l'adaptation des sources C++ en C:
* Déboggage des sources C

== Séance 16 (30/11) ==

* Suite du déboggage des sources C
* Finitions de la liste (avec enchainement, bouton play-pause)

== Séance 17 (1/12) ==

* Mise en avant de la musique joué
* Lecture des tag des mp3 grâce à http://www.jthink.net/jaudiotagger/
* Fin du déboggage des sources
* Début du développement d'un programme test

== Séance 18 (5/12) ==
* Test inclusion de l'information de BPM dans les tags de la musique. Tests Réussi
* Recherche de solution pour prendre le bpm de chaque musique ( http://stackoverflow.com/questions/79445/beats-per-minute-from-real-time-audio-input http://www.streamhead.com/easy-bpm-calculation-in-java/ http://bpmdj.yellowcouch.org/ & http://jorgenmodin.net/index_html/archive/2010/07/23/counting-bpm-beats-per-minute-on-linux/weblogentry_view#1315989621 )
* deboggage des sources terminé, développement d'un programme test

== Séance 19 (04/01) ==
* Exploration du calcul du BPM instantanéement. Exploration de la solution http://www.streamhead.com/easy-bpm-calculation-in-java/ qui donne des résultats cohérents.
* Recherche d'autres outils de calcul pour avoir des référance de BPM.

== Séance 20 (05/01) ==
* Débuggage des sources C pour Arduino

== Séance 21 (11/01) ==
* Premier programme de test de connexion d'un téléphone à la plateforme Arduino
Deux fonctions posent problème : celle d'initialisation du port usb (powerOn) de la plateforme ainsi que celle qui permet de détecter la connexion d'un téléphone (isConnected).

== Séance 22 (12/01) ==
Arduino
Le problème des fonction powerOn et isConnected a été résolu en réalité les soucis venaient du fait que le port usb n'était pas initialisé dans le programme test et il y avait également un délai trop long (200s) à la fin de la fonction powerOn.

== Séance 23 (16/01) ==
*Début d'intégration de la bibliothèque de calcul de BPM dans l'application

Arduino:
La lecture de l'information sur le port usb pose problème il semblerait qu'un code retour soit égal à 0x65 au lieu de 0x00 (usb.c ligne 320)

== Séance 24 (31/01) ==
* Ecriture des BPMs dans le champs "encoder" des fichiers. Sous la forme : "CDD|Nombre_de_BPMs|[Liste des BPMs]" exemple : "CDD|6|[95, 119, 119, 131, 107, 143]"
Arduino:
bugs du programme de base=>
* il arrive que le programme s'arrête puis redémarre après qu'on ai connecté la borne MISO et la borne +5V du composant ICSP.
* La fonction isConnected renvoie toujours 1 même quand le téléphone n'est pas connecté

== 07/02 ==

* création du circuit permettant de detecter le mouvement d'un accelerometre pour tagger automatiquement les musiques.
http://web.media.mit.edu/~leah/LilyPad/build/accelero_shirt.html et http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1245357699

* Après correction des sources C par Mr. Vantroys, le code arduino de test a été amélioré. On peut maintenant brancher un téléphone sur la MegaADk, récupérer l'octet '1' envoyé par l'application demokit v0.3.1 et le renvoyer par commmunication zigbee.

=Préparation téléphones=
== Commun ==
* Suivre ce tuto pour pouvoir tester els applciations directement sur le telephone : http://developer.android.com/guide/developing/device.html j'ai utilisé celui ci : http://bzed.de/posts/2009/05/howto_set_android_developer_device_permissions_with_udev/

=== Soucis de com.android.future.usb.accessory.jar ===
xml : [[Google_ADK_et_wearable_computing/android.hardware.usb.accessory.xml|android.hardware.usb.accessory.xml]]

jar : [http://www.mirorii.com/fichier/8/444186/com-android-future-usb-accessory-jar.html com.android.future.usb.accessory.jar]

su
mount -o remount,rw -t yaffs2 /dev/block/mtdblock4 /system
cp /sdcard/com.android.future.usb.accessory.jar /system/framework
chmod 655 /system/framework/com.android.future.usb.accessory.jar
vi /etc/permissions/android.hardware.usb.accessory.xml
chmod 655 /etc/permissions/android.hardware.usb.accessory.xml
mount -o ro,remount -t yaffs2 /dev/block/mtdblock4 /system

manipulation légèrement différente pour le motorola defy:

mount -o remount,rw -t ext3 /dev/block/mmsblk1p21 /system
cp com.android.future.usb.accessory.jar /system/framework
chmod 644 /system/framework/com.android.future.usb.accessory.jar
cp android.hardware.usb.accessory.xml /etc/permissions
chmod 644 /etc/permissions/android.hardware.usb.accessory.xml
mount -o ro,remount -t ext3 /dev/block/mmsblk1p21 /system
---------> reboot pour que la librairie soit prise en compte.

==Milestone 2 (droid2)==
Passage en 2.3.4 : http://forum.xda-developers.com/showthread.php?t=1169038
Compte google : imapolytech@gmail.com (mot de passe = mot de passe habituel "root")

==Motorola Defy==
Passage en 2.3.4 : http://forum.frandroid.com/topic/51780-rom-cyanogen-7-rc15/ (gingerbreak incompatible avec android 2.1 : utilisation de z4root => failed, nécessite un passage à froyo via Windows avec le logiciel Motorola Software Update)
Compte google : defypolytechima@gmail.com

= Arduino =
==Hardware==
*liste des pins pour le microprocesseur ATmega2560 
http://arduino.cc/en/Hacking/PinMapping2560
*exemple de programmation avec AVR 
http://hlt.media.mit.edu/wiki/pmwiki.php?n=Main.AVRProgrammingAdvanced
*exemple de code arduino en C pour communiquer via le port série 
http://todbot.com/blog/2006/12/06/arduino-serial-c-code-to-talk-to-arduino/
*présentation arduinoboardADK 
http://www.arduino.cc/en/Main/ArduinoBoardADK
*code source led qui clignote pour Atmega328p (commande pour compiler avec avr-gcc et uploader avecavrdude) 
http://balau82.wordpress.com/2011/03/29/programming-arduino-uno-in-pure-c/
*code source led qui clignote atmega168 
http://www.javiervalcarce.eu/wiki/Program_Arduino_with_AVR-GCC
*code source pour USB Host: MAX3421E 
http://code.google.com/p/microbridge/source/browse/trunk/src/mcu/?r=20#mcu

== Xbee ==

Utilisation du channel 15 ( sous minicom -s "+++" -> "ATCH15" -> "ATCH" pour verifier -> "ATWR" pour sauvegarder -> ATCN pour quitter la modif
=== Configuration===

*http://arduino.cc/en/Guide/ArduinoXbeeShield

== C ==
===Compilation ===
*[[:Fichier:Makefile.jpg|Makefile de Mr Vantroys]] points à veririer : MCU, CFLAG et DUDE
*[http://www.robgray.com/temp/makefile Makefile plus imposant]

==Divers==
=== Connexion root pour lancer l'IDE arduino===
ssh -X -lroot localhost

=Arduino=
*[http://www.mirorii.com/fichier/84/492503/code_arduinoV1-tar-gz.html code arduino v1.0]: Version de code qui fonctionne
**envoie d'un octet '1' par appli android, récupération par arduino sur le port usb, envoi d'un 1 par liaison Zigbee

= Android =
== Création apk ==
Le certificat contenant les clef de cryptage des apk se situe dans le repertoire /home/pifou/.android/keystore_signature_apk de tutur02. Les mots de passe sont ceux les mots de passe root habituels.

== Version App Coachoid ==

* [http://www.mirorii.com/fichier/91/456089/DemoKit_0-3-1-apk.html DemoKit 0.3.1] : Appli de test d'envoi d'1 bit avec un BPM voulu. ([http://www.mirorii.com/fichier/46/456090/DemoKit_0-3-1-zip.html sources])
* [http://www.mirorii.com/fichier/45/460974/Coachoid_0-4-apk.html Coachoid 0.4] : Application présentation pre-soutenance.
**Lecture musiques
**Lecture d'un BPM dans les tags de la musique
**Envoi des BPMs à l'accessoire.

Google ADK et wearable computing

2012-02-09T14:32:40Z

Cdesravi : /* 07/02 */

=Présentation=

'''Contexte:''' Développement d'extension pour Android

Android dispose d'un protocole facilitant la connexion de périphériques sur les téléphones et les tablets
http://developer.android.com/guide/topics/usb/adk.html
A l'heure actuelle, il existe quelques kit de développement, mais peu d'extension existent. L'objectif du projet consiste à réaliser plusieurs cartes d'extensions. Ci-après la liste des premières cartes à réaliser,
Les étudiants pourront ensuite proposer leurs propres extensions:

- Support XBee (comme pour les Arduino)

- Support RFID

- Support vêtement intelligent pour la danse (suite du projet IMA4SC)

-...

=Réalisation=

==Séance 1 (5/10/2011)==

Prise en main des téléphones et du sujet, mis à jour des téléphones vers 2.3.4.

==Séance 2 (10/10/2011)==

Fin de mise à jour des téléphones vers 2.3.4 et 2.3.5.

==Séance 3 (11/10/2011)==
Installation de Android SDK
: -http://developer.android.com/sdk/installing.html
:: -http://developer.android.com/sdk/requirements.html
::: -installation de Eclipse Galileo
::: -installation du plugin ADT http://developer.android.com/sdk/eclipse-adt.html

Problèmes rencontrés et solutions apportées:

lien https de dl-ssl.google.com ne fonctionne pas: remplacement du https en http
NB: pour le STEP 4 de http://developer.android.com/sdk/installing.html => http forcé dans les paramètres du SDK Manager

== Séance 4(18/10/2011)==
Test de l'installation DemoKit de l'ADK.

== Séance 5(2/11/2011)==
Définition des tâches principales et répartition:

*lecture de la musique par le téléphone (application Android), détection des BPM (Matlab) => Nicolas
*envoi des infos BPM à l'arduino (extraction des metadatas et envoi) => Nicolas
*transmission des BPM via Zigbee au T-shirt => Catherine

*Test liaison telephone <-> Arduino : affichage message sur terminal serie (arduino) lors de l'appui sur un interrupteur sur le telephone.
* Exploration des datasheet du Arduino pour trouver la correspondance des Port en C avec les broches.

===Problèmes rencontrés===
*Manque de certains fichiers qui permettent la communication USB sur les téléphones.
*Incompatibilité du programme Arduino de démonstration => programmation en C

== Séance 6 (04/11/2011) ==
Début des tâches séparées.

* début création application android simple avec un seul bouton qui permet l'envoi d'un seul bit sur le port usb lorsqu'il est appuyé.
* prise en main du makefile pour la compilation directe en C pour arduino

== Séance 7 ( 07/11 ) ==
* App: Mise en place bouton d'envoi de bit et Slider de selection de BPM pour simulation : interface ok, mais pas connecté.

* [[Fichier:C360 2011-11-0816-01-14.jpg|200px|thumb|right|led qui clignote]] Arduino : Finalisation clignotage de LED en C, et mise en place d'AVR pour eclipse.

== Séance 8 ( 8/11 ) ==
[[Fichier:App01_test_bpm.png|200px|thumb|right|application de test avec un envoi à 124 BPM]]
* Finalisation interface de l'application de test et début d'intégration de l'ADK pour communiquer avec la board.
* headers et codes source C pour le connecteur usb de la carte trouvés il ne reste qu'à tranposer le header AndroidAccessory.cpp en .c et adapter le header.

== Séance 9 (14/11) ==

* Mise en place de la connectivité avec les accessoires sur l'application de test. Reste à tester sur l'arduino.

== Séance 10 (15/11) ==

* L'application communique bien avec le circuit arduino. Début de mise en place d'un tâche périodique pour envoyer un bit régulièrement suivant le BPM.

* Traduction en C des librairies.

== Séance 11 (18/11) ==
* Tâche périodique d'envoi de Beat mise en place. Mais soucis de prise en compte des modifications lors du slide ( trop de changements d'états en peu de temps...). ( aide : http://www.developpez.net/forums/d669466/c-cpp/outils-c-cpp/visual-cpp/mfc/interception-levt-mousedown-slider/ et http://stackoverflow.com/questions/937313/android-basic-gesture-detection )
* Traduction en C de la librairie AndroidAccessory.c

== Séance 12 (21/11) ==

* Finalisation de l'application de test avec l'envoi periodique de Beat ( 1 binaire) en choisissant la fréquence grâce au slider. Création de l'[http://www.mirorii.com/fichier/91/456089/DemoKit_0-3-1-apk.html apk associé DemoKit 0.3.1] ([http://www.mirorii.com/fichier/46/456090/DemoKit_0-3-1-zip.html sources]).
* Poursuite de la traduction en C.

== Séance 13 (22/11) ==

* Test de l'application avec les XBee (configuration de ceux-ci), et test avec le T-shirt du projet de l'année dernière avec succès.
* Début de l'application Coachoid v4.0 = application finale de lecture de musique & co. ( http://developer.android.com/guide/topics/media/mediaplayer.html )
* Les sources trouvées sur Internet se sont révélées être incomplètes et trop complexes à utiliser. Adaptation en C des sources C++ fournies avec l'ADK
** codes source inchangés: ch9.h, Max3421e_constants.h
** codes source en cours d'adaptation: Usb.h,Max3421e.h, Max3421e.c, Usb.c
** codes source restant à adapter: AndroidAccessory.cpp, AndroidAccessory.h

Il y aura la fonction digitalWrite à réécrire également.

== Séance 14 (28/11) ==

* Suite de l'adaptation des sources C++ en C:
** codes sources adaptés: Max3421e.h, Max3421e.c
** codes source en cours d'adaptation: Usb.h, Usb.c
** codes source restant à adapter: AndroidAccessory.cpp, AndroidAccessory.h, fonction digitalWrite de la librairie Wiring
* Mise en place de la recherche des musiques du telephone, affichage en list et début d'implementation des intéractions avec les musiques.

== Séance 15 (29/11) ==

* Lecture basique de musique fonctionnel avec barre progression et selection de musique
* Suite et fin de l'adaptation des sources C++ en C:
* Déboggage des sources C

== Séance 16 (30/11) ==

* Suite du déboggage des sources C
* Finitions de la liste (avec enchainement, bouton play-pause)

== Séance 17 (1/12) ==

* Mise en avant de la musique joué
* Lecture des tag des mp3 grâce à http://www.jthink.net/jaudiotagger/
* Fin du déboggage des sources
* Début du développement d'un programme test

== Séance 18 (5/12) ==
* Test inclusion de l'information de BPM dans les tags de la musique. Tests Réussi
* Recherche de solution pour prendre le bpm de chaque musique ( http://stackoverflow.com/questions/79445/beats-per-minute-from-real-time-audio-input http://www.streamhead.com/easy-bpm-calculation-in-java/ http://bpmdj.yellowcouch.org/ & http://jorgenmodin.net/index_html/archive/2010/07/23/counting-bpm-beats-per-minute-on-linux/weblogentry_view#1315989621 )
* deboggage des sources terminé, développement d'un programme test

== Séance 19 (04/01) ==
* Exploration du calcul du BPM instantanéement. Exploration de la solution http://www.streamhead.com/easy-bpm-calculation-in-java/ qui donne des résultats cohérents.
* Recherche d'autres outils de calcul pour avoir des référance de BPM.

== Séance 20 (05/01) ==
* Débuggage des sources C pour Arduino

== Séance 21 (11/01) ==
* Premier programme de test de connexion d'un téléphone à la plateforme Arduino
Deux fonctions posent problème : celle d'initialisation du port usb (powerOn) de la plateforme ainsi que celle qui permet de détecter la connexion d'un téléphone (isConnected).

== Séance 22 (12/01) ==
Arduino
Le problème des fonction powerOn et isConnected a été résolu en réalité les soucis venaient du fait que le port usb n'était pas initialisé dans le programme test et il y avait également un délai trop long (200s) à la fin de la fonction powerOn.

== Séance 23 (16/01) ==
*Début d'intégration de la bibliothèque de calcul de BPM dans l'application

Arduino:
La lecture de l'information sur le port usb pose problème il semblerait qu'un code retour soit égal à 0x65 au lieu de 0x00 (usb.c ligne 320)

== Séance 24 (31/01) ==
* Ecriture des BPMs dans le champs "encoder" des fichiers. Sous la forme : "CDD|Nombre_de_BPMs|[Liste des BPMs]" exemple : "CDD|6|[95, 119, 119, 131, 107, 143]"
Arduino:
bugs du programme de base=>
* il arrive que le programme s'arrête puis redémarre après qu'on ai connecté la borne MISO et la borne +5V du composant ICSP.
* La fonction isConnected renvoie toujours 1 même quand le téléphone n'est pas connecté

== 07/02 ==

* création du circuit permettant de detecter le mouvement d'un accelerometre pour tagger automatiquement les musiques.
http://web.media.mit.edu/~leah/LilyPad/build/accelero_shirt.html et http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1245357699

* Après correction des sources C par Mr. Vantroys, le code arduino de test a été amélioré. On peut maintenant brancher un téléphone sur la MegaADk, récupérer l'octet '1' envoyé par l'application demokit v0.3.1 et le renvoyer par commmunication zigbee.

=Préparation téléphones=
== Commun ==
* Suivre ce tuto pour pouvoir tester els applciations directement sur le telephone : http://developer.android.com/guide/developing/device.html j'ai utilisé celui ci : http://bzed.de/posts/2009/05/howto_set_android_developer_device_permissions_with_udev/

=== Soucis de com.android.future.usb.accessory.jar ===
xml : [[Google_ADK_et_wearable_computing/android.hardware.usb.accessory.xml|android.hardware.usb.accessory.xml]]

jar : [http://www.mirorii.com/fichier/8/444186/com-android-future-usb-accessory-jar.html com.android.future.usb.accessory.jar]

su
mount -o remount,rw -t yaffs2 /dev/block/mtdblock4 /system
cp /sdcard/com.android.future.usb.accessory.jar /system/framework
chmod 655 /system/framework/com.android.future.usb.accessory.jar
vi /etc/permissions/android.hardware.usb.accessory.xml
chmod 655 /etc/permissions/android.hardware.usb.accessory.xml
mount -o ro,remount -t yaffs2 /dev/block/mtdblock4 /system

manipulation légèrement différente pour le motorola defy:

mount -o remount,rw -t ext3 /dev/block/mmsblk1p21 /system
cp com.android.future.usb.accessory.jar /system/framework
chmod 644 /system/framework/com.android.future.usb.accessory.jar
cp android.hardware.usb.accessory.xml /etc/permissions
chmod 644 /etc/permissions/android.hardware.usb.accessory.xml
mount -o ro,remount -t ext3 /dev/block/mmsblk1p21 /system
---------> reboot pour que la librairie soit prise en compte.

==Milestone 2 (droid2)==
Passage en 2.3.4 : http://forum.xda-developers.com/showthread.php?t=1169038
Compte google : imapolytech@gmail.com (mot de passe = mot de passe habituel "root")

==Motorola Defy==
Passage en 2.3.4 : http://forum.frandroid.com/topic/51780-rom-cyanogen-7-rc15/ (gingerbreak incompatible avec android 2.1 : utilisation de z4root => failed, nécessite un passage à froyo via Windows avec le logiciel Motorola Software Update)
Compte google : defypolytechima@gmail.com

= Arduino =
==Hardware==
*liste des pins pour le microprocesseur ATmega2560 
http://arduino.cc/en/Hacking/PinMapping2560
*exemple de programmation avec AVR 
http://hlt.media.mit.edu/wiki/pmwiki.php?n=Main.AVRProgrammingAdvanced
*exemple de code arduino en C pour communiquer via le port série 
http://todbot.com/blog/2006/12/06/arduino-serial-c-code-to-talk-to-arduino/
*présentation arduinoboardADK 
http://www.arduino.cc/en/Main/ArduinoBoardADK
*code source led qui clignote pour Atmega328p (commande pour compiler avec avr-gcc et uploader avecavrdude) 
http://balau82.wordpress.com/2011/03/29/programming-arduino-uno-in-pure-c/
*code source led qui clignote atmega168 
http://www.javiervalcarce.eu/wiki/Program_Arduino_with_AVR-GCC
*code source pour USB Host: MAX3421E 
http://code.google.com/p/microbridge/source/browse/trunk/src/mcu/?r=20#mcu

== Xbee ==

Utilisation du channel 15 ( sous minicom -s "+++" -> "ATCH15" -> "ATCH" pour verifier -> "ATWR" pour sauvegarder -> ATCN pour quitter la modif
=== Configuration===

*http://arduino.cc/en/Guide/ArduinoXbeeShield

== C ==
===Compilation ===
*[[:Fichier:Makefile.jpg|Makefile de Mr Vantroys]] points à veririer : MCU, CFLAG et DUDE
*[http://www.robgray.com/temp/makefile Makefile plus imposant]

==Divers==
=== Connexion root pour lancer l'IDE arduino===
ssh -X -lroot localhost

= Android =
== Création apk ==
Le certificat contenant les clef de cryptage des apk se situe dans le repertoire /home/pifou/.android/keystore_signature_apk de tutur02. Les mots de passe sont ceux les mots de passe root habituels.

== Version App Coachoid ==

* [http://www.mirorii.com/fichier/91/456089/DemoKit_0-3-1-apk.html DemoKit 0.3.1] : Appli de test d'envoi d'1 bit avec un BPM voulu. ([http://www.mirorii.com/fichier/46/456090/DemoKit_0-3-1-zip.html sources])
* [http://www.mirorii.com/fichier/45/460974/Coachoid_0-4-apk.html Coachoid 0.4] : Application présentation pre-soutenance.
**Lecture musiques
**Lecture d'un BPM dans les tags de la musique
**Envoi des BPMs à l'accessoire.

Google ADK et wearable computing

2012-02-01T15:13:52Z

Cdesravi : /* Séance 24 (31/01) */

=Présentation=

'''Contexte:''' Développement d'extension pour Android

Android dispose d'un protocole facilitant la connexion de périphériques sur les téléphones et les tablets
http://developer.android.com/guide/topics/usb/adk.html
A l'heure actuelle, il existe quelques kit de développement, mais peu d'extension existent. L'objectif du projet consiste à réaliser plusieurs cartes d'extensions. Ci-après la liste des premières cartes à réaliser,
Les étudiants pourront ensuite proposer leurs propres extensions:

- Support XBee (comme pour les Arduino)

- Support RFID

- Support vêtement intelligent pour la danse (suite du projet IMA4SC)

-...

=Réalisation=

==Séance 1 (5/10/2011)==

Prise en main des téléphones et du sujet, mis à jour des téléphones vers 2.3.4.

==Séance 2 (10/10/2011)==

Fin de mise à jour des téléphones vers 2.3.4 et 2.3.5.

==Séance 3 (11/10/2011)==
Installation de Android SDK
: -http://developer.android.com/sdk/installing.html
:: -http://developer.android.com/sdk/requirements.html
::: -installation de Eclipse Galileo
::: -installation du plugin ADT http://developer.android.com/sdk/eclipse-adt.html

Problèmes rencontrés et solutions apportées:

lien https de dl-ssl.google.com ne fonctionne pas: remplacement du https en http
NB: pour le STEP 4 de http://developer.android.com/sdk/installing.html => http forcé dans les paramètres du SDK Manager

== Séance 4(18/10/2011)==
Test de l'installation DemoKit de l'ADK.

== Séance 5(2/11/2011)==
Définition des tâches principales et répartition:

*lecture de la musique par le téléphone (application Android), détection des BPM (Matlab) => Nicolas
*envoi des infos BPM à l'arduino (extraction des metadatas et envoi) => Nicolas
*transmission des BPM via Zigbee au T-shirt => Catherine

*Test liaison telephone <-> Arduino : affichage message sur terminal serie (arduino) lors de l'appui sur un interrupteur sur le telephone.
* Exploration des datasheet du Arduino pour trouver la correspondance des Port en C avec les broches.

===Problèmes rencontrés===
*Manque de certains fichiers qui permettent la communication USB sur les téléphones.
*Incompatibilité du programme Arduino de démonstration => programmation en C

== Séance 6 (04/11/2011) ==
Début des tâches séparées.

* début création application android simple avec un seul bouton qui permet l'envoi d'un seul bit sur le port usb lorsqu'il est appuyé.
* prise en main du makefile pour la compilation directe en C pour arduino

== Séance 7 ( 07/11 ) ==
* App: Mise en place bouton d'envoi de bit et Slider de selection de BPM pour simulation : interface ok, mais pas connecté.

* [[Fichier:C360 2011-11-0816-01-14.jpg|200px|thumb|right|led qui clignote]] Arduino : Finalisation clignotage de LED en C, et mise en place d'AVR pour eclipse.

== Séance 8 ( 8/11 ) ==
[[Fichier:App01_test_bpm.png|200px|thumb|right|application de test avec un envoi à 124 BPM]]
* Finalisation interface de l'application de test et début d'intégration de l'ADK pour communiquer avec la board.
* headers et codes source C pour le connecteur usb de la carte trouvés il ne reste qu'à tranposer le header AndroidAccessory.cpp en .c et adapter le header.

== Séance 9 (14/11) ==

* Mise en place de la connectivité avec les accessoires sur l'application de test. Reste à tester sur l'arduino.

== Séance 10 (15/11) ==

* L'application communique bien avec le circuit arduino. Début de mise en place d'un tâche périodique pour envoyer un bit régulièrement suivant le BPM.

* Traduction en C des librairies.

== Séance 11 (18/11) ==
* Tâche périodique d'envoi de Beat mise en place. Mais soucis de prise en compte des modifications lors du slide ( trop de changements d'états en peu de temps...). ( aide : http://www.developpez.net/forums/d669466/c-cpp/outils-c-cpp/visual-cpp/mfc/interception-levt-mousedown-slider/ et http://stackoverflow.com/questions/937313/android-basic-gesture-detection )
* Traduction en C de la librairie AndroidAccessory.c

== Séance 12 (21/11) ==

* Finalisation de l'application de test avec l'envoi periodique de Beat ( 1 binaire) en choisissant la fréquence grâce au slider. Création de l'[http://www.mirorii.com/fichier/91/456089/DemoKit_0-3-1-apk.html apk associé DemoKit 0.3.1] ([http://www.mirorii.com/fichier/46/456090/DemoKit_0-3-1-zip.html sources]).
* Poursuite de la traduction en C.

== Séance 13 (22/11) ==

* Test de l'application avec les XBee (configuration de ceux-ci), et test avec le T-shirt du projet de l'année dernière avec succès.
* Début de l'application Coachoid v4.0 = application finale de lecture de musique & co. ( http://developer.android.com/guide/topics/media/mediaplayer.html )
* Les sources trouvées sur Internet se sont révélées être incomplètes et trop complexes à utiliser. Adaptation en C des sources C++ fournies avec l'ADK
** codes source inchangés: ch9.h, Max3421e_constants.h
** codes source en cours d'adaptation: Usb.h,Max3421e.h, Max3421e.c, Usb.c
** codes source restant à adapter: AndroidAccessory.cpp, AndroidAccessory.h

Il y aura la fonction digitalWrite à réécrire également.

== Séance 14 (28/11) ==

* Suite de l'adaptation des sources C++ en C:
** codes sources adaptés: Max3421e.h, Max3421e.c
** codes source en cours d'adaptation: Usb.h, Usb.c
** codes source restant à adapter: AndroidAccessory.cpp, AndroidAccessory.h, fonction digitalWrite de la librairie Wiring
* Mise en place de la recherche des musiques du telephone, affichage en list et début d'implementation des intéractions avec les musiques.

== Séance 15 (29/11) ==

* Lecture basique de musique fonctionnel avec barre progression et selection de musique
* Suite et fin de l'adaptation des sources C++ en C:
* Déboggage des sources C

== Séance 16 (30/11) ==

* Suite du déboggage des sources C
* Finitions de la liste (avec enchainement, bouton play-pause)

== Séance 17 (1/12) ==

* Mise en avant de la musique joué
* Lecture des tag des mp3 grâce à http://www.jthink.net/jaudiotagger/
* Fin du déboggage des sources
* Début du développement d'un programme test

== Séance 18 (5/12) ==
* Test inclusion de l'information de BPM dans les tags de la musique. Tests Réussi
* Recherche de solution pour prendre le bpm de chaque musique ( http://stackoverflow.com/questions/79445/beats-per-minute-from-real-time-audio-input http://www.streamhead.com/easy-bpm-calculation-in-java/ http://bpmdj.yellowcouch.org/ & http://jorgenmodin.net/index_html/archive/2010/07/23/counting-bpm-beats-per-minute-on-linux/weblogentry_view#1315989621 )
* deboggage des sources terminé, développement d'un programme test

== Séance 19 (04/01) ==
* Exploration du calcul du BPM instantanéement. Exploration de la solution http://www.streamhead.com/easy-bpm-calculation-in-java/ qui donne des résultats cohérents.
* Recherche d'autres outils de calcul pour avoir des référance de BPM.

== Séance 20 (05/01) ==
* Débuggage des sources C pour Arduino

== Séance 21 (11/01) ==
* Premier programme de test de connexion d'un téléphone à la plateforme Arduino
Deux fonctions posent problème : celle d'initialisation du port usb (powerOn) de la plateforme ainsi que celle qui permet de détecter la connexion d'un téléphone (isConnected).

== Séance 22 (12/01) ==
Arduino
Le problème des fonction powerOn et isConnected a été résolu en réalité les soucis venaient du fait que le port usb n'était pas initialisé dans le programme test et il y avait également un délai trop long (200s) à la fin de la fonction powerOn.

== Séance 23 (16/01) ==
*Début d'intégration de la bibliothèque de calcul de BPM dans l'application

Arduino:
La lecture de l'information sur le port usb pose problème il semblerait qu'un code retour soit égal à 0x65 au lieu de 0x00 (usb.c ligne 320)

== Séance 24 (31/01) ==
* Ecriture des BPMs dans le champs "encoder" des fichiers. Sous la forme : "CDD|Nombre_de_BPMs|[Liste des BPMs]" exemple : "CDD|6|[95, 119, 119, 131, 107, 143]"
Arduino:
bugs du programme de base=>
* il arrive que le programme s'arrête puis redémarre après qu'on ai connecté la borne MISO et la borne +5V du composant ICSP.
* La fonction isConnected renvoie toujours 1 même quand le téléphone n'est pas connecté

=Préparation téléphones=
== Commun ==
* Suivre ce tuto pour pouvoir tester els applciations directement sur le telephone : http://developer.android.com/guide/developing/device.html j'ai utilisé celui ci : http://bzed.de/posts/2009/05/howto_set_android_developer_device_permissions_with_udev/

=== Soucis de com.android.future.usb.accessory.jar ===
xml : [https://projets-imasc.polytech-lille.net:40000/mediawiki/index.php?title=Google_ADK_et_wearable_computing/android.hardware.usb.accessory.xml android.hardware.usb.accessory.xml]

jar : [http://www.mirorii.com/fichier/8/444186/com-android-future-usb-accessory-jar.html com.android.future.usb.accessory.jar]

su
mount -o remount,rw -t yaffs2 /dev/block/mtdblock4 /system
cp /sdcard/com.android.future.usb.accessory.jar /system/framework
chmod 655 /system/framework/com.android.future.usb.accessory.jar
vi /etc/permissions/android.hardware.usb.accessory.xml
chmod 655 /etc/permissions/android.hardware.usb.accessory.xml
mount -o ro,remount -t yaffs2 /dev/block/mtdblock4 /system

manipulation légèrement différente pour le motorola defy:

mount -o remount,rw -t ext3 /dev/block/mmsblk1p21 /system
cp com.android.future.usb.accessory.jar /system/framework
chmod 644 /system/framework/com.android.future.usb.accessory.jar
cp android.hardware.usb.accessory.xml /etc/permissions
chmod 644 /etc/permissions/android.hardware.usb.accessory.xml
mount -o ro,remount -t ext3 /dev/block/mmsblk1p21 /system
---------> reboot pour que la librairie soit prise en compte.

==Milestone 2 (droid2)==
Passage en 2.3.4 : http://forum.xda-developers.com/showthread.php?t=1169038
Compte google : imapolytech@gmail.com (mot de passe = mot de passe habituel "root")

==Motorola Defy==
Passage en 2.3.4 : http://forum.frandroid.com/topic/51780-rom-cyanogen-7-rc15/ (gingerbreak incompatible avec android 2.1 : utilisation de z4root => failed, nécessite un passage à froyo via Windows avec le logiciel Motorola Software Update)
Compte google : defypolytechima@gmail.com

= Arduino =
==Hardware==
*liste des pins pour le microprocesseur ATmega2560 
http://arduino.cc/en/Hacking/PinMapping2560
*exemple de programmation avec AVR 
http://hlt.media.mit.edu/wiki/pmwiki.php?n=Main.AVRProgrammingAdvanced
*exemple de code arduino en C pour communiquer via le port série 
http://todbot.com/blog/2006/12/06/arduino-serial-c-code-to-talk-to-arduino/
*présentation arduinoboardADK 
http://www.arduino.cc/en/Main/ArduinoBoardADK
*code source led qui clignote pour Atmega328p (commande pour compiler avec avr-gcc et uploader avecavrdude) 
http://balau82.wordpress.com/2011/03/29/programming-arduino-uno-in-pure-c/
*code source led qui clignote atmega168 
http://www.javiervalcarce.eu/wiki/Program_Arduino_with_AVR-GCC
*code source pour USB Host: MAX3421E 
http://code.google.com/p/microbridge/source/browse/trunk/src/mcu/?r=20#mcu

== Xbee ==

Utilisation du channel 15 ( sous minicom -s "+++" -> "ATCH15" -> "ATCH" pour verifier -> "ATWR" pour sauvegarder -> ATCN pour quitter la modif
=== Configuration===

*http://arduino.cc/en/Guide/ArduinoXbeeShield

== C ==
===Compilation ===
*[[:Fichier:Makefile.jpg|Makefile de Mr Vantroys]] points à veririer : MCU, CFLAG et DUDE
*[http://www.robgray.com/temp/makefile Makefile plus imposant]

==Divers==
=== Connexion root pour lancer l'IDE arduino===
ssh -X -lroot localhost

= Android =
== Création apk ==
Le certificat contenant les clef de cryptage des apk se situe dans le repertoire /home/pifou/.android/keystore_signature_apk de tutur02. Les mots de passe sont ceux les mots de passe root habituels.

== Version App Coachoid ==

* [http://www.mirorii.com/fichier/91/456089/DemoKit_0-3-1-apk.html DemoKit 0.3.1] : Appli de test d'envoi d'1 bit avec un BPM voulu. ([http://www.mirorii.com/fichier/46/456090/DemoKit_0-3-1-zip.html sources])
* [http://www.mirorii.com/fichier/45/460974/Coachoid_0-4-apk.html Coachoid 0.4] : Application présentation pre-soutenance.
**Lecture musiques
**Lecture d'un BPM dans les tags de la musique
**Envoi des BPMs à l'accessoire.

Google ADK et wearable computing

2012-01-16T16:26:20Z

Cdesravi : /* Séance 22 (12/01) */

=Présentation=

'''Contexte:''' Développement d'extension pour Android

Android dispose d'un protocole facilitant la connexion de périphériques sur les téléphones et les tablets
http://developer.android.com/guide/topics/usb/adk.html
A l'heure actuelle, il existe quelques kit de développement, mais peu d'extension existent. L'objectif du projet consiste à réaliser plusieurs cartes d'extensions. Ci-après la liste des premières cartes à réaliser,
Les étudiants pourront ensuite proposer leurs propres extensions:

- Support XBee (comme pour les Arduino)

- Support RFID

- Support vêtement intelligent pour la danse (suite du projet IMA4SC)

-...

=Réalisation=

==Séance 1 (5/10/2011)==

Prise en main des téléphones et du sujet, mis à jour des téléphones vers 2.3.4.

==Séance 2 (10/10/2011)==

Fin de mise à jour des téléphones vers 2.3.4 et 2.3.5.

==Séance 3 (11/10/2011)==
Installation de Android SDK
: -http://developer.android.com/sdk/installing.html
:: -http://developer.android.com/sdk/requirements.html
::: -installation de Eclipse Galileo
::: -installation du plugin ADT http://developer.android.com/sdk/eclipse-adt.html

Problèmes rencontrés et solutions apportées:

lien https de dl-ssl.google.com ne fonctionne pas: remplacement du https en http
NB: pour le STEP 4 de http://developer.android.com/sdk/installing.html => http forcé dans les paramètres du SDK Manager

== Séance 4(18/10/2011)==
Test de l'installation DemoKit de l'ADK.

== Séance 5(2/11/2011)==
Définition des tâches principales et répartition:

*lecture de la musique par le téléphone (application Android), détection des BPM (Matlab) => Nicolas
*envoi des infos BPM à l'arduino (extraction des metadatas et envoi) => Nicolas
*transmission des BPM via Zigbee au T-shirt => Catherine

*Test liaison telephone <-> Arduino : affichage message sur terminal serie (arduino) lors de l'appui sur un interrupteur sur le telephone.
* Exploration des datasheet du Arduino pour trouver la correspondance des Port en C avec les broches.

===Problèmes rencontrés===
*Manque de certains fichiers qui permettent la communication USB sur les téléphones.
*Incompatibilité du programme Arduino de démonstration => programmation en C

== Séance 6 (04/11/2011) ==
Début des tâches séparées.

* début création application android simple avec un seul bouton qui permet l'envoi d'un seul bit sur le port usb lorsqu'il est appuyé.
* prise en main du makefile pour la compilation directe en C pour arduino

== Séance 7 ( 07/11 ) ==
* App: Mise en place bouton d'envoi de bit et Slider de selection de BPM pour simulation : interface ok, mais pas connecté.

* [[Fichier:C360 2011-11-0816-01-14.jpg|200px|thumb|right|led qui clignote]] Arduino : Finalisation clignotage de LED en C, et mise en place d'AVR pour eclipse.

== Séance 8 ( 8/11 ) ==
[[Fichier:App01_test_bpm.png|200px|thumb|right|application de test avec un envoi à 124 BPM]]
* Finalisation interface de l'application de test et début d'intégration de l'ADK pour communiquer avec la board.
* headers et codes source C pour le connecteur usb de la carte trouvés il ne reste qu'à tranposer le header AndroidAccessory.cpp en .c et adapter le header.

== Séance 9 (14/11) ==

* Mise en place de la connectivité avec les accessoires sur l'application de test. Reste à tester sur l'arduino.

== Séance 10 (15/11) ==

* L'application communique bien avec le circuit arduino. Début de mise en place d'un tâche périodique pour envoyer un bit régulièrement suivant le BPM.

* Traduction en C des librairies.

== Séance 11 (18/11) ==
* Tâche périodique d'envoi de Beat mise en place. Mais soucis de prise en compte des modifications lors du slide ( trop de changements d'états en peu de temps...). ( aide : http://www.developpez.net/forums/d669466/c-cpp/outils-c-cpp/visual-cpp/mfc/interception-levt-mousedown-slider/ et http://stackoverflow.com/questions/937313/android-basic-gesture-detection )
* Traduction en C de la librairie AndroidAccessory.c

== Séance 12 (21/11) ==

* Finalisation de l'application de test avec l'envoi periodique de Beat ( 1 binaire) en choisissant la fréquence grâce au slider. Création de l'[http://www.mirorii.com/fichier/91/456089/DemoKit_0-3-1-apk.html apk associé DemoKit 0.3.1] ([http://www.mirorii.com/fichier/46/456090/DemoKit_0-3-1-zip.html sources]).
* Poursuite de la traduction en C.

== Séance 13 (22/11) ==

* Test de l'application avec les XBee (configuration de ceux-ci), et test avec le T-shirt du projet de l'année dernière avec succès.
* Début de l'application Coachoid v4.0 = application finale de lecture de musique & co. ( http://developer.android.com/guide/topics/media/mediaplayer.html )
* Les sources trouvées sur Internet se sont révélées être incomplètes et trop complexes à utiliser. Adaptation en C des sources C++ fournies avec l'ADK
** codes source inchangés: ch9.h, Max3421e_constants.h
** codes source en cours d'adaptation: Usb.h,Max3421e.h, Max3421e.c, Usb.c
** codes source restant à adapter: AndroidAccessory.cpp, AndroidAccessory.h

Il y aura la fonction digitalWrite à réécrire également.

== Séance 14 (28/11) ==

* Suite de l'adaptation des sources C++ en C:
** codes sources adaptés: Max3421e.h, Max3421e.c
** codes source en cours d'adaptation: Usb.h, Usb.c
** codes source restant à adapter: AndroidAccessory.cpp, AndroidAccessory.h, fonction digitalWrite de la librairie Wiring
* Mise en place de la recherche des musiques du telephone, affichage en list et début d'implementation des intéractions avec les musiques.

== Séance 15 (29/11) ==

* Lecture basique de musique fonctionnel avec barre progression et selection de musique
* Suite et fin de l'adaptation des sources C++ en C:
* Déboggage des sources C

== Séance 16 (30/11) ==

* Suite du déboggage des sources C
* Finitions de la liste (avec enchainement, bouton play-pause)

== Séance 17 (1/12) ==

* Mise en avant de la musique joué
* Lecture des tag des mp3 grâce à http://www.jthink.net/jaudiotagger/
* Fin du déboggage des sources
* Début du développement d'un programme test

== Séance 18 (5/12) ==
* Test inclusion de l'information de BPM dans les tags de la musique. Tests Réussi
* Recherche de solution pour prendre le bpm de chaque musique ( http://stackoverflow.com/questions/79445/beats-per-minute-from-real-time-audio-input http://www.streamhead.com/easy-bpm-calculation-in-java/ http://bpmdj.yellowcouch.org/ & http://jorgenmodin.net/index_html/archive/2010/07/23/counting-bpm-beats-per-minute-on-linux/weblogentry_view#1315989621 )
* deboggage des sources terminé, développement d'un programme test

== Séance 19 (04/01) ==
* Exploration du calcul du BPM instantanéement. Exploration de la solution http://www.streamhead.com/easy-bpm-calculation-in-java/ qui donne des résultats cohérents.
* Recherche d'autres outils de calcul pour avoir des référance de BPM.

== Séance 20 (05/01) ==
* Débuggage des sources C pour Arduino

== Séance 21 (11/01) ==
* Premier programme de test de connexion d'un téléphone à la plateforme Arduino
Deux fonctions posent problème : celle d'initialisation du port usb (powerOn) de la plateforme ainsi que celle qui permet de détecter la connexion d'un téléphone (isConnected).

== Séance 22 (12/01) ==
Arduino
Le problème des fonction powerOn et isConnected a été résolu en réalité les soucis venaient du fait que le port usb n'était pas initialisé dans le programme test et il y avait également un délai trop long (200s) à la fin de la fonction powerOn.

== Séance 23 (16/01) ==
Arduino:
La lecture de l'information sur le port usb pose problème il semblerait qu'un code retour soit égal à 0x65 au lieu de 0x00 (usb.c ligne 320)

=Préparation téléphones=
== Commun ==
* Suivre ce tuto pour pouvoir tester els applciations directement sur le telephone : http://developer.android.com/guide/developing/device.html j'ai utilisé celui ci : http://bzed.de/posts/2009/05/howto_set_android_developer_device_permissions_with_udev/

=== Soucis de com.android.future.usb.accessory.jar ===
xml : [https://projets-imasc.polytech-lille.net:40000/mediawiki/index.php?title=Google_ADK_et_wearable_computing/android.hardware.usb.accessory.xml android.hardware.usb.accessory.xml]

jar : [http://www.mirorii.com/fichier/8/444186/com-android-future-usb-accessory-jar.html com.android.future.usb.accessory.jar]

su
mount -o remount,rw -t yaffs2 /dev/block/mtdblock4 /system
cp /sdcard/com.android.future.usb.accessory.jar /system/framework
chmod 655 /system/framework/com.android.future.usb.accessory.jar
vi /etc/permissions/android.hardware.usb.accessory.xml
chmod 655 /etc/permissions/android.hardware.usb.accessory.xml
mount -o ro,remount -t yaffs2 /dev/block/mtdblock4 /system

manipulation légèrement différente pour le motorola defy:

mount -o remount,rw -t ext3 /dev/block/mmsblk1p21 /system
cp com.android.future.usb.accessory.jar /system/framework
chmod 644 /system/framework/com.android.future.usb.accessory.jar
cp android.hardware.usb.accessory.xml /etc/permissions
chmod 644 /etc/permissions/android.hardware.usb.accessory.xml
mount -o ro,remount -t ext3 /dev/block/mmsblk1p21 /system
---------> reboot pour que la librairie soit prise en compte.

==Milestone 2 (droid2)==
Passage en 2.3.4 : http://forum.xda-developers.com/showthread.php?t=1169038
Compte google : imapolytech@gmail.com (mot de passe = mot de passe habituel "root")

==Motorola Defy==
Passage en 2.3.4 : http://forum.frandroid.com/topic/51780-rom-cyanogen-7-rc15/ (gingerbreak incompatible avec android 2.1 : utilisation de z4root => failed, nécessite un passage à froyo via Windows avec le logiciel Motorola Software Update)
Compte google : defypolytechima@gmail.com

= Arduino =
==Hardware==
*liste des pins pour le microprocesseur ATmega2560 
http://arduino.cc/en/Hacking/PinMapping2560
*exemple de programmation avec AVR 
http://hlt.media.mit.edu/wiki/pmwiki.php?n=Main.AVRProgrammingAdvanced
*exemple de code arduino en C pour communiquer via le port série 
http://todbot.com/blog/2006/12/06/arduino-serial-c-code-to-talk-to-arduino/
*présentation arduinoboardADK 
http://www.arduino.cc/en/Main/ArduinoBoardADK
*code source led qui clignote pour Atmega328p (commande pour compiler avec avr-gcc et uploader avecavrdude) 
http://balau82.wordpress.com/2011/03/29/programming-arduino-uno-in-pure-c/
*code source led qui clignote atmega168 
http://www.javiervalcarce.eu/wiki/Program_Arduino_with_AVR-GCC
*code source pour USB Host: MAX3421E 
http://code.google.com/p/microbridge/source/browse/trunk/src/mcu/?r=20#mcu

== Xbee ==

Utilisation du channel 15 ( sous minicom -s "+++" -> "ATCH15" -> "ATCH" pour verifier -> "ATWR" pour sauvegarder -> ATCN pour quitter la modif
=== Configuration===

*http://arduino.cc/en/Guide/ArduinoXbeeShield

== C ==
===Compilation ===
*[[:Fichier:Makefile.jpg|Makefile de Mr Vantroys]] points à veririer : MCU, CFLAG et DUDE
*[http://www.robgray.com/temp/makefile Makefile plus imposant]

==Divers==
=== Connexion root pour lancer l'IDE arduino===
ssh -X -lroot localhost

= Android =
== Création apk ==
Le certificat contenant les clef de cryptage des apk se situe dans le repertoire /home/pifou/.android/keystore_signature_apk de tutur02. Les mots de passe sont ceux les mots de passe root habituels.

== Version App Coachoid ==

* [http://www.mirorii.com/fichier/91/456089/DemoKit_0-3-1-apk.html DemoKit 0.3.1] : Appli de test d'envoi d'1 bit avec un BPM voulu. ([http://www.mirorii.com/fichier/46/456090/DemoKit_0-3-1-zip.html sources])
* [http://www.mirorii.com/fichier/45/460974/Coachoid_0-4-apk.html Coachoid 0.4] : Application présentation pre-soutenance.
**Lecture musiques
**Lecture d'un BPM dans les tags de la musique
**Envoi des BPMs à l'accessoire.

Google ADK et wearable computing

2012-01-16T14:42:46Z

Cdesravi : /* Séance 21 (11/01) */

=Présentation=

'''Contexte:''' Développement d'extension pour Android

Android dispose d'un protocole facilitant la connexion de périphériques sur les téléphones et les tablets
http://developer.android.com/guide/topics/usb/adk.html
A l'heure actuelle, il existe quelques kit de développement, mais peu d'extension existent. L'objectif du projet consiste à réaliser plusieurs cartes d'extensions. Ci-après la liste des premières cartes à réaliser,
Les étudiants pourront ensuite proposer leurs propres extensions:

- Support XBee (comme pour les Arduino)

- Support RFID

- Support vêtement intelligent pour la danse (suite du projet IMA4SC)

-...

=Réalisation=

==Séance 1 (5/10/2011)==

Prise en main des téléphones et du sujet, mis à jour des téléphones vers 2.3.4.

==Séance 2 (10/10/2011)==

Fin de mise à jour des téléphones vers 2.3.4 et 2.3.5.

==Séance 3 (11/10/2011)==
Installation de Android SDK
: -http://developer.android.com/sdk/installing.html
:: -http://developer.android.com/sdk/requirements.html
::: -installation de Eclipse Galileo
::: -installation du plugin ADT http://developer.android.com/sdk/eclipse-adt.html

Problèmes rencontrés et solutions apportées:

lien https de dl-ssl.google.com ne fonctionne pas: remplacement du https en http
NB: pour le STEP 4 de http://developer.android.com/sdk/installing.html => http forcé dans les paramètres du SDK Manager

== Séance 4(18/10/2011)==
Test de l'installation DemoKit de l'ADK.

== Séance 5(2/11/2011)==
Définition des tâches principales et répartition:

*lecture de la musique par le téléphone (application Android), détection des BPM (Matlab) => Nicolas
*envoi des infos BPM à l'arduino (extraction des metadatas et envoi) => Nicolas
*transmission des BPM via Zigbee au T-shirt => Catherine

*Test liaison telephone <-> Arduino : affichage message sur terminal serie (arduino) lors de l'appui sur un interrupteur sur le telephone.
* Exploration des datasheet du Arduino pour trouver la correspondance des Port en C avec les broches.

===Problèmes rencontrés===
*Manque de certains fichiers qui permettent la communication USB sur les téléphones.
*Incompatibilité du programme Arduino de démonstration => programmation en C

== Séance 6 (04/11/2011) ==
Début des tâches séparées.

* début création application android simple avec un seul bouton qui permet l'envoi d'un seul bit sur le port usb lorsqu'il est appuyé.
* prise en main du makefile pour la compilation directe en C pour arduino

== Séance 7 ( 07/11 ) ==
* App: Mise en place bouton d'envoi de bit et Slider de selection de BPM pour simulation : interface ok, mais pas connecté.

* [[Fichier:C360 2011-11-0816-01-14.jpg|200px|thumb|right|led qui clignote]] Arduino : Finalisation clignotage de LED en C, et mise en place d'AVR pour eclipse.

== Séance 8 ( 8/11 ) ==
[[Fichier:App01_test_bpm.png|200px|thumb|right|application de test avec un envoi à 124 BPM]]
* Finalisation interface de l'application de test et début d'intégration de l'ADK pour communiquer avec la board.
* headers et codes source C pour le connecteur usb de la carte trouvés il ne reste qu'à tranposer le header AndroidAccessory.cpp en .c et adapter le header.

== Séance 9 (14/11) ==

* Mise en place de la connectivité avec les accessoires sur l'application de test. Reste à tester sur l'arduino.

== Séance 10 (15/11) ==

* L'application communique bien avec le circuit arduino. Début de mise en place d'un tâche périodique pour envoyer un bit régulièrement suivant le BPM.

* Traduction en C des librairies.

== Séance 11 (18/11) ==
* Tâche périodique d'envoi de Beat mise en place. Mais soucis de prise en compte des modifications lors du slide ( trop de changements d'états en peu de temps...). ( aide : http://www.developpez.net/forums/d669466/c-cpp/outils-c-cpp/visual-cpp/mfc/interception-levt-mousedown-slider/ et http://stackoverflow.com/questions/937313/android-basic-gesture-detection )
* Traduction en C de la librairie AndroidAccessory.c

== Séance 12 (21/11) ==

* Finalisation de l'application de test avec l'envoi periodique de Beat ( 1 binaire) en choisissant la fréquence grâce au slider. Création de l'[http://www.mirorii.com/fichier/91/456089/DemoKit_0-3-1-apk.html apk associé DemoKit 0.3.1] ([http://www.mirorii.com/fichier/46/456090/DemoKit_0-3-1-zip.html sources]).
* Poursuite de la traduction en C.

== Séance 13 (22/11) ==

* Test de l'application avec les XBee (configuration de ceux-ci), et test avec le T-shirt du projet de l'année dernière avec succès.
* Début de l'application Coachoid v4.0 = application finale de lecture de musique & co. ( http://developer.android.com/guide/topics/media/mediaplayer.html )
* Les sources trouvées sur Internet se sont révélées être incomplètes et trop complexes à utiliser. Adaptation en C des sources C++ fournies avec l'ADK
** codes source inchangés: ch9.h, Max3421e_constants.h
** codes source en cours d'adaptation: Usb.h,Max3421e.h, Max3421e.c, Usb.c
** codes source restant à adapter: AndroidAccessory.cpp, AndroidAccessory.h

Il y aura la fonction digitalWrite à réécrire également.

== Séance 14 (28/11) ==

* Suite de l'adaptation des sources C++ en C:
** codes sources adaptés: Max3421e.h, Max3421e.c
** codes source en cours d'adaptation: Usb.h, Usb.c
** codes source restant à adapter: AndroidAccessory.cpp, AndroidAccessory.h, fonction digitalWrite de la librairie Wiring
* Mise en place de la recherche des musiques du telephone, affichage en list et début d'implementation des intéractions avec les musiques.

== Séance 15 (29/11) ==

* Lecture basique de musique fonctionnel avec barre progression et selection de musique
* Suite et fin de l'adaptation des sources C++ en C:
* Déboggage des sources C

== Séance 16 (30/11) ==

* Suite du déboggage des sources C
* Finitions de la liste (avec enchainement, bouton play-pause)

== Séance 17 (1/12) ==

* Mise en avant de la musique joué
* Lecture des tag des mp3 grâce à http://www.jthink.net/jaudiotagger/
* Fin du déboggage des sources
* Début du développement d'un programme test

== Séance 18 (5/12) ==
* Test inclusion de l'information de BPM dans les tags de la musique. Tests Réussi
* Recherche de solution pour prendre le bpm de chaque musique ( http://stackoverflow.com/questions/79445/beats-per-minute-from-real-time-audio-input http://www.streamhead.com/easy-bpm-calculation-in-java/ http://bpmdj.yellowcouch.org/ & http://jorgenmodin.net/index_html/archive/2010/07/23/counting-bpm-beats-per-minute-on-linux/weblogentry_view#1315989621 )
* deboggage des sources terminé, développement d'un programme test

== Séance 19 (04/01) ==
* Exploration du calcul du BPM instantanéement. Exploration de la solution http://www.streamhead.com/easy-bpm-calculation-in-java/ qui donne des résultats cohérents.
* Recherche d'autres outils de calcul pour avoir des référance de BPM.

== Séance 20 (05/01) ==
* Débuggage des sources C pour Arduino

== Séance 21 (11/01) ==
* Premier programme de test de connexion d'un téléphone à la plateforme Arduino
Deux fonctions posent problème : celle d'initialisation du port usb (powerOn) de la plateforme ainsi que celle qui permet de détecter la connexion d'un téléphone (isConnected).

== Séance 22 (12/01) ==
Le problème des fonction powerOn et isConnected a été résolu en réalité les soucis venaient du fait que le port usb n'était pas initialisé dans le programme test et il y avait également un délai trop long (200s) à la fin de la fonction powerOn.

=Préparation téléphones=
== Commun ==
* Suivre ce tuto pour pouvoir tester els applciations directement sur le telephone : http://developer.android.com/guide/developing/device.html j'ai utilisé celui ci : http://bzed.de/posts/2009/05/howto_set_android_developer_device_permissions_with_udev/

=== Soucis de com.android.future.usb.accessory.jar ===
xml : [https://projets-imasc.polytech-lille.net:40000/mediawiki/index.php?title=Google_ADK_et_wearable_computing/android.hardware.usb.accessory.xml android.hardware.usb.accessory.xml]

jar : [http://www.mirorii.com/fichier/8/444186/com-android-future-usb-accessory-jar.html com.android.future.usb.accessory.jar]

su
mount -o remount,rw -t yaffs2 /dev/block/mtdblock4 /system
cp /sdcard/com.android.future.usb.accessory.jar /system/framework
chmod 655 /system/framework/com.android.future.usb.accessory.jar
vi /etc/permissions/android.hardware.usb.accessory.xml
chmod 655 /etc/permissions/android.hardware.usb.accessory.xml
mount -o ro,remount -t yaffs2 /dev/block/mtdblock4 /system

manipulation légèrement différente pour le motorola defy:

mount -o remount,rw -t ext3 /dev/block/mmsblk1p21 /system
cp com.android.future.usb.accessory.jar /system/framework
chmod 644 /system/framework/com.android.future.usb.accessory.jar
cp android.hardware.usb.accessory.xml /etc/permissions
chmod 644 /etc/permissions/android.hardware.usb.accessory.xml
mount -o ro,remount -t ext3 /dev/block/mmsblk1p21 /system
---------> reboot pour que la librairie soit prise en compte.

==Milestone 2 (droid2)==
Passage en 2.3.4 : http://forum.xda-developers.com/showthread.php?t=1169038
Compte google : imapolytech@gmail.com (mot de passe = mot de passe habituel "root")

==Motorola Defy==
Passage en 2.3.4 : http://forum.frandroid.com/topic/51780-rom-cyanogen-7-rc15/ (gingerbreak incompatible avec android 2.1 : utilisation de z4root => failed, nécessite un passage à froyo via Windows avec le logiciel Motorola Software Update)
Compte google : defypolytechima@gmail.com

= Arduino =
==Hardware==
*liste des pins pour le microprocesseur ATmega2560 
http://arduino.cc/en/Hacking/PinMapping2560
*exemple de programmation avec AVR 
http://hlt.media.mit.edu/wiki/pmwiki.php?n=Main.AVRProgrammingAdvanced
*exemple de code arduino en C pour communiquer via le port série 
http://todbot.com/blog/2006/12/06/arduino-serial-c-code-to-talk-to-arduino/
*présentation arduinoboardADK 
http://www.arduino.cc/en/Main/ArduinoBoardADK
*code source led qui clignote pour Atmega328p (commande pour compiler avec avr-gcc et uploader avecavrdude) 
http://balau82.wordpress.com/2011/03/29/programming-arduino-uno-in-pure-c/
*code source led qui clignote atmega168 
http://www.javiervalcarce.eu/wiki/Program_Arduino_with_AVR-GCC
*code source pour USB Host: MAX3421E 
http://code.google.com/p/microbridge/source/browse/trunk/src/mcu/?r=20#mcu

== Xbee ==

Utilisation du channel 15 ( sous minicom -s "+++" -> "ATCH15" -> "ATCH" pour verifier -> "ATWR" pour sauvegarder -> ATCN pour quitter la modif
=== Configuration===

*http://arduino.cc/en/Guide/ArduinoXbeeShield

== C ==
===Compilation ===
*[[:Fichier:Makefile.jpg|Makefile de Mr Vantroys]] points à veririer : MCU, CFLAG et DUDE
*[http://www.robgray.com/temp/makefile Makefile plus imposant]

==Divers==
=== Connexion root pour lancer l'IDE arduino===
ssh -X -lroot localhost

= Android =
== Création apk ==
Le certificat contenant les clef de cryptage des apk se situe dans le repertoire /home/pifou/.android/keystore_signature_apk de tutur02. Les mots de passe sont ceux les mots de passe root habituels.

== Version App Coachoid ==

* [http://www.mirorii.com/fichier/91/456089/DemoKit_0-3-1-apk.html DemoKit 0.3.1] : Appli de test d'envoi d'1 bit avec un BPM voulu. ([http://www.mirorii.com/fichier/46/456090/DemoKit_0-3-1-zip.html sources])
* [http://www.mirorii.com/fichier/45/460974/Coachoid_0-4-apk.html Coachoid 0.4] : Application présentation pre-soutenance.
**Lecture musiques
**Lecture d'un BPM dans les tags de la musique
**Envoi des BPMs à l'accessoire.

Google ADK et wearable computing

2012-01-11T16:37:05Z

Cdesravi : /* Séance 20 (05/01) */

=Présentation=

'''Contexte:''' Développement d'extension pour Android

Android dispose d'un protocole facilitant la connexion de périphériques sur les téléphones et les tablets
http://developer.android.com/guide/topics/usb/adk.html
A l'heure actuelle, il existe quelques kit de développement, mais peu d'extension existent. L'objectif du projet consiste à réaliser plusieurs cartes d'extensions. Ci-après la liste des premières cartes à réaliser,
Les étudiants pourront ensuite proposer leurs propres extensions:

- Support XBee (comme pour les Arduino)

- Support RFID

- Support vêtement intelligent pour la danse (suite du projet IMA4SC)

-...

=Réalisation=

==Séance 1 (5/10/2011)==

Prise en main des téléphones et du sujet, mis à jour des téléphones vers 2.3.4.

==Séance 2 (10/10/2011)==

Fin de mise à jour des téléphones vers 2.3.4 et 2.3.5.

==Séance 3 (11/10/2011)==
Installation de Android SDK
: -http://developer.android.com/sdk/installing.html
:: -http://developer.android.com/sdk/requirements.html
::: -installation de Eclipse Galileo
::: -installation du plugin ADT http://developer.android.com/sdk/eclipse-adt.html

Problèmes rencontrés et solutions apportées:

lien https de dl-ssl.google.com ne fonctionne pas: remplacement du https en http
NB: pour le STEP 4 de http://developer.android.com/sdk/installing.html => http forcé dans les paramètres du SDK Manager

== Séance 4(18/10/2011)==
Test de l'installation DemoKit de l'ADK.

== Séance 5(2/11/2011)==
Définition des tâches principales et répartition:

*lecture de la musique par le téléphone (application Android), détection des BPM (Matlab) => Nicolas
*envoi des infos BPM à l'arduino (extraction des metadatas et envoi) => Nicolas
*transmission des BPM via Zigbee au T-shirt => Catherine

*Test liaison telephone <-> Arduino : affichage message sur terminal serie (arduino) lors de l'appui sur un interrupteur sur le telephone.
* Exploration des datasheet du Arduino pour trouver la correspondance des Port en C avec les broches.

===Problèmes rencontrés===
*Manque de certains fichiers qui permettent la communication USB sur les téléphones.
*Incompatibilité du programme Arduino de démonstration => programmation en C

== Séance 6 (04/11/2011) ==
Début des tâches séparées.

* début création application android simple avec un seul bouton qui permet l'envoi d'un seul bit sur le port usb lorsqu'il est appuyé.
* prise en main du makefile pour la compilation directe en C pour arduino

== Séance 7 ( 07/11 ) ==
* App: Mise en place bouton d'envoi de bit et Slider de selection de BPM pour simulation : interface ok, mais pas connecté.

* [[Fichier:C360 2011-11-0816-01-14.jpg|200px|thumb|right|led qui clignote]] Arduino : Finalisation clignotage de LED en C, et mise en place d'AVR pour eclipse.

== Séance 8 ( 8/11 ) ==
[[Fichier:App01_test_bpm.png|200px|thumb|right|application de test avec un envoi à 124 BPM]]
* Finalisation interface de l'application de test et début d'intégration de l'ADK pour communiquer avec la board.
* headers et codes source C pour le connecteur usb de la carte trouvés il ne reste qu'à tranposer le header AndroidAccessory.cpp en .c et adapter le header.

== Séance 9 (14/11) ==

* Mise en place de la connectivité avec les accessoires sur l'application de test. Reste à tester sur l'arduino.

== Séance 10 (15/11) ==

* L'application communique bien avec le circuit arduino. Début de mise en place d'un tâche périodique pour envoyer un bit régulièrement suivant le BPM.

* Traduction en C des librairies.

== Séance 11 (18/11) ==
* Tâche périodique d'envoi de Beat mise en place. Mais soucis de prise en compte des modifications lors du slide ( trop de changements d'états en peu de temps...). ( aide : http://www.developpez.net/forums/d669466/c-cpp/outils-c-cpp/visual-cpp/mfc/interception-levt-mousedown-slider/ et http://stackoverflow.com/questions/937313/android-basic-gesture-detection )
* Traduction en C de la librairie AndroidAccessory.c

== Séance 12 (21/11) ==

* Finalisation de l'application de test avec l'envoi periodique de Beat ( 1 binaire) en choisissant la fréquence grâce au slider. Création de l'[http://www.mirorii.com/fichier/91/456089/DemoKit_0-3-1-apk.html apk associé DemoKit 0.3.1] ([http://www.mirorii.com/fichier/46/456090/DemoKit_0-3-1-zip.html sources]).
* Poursuite de la traduction en C.

== Séance 13 (22/11) ==

* Test de l'application avec les XBee (configuration de ceux-ci), et test avec le T-shirt du projet de l'année dernière avec succès.
* Début de l'application Coachoid v4.0 = application finale de lecture de musique & co. ( http://developer.android.com/guide/topics/media/mediaplayer.html )
* Les sources trouvées sur Internet se sont révélées être incomplètes et trop complexes à utiliser. Adaptation en C des sources C++ fournies avec l'ADK
** codes source inchangés: ch9.h, Max3421e_constants.h
** codes source en cours d'adaptation: Usb.h,Max3421e.h, Max3421e.c, Usb.c
** codes source restant à adapter: AndroidAccessory.cpp, AndroidAccessory.h

Il y aura la fonction digitalWrite à réécrire également.

== Séance 14 (28/11) ==

* Suite de l'adaptation des sources C++ en C:
** codes sources adaptés: Max3421e.h, Max3421e.c
** codes source en cours d'adaptation: Usb.h, Usb.c
** codes source restant à adapter: AndroidAccessory.cpp, AndroidAccessory.h, fonction digitalWrite de la librairie Wiring
* Mise en place de la recherche des musiques du telephone, affichage en list et début d'implementation des intéractions avec les musiques.

== Séance 15 (29/11) ==

* Lecture basique de musique fonctionnel avec barre progression et selection de musique
* Suite et fin de l'adaptation des sources C++ en C:
* Déboggage des sources C

== Séance 16 (30/11) ==

* Suite du déboggage des sources C
* Finitions de la liste (avec enchainement, bouton play-pause)

== Séance 17 (1/12) ==

* Mise en avant de la musique joué
* Lecture des tag des mp3 grâce à http://www.jthink.net/jaudiotagger/
* Fin du déboggage des sources
* Début du développement d'un programme test

== Séance 18 (5/12) ==
* Test inclusion de l'information de BPM dans les tags de la musique. Tests Réussi
* Recherche de solution pour prendre le bpm de chaque musique ( http://stackoverflow.com/questions/79445/beats-per-minute-from-real-time-audio-input http://www.streamhead.com/easy-bpm-calculation-in-java/ http://bpmdj.yellowcouch.org/ & http://jorgenmodin.net/index_html/archive/2010/07/23/counting-bpm-beats-per-minute-on-linux/weblogentry_view#1315989621 )
* deboggage des sources terminé, développement d'un programme test

== Séance 19 (04/01) ==
* Exploration du calcul du BPM instantanéement. Exploration de la solution http://www.streamhead.com/easy-bpm-calculation-in-java/ qui donne des résultats cohérents.
* Recherche d'autres outils de calcul pour avoir des référance de BPM.

== Séance 20 (05/01) ==
* Débuggage des sources C pour Arduino

== Séance 21 (11/01) ==
* Premier programme de test de connexion d'un téléphone à la plateforme Arduino
Deux fonctions posent problème : celle d'initialisation du port usb (powerOn) de la plateforme ainsi que celle qui permet de détecter la connexion d'un téléphone (isConnected).

=Préparation téléphones=
== Commun ==
* Suivre ce tuto pour pouvoir tester els applciations directement sur le telephone : http://developer.android.com/guide/developing/device.html j'ai utilisé celui ci : http://bzed.de/posts/2009/05/howto_set_android_developer_device_permissions_with_udev/

=== Soucis de com.android.future.usb.accessory.jar ===
xml : [https://projets-imasc.polytech-lille.net:40000/mediawiki/index.php?title=Google_ADK_et_wearable_computing/android.hardware.usb.accessory.xml android.hardware.usb.accessory.xml]

jar : [http://www.mirorii.com/fichier/8/444186/com-android-future-usb-accessory-jar.html com.android.future.usb.accessory.jar]

su
mount -o remount,rw -t yaffs2 /dev/block/mtdblock4 /system
cp /sdcard/com.android.future.usb.accessory.jar /system/framework
chmod 655 /system/framework/com.android.future.usb.accessory.jar
vi /etc/permissions/android.hardware.usb.accessory.xml
chmod 655 /etc/permissions/android.hardware.usb.accessory.xml
mount -o ro,remount -t yaffs2 /dev/block/mtdblock4 /system

manipulation légèrement différente pour le motorola defy:

mount -o remount,rw -t ext3 /dev/block/mmsblk1p21 /system
cp com.android.future.usb.accessory.jar /system/framework
chmod 644 /system/framework/com.android.future.usb.accessory.jar
cp android.hardware.usb.accessory.xml /etc/permissions
chmod 644 /etc/permissions/android.hardware.usb.accessory.xml
mount -o ro,remount -t ext3 /dev/block/mmsblk1p21 /system
---------> reboot pour que la librairie soit prise en compte.

==Milestone 2 (droid2)==
Passage en 2.3.4 : http://forum.xda-developers.com/showthread.php?t=1169038
Compte google : imapolytech@gmail.com (mot de passe = mot de passe habituel "root")

==Motorola Defy==
Passage en 2.3.4 : http://forum.frandroid.com/topic/51780-rom-cyanogen-7-rc15/ (gingerbreak incompatible avec android 2.1 : utilisation de z4root => failed, nécessite un passage à froyo via Windows avec le logiciel Motorola Software Update)
Compte google : defypolytechima@gmail.com

= Arduino =
==Hardware==
*liste des pins pour le microprocesseur ATmega2560 
http://arduino.cc/en/Hacking/PinMapping2560
*exemple de programmation avec AVR 
http://hlt.media.mit.edu/wiki/pmwiki.php?n=Main.AVRProgrammingAdvanced
*exemple de code arduino en C pour communiquer via le port série 
http://todbot.com/blog/2006/12/06/arduino-serial-c-code-to-talk-to-arduino/
*présentation arduinoboardADK 
http://www.arduino.cc/en/Main/ArduinoBoardADK
*code source led qui clignote pour Atmega328p (commande pour compiler avec avr-gcc et uploader avecavrdude) 
http://balau82.wordpress.com/2011/03/29/programming-arduino-uno-in-pure-c/
*code source led qui clignote atmega168 
http://www.javiervalcarce.eu/wiki/Program_Arduino_with_AVR-GCC
*code source pour USB Host: MAX3421E 
http://code.google.com/p/microbridge/source/browse/trunk/src/mcu/?r=20#mcu

== Xbee ==

Utilisation du channel 15 ( sous minicom -s "+++" -> "ATCH15" -> "ATCH" pour verifier -> "ATWR" pour sauvegarder -> ATCN pour quitter la modif
=== Configuration===

*http://arduino.cc/en/Guide/ArduinoXbeeShield

== C ==
===Compilation ===
*[[:Fichier:Makefile.jpg|Makefile de Mr Vantroys]] points à veririer : MCU, CFLAG et DUDE
*[http://www.robgray.com/temp/makefile Makefile plus imposant]

==Divers==
=== Connexion root pour lancer l'IDE arduino===
ssh -X -lroot localhost

= Android =
== Création apk ==
Le certificat contenant les clef de cryptage des apk se situe dans le repertoire /home/pifou/.android/keystore_signature_apk de tutur02. Les mots de passe sont ceux les mots de passe root habituels.

== Version App Coachoid ==

* [http://www.mirorii.com/fichier/91/456089/DemoKit_0-3-1-apk.html DemoKit 0.3.1] : Appli de test d'envoi d'1 bit avec un BPM voulu. ([http://www.mirorii.com/fichier/46/456090/DemoKit_0-3-1-zip.html sources])
* [http://www.mirorii.com/fichier/45/460974/Coachoid_0-4-apk.html Coachoid 0.4] : Application présentation pre-soutenance.
**Lecture musiques
**Lecture d'un BPM dans les tags de la musique
**Envoi des BPMs à l'accessoire.

Google ADK et wearable computing

2012-01-11T16:31:26Z

Cdesravi : /* Séance 19 (04/01) */

=Présentation=

'''Contexte:''' Développement d'extension pour Android

Android dispose d'un protocole facilitant la connexion de périphériques sur les téléphones et les tablets
http://developer.android.com/guide/topics/usb/adk.html
A l'heure actuelle, il existe quelques kit de développement, mais peu d'extension existent. L'objectif du projet consiste à réaliser plusieurs cartes d'extensions. Ci-après la liste des premières cartes à réaliser,
Les étudiants pourront ensuite proposer leurs propres extensions:

- Support XBee (comme pour les Arduino)

- Support RFID

- Support vêtement intelligent pour la danse (suite du projet IMA4SC)

-...

=Réalisation=

==Séance 1 (5/10/2011)==

Prise en main des téléphones et du sujet, mis à jour des téléphones vers 2.3.4.

==Séance 2 (10/10/2011)==

Fin de mise à jour des téléphones vers 2.3.4 et 2.3.5.

==Séance 3 (11/10/2011)==
Installation de Android SDK
: -http://developer.android.com/sdk/installing.html
:: -http://developer.android.com/sdk/requirements.html
::: -installation de Eclipse Galileo
::: -installation du plugin ADT http://developer.android.com/sdk/eclipse-adt.html

Problèmes rencontrés et solutions apportées:

lien https de dl-ssl.google.com ne fonctionne pas: remplacement du https en http
NB: pour le STEP 4 de http://developer.android.com/sdk/installing.html => http forcé dans les paramètres du SDK Manager

== Séance 4(18/10/2011)==
Test de l'installation DemoKit de l'ADK.

== Séance 5(2/11/2011)==
Définition des tâches principales et répartition:

*lecture de la musique par le téléphone (application Android), détection des BPM (Matlab) => Nicolas
*envoi des infos BPM à l'arduino (extraction des metadatas et envoi) => Nicolas
*transmission des BPM via Zigbee au T-shirt => Catherine

*Test liaison telephone <-> Arduino : affichage message sur terminal serie (arduino) lors de l'appui sur un interrupteur sur le telephone.
* Exploration des datasheet du Arduino pour trouver la correspondance des Port en C avec les broches.

===Problèmes rencontrés===
*Manque de certains fichiers qui permettent la communication USB sur les téléphones.
*Incompatibilité du programme Arduino de démonstration => programmation en C

== Séance 6 (04/11/2011) ==
Début des tâches séparées.

* début création application android simple avec un seul bouton qui permet l'envoi d'un seul bit sur le port usb lorsqu'il est appuyé.
* prise en main du makefile pour la compilation directe en C pour arduino

== Séance 7 ( 07/11 ) ==
* App: Mise en place bouton d'envoi de bit et Slider de selection de BPM pour simulation : interface ok, mais pas connecté.

* [[Fichier:C360 2011-11-0816-01-14.jpg|200px|thumb|right|led qui clignote]] Arduino : Finalisation clignotage de LED en C, et mise en place d'AVR pour eclipse.

== Séance 8 ( 8/11 ) ==
[[Fichier:App01_test_bpm.png|200px|thumb|right|application de test avec un envoi à 124 BPM]]
* Finalisation interface de l'application de test et début d'intégration de l'ADK pour communiquer avec la board.
* headers et codes source C pour le connecteur usb de la carte trouvés il ne reste qu'à tranposer le header AndroidAccessory.cpp en .c et adapter le header.

== Séance 9 (14/11) ==

* Mise en place de la connectivité avec les accessoires sur l'application de test. Reste à tester sur l'arduino.

== Séance 10 (15/11) ==

* L'application communique bien avec le circuit arduino. Début de mise en place d'un tâche périodique pour envoyer un bit régulièrement suivant le BPM.

* Traduction en C des librairies.

== Séance 11 (18/11) ==
* Tâche périodique d'envoi de Beat mise en place. Mais soucis de prise en compte des modifications lors du slide ( trop de changements d'états en peu de temps...). ( aide : http://www.developpez.net/forums/d669466/c-cpp/outils-c-cpp/visual-cpp/mfc/interception-levt-mousedown-slider/ et http://stackoverflow.com/questions/937313/android-basic-gesture-detection )
* Traduction en C de la librairie AndroidAccessory.c

== Séance 12 (21/11) ==

* Finalisation de l'application de test avec l'envoi periodique de Beat ( 1 binaire) en choisissant la fréquence grâce au slider. Création de l'[http://www.mirorii.com/fichier/91/456089/DemoKit_0-3-1-apk.html apk associé DemoKit 0.3.1] ([http://www.mirorii.com/fichier/46/456090/DemoKit_0-3-1-zip.html sources]).
* Poursuite de la traduction en C.

== Séance 13 (22/11) ==

* Test de l'application avec les XBee (configuration de ceux-ci), et test avec le T-shirt du projet de l'année dernière avec succès.
* Début de l'application Coachoid v4.0 = application finale de lecture de musique & co. ( http://developer.android.com/guide/topics/media/mediaplayer.html )
* Les sources trouvées sur Internet se sont révélées être incomplètes et trop complexes à utiliser. Adaptation en C des sources C++ fournies avec l'ADK
** codes source inchangés: ch9.h, Max3421e_constants.h
** codes source en cours d'adaptation: Usb.h,Max3421e.h, Max3421e.c, Usb.c
** codes source restant à adapter: AndroidAccessory.cpp, AndroidAccessory.h

Il y aura la fonction digitalWrite à réécrire également.

== Séance 14 (28/11) ==

* Suite de l'adaptation des sources C++ en C:
** codes sources adaptés: Max3421e.h, Max3421e.c
** codes source en cours d'adaptation: Usb.h, Usb.c
** codes source restant à adapter: AndroidAccessory.cpp, AndroidAccessory.h, fonction digitalWrite de la librairie Wiring
* Mise en place de la recherche des musiques du telephone, affichage en list et début d'implementation des intéractions avec les musiques.

== Séance 15 (29/11) ==

* Lecture basique de musique fonctionnel avec barre progression et selection de musique
* Suite et fin de l'adaptation des sources C++ en C:
* Déboggage des sources C

== Séance 16 (30/11) ==

* Suite du déboggage des sources C
* Finitions de la liste (avec enchainement, bouton play-pause)

== Séance 17 (1/12) ==

* Mise en avant de la musique joué
* Lecture des tag des mp3 grâce à http://www.jthink.net/jaudiotagger/
* Fin du déboggage des sources
* Début du développement d'un programme test

== Séance 18 (5/12) ==
* Test inclusion de l'information de BPM dans les tags de la musique. Tests Réussi
* Recherche de solution pour prendre le bpm de chaque musique ( http://stackoverflow.com/questions/79445/beats-per-minute-from-real-time-audio-input http://www.streamhead.com/easy-bpm-calculation-in-java/ http://bpmdj.yellowcouch.org/ & http://jorgenmodin.net/index_html/archive/2010/07/23/counting-bpm-beats-per-minute-on-linux/weblogentry_view#1315989621 )
* deboggage des sources terminé, développement d'un programme test

== Séance 19 (04/01) ==
* Exploration du calcul du BPM instantanéement. Exploration de la solution http://www.streamhead.com/easy-bpm-calculation-in-java/ qui donne des résultats cohérents.
* Recherche d'autres outils de calcul pour avoir des référance de BPM.

== Séance 20 (05/01) ==
* Débuggage des sources C pour Arduino

=Préparation téléphones=
== Commun ==
* Suivre ce tuto pour pouvoir tester els applciations directement sur le telephone : http://developer.android.com/guide/developing/device.html j'ai utilisé celui ci : http://bzed.de/posts/2009/05/howto_set_android_developer_device_permissions_with_udev/

=== Soucis de com.android.future.usb.accessory.jar ===
xml : [https://projets-imasc.polytech-lille.net:40000/mediawiki/index.php?title=Google_ADK_et_wearable_computing/android.hardware.usb.accessory.xml android.hardware.usb.accessory.xml]

jar : [http://www.mirorii.com/fichier/8/444186/com-android-future-usb-accessory-jar.html com.android.future.usb.accessory.jar]

su
mount -o remount,rw -t yaffs2 /dev/block/mtdblock4 /system
cp /sdcard/com.android.future.usb.accessory.jar /system/framework
chmod 655 /system/framework/com.android.future.usb.accessory.jar
vi /etc/permissions/android.hardware.usb.accessory.xml
chmod 655 /etc/permissions/android.hardware.usb.accessory.xml
mount -o ro,remount -t yaffs2 /dev/block/mtdblock4 /system

manipulation légèrement différente pour le motorola defy:

mount -o remount,rw -t ext3 /dev/block/mmsblk1p21 /system
cp com.android.future.usb.accessory.jar /system/framework
chmod 644 /system/framework/com.android.future.usb.accessory.jar
cp android.hardware.usb.accessory.xml /etc/permissions
chmod 644 /etc/permissions/android.hardware.usb.accessory.xml
mount -o ro,remount -t ext3 /dev/block/mmsblk1p21 /system
---------> reboot pour que la librairie soit prise en compte.

==Milestone 2 (droid2)==
Passage en 2.3.4 : http://forum.xda-developers.com/showthread.php?t=1169038
Compte google : imapolytech@gmail.com (mot de passe = mot de passe habituel "root")

==Motorola Defy==
Passage en 2.3.4 : http://forum.frandroid.com/topic/51780-rom-cyanogen-7-rc15/ (gingerbreak incompatible avec android 2.1 : utilisation de z4root => failed, nécessite un passage à froyo via Windows avec le logiciel Motorola Software Update)
Compte google : defypolytechima@gmail.com

= Arduino =
==Hardware==
*liste des pins pour le microprocesseur ATmega2560 
http://arduino.cc/en/Hacking/PinMapping2560
*exemple de programmation avec AVR 
http://hlt.media.mit.edu/wiki/pmwiki.php?n=Main.AVRProgrammingAdvanced
*exemple de code arduino en C pour communiquer via le port série 
http://todbot.com/blog/2006/12/06/arduino-serial-c-code-to-talk-to-arduino/
*présentation arduinoboardADK 
http://www.arduino.cc/en/Main/ArduinoBoardADK
*code source led qui clignote pour Atmega328p (commande pour compiler avec avr-gcc et uploader avecavrdude) 
http://balau82.wordpress.com/2011/03/29/programming-arduino-uno-in-pure-c/
*code source led qui clignote atmega168 
http://www.javiervalcarce.eu/wiki/Program_Arduino_with_AVR-GCC
*code source pour USB Host: MAX3421E 
http://code.google.com/p/microbridge/source/browse/trunk/src/mcu/?r=20#mcu

== Xbee ==

Utilisation du channel 15 ( sous minicom -s "+++" -> "ATCH15" -> "ATCH" pour verifier -> "ATWR" pour sauvegarder -> ATCN pour quitter la modif
=== Configuration===

*http://arduino.cc/en/Guide/ArduinoXbeeShield

== C ==
===Compilation ===
*[[:Fichier:Makefile.jpg|Makefile de Mr Vantroys]] points à veririer : MCU, CFLAG et DUDE
*[http://www.robgray.com/temp/makefile Makefile plus imposant]

==Divers==
=== Connexion root pour lancer l'IDE arduino===
ssh -X -lroot localhost

= Android =
== Création apk ==
Le certificat contenant les clef de cryptage des apk se situe dans le repertoire /home/pifou/.android/keystore_signature_apk de tutur02. Les mots de passe sont ceux les mots de passe root habituels.

== Version App Coachoid ==

* [http://www.mirorii.com/fichier/91/456089/DemoKit_0-3-1-apk.html DemoKit 0.3.1] : Appli de test d'envoi d'1 bit avec un BPM voulu. ([http://www.mirorii.com/fichier/46/456090/DemoKit_0-3-1-zip.html sources])
* [http://www.mirorii.com/fichier/45/460974/Coachoid_0-4-apk.html Coachoid 0.4] : Application présentation pre-soutenance.
**Lecture musiques
**Lecture d'un BPM dans les tags de la musique
**Envoi des BPMs à l'accessoire.

Google ADK et wearable computing

2011-12-05T10:49:52Z

Cdesravi : /* Séance 17 (1/12) */

Google ADK et wearable computing

2011-12-05T10:49:38Z

Cdesravi : /* Séance 18 (5/12) */

Google ADK et wearable computing

2011-12-01T10:42:17Z

Cdesravi : /* Séance 17 (1/12) */

Google ADK et wearable computing

2011-11-30T15:51:31Z

Cdesravi : /* Séance 15 (30/11) */

Google ADK et wearable computing

2011-11-30T15:51:10Z

Cdesravi : /* Séance 15 (29/11) */

Google ADK et wearable computing

2011-11-30T15:36:58Z

Cdesravi : /* Séance 15 (29/11) */

Google ADK et wearable computing

2011-11-28T10:41:30Z

Cdesravi : /* Séance 13 (22/11) */

Google ADK et wearable computing

2011-11-28T09:55:07Z

Cdesravi : /* Séance 13 (22/11) */

Google ADK et wearable computing

2011-11-22T16:32:56Z

Cdesravi : /* Séance 13 (22/11) */

Google ADK et wearable computing

2011-11-08T16:08:26Z

Cdesravi : /* Séance 7 ( 07/11 ) */

Fichier:C360 2011-11-0816-01-14.jpg

2011-11-08T16:04:58Z

Cdesravi : led qui clignote

led qui clignote

Google ADK et wearable computing

2011-11-08T15:59:09Z

Cdesravi : /* Séance 8 ( 8/11 ) */

Google ADK et wearable computing

2011-11-08T15:11:25Z

Cdesravi : /* Hardware */

Google ADK et wearable computing

2011-11-08T14:32:55Z

Cdesravi : /* Hardware */

Google ADK et wearable computing

2011-11-02T16:33:02Z

Cdesravi : /* Arduino */

Google ADK et wearable computing

2011-11-02T15:24:06Z

Cdesravi : /* Séance 5(2/11/2011) */

Google ADK et wearable computing

2011-11-02T15:23:50Z

Cdesravi : /* Séance 4(18/10/2011) */

Google ADK et wearable computing

2011-11-02T15:12:33Z

Cdesravi : /* Problèmes rencontrés */

Google ADK et wearable computing

2011-10-18T12:32:15Z

Cdesravi : /* Soucis de com.android.future.usb.accessory.jar */

Google ADK et wearable computing

2011-10-18T12:30:41Z

Cdesravi : /* Soucis de com.android.future.usb.accessory.jar */

Google ADK et wearable computing

2011-10-12T14:55:24Z

Cdesravi : /* Réalisation */

Google ADK et wearable computing

2011-10-12T14:39:01Z

Cdesravi : /* Motorola Defy */

Google ADK et wearable computing

2011-10-05T16:07:24Z

Cdesravi : /* Séance 1 (5/10/2012) */

Google ADK et wearable computing

2011-10-05T16:01:15Z

Cdesravi : /* Séance 1 (5/10/2012) */

Google ADK et wearable computing

2011-10-05T15:18:05Z

Cdesravi : /* Séance 1 (5/10/2012) */

Google ADK et wearable computing

2011-10-05T15:17:51Z

Cdesravi : /* Présentation */

Google ADK et wearable computing

2011-10-05T11:40:42Z

Cdesravi : Page créée avec « =Présentation= '''Contexte:''' Développement d'extension pour Android Android dispose d'un protocole facilitant la connexion de périphériques sur les téléphones et le... »

Coach Dance

2011-05-12T16:34:31Z

Cdesravi : /* Séances Bonus */

[[Image:salsa.jpg|right|thumb]]
= 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) [http://www.selectronic.fr/article.asp?article_ref_entier=11.1142-9999];
* -> 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

<big>'''Etapes prévues:'''</big>

;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 : 
<ul>
<li/>Mise en place du programme Altium : conception du schematic (indique quels composants de la nanoboard utiliser) et d'un code C simple.
<li/>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.
</ul>

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

;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
<ul>
<li/>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.
<li/>Je m'aide d'un programme exemple fourni avec le soft Altium Designer
<li/>Probleme : les valeurs retournées par l'enregistrement ne sont pas satisfaisantes.
</ul>

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

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
<ul>
<li/>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)
<li/>Je décide d'utiliser directement l'exemple d'Altium et de le modifier pour mon projet
</ul>

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

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===
Arduino

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 : 
<ul>
<li/>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.
<li/>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.
</ul>

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

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 :
[[Fichier:Coeff.jpg|200px|thumb|right|Affichage de 300 coefficients. Une 50aine est utile]]
<ul>
<li/>Implémentation d'un filtre à réponse impulsionnelle finie (RIF).
<li/>Pour l'instant je filtre les fréquences entre 250 et 350Hz (fréquences de la caisse claire environ).
<li/>Pour cela, je regarde chez moi sur le logiciel de calcul scilab les coefficients d'un tel filtre :
<ul>
<li/>Filtre passe bande,
<li/>Fréquence de coupure haute : 350Hz,
<li/>Fréquence de coupure basse : 250Hz,
<li/>Échantillonnage à 2000Hz (ça devrait suffire), sur 8 bits.
</ul>
<li/>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.
<li/>Je peux donc en séance projet implémenter mon code avec 50 coefficients.
</ul>

Choix de l'algorithme :
<ul>
<li/>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.
<li/>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).
<li/>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).
<li/>Je recommence avec 50 nouveaux échantillons, ad infinitum.
<li/>É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.
</ul>

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

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 des éléments 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===
Arduino

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
Câblage du Lilypad reporté à des séances ultérieures

Plateforme Altium :
<ul>
<li/>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.
<li/>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.
<li/>Je remet en question la bande passante de mon filtre, elle est peut être trop large et trop haute en fréquence.
</ul>

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

Problème de pause entre chaque cycle de vibrations

Plateforme Altium :
[[Fichier:Coeff.jpg|200px|thumb|right|150 coefficients pour coller au gabarit du filtre]]
<ul>
<li/>Je décide de changer mes coefficients pour qu'ils correspondent à un nouveau type de filtre :
<ul>
<li/>Filtre passe bande toujours
<li/>fréquence de coupure haute 80Hz
<li/>fréquence de coupure basse 50Hz
<li/>Même échantillonnage à 2000Hz sur 8 bits
</ul>
<li/>Il me faut cette fois ci 150 échantillons environ.
<li/>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.
</ul
>Résultat :
<ul>
<li/>Les données reçues en sortie de filtre me laissent toujours perplexe :
<li/>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).
<li/>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.
</ul>

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

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 :
<ul>
<li/>Je décide de ré-examiner mes valeurs reçues dès l'enregistrement audio.
<li/>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.
<li/>Je met en place une fonction qui me renvoie ces données sur des entiers non signés.
</ul>

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

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) - 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 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) .

Plateforme Altium :
[[Fichier:Illustration_wiki.jpg|300px|thumb|right|changement de l'échelle pour l'échantillonage]]
<ul>
<li/>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.
<li/>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).
<li/>Poursuite des tests.
</ul>

===Quatorzième Séance (7/04/2011) -- 2h===
Arduino
[[Fichier:Schéma_cablage_coach_danse.png|600px|center|Schéma de câblage des éléments Lilypad]]

début de couture des éléments Lilypad sur le t-shirt

Plateforme Altium :
[[Fichier:Filtre.jpg|300px|thumb|right|Apparition d'une basse au début ?]]
<ul>
<li/>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.
</ul>

===Quinzième Séance (11/04/2011) -- 2h===

Plateforme Altium :
<ul>
<li/>Réalisation de nouveaux tests. Le filtrage semble fonctionner (les valeurs retournées lorsqu'il n'y a pas de basses sont presque nulles, et augmentent lorsqu'il y en a - pour un volume sonore donné). Mais il reste très difficile de détecter les basses en soi lorsqu'elles arrivent
<li/>Mise en place de l'envoi d'un signal +5V ainsi que l'affichage des leds lors de la détection d'une basse. Reste à détecter la basse en question....
</ul>

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

voici le t-shirt après quelques coutures:
[[Fichier:Couture_debut.jpg|400px|center]]

Plateforme Altium :
<ul>
<li/>Poursuite des tests, toujours dans le but de déterminer une basse de manière explicite...
<li/>J'encode les informations binaires sur 32 bits au lieu de 8bits, mais cela n'apporte pas plus de résultats. Même la qualité lecture par la nanoboard n'en est pas grandement affectée.
<li/>Je pense déterminer le principal problème : le temps de filtrage (calcul de 150 valeurs qui nécessitent chacune 150 multiplications => au moins 22500 opérations) est trop long par rapport au temps de lecture, peut être que trop d'informations sont perdues entre deux filtrages
</ul>

===Séances Bonus ===
Arduino :

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]]

Plateforme Altium :
<ul>
<li/>Je change mon code, certaines valeurs n'étaient pas effacées après traitement, ce qui faussait le résultat après plusieurs secondes de filtrage.
<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 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 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>

 
[[Fichier:Signal.png|400px|thumb|right|signal filtré]]
Au final j'arrive à détecter des beats, mais il reste deux points noirs :
<ul>
<li/>Tous ne s'affichent pas, quelques uns ne doivent pas être enregistrés du fait du temps de filtrage
<li/>Ceux qui arrivent à s'afficher le font avec quelques dixièmes de seconde de latence.
</ul>

Fichier:Tshirt final.jpg

2011-05-12T16:32:21Z

Cdesravi :

Coach Dance

2011-05-11T22:55:27Z

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

[[Image:salsa.jpg|right|thumb]]
= 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) [http://www.selectronic.fr/article.asp?article_ref_entier=11.1142-9999];
* -> 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

<big>'''Etapes prévues:'''</big>

;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 : 
<ul>
<li/>Mise en place du programme Altium : conception du schematic (indique quels composants de la nanoboard utiliser) et d'un code C simple.
<li/>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.
</ul>

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

;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
<ul>
<li/>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.
<li/>Je m'aide d'un programme exemple fourni avec le soft Altium Designer
<li/>Probleme : les valeurs retournées par l'enregistrement ne sont pas satisfaisantes.
</ul>

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

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
<ul>
<li/>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)
<li/>Je décide d'utiliser directement l'exemple d'Altium et de le modifier pour mon projet
</ul>

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

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===
Arduino

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 : 
<ul>
<li/>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.
<li/>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.
</ul>

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

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 :
[[Fichier:Coeff.jpg|200px|thumb|right|Affichage de 300 coefficients. Une 50aine est utile]]
<ul>
<li/>Implémentation d'un filtre à réponse impulsionnelle finie (RIF).
<li/>Pour l'instant je filtre les fréquences entre 250 et 350Hz (fréquences de la caisse claire environ).
<li/>Pour cela, je regarde chez moi sur le logiciel de calcul scilab les coefficients d'un tel filtre :
<ul>
<li/>Filtre passe bande,
<li/>Fréquence de coupure haute : 350Hz,
<li/>Fréquence de coupure basse : 250Hz,
<li/>Échantillonnage à 2000Hz (ça devrait suffire), sur 8 bits.
</ul>
<li/>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.
<li/>Je peux donc en séance projet implémenter mon code avec 50 coefficients.
</ul>

Choix de l'algorithme :
<ul>
<li/>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.
<li/>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).
<li/>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).
<li/>Je recommence avec 50 nouveaux échantillons, ad infinitum.
<li/>É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.
</ul>

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

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 des éléments 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===
Arduino

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
Câblage du Lilypad reporté à des séances ultérieures

Plateforme Altium :
<ul>
<li/>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.
<li/>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.
<li/>Je remet en question la bande passante de mon filtre, elle est peut être trop large et trop haute en fréquence.
</ul>

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

Problème de pause entre chaque cycle de vibrations

Plateforme Altium :
[[Fichier:Coeff.jpg|200px|thumb|right|150 coefficients pour coller au gabarit du filtre]]
<ul>
<li/>Je décide de changer mes coefficients pour qu'ils correspondent à un nouveau type de filtre :
<ul>
<li/>Filtre passe bande toujours
<li/>fréquence de coupure haute 80Hz
<li/>fréquence de coupure basse 50Hz
<li/>Même échantillonnage à 2000Hz sur 8 bits
</ul>
<li/>Il me faut cette fois ci 150 échantillons environ.
<li/>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.
</ul
>Résultat :
<ul>
<li/>Les données reçues en sortie de filtre me laissent toujours perplexe :
<li/>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).
<li/>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.
</ul>

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

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 :
<ul>
<li/>Je décide de ré-examiner mes valeurs reçues dès l'enregistrement audio.
<li/>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.
<li/>Je met en place une fonction qui me renvoie ces données sur des entiers non signés.
</ul>

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

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) - 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 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) .

Plateforme Altium :
[[Fichier:Illustration_wiki.jpg|300px|thumb|right|changement de l'échelle pour l'échantillonage]]
<ul>
<li/>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.
<li/>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).
<li/>Poursuite des tests.
</ul>

===Quatorzième Séance (7/04/2011) -- 2h===
Arduino
[[Fichier:Schéma_cablage_coach_danse.png|600px|center|Schéma de câblage des éléments Lilypad]]

début de couture des éléments Lilypad sur le t-shirt

Plateforme Altium :
[[Fichier:Filtre.jpg|300px|thumb|right|Apparition d'une basse au début ?]]
<ul>
<li/>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.
</ul>

===Quinzième Séance (11/04/2011) -- 2h===

Plateforme Altium :
<ul>
<li/>Réalisation de nouveaux tests. Le filtrage semble fonctionner (les valeurs retournées lorsqu'il n'y a pas de basses sont presque nulles, et augmentent lorsqu'il y en a - pour un volume sonore donné). Mais il reste très difficile de détecter les basses en soi lorsqu'elles arrivent
<li/>Mise en place de l'envoi d'un signal +5V ainsi que l'affichage des leds lors de la détection d'une basse. Reste à détecter la basse en question....
</ul>

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

voici le t-shirt après quelques coutures:
[[Fichier:Couture_debut.jpg|400px|center]]

Plateforme Altium :
<ul>
<li/>Poursuite des tests, toujours dans le but de déterminer une basse de manière explicite...
<li/>J'encode les informations binaires sur 32 bits au lieu de 8bits, mais cela n'apporte pas plus de résultats. Même la qualité lecture par la nanoboard n'en est pas grandement affectée.
<li/>Je pense déterminer le principal problème : le temps de filtrage (calcul de 150 valeurs qui nécessitent chacune 150 multiplications => au moins 22500 opérations) est trop long par rapport au temps de lecture, peut être que trop d'informations sont perdues entre deux filtrages
</ul>

===Séances Bonus ===
Arduino :

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.

Plateforme Altium :
<ul>
<li/>Je change mon code, certaines valeurs n'étaient pas effacées après traitement, ce qui faussait le résultat après plusieurs secondes de filtrage.
<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 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 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>

 
[[Fichier:Signal.png|400px|thumb|right|signal filtré]]
Au final j'arrive à détecter des beats, mais il reste deux points noirs :
<ul>
<li/>Tous ne s'affichent pas, quelques uns ne doivent pas être enregistrés du fait du temps de filtrage
<li/>Ceux qui arrivent à s'afficher le font avec quelques dixièmes de seconde de latence.
</ul>

Coach Dance

2011-05-04T22:30:44Z

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

[[Image:salsa.jpg|right|thumb]]
= 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) [http://www.selectronic.fr/article.asp?article_ref_entier=11.1142-9999];
* -> 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

<big>'''Etapes prévues:'''</big>

;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 : 
<ul>
<li/>Mise en place du programme Altium : conception du schematic (indique quels composants de la nanoboard utiliser) et d'un code C simple.
<li/>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.
</ul>

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

;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
<ul>
<li/>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.
<li/>Je m'aide d'un programme exemple fourni avec le soft Altium Designer
<li/>Probleme : les valeurs retournées par l'enregistrement ne sont pas satisfaisantes.
</ul>

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

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
<ul>
<li/>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)
<li/>Je décide d'utiliser directement l'exemple d'Altium et de le modifier pour mon projet
</ul>

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

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===
Arduino

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 : 
<ul>
<li/>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.
<li/>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.
</ul>

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

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 :
[[Fichier:Coeff.jpg|200px|thumb|right|Affichage de 300 coefficients. Une 50aine est utile]]
<ul>
<li/>Implémentation d'un filtre à réponse impulsionnelle finie (RIF).
<li/>Pour l'instant je filtre les fréquences entre 250 et 350Hz (fréquences de la caisse claire environ).
<li/>Pour cela, je regarde chez moi sur le logiciel de calcul scilab les coefficients d'un tel filtre :
<ul>
<li/>Filtre passe bande,
<li/>Fréquence de coupure haute : 350Hz,
<li/>Fréquence de coupure basse : 250Hz,
<li/>Échantillonnage à 2000Hz (ça devrait suffire), sur 8 bits.
</ul>
<li/>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.
<li/>Je peux donc en séance projet implémenter mon code avec 50 coefficients.
</ul>

Choix de l'algorithme :
<ul>
<li/>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.
<li/>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).
<li/>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).
<li/>Je recommence avec 50 nouveaux échantillons, ad infinitum.
<li/>É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.
</ul>

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

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 des éléments 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===
Arduino

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
Câblage du Lilypad reporté à des séances ultérieures

Plateforme Altium :
<ul>
<li/>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.
<li/>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.
<li/>Je remet en question la bande passante de mon filtre, elle est peut être trop large et trop haute en fréquence.
</ul>

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

Problème de pause entre chaque cycle de vibrations

Plateforme Altium :
[[Fichier:Coeff.jpg|200px|thumb|right|150 coefficients pour coller au gabarit du filtre]]
<ul>
<li/>Je décide de changer mes coefficients pour qu'ils correspondent à un nouveau type de filtre :
<ul>
<li/>Filtre passe bande toujours
<li/>fréquence de coupure haute 80Hz
<li/>fréquence de coupure basse 50Hz
<li/>Même échantillonnage à 2000Hz sur 8 bits
</ul>
<li/>Il me faut cette fois ci 150 échantillons environ.
<li/>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.
</ul
>Résultat :
<ul>
<li/>Les données reçues en sortie de filtre me laissent toujours perplexe :
<li/>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).
<li/>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.
</ul>

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

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 :
<ul>
<li/>Je décide de ré-examiner mes valeurs reçues dès l'enregistrement audio.
<li/>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.
<li/>Je met en place une fonction qui me renvoie ces données sur des entiers non signés.
</ul>

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

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).
[[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) .

Plateforme Altium :
[[Fichier:Illustration_wiki.jpg|300px|thumb|right|changement de l'échelle pour l'échantillonage]]
<ul>
<li/>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.
<li/>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).
<li/>Poursuite des tests.
</ul>

===Quatorzième Séance (7/04/2011) -- 2h===
Arduino
[[Fichier:Schéma_cablage_coach_danse.png|600px|center|Schéma de câblage des éléments Lilypad]]

début de couture des éléments Lilypad sur le t-shirt

Plateforme Altium :
[[Fichier:Filtre.jpg|300px|thumb|right|Apparition d'une basse au début ?]]
<ul>
<li/>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.
</ul>

===Quinzième Séance (11/04/2011) -- 2h===

Plateforme Altium :
<ul>
<li/>Réalisation de nouveaux tests. Le filtrage semble fonctionner (les valeurs retournées lorsqu'il n'y a pas de basses sont presque nulles, et augmentent lorsqu'il y en a - pour un volume sonore donné). Mais il reste très difficile de détecter les basses en soi lorsqu'elles arrivent
<li/>Mise en place de l'envoi d'un signal +5V ainsi que l'affichage des leds lors de la détection d'une basse. Reste à détecter la basse en question....
</ul>

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

voici le t-shirt après quelques coutures:
[[Fichier:Couture_debut.jpg|400px|center]]

Plateforme Altium :
<ul>
<li/>Poursuite des tests, toujours dans le but de déterminer une basse de manière explicite...
<li/>J'encode les informations binaires sur 32 bits au lieu de 8bits, mais cela n'apporte pas plus de résultats. Même la qualité lecture par la nanoboard n'en est pas grandement affectée.
<li/>Je pense déterminer le principal problème : le temps de filtrage (calcul de 150 valeurs qui nécessitent chacune 150 multiplications => au moins 22500 opérations) est trop long par rapport au temps de lecture, peut être que trop d'informations sont perdues entre deux filtrages
</ul>

===Séances Bonus ===
Arduino :

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.

Plateforme Altium :
<ul>
<li/>Je change mon code, certaines valeurs n'étaient pas effacées après traitement, ce qui faussait le résultat après plusieurs secondes de filtrage.
<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 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 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>

 
[[Fichier:Signal.png|400px|thumb|right|signal filtré]]
Au final j'arrive à détecter des beats, mais il reste deux points noirs :
<ul>
<li/>Tous ne s'affichent pas, quelques uns ne doivent pas être enregistrés du fait du temps de filtrage
<li/>Ceux qui arrivent à s'afficher le font avec quelques dixièmes de seconde de latence.
</ul>

Coach Dance

2011-05-04T22:27:21Z

Cdesravi : /* Séances Bonus */

[[Image:salsa.jpg|right|thumb]]
= 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) [http://www.selectronic.fr/article.asp?article_ref_entier=11.1142-9999];
* -> 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

<big>'''Etapes prévues:'''</big>

;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 : 
<ul>
<li/>Mise en place du programme Altium : conception du schematic (indique quels composants de la nanoboard utiliser) et d'un code C simple.
<li/>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.
</ul>

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

;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
<ul>
<li/>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.
<li/>Je m'aide d'un programme exemple fourni avec le soft Altium Designer
<li/>Probleme : les valeurs retournées par l'enregistrement ne sont pas satisfaisantes.
</ul>

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

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
<ul>
<li/>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)
<li/>Je décide d'utiliser directement l'exemple d'Altium et de le modifier pour mon projet
</ul>

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

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===
Arduino

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 : 
<ul>
<li/>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.
<li/>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.
</ul>

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

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 :
[[Fichier:Coeff.jpg|200px|thumb|right|Affichage de 300 coefficients. Une 50aine est utile]]
<ul>
<li/>Implémentation d'un filtre à réponse impulsionnelle finie (RIF).
<li/>Pour l'instant je filtre les fréquences entre 250 et 350Hz (fréquences de la caisse claire environ).
<li/>Pour cela, je regarde chez moi sur le logiciel de calcul scilab les coefficients d'un tel filtre :
<ul>
<li/>Filtre passe bande,
<li/>Fréquence de coupure haute : 350Hz,
<li/>Fréquence de coupure basse : 250Hz,
<li/>Échantillonnage à 2000Hz (ça devrait suffire), sur 8 bits.
</ul>
<li/>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.
<li/>Je peux donc en séance projet implémenter mon code avec 50 coefficients.
</ul>

Choix de l'algorithme :
<ul>
<li/>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.
<li/>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).
<li/>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).
<li/>Je recommence avec 50 nouveaux échantillons, ad infinitum.
<li/>É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.
</ul>

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

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 des éléments 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===
Arduino

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
Câblage du Lilypad reporté à des séances ultérieures

Plateforme Altium :
<ul>
<li/>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.
<li/>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.
<li/>Je remet en question la bande passante de mon filtre, elle est peut être trop large et trop haute en fréquence.
</ul>

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

Problème de pause entre chaque cycle de vibrations

Plateforme Altium :
[[Fichier:Coeff.jpg|200px|thumb|right|150 coefficients pour coller au gabarit du filtre]]
<ul>
<li/>Je décide de changer mes coefficients pour qu'ils correspondent à un nouveau type de filtre :
<ul>
<li/>Filtre passe bande toujours
<li/>fréquence de coupure haute 80Hz
<li/>fréquence de coupure basse 50Hz
<li/>Même échantillonnage à 2000Hz sur 8 bits
</ul>
<li/>Il me faut cette fois ci 150 échantillons environ.
<li/>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.
</ul
>Résultat :
<ul>
<li/>Les données reçues en sortie de filtre me laissent toujours perplexe :
<li/>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).
<li/>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.
</ul>

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

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 :
<ul>
<li/>Je décide de ré-examiner mes valeurs reçues dès l'enregistrement audio.
<li/>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.
<li/>Je met en place une fonction qui me renvoie ces données sur des entiers non signés.
</ul>

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

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).
[[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) .

Plateforme Altium :
[[Fichier:Illustration_wiki.jpg|300px|thumb|right|changement de l'échelle pour l'échantillonage]]
<ul>
<li/>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.
<li/>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).
<li/>Poursuite des tests.
</ul>

===Quatorzième Séance (7/04/2011) -- 2h===
Arduino
[[Fichier:Schéma_cablage_coach_danse.png|600px|center|Schéma de câblage des éléments Lilypad]]

début de couture des éléments Lilypad sur le t-shirt

Plateforme Altium :
[[Fichier:Filtre.jpg|300px|thumb|right|Apparition d'une basse au début ?]]
<ul>
<li/>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.
</ul>

===Quinzième Séance (11/04/2011) -- 2h===

Plateforme Altium :
<ul>
<li/>Réalisation de nouveaux tests. Le filtrage semble fonctionner (les valeurs retournées lorsqu'il n'y a pas de basses sont presque nulles, et augmentent lorsqu'il y en a - pour un volume sonore donné). Mais il reste très difficile de détecter les basses en soi lorsqu'elles arrivent
<li/>Mise en place de l'envoi d'un signal +5V ainsi que l'affichage des leds lors de la détection d'une basse. Reste à détecter la basse en question....
</ul>

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

Plateforme Altium :
<ul>
<li/>Poursuite des tests, toujours dans le but de déterminer une basse de manière explicite...
<li/>J'encode les informations binaires sur 32 bits au lieu de 8bits, mais cela n'apporte pas plus de résultats. Même la qualité lecture par la nanoboard n'en est pas grandement affectée.
<li/>Je pense déterminer le principal problème : le temps de filtrage (calcul de 150 valeurs qui nécessitent chacune 150 multiplications => au moins 22500 opérations) est trop long par rapport au temps de lecture, peut être que trop d'informations sont perdues entre deux filtrages
</ul>

===Séances Bonus ===
Arduino :

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.

Plateforme Altium :
<ul>
<li/>Je change mon code, certaines valeurs n'étaient pas effacées après traitement, ce qui faussait le résultat après plusieurs secondes de filtrage.
<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 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 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>

 
[[Fichier:Signal.png|400px|thumb|right|signal filtré]]
Au final j'arrive à détecter des beats, mais il reste deux points noirs :
<ul>
<li/>Tous ne s'affichent pas, quelques uns ne doivent pas être enregistrés du fait du temps de filtrage
<li/>Ceux qui arrivent à s'afficher le font avec quelques dixièmes de seconde de latence.
</ul>

Fichier:Couture debut.jpg

2011-05-04T22:21:13Z

Cdesravi :

Coach Dance

2011-05-04T22:12:48Z

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

[[Image:salsa.jpg|right|thumb]]
= 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) [http://www.selectronic.fr/article.asp?article_ref_entier=11.1142-9999];
* -> 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

<big>'''Etapes prévues:'''</big>

;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 : 
<ul>
<li/>Mise en place du programme Altium : conception du schematic (indique quels composants de la nanoboard utiliser) et d'un code C simple.
<li/>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.
</ul>

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

;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
<ul>
<li/>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.
<li/>Je m'aide d'un programme exemple fourni avec le soft Altium Designer
<li/>Probleme : les valeurs retournées par l'enregistrement ne sont pas satisfaisantes.
</ul>

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

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
<ul>
<li/>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)
<li/>Je décide d'utiliser directement l'exemple d'Altium et de le modifier pour mon projet
</ul>

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

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===
Arduino

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 : 
<ul>
<li/>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.
<li/>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.
</ul>

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

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 :
[[Fichier:Coeff.jpg|200px|thumb|right|Affichage de 300 coefficients. Une 50aine est utile]]
<ul>
<li/>Implémentation d'un filtre à réponse impulsionnelle finie (RIF).
<li/>Pour l'instant je filtre les fréquences entre 250 et 350Hz (fréquences de la caisse claire environ).
<li/>Pour cela, je regarde chez moi sur le logiciel de calcul scilab les coefficients d'un tel filtre :
<ul>
<li/>Filtre passe bande,
<li/>Fréquence de coupure haute : 350Hz,
<li/>Fréquence de coupure basse : 250Hz,
<li/>Échantillonnage à 2000Hz (ça devrait suffire), sur 8 bits.
</ul>
<li/>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.
<li/>Je peux donc en séance projet implémenter mon code avec 50 coefficients.
</ul>

Choix de l'algorithme :
<ul>
<li/>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.
<li/>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).
<li/>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).
<li/>Je recommence avec 50 nouveaux échantillons, ad infinitum.
<li/>É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.
</ul>

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

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 des éléments 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===
Arduino

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
Câblage du Lilypad reporté à des séances ultérieures

Plateforme Altium :
<ul>
<li/>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.
<li/>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.
<li/>Je remet en question la bande passante de mon filtre, elle est peut être trop large et trop haute en fréquence.
</ul>

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

Problème de pause entre chaque cycle de vibrations

Plateforme Altium :
[[Fichier:Coeff.jpg|200px|thumb|right|150 coefficients pour coller au gabarit du filtre]]
<ul>
<li/>Je décide de changer mes coefficients pour qu'ils correspondent à un nouveau type de filtre :
<ul>
<li/>Filtre passe bande toujours
<li/>fréquence de coupure haute 80Hz
<li/>fréquence de coupure basse 50Hz
<li/>Même échantillonnage à 2000Hz sur 8 bits
</ul>
<li/>Il me faut cette fois ci 150 échantillons environ.
<li/>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.
</ul
>Résultat :
<ul>
<li/>Les données reçues en sortie de filtre me laissent toujours perplexe :
<li/>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).
<li/>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.
</ul>

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

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 :
<ul>
<li/>Je décide de ré-examiner mes valeurs reçues dès l'enregistrement audio.
<li/>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.
<li/>Je met en place une fonction qui me renvoie ces données sur des entiers non signés.
</ul>

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

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).
[[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) .

Plateforme Altium :
[[Fichier:Illustration_wiki.jpg|300px|thumb|right|changement de l'échelle pour l'échantillonage]]
<ul>
<li/>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.
<li/>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).
<li/>Poursuite des tests.
</ul>

===Quatorzième Séance (7/04/2011) -- 2h===
Arduino
[[Fichier:Schéma_cablage_coach_danse.png|600px|center|Schéma de câblage des éléments Lilypad]]

début de couture des éléments Lilypad sur le t-shirt

Plateforme Altium :
[[Fichier:Filtre.jpg|300px|thumb|right|Apparition d'une basse au début ?]]
<ul>
<li/>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.
</ul>

===Quinzième Séance (11/04/2011) -- 2h===

Plateforme Altium :
<ul>
<li/>Réalisation de nouveaux tests. Le filtrage semble fonctionner (les valeurs retournées lorsqu'il n'y a pas de basses sont presque nulles, et augmentent lorsqu'il y en a - pour un volume sonore donné). Mais il reste très difficile de détecter les basses en soi lorsqu'elles arrivent
<li/>Mise en place de l'envoi d'un signal +5V ainsi que l'affichage des leds lors de la détection d'une basse. Reste à détecter la basse en question....
</ul>

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

Plateforme Altium :
<ul>
<li/>Poursuite des tests, toujours dans le but de déterminer une basse de manière explicite...
<li/>J'encode les informations binaires sur 32 bits au lieu de 8bits, mais cela n'apporte pas plus de résultats. Même la qualité lecture par la nanoboard n'en est pas grandement affectée.
<li/>Je pense déterminer le principal problème : le temps de filtrage (calcul de 150 valeurs qui nécessitent chacune 150 multiplications => au moins 22500 opérations) est trop long par rapport au temps de lecture, peut être que trop d'informations sont perdues entre deux filtrages
</ul>

===Séances Bonus ===

Plateforme Altium :
<ul>
<li/>Je change mon code, certaines valeurs n'étaient pas effacées après traitement, ce qui faussait le résultat après plusieurs secondes de filtrage.
<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 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 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>

 
[[Fichier:Signal.png|400px|thumb|right|signal filtré]]
Au final j'arrive à détecter des beats, mais il reste deux points noirs :
<ul>
<li/>Tous ne s'affichent pas, quelques uns ne doivent pas être enregistrés du fait du temps de filtrage
<li/>Ceux qui arrivent à s'afficher le font avec quelques dixièmes de seconde de latence.
</ul>

Fichier:Schéma cablage coach danse.png

2011-05-04T22:08:34Z

Cdesravi :

Coach Dance

2011-04-17T20:25:47Z

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

[[Image:salsa.jpg|right|thumb]]
= 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) [http://www.selectronic.fr/article.asp?article_ref_entier=11.1142-9999];
* -> 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

<big>'''Etapes prévues:'''</big>

;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 : 
<ul>
<li/>Mise en place du programme Altium : conception du schematic (indique quels composants de la nanoboard utiliser) et d'un code C simple.
<li/>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.
</ul>

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

;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
<ul>
<li/>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.
<li/>Je m'aide d'un programme exemple fourni avec le soft Altium Designer
<li/>Probleme : les valeurs retournées par l'enregistrement ne sont pas satisfaisantes.
</ul>

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

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
<ul>
<li/>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)
<li/>Je décide d'utiliser directement l'exemple d'Altium et de le modifier pour mon projet
</ul>

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

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===
Arduino

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 : 
<ul>
<li/>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.
<li/>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.
</ul>

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

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 :
[[Fichier:Coeff.jpg|200px|thumb|right|Affichage de 300 coefficients. Une 50aine est utile]]
<ul>
<li/>Implémentation d'un filtre à réponse impulsionnelle finie (RIF).
<li/>Pour l'instant je filtre les fréquences entre 250 et 350Hz (fréquences de la caisse claire environ).
<li/>Pour cela, je regarde chez moi sur le logiciel de calcul scilab les coefficients d'un tel filtre :
<ul>
<li/>Filtre passe bande,
<li/>Fréquence de coupure haute : 350Hz,
<li/>Fréquence de coupure basse : 250Hz,
<li/>Échantillonnage à 2000Hz (ça devrait suffire), sur 8 bits.
</ul>
<li/>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.
<li/>Je peux donc en séance projet implémenter mon code avec 50 coefficients.
</ul>

Choix de l'algorithme :
<ul>
<li/>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.
<li/>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).
<li/>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).
<li/>Je recommence avec 50 nouveaux échantillons, ad infinitum.
<li/>É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.
</ul>

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

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 des éléments 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===
Arduino

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
Câblage du Lilypad reporté à des séances ultérieures

Plateforme Altium :
<ul>
<li/>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.
<li/>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.
<li/>Je remet en question la bande passante de mon filtre, elle est peut être trop large et trop haute en fréquence.
</ul>

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

Problème de pause entre chaque cycle de vibrations

Plateforme Altium :
[[Fichier:Coeff.jpg|200px|thumb|right|150 coefficients pour coller au gabarit du filtre]]
<ul>
<li/>Je décide de changer mes coefficients pour qu'ils correspondent à un nouveau type de filtre :
<ul>
<li/>Filtre passe bande toujours
<li/>fréquence de coupure haute 80Hz
<li/>fréquence de coupure basse 50Hz
<li/>Même échantillonnage à 2000Hz sur 8 bits
</ul>
<li/>Il me faut cette fois ci 150 échantillons environ.
<li/>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.
</ul
>Résultat :
<ul>
<li/>Les données reçues en sortie de filtre me laissent toujours perplexe :
<li/>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).
<li/>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.
</ul>

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

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 :
<ul>
<li/>Je décide de ré-examiner mes valeurs reçues dès l'enregistrement audio.
<li/>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.
<li/>Je met en place une fonction qui me renvoie ces données sur des entiers non signés.
</ul>

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

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).
[[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) .

Plateforme Altium :
[[Fichier:Illustration_wiki.jpg|300px|thumb|right|changement de l'échelle pour l'échantillonage]]
<ul>
<li/>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.
<li/>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).
<li/>Poursuite des tests.
</ul>

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

début de couture des éléments Lilypad sur le t-shirt

Plateforme Altium :
[[Fichier:Filtre.jpg|300px|thumb|right|Apparition d'une basse au début ?]]
<ul>
<li/>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.
</ul>

===Quinzième Séance (11/04/2011) -- 2h===

Plateforme Altium :
<ul>
<li/>Réalisation de nouveaux tests. Le filtrage semble fonctionner (les valeurs retournées lorsqu'il n'y a pas de basses sont presque nulles, et augmentent lorsqu'il y en a - pour un volume sonore donné). Mais il reste très difficile de détecter les basses en soi lorsqu'elles arrivent
<li/>Mise en place de l'envoi d'un signal +5V ainsi que l'affichage des leds lors de la détection d'une basse. Reste à détecter la basse en question....
</ul>

===Seizième Séance (12/04/2011) -- 2h===

Fichier:Cycle de vibration.jpg

2011-04-17T20:19:17Z

Cdesravi :

Coach Dance

2011-04-17T20:18:08Z

Cdesravi : /* Avancement du projet */

[[Image:salsa.jpg|right|thumb]]
= 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) [http://www.selectronic.fr/article.asp?article_ref_entier=11.1142-9999];
* -> 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

<big>'''Etapes prévues:'''</big>

;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 : 
<ul>
<li/>Mise en place du programme Altium : conception du schematic (indique quels composants de la nanoboard utiliser) et d'un code C simple.
<li/>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.
</ul>

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

;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
<ul>
<li/>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.
<li/>Je m'aide d'un programme exemple fourni avec le soft Altium Designer
<li/>Probleme : les valeurs retournées par l'enregistrement ne sont pas satisfaisantes.
</ul>

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

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
<ul>
<li/>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)
<li/>Je décide d'utiliser directement l'exemple d'Altium et de le modifier pour mon projet
</ul>

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

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===
Arduino

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 : 
<ul>
<li/>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.
<li/>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.
</ul>

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

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 :
[[Fichier:Coeff.jpg|200px|thumb|right|Affichage de 300 coefficients. Une 50aine est utile]]
<ul>
<li/>Implémentation d'un filtre à réponse impulsionnelle finie (RIF).
<li/>Pour l'instant je filtre les fréquences entre 250 et 350Hz (fréquences de la caisse claire environ).
<li/>Pour cela, je regarde chez moi sur le logiciel de calcul scilab les coefficients d'un tel filtre :
<ul>
<li/>Filtre passe bande,
<li/>Fréquence de coupure haute : 350Hz,
<li/>Fréquence de coupure basse : 250Hz,
<li/>Échantillonnage à 2000Hz (ça devrait suffire), sur 8 bits.
</ul>
<li/>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.
<li/>Je peux donc en séance projet implémenter mon code avec 50 coefficients.
</ul>

Choix de l'algorithme :
<ul>
<li/>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.
<li/>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).
<li/>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).
<li/>Je recommence avec 50 nouveaux échantillons, ad infinitum.
<li/>É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.
</ul>

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

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 des éléments 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===
Arduino

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
Câblage du Lilypad reporté à des séances ultérieures

Plateforme Altium :
<ul>
<li/>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.
<li/>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.
<li/>Je remet en question la bande passante de mon filtre, elle est peut être trop large et trop haute en fréquence.
</ul>

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

Problème de pause entre chaque cycle de vibrations

Plateforme Altium :
[[Fichier:Coeff.jpg|200px|thumb|right|150 coefficients pour coller au gabarit du filtre]]
<ul>
<li/>Je décide de changer mes coefficients pour qu'ils correspondent à un nouveau type de filtre :
<ul>
<li/>Filtre passe bande toujours
<li/>fréquence de coupure haute 80Hz
<li/>fréquence de coupure basse 50Hz
<li/>Même échantillonnage à 2000Hz sur 8 bits
</ul>
<li/>Il me faut cette fois ci 150 échantillons environ.
<li/>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.
</ul
>Résultat :
<ul>
<li/>Les données reçues en sortie de filtre me laissent toujours perplexe :
<li/>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).
<li/>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.
</ul>

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

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 :
<ul>
<li/>Je décide de ré-examiner mes valeurs reçues dès l'enregistrement audio.
<li/>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.
<li/>Je met en place une fonction qui me renvoie ces données sur des entiers non signés.
</ul>

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

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).

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) .

Plateforme Altium :
[[Fichier:Illustration_wiki.jpg|300px|thumb|right|changement de l'échelle pour l'échantillonage]]
<ul>
<li/>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.
<li/>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).
<li/>Poursuite des tests.
</ul>

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

début de couture des éléments Lilypad sur le t-shirt

Plateforme Altium :
[[Fichier:Filtre.jpg|300px|thumb|right|Apparition d'une basse au début ?]]
<ul>
<li/>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.
</ul>

===Quinzième Séance (11/04/2011) -- 2h===

Plateforme Altium :
<ul>
<li/>Réalisation de nouveaux tests. Le filtrage semble fonctionner (les valeurs retournées lorsqu'il n'y a pas de basses sont presque nulles, et augmentent lorsqu'il y en a - pour un volume sonore donné). Mais il reste très difficile de détecter les basses en soi lorsqu'elles arrivent
<li/>Mise en place de l'envoi d'un signal +5V ainsi que l'affichage des leds lors de la détection d'une basse. Reste à détecter la basse en question....
</ul>

===Seizième Séance (12/04/2011) -- 2h===

Coach Dance

2011-04-17T20:09:03Z

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

[[Image:salsa.jpg|right|thumb]]
= 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) [http://www.selectronic.fr/article.asp?article_ref_entier=11.1142-9999];
* -> 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

<big>'''Etapes prévues:'''</big>

;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 : 
<ul>
<li/>Mise en place du programme Altium : conception du schematic (indique quels composants de la nanoboard utiliser) et d'un code C simple.
<li/>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.
</ul>

===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
<ul>
<li/>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.
<li/>Je m'aide d'un programme exemple fourni avec le soft Altium Designer
<li/>Probleme : les valeurs retournées par l'enregistrement ne sont pas satisfaisantes.
</ul>

===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
<ul>
<li/>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)
<li/>Je décide d'utiliser directement l'exemple d'Altium et de le modifier pour mon projet
</ul>

===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 : 
<ul>
<li/>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.
<li/>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.
</ul>

===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 :
[[Fichier:Coeff.jpg|200px|thumb|right|Affichage de 300 coefficients. Une 50aine est utile]]
<ul>
<li/>Implémentation d'un filtre à réponse impulsionnelle finie (RIF).
<li/>Pour l'instant je filtre les fréquences entre 250 et 350Hz (fréquences de la caisse claire environ).
<li/>Pour cela, je regarde chez moi sur le logiciel de calcul scilab les coefficients d'un tel filtre :
<ul>
<li/>Filtre passe bande,
<li/>Fréquence de coupure haute : 350Hz,
<li/>Fréquence de coupure basse : 250Hz,
<li/>Échantillonnage à 2000Hz (ça devrait suffire), sur 8 bits.
</ul>
<li/>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.
<li/>Je peux donc en séance projet implémenter mon code avec 50 coefficients.
</ul>

Choix de l'algorithme :
<ul>
<li/>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.
<li/>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).
<li/>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).
<li/>Je recommence avec 50 nouveaux échantillons, ad infinitum.
<li/>É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.
</ul>

===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 :
<ul>
<li/>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.
<li/>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.
<li/>Je remet en question la bande passante de mon filtre, elle est peut être trop large et trop haute en fréquence.
</ul>

===Onzième Séance (31/03/2011) -- 2h===
Problème de pause entre chaque cycle de vibrations

Plateforme Altium :
[[Fichier:Coeff.jpg|200px|thumb|right|150 coefficients pour coller au gabarit du filtre]]
<ul>
<li/>Je décide de changer mes coefficients pour qu'ils correspondent à un nouveau type de filtre :
<ul>
<li/>Filtre passe bande toujours
<li/>fréquence de coupure haute 80Hz
<li/>fréquence de coupure basse 50Hz
<li/>Même échantillonnage à 2000Hz sur 8 bits
</ul>
<li/>Il me faut cette fois ci 150 échantillons environ.
<li/>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.
</ul
>Résultat :
<ul>
<li/>Les données reçues en sortie de filtre me laissent toujours perplexe :
<li/>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).
<li/>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.
</ul>

===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 :
<ul>
<li/>Je décide de ré-examiner mes valeurs reçues dès l'enregistrement audio.
<li/>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.
<li/>Je met en place une fonction qui me renvoie ces données sur des entiers non signés.
</ul>

===Treizième Séance (5/04/2011) -- 4h===
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).

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. 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) .

Plateforme Altium :
[[Fichier:Illustration_wiki.jpg|300px|thumb|right|changement de l'échelle pour l'échantillonage]]
<ul>
<li/>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.
<li/>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).
<li/>Poursuite des tests.
</ul>

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

Plateforme Altium :
[[Fichier:Filtre.jpg|300px|thumb|right|Apparition d'une basse au début ?]]
<ul>
<li/>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.
</ul>

===Quinzième Séance (11/04/2011) -- 2h===

Plateforme Altium :
<ul>
<li/>Réalisation de nouveaux tests. Le filtrage semble fonctionner (les valeurs retournées lorsqu'il n'y a pas de basses sont presque nulles, et augmentent lorsqu'il y en a - pour un volume sonore donné). Mais il reste très difficile de détecter les basses en soi lorsqu'elles arrivent
<li/>Mise en place de l'envoi d'un signal +5V ainsi que l'affichage des leds lors de la détection d'une basse. Reste à détecter la basse en question....
</ul>

===Seizième Séance (12/04/2011) -- 2h===